On 8 Dec 2010, at 7:06 AM, Stephane Bortzmeyer wrote:

> 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.

We have removed this.

> 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.

I changed the reference to RFC 5198.

> "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/>.

I changed it to say "Basic Multilingual Plane"

> 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.

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

> 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?

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].

> 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).

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 <cheshire@apple.com>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org