Fwd: Re: Server issues

[Neal McBurnett]

Sebastian posted a good response on the real issue at hand, so feel
free to ignore this post of mine unless you want to hear me
pontificate on why Informational != IETF_standard   :-)

I don't really have a well informed opinion on the topic of zeroconf
and/or LLMNR, despite having paid some attention to it.

On Tue, Nov 20, 2007 at 07:48:20PM -0500, Scott Kitterman wrote:
> IESG Note
> 
>    This document was originally intended for advancement as a Proposed
>    Standard, but the IETF did not achieve consensus on the approach.
>    The document has had significant review and input.  At time of
>    publication, early versions were implemented and deployed.

That is very helpful.  This particular "Informational" RFC has
had way more review than most.

Though see also "Status of This Memo":
http://tools.ietf.org/html/rfc4795
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind. 

> The lack of consensus (anyone can search the IETF main list for the
> last call discussion on this RFC, it was pretty extensive) was
> primarily over whether to use the mDNS or LLMNR protocols in the
> .local namespace.  Informational or not, it's a published RFC.  The
> distinction among Informational, Experimental, and Proposed Standard
> is significant within the IETF community, but in the wider internet
> world, I don't think people really know or care.

But having worked with standards for a few decades and with the IETF
since 1995 on and off, I strongly suggest that in general people
shouldn't treat Informational or Experimental protocols at all like
protocols on the standards track.  That is almost like comparing the
rantings of some congressman in the Congressional Record to a law that
is also published in the Congressional Record.

To quote the Tao of the IETF (itself Informational :-)
http://www.faqs.org/rfcs/rfc3160.html

  some people refer to Informational RFCs as "standards" even though
  the RFCs are not standards, usually to fool the gullible public
  about something that the person is selling or supporting.  When this
  happens, the debate about Informational RFCs is renewed.

Statistically speaking, most Informational RFCs may be interesting and
serious reading about good stuff.  And of course they are generally
way better than proprietary "industry standards", since they are
published to be read by anyone.  But they are intentionally not to be
treated as open standards.

> So currently we install and enable a system using an unstandarized protocol 
> that works in the same namespace with another protocol that fulfills 
> essentially the same purpose and that protocol is at least documented in an 
> (Informational) RFC.  The key point here is that the IETF picked one and it 
> isn't the one we use.

Note that the IETF asked the Zeroconf folks to also publish their
protocol, which is much more widely used, as Informational also.  So
in no way did the IETF finally "pick one" officially.

The working group that dealt with it, dnsext
(http://ietf.org/html.charters/dnsext-charter.html) did pick LLMNR,
and that is generally a pretty big vote of confidence in the IETF.
But I've seen enough of the debate to have serious question as to
whether there was much good reason to go the way the working group did
in terms of proposing LLMNR as their choice for a standard for last
call.  See e.g. the rather interesting comments of Stuart Cheshire (a
primary mDNS/DNS-SD proponent):

 http://www1.ietf.org/mail-archive/web/ietf/current/msg37340.html

 What happened was that the DNSEXT working group disagreed with me on
 the problem statement. I said, "Here's a proposed way to do simple
 effective service discovery using existing DNS record types." The
 DNSEXT working group said, "The DNS protocol is not to be used for
 service discovery. We forbid it, and furthermore, to prove the point,
 we're going to design a protocol of our own that superficially looks
 like yours but can't be used for service discovery."

Neal McBurnett                 http://mcburnett.org/neal/