Subject: [dnsext] Gen-ART review of draft-cheshire-dnsext-dns-sd-07.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Dec 2010 16:06:01 +0100

[Also sent to the gen-art mailing list but I think it is appropriate
to send a copy here.]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-cheshire-dnsext-dns-sd-07.txt
Reviewer: Stéphane Bortzmeyer <[email-masked]>
Review Date: 2010-12-06
IETF LC End Date: 2010-11-23
IESG Telechat date: Unknown

Summary:

The draft is long, containing a lot of interesting material, but not
always well organized. As a general rule, I am a big fan of
"rationale" sections, which let you know why a MUST or a SHOULD was
used. But, here, they are intermixed with the normative content and it
is often difficult to know when standard stops and background material
begins. Examples are sections 4.4 or 6.2.

In the same way, user interface discussions (section 4.2 for instance)
are very interesting and useful but should be more clearly separated
(may be in a distinct document).

It also raises a major issue when you put it in perspective with other
DNS-related documents: non-standard terminology and strange ways to
describe the rest of the DNS world. It does not seem suitable for a
Standards-Track document.

Major issues:

There are non-standard terms which may create confusion with existing
technologies. My main concern is with "unicast DNS". There is no such
thing as unicast DNS, there is the DNS and there are other protocols
(like LLMNR or Apple Bonjour name protocol) which are not DNS. Even
worse is "unicast DNS domain name" (unicast refers to a name
resolution method, but a name exists independently of a resolution
method).

Using "local", outside of the procedures of RFC 2606 and 2826 and
similar is a bad idea. I do not elaborate here since the problem is
actually in draft-cheshire-dnsext-multicastdns-12.txt.

The idea in section 7 of using _udp for every SRV records (but TCP) is
a bad one, which you cannot find in RFC 2782 which states clearly that
other values than _tcp and _udp can be used. The fact (section 18)
that there is no IANA registry for these values is not, in my opinion,
a sufficient reason.

The idea of "IANA secret registrations" (section 18) would be, it
seems, a first in the IETF world and should be rejected. The entire
point of IANA registries is to document publicly the *technical*
identifiers. Trademarks and marketing terms do not have to be in the
IANA registry and therefore do not need special rules for them.

Minor issues:

For name resolution on the local network, only mDNS (a misnomer since
it is not DNS) is mentioned, not LLMNR (RFC 4795) which seems it would
work as well.

Section 4.1 says that the name must be in NFC. Why not referring to
its subset defined in RFC 5198? Among the practical differences are
the fact that RFC 5198 handles the case of end-of-lines, which is
ignored by the draft.

"commonly-used 16-bit Unicode space" is a misnomer. If one wants to
talk about the Basic Multilingual Plane (which stores only a minority
of Unicode code points), it should use the standard term
<http://unicode.org/glossary/>.

The "standard DNS message size" is no longer 512 bytes since RFC 2671
(section 6.1). Yes, EDNS0 sometimes is blocked by broken middleboxes
but for a technique used only in local networks, this is not a too
serious issue.

It seems that the possibility of several TXT in a RRset (not several
strings in a TXT, which is covered in 6.1) is not mentioned. Is it
legal and, if yes, how to use it?

The advice of section 13.1 to stuff several other records (which may
be in different bailiwicks) in the DNS answer is at odds with security
practices (RFC 2181, section 5.4.1 and RFC 5452, section 6).

Nits/editorial comments:

Long quotes of existing RFCs (section 4.1) are unecessary since the
other RFCs are available elsewhere.

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 15 Dec 2010 23:56:12 -0800

> IANA registry and therefore do not need special rules for them.

We have removed this.

> the fact that RFC 5198 handles the case of end-of-lines, which is

I changed the reference to RFC 5198.

> <http://unicode.org/glossary/>.

I changed it to say "Basic Multilingual Plane"

> but for a technique used only in local networks, this is not a too

I removed the phrase "standard 512-byte DNS message"

> legal and, if yes, how to use it?

I have added this text explaining how multiple TXT records can be used:

    Generally speaking every DNS-SD service has exactly one TXT record.
    However it is possible for the DNS-SD advertising specification for
    a particular protocol to specify that it allows multiple TXT  
records.
    In this case, each TXT record describes a different variant of the
    same logical service, offered using the same underlying protocol on
    the same port, described by the same SRV record. The is very rare,
    and to date, of the many hundreds of registered DNS-SD service types
    [services], only one makes use of this capability, namely printing
    [BJP]. This is used when printers support more than one page
    description language, such as plain text, Adobe PostScript, or other
    proprietary page description language. When this is used, printers
    include two additional keys in each TXT records, 'qtotal', which
    specifies the total number of TXT records associated with this SRV
    record, and 'priority', which gives the printer's relative  
preference
    for this particular TXT record. Clients then select the most  
preferred
    TXT record suitable for the client's needs [BJP].

> practices (RFC 2181, section 5.4.1 and RFC 5452, section 6).

I have added this text:

    Note that while servers may choose to add these additional records
    for efficiency purposes, as with all DNS additional records it is
    the client's responsibility to determine whether it trusts them.
    Generally speaking stub resolves that talk to a single recursive  
name
    server for all their queries will trust all records they receive  
from
    that recursive name server. Recursive name servers that talk to
    multiple authoritate name servers should verify that any records  
they
    receive from a given authoritate name server are "in bailiwick" for
    that server, and ignore them if not.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org