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

[Dave Cridland <[e-mail]>]

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:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade