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 ajs@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf