Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I have read draft-cheshire-dnsext-multicastdns-08.  I have some
comments.  This is not an exhaustive or complete review, although I
have shared some previous observations with the authors of the
document.

First, I must emphasise that, while I currently serve as one of the
chairs of the DNS Extensions Working Group, I make my comments as an
individual and not as Chair.  Neither do I in any way speak for the
community or the Working Group.  I also want to emphasise that I was
not involved in the early history of this draft, and had no official
responsibilities of any sort to the DNSEXT WG when this draft came
under discussion there some years ago.

Given the long and painful history of the draft, and that the protocol
it documents is manifestly successful and in wide use, I think it
would be a disservice to interoperability if we did not publish it.
If for no other reason, I support its publication (under the terms of
the question put to us) as an Informational RFC.

I think there are sections of the text that could be cleaned up.
Leaving aside others' complaints about the number of Apple references
in the document, there is a querulousness to the text that is a little
jarring.  Sentences like "It is easy for those of us in the IETF
community who run our own name servers at home to forget that the
majority of computer users do not run their own name server and have
no easy way to create their own host names," despite their evident
truth and probable justification in light of some past comment on a
mailing list, just aren't needed in a protocol document.  If it were
up to me, I'd take that sort of thing out.  That said, I do not
withold my support on this basis.

The IANA Considerations section is a little coy in the way it notes
that the document reserves .local.  Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action.  If there is a strong reason to put this document
on the standards track, the use of .local is surely it.

I like the way the document emphasises that, in a multicast
environment, many of the assumptions one might make about uniqueness
are wrong.  I think this is quite right, and I hope clients and
implementers will take heed.  

The discussion of port 5353 vs. 53 is comprehensive without rehashing
the entire history of that debate.  (Contrast this with my previous
comment about querulous bits of the text.  One can outline the
background without sounding annoyed by snipers.)

I am unwilling right now to make an argument in favour or against
moving this document to the standards track.  I think there are
arguments to be constructed in both directions, but when I consider
the value to interoperability, it seems to me that getting something
published, even in a flawed way, is more important than picking
exactly the right document stream.

Best regards,

A
-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.