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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote:
There have been a number of cases where things are not developed within the IETF
but are "out there".

Agreed.


Whether or not folk LIKE those schemes/the companies that promulgate them/the author(s)
/the document style/the weather is not really important.

You make it sound like I have some trivial personal axe to grind - I do not, although I readily agree that I do not like the document style. (And I wasn't the only one to raise this comment about dns-sd, the sister document).

Having an Informational RFC to describe these protocols or file formats is useful. If nothing else, it tells you what the heck is going on down the wire.

Right, this much I agree with. And if this was an isolated protocol, I would not be concerned with it at all - it is, as you imply, what Informational is *for* - well, modulo the marketing, anyway.

But there are, as I say, a number of standards-track protocols both in the IETF and other SDOs which depend on these two documents, just as was the case a year ago:

http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=44223&tid=1244548867

As it happens, the IETF documents haven't advanced - and I wonder if that's in part because mDNS and DNS-SD haven't been made standards-track.

I'm not arguing against the protocol's existence, and not against its documentation. I'm arguing that we should take the time to document it clearly, and ensure that it can be easily implemented in an interoperable manner from that documentation, and - potentially - make a handful of compatible changes where appropriate.

Burying it in a WG to try (and fail) to turn this into an IETF standards-track document is not helpful. I fear that someone will go postal if we do Zeroconf again. There has been Sooooo much history that it is simply not worth repeating the pain.
(I seem to recall discussions on this starting out @IETF-41 in LA,
 since which time it's in very wide use "out there" :).

So you're primary argument against this not being made a standards track document is that it's an awful lot of work, and that it's bound to fail anyway.

Well, I can't deny that it *is* a substantial amount of work, but given that this protocol is, as you point out, deployed in the wild, I'm not really sure this is a problem, and arguing the IETF shouldn't put documents on the standards track, with a working group, because it's a lot of work and might fail to produce a useful result does - to me, anyway - sound my irony alarm full blast. Isn't this what the IETF is *for*?

So I reiterate - I see no reason not to charter a working group to revise this specification (and dns-sd), and I would welcome such a group being chartered such that it cannot make any incompatible changes to the protocol.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]