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

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Nov 2009 08:41:18 -0700

Can someone walk me through the pro/cons of this being standards track  
vs informational?

Thanks, Cullen

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Nov 2009 16:20:20 +0000

On Wed Nov 18 15:41:18 2009, Cullen Jennings wrote:
> 
> Can someone walk me through the pro/cons of this being standards  
> track  vs informational?

Cons:

For one thing, it's a lot of work to make a specification like this  
up to the quality of the standards-track.

Some of the 20 or so mentions of Apple™ and its trademarks may be  
removed during the standardization work. It's much harder to get away  
with using apple.com™ for most of the example domains, for instance.

The standards track doesn't mean anything anymore. It's so last  
decade. mDNS™ only really needs an RFC number, and a couple of  
trendy (preferably French™-sounding) product names carefully placed  
in the document.

What if changes are demanded by those annoying DNS experts? That  
might break backwards compatibility with the existing deployment,  
starting from Apple™ Jaguar™ OS X™ 10™, in case I've not  
mentioned that in a few paragraphs.

Pros:

Only really annoying old stick-in-the-muds would think of anything  
positive to come out of making a consensus-driven, interoperable  
standards-track specification, which'd be almost completely out of  
the control of a single entity.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Dambier <[email-masked]>
Date: Wed, 18 Nov 2009 22:30:18 +0100

> Can someone walk me through the pro/cons of this being standards track

Apple supports it.
Linux supports it (mostly).
BSD supports it (mostly).

So half the world supports it.
When Microsoft too supports it, it is a standard.

I do support it (becomming a standard).

Well, making this a standard keeps people from building something
colliding with existing implementations.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

---

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Nov 2009 14:14:31 +0000

Since people thought I was merely being amusing, instead of also  
intending to make a point, let me rephrase in a dry, dull, and  
serious tone, so I'm no longer told it was "very amusing, but not  
much help".

There exist a few protocols based around mDNS and DNS-SD, in  
particular in combination, and the general high-level design of both  
protocols is essentially sound. These are sometimes standards-track  
specifications of the IETF - I seem to recall some of the SIP related  
protocols are DNS-SD/mDNS based. In other SDOs, there are also  
standards track specifications based around the combination, such as  
the XSF's XEP-0174 - http://www.xmpp.org/extensions/xep-0174.html -  
and these are also reliant on a stable, well-specified, protocol. To  
my mind, this implies that both specifications need to be standards  
track, if that status has any meaning at all - and I firmly believe  
it should and does.

Unfortunately, the specification of both of them suffers in,  
essentially, the same ways.

- They use RFC 2119 language in an informational specification, which  
at the least carries with it a strong implication that the intent is  
to specify a standard.

- They repeat the base specifications they refer to, and even in some  
cases contradict, for unclear benefit. (For example in mDNS, the  
mandatory requirement to use compression in the first label of an SRV  
record).

- A considerable amount of space is given over to Apple trademarks,  
which I confess to finding deeply irritating. mDNS is not nearly so  
bad as DNS-SD in this regard, but this still applies. I have no  
problem with acknowledging the input of Apple here, but there's a  
thin line between acknowledgement and outright product placement.

In summary, I think both specifications would derive enormous benefit  
from WG-level review and experienced specification-crafting. This  
need not result in any changes which are not backwards compatible -  
indeed, I find it unlikely given the levels of deployment that exist.

FWIW, I see no need to go through an extensive BOF process, and -  
again given the levels of deployment - I'd anticipate rapid progress  
through the standards-track ought to be possible.

Dave.

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 23 Nov 2009 00:17:45 +0000

Hi Cullen, folks,
  It seems to me ...
There have been a number of cases where things are not developed  
within the IETF
but are "out there".
Whether or not folk LIKE those schemes/the companies that promulgate  
them/the author(s)
/the document style/the weather is not really important.
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.
IF the IESG wants to tag on a comment that the described protocol/ 
format is broken
or conflicts with a more sensible IETF-anointed approach, it can and  
does.

I support this as an Informational document. I would like this  
description out now.
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" :).

Please can we ship this as an Informational, and soon?

all the best,
   Lawrence

On 18 Nov 2009, at 15:41, Cullen Jennings wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Nov 2009 18:55:21 -0700

+1 to Informational. Let's get this documentation out there in a stable
reference. That doesn't preclude publishing a standards-track version in
the future...

On 11/22/09 5:17 PM, Lawrence Conroy wrote:
> Hi Cullen, folks,
>  It seems to me ...
> There have been a number of cases where things are not developed within
> the IETF
> but are "out there".
> Having an Informational RFC to describe these protocols or file formats
> is useful.
> IF the IESG wants to tag on a comment that the described protocol/format
> is broken
> or conflicts with a more sensible IETF-anointed approach, it can and does.
> 
> There has been Sooooo much history that it is simply not worth repeating
> the pain.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Nov 2009 13:49:39 +0000

> There have been a number of cases where things are not developed   

Agreed.

> Whether or not folk LIKE those schemes/the companies that  
> promulgate  them/the author(s)

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).

> If nothing else, it tells you what the heck is going on down the  

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.

> document is not helpful. I fear that someone will go postal if we  
> do  Zeroconf again.

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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 23 Nov 2009 16:11:41 +0100

> group being chartered such that it cannot make any incompatible  

+1

Except that I'd put the compatibility requirement in terms of deployed 
code rather than the current draft. Mumble SRV RR mumble compression 
mumble. "The final RFC must be compatible with <a> version <b>, <c> 
version <d> and <e> version <f>, and if possible with other deployed 
implementations known to the WG" for some values of a-f.

Arnt

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Nov 2009 10:06:42 -0700

On 11/23/09 6:49 AM, Dave Cridland wrote:
> 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
> 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:
> 
> that's in part because mDNS and DNS-SD haven't been made standards-track.
> 
> 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.
> 
> 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*?
> 
> 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.

There are two separate actions that could be taken here:

a. Publish draft-cheshire-dnsext-multicastdns as an Informational RFC
(call it "mDNS 1.0" if that makes people happy).

b. Charter a WG to complete work on a standards-track protocol for the
same or similar functionality (call it "mDNS 1.1").

Are you in favor of a-and-b, or b-only?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Nov 2009 10:11:24 -0700

Pretty much all the emails I have received on this have suggested we should just go publish it now. To be clear, I was not talking about forming a WG to go do a standards track version of this. I was talking about clicking one flag in the data tracker and changing it from information to standards track and publishing the draft  "as is" as standards track. 

The consensus seems to be: this document is important to get publish soon and is used by many other standards. Because of this, this draft is too important to publish it as standards track and we should publish it as informational instead. Anyways, I'm convinced that having this as a RFC is important and decided that I, like most other people, could care less if it was experimental or full standard as that will be close to irrelevant for what interoperability this enables on the internet. 

>> Can someone walk me through the pro/cons of this being standards track vs informational?
>> 
>> Thanks, Cullen

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Nov 2009 14:47:04 +0900

Hello Cullen,

I have started reading draft-cheshire-dnsext-multicastdns for an Apps 
Area review. I also started asking myself the question of "standards 
track vs. informational". However, this was not in the general sense, 
but in regards to some very specific issues. In the general sense, I was 
assuming that this was Informational because it documented an existing 
practice and deployment by an existing company.

Where I wasn't at all sure about whether Informational was appropriate 
was things such as reserving the top-level domain name ".local" with 
ICANN (Section 3). Of course the IETF has the rigth to do this, but 
shouldn't this be done in a standards track or BCP document?

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Nov 2009 16:00:12 +0100

On Wed, Nov 18, 2009 at 06:07:17AM -0800,
 The IESG <[email-masked]> wrote 
 a message of 23 lines which said:

> - 'Multicast DNS '
>    <draft-cheshire-dnsext-multicastdns-08.txt> as an Informational RFC

I do not think that the publication of this document as it is would be
a good idea.

The main reason is that it reserves a Top-Level Domain (".local")
which is already used at many sites, without any sort of reasonable
process, except "we already decided to use it and deployed the code".

Unlike what the text of the I-D says in section 3.1, there is little
evidence that IETF can do so. Unless what happened with RFC 2606,
nothing indicates that IANA/ICANN or any other body agreed to the
"hijack".

The I-D also gives questionable advices such as using ".home" or
".lan" which are not (and for good reasons) in RFC 2606. 

The only reasons given in the current discussion on [email-masked] are
"it is already deployed" and "we need such a protocol for the
dentist's office".

The first one is weak: certainly, it should not be possible for any
company to have a RFC just by deploying a protocol is has unilaterally
conceived. The IETF is not a Patent Office: it *does* check the
applications.

Also, the I-D is not a pure description of a deployed protocol. For
instance, it says "it is even more important to use DNSSEC or other
security mechanisms to ensure that the response is trustworthy" while
the current implementations have no such mechanism.

The second reason is also questionable since IETF already has RFC
4795, which is not mentioned even once in the I-D we are discussing!

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Nov 2009 13:29:31 -0800

On Nov 19, 2009, at 06:14 , Dave Cridland wrote:
> 
> There exist a few protocols based around mDNS and DNS-SD, in particular in combination, and the general high-level design of both protocols is essentially sound. These are sometimes standards-track specifications of the IETF - I seem to recall some of the SIP related protocols are DNS-SD/mDNS based. In other SDOs, there are also standards track specifications based around the combination, such as the XSF's XEP-0174 - http://www.xmpp.org/extensions/xep-0174.html - and these are also reliant on a stable, well-specified, protocol. To my mind, this implies that both specifications need to be standards track, if that status has any meaning at all - and I firmly believe it should and does.

Chiming in to add another ongoing standards effort that would like to reference this document by its RFC number: the TC32-TG21 - Proxying Support for Sleep Modes program at ECMA International, which is now circulating a draft for TC postal vote.  See <http://www.ecma-international.org/memento/TC32-TG21-M.htm> for more information about this effort.

One reason to prefer a standards track document here would be to preempt procedural objections in ISO/IEC about references to informational category IETF documents, which have been known to arise from time to time in that body.  There is some concern in TC32-TG21 about such objections to ancillary citations of RFC 4795, which is *also* an informational category document.  It's possible ISO/IEC won't object to the informational status of either document, but we have a chance to preempt those objections now by publishing mDNS as standards-track.

That said, having an RFC number for an informational mDNS document-- in a small number of weeks-- would be orders of magnitude more preferable than not having it, and having to wait an indefinite period of time for a standards track RFC to be published, if that's what IETF decides to do.

To make the obvious explicit, I support publishing this document as an RFC without any further delay.

If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent.  However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document.

It should have been published years go, fergawdzakes.  Faster, please.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 30 Nov 2009 09:48:40 +0100

james woodyatt writes:
> If it could be published as standards-track, instead of informational, 
> *without* *any* *further* *delay*, that would be excellent. However, 
> I believe there is nothing to be gained for the Internet community by 
> any further delay in publishing this important document.
>

It's not difficult to get a standards-track RFC out quickly from this 
point. Unusual, yes, but not difficult. Mark Crispin did it in a week 
or so for RFC 4315 (another basically sound document with severe but 
superficial problems).

The document author/editor has to react to comments and fix issues 
promptly. That's all there really is to it.

Arnt

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 30 Nov 2009 10:38:04 -0800

> I do support it (becomming a standard).

Some additional data points:

Anyone using iTunes on Windows also has Multicast DNS on Windows,  
which is quite a lot of people.

And there are the hand-held devices like iPhones and Google Android  
phones, where peer-to-peer games and other network applications use  
Multicast DNS.

Also, other devices like network printers use Multicast DNS too. (If  
you have a network printer, click on the Bonjour button in the Safari  
sidebar and see if your printer's status and configuration web page  
appears. If you're on Windows, you can get Safari from <http:// 
www.apple.com/safari/>.)

And if you have a TiVo, they use Multicast DNS too.

These days, if you use computers at all, you've got to be trying  
*really* hard not to own or use some device that has Multicast DNS in  
it.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 30 Nov 2009 10:38:29 -0800

On 19 Nov, 2009, at 06:14, Dave Cridland wrote:

> particular in combination, and the general high-level design of  
> both protocols is essentially sound. These are sometimes standards- 
> track specifications of the IETF - I seem to recall some of the SIP  
> related protocols are DNS-SD/mDNS based. In other SDOs, there are  
> also standards track specifications based around the combination,  
> such as the XSF's XEP-0174 - http://www.xmpp.org/extensions/ 
> xep-0174.html - and these are also reliant on a stable, well- 
> specified, protocol. To my mind, this implies that both  
> specifications need to be standards track, if that status has any  
> meaning at all - and I firmly believe it should and does.

Thank you. I think you are right.

> ...

I would be happy to work with you in the next couple of weeks to de- 
cruft the document and get a cleaned up draft submitted before  
Christmas.

What you're seeing is the end result of a gradual accretion of text  
over the course of eight years since draft-00 in 2001. It was  
natural, especially in the early days, that many of the examples came  
from Apple products. Here and now, in 2009, if this is to be  
published as a Standards Track RFC, I don't have any problem with  
removing many or even all mentions of Apple and Apple products.

> again given the levels of deployment - I'd anticipate rapid  
> progress through the standards-track ought to be possible.

I agree.

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 30 Nov 2009 10:39:21 -0800

On 23 Nov, 2009, at 09:11, Cullen Jennings wrote:

> Pretty much all the emails I have received on this have suggested  
> we should just go publish it now. To be clear, I was not talking  
> about forming a WG to go do a standards track version of this. I  
> was talking about clicking one flag in the data tracker and  
> changing it from information to standards track and publishing the  
> draft "as is" as standards track.

I support this, with one modification: I don't think we need to  
commit to publishing this draft literally "as is".

People like Dave Cridland have pointed out legitimate style  
criticisms, which I'm happy to fix in the next couple of weeks.

As I'm sure you know (but others may not) a Standards-Track RFC  
doesn't need a Working Group. It's possible to have an Individual  
Submission Standards-Track RFC, subject to the IETF community  
reviewing it and finding it to be worthwhile, and this would not be  
the first time I've done that. Last year we published RFC 5227, "IPv4  
Address Conflict Detection", as an Individual Submission Standards- 
Track RFC.

I think Multicast DNS easily meets criteria for Proposed Standard. In  
fact, in terms of stability, maturity, deployment, number of  
independent implementations, etc., it easily meets criteria that for  
other protocols would qualify them for Draft Standard status.

When other Standards-Track RFCs and other standards bodies (ECMA,  
WiFi alliance, ISO/IEC, XMPP, etc.) need to reference Multicast DNS,  
having a Standards-Track document to reference helps avoid procedural  
objections.

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 30 Nov 2009 16:56:54 -0800

On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote:

> 90% of this proposal is equally relevant to the enterprise case.
> But the multicast part is not.

The document is called "Multicast DNS". Which parts of the document  
do you think do *not* relate to multicast?