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