Subject: Re: LLMNR consensus statement

From: Stuart Cheshire <[email-masked]>
Date: Thu, 16 Feb 2006 15:50:18 -0800

>We are sad we have to ask for this consensus position. Bernard has
>been an excellent document editor and we, the chairs and others
>involved, should have gauged the quorum for this work earlier, and at
>several stages of development. This is not the most elegant end of
>this process. If you think there are more elegant ways forward please
>let us know.
>
>Our apologies to Bernard and others that have been constructively and
>co-operatively working on this document.

I have great respect for Benard. We worked well together on RFC 3927, and 
I was never happy that in this instance we found ourselves on opposite 
sides of a debate concerning two documents that were very much like two 
twins separated at birth.

I view this as an opportunity to move forward productively, and I welcome 
the prospect of working constructively with Bernard and other interested 
parties to improve draft-cheshire-dnsext-multicastdns.txt. This gives us 
the chance to improve and enhance the protocol currently being used on 
tens of millions of deployed devices, rather than architecting a 
competing document which may well have gone nowhere.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Feb 2006 09:57:12 +0100

On Thu, Feb 16, 2006 at 03:50:18PM -0800,
 Stuart Cheshire <[email-masked]> wrote 
 a message of 31 lines which said:

> I welcome the prospect of working constructively with Bernard and
> other interested parties to improve
> draft-cheshire-dnsext-multicastdns.txt.

The SPF (Sender Policy Framework, for email authentication) people
were always turned down by the IETF when trying to push their protocol
as a RFC, with the reasoning that IETF is not here to "rubber stamp"
any external proprietary protocol, even widely deployed.

> the chance to improve and enhance the protocol currently being used
> on tens of millions of deployed devices, rather than architecting a

Is there somewhere IETF guidance about this issue? Basically, you
suggest that Apple's protocol should be approved by IETF, just because
of prior deployment, which may encourage other people to deploy first
(and think later), in the hope of using the same argument.

In working groups like MARID, there has been a lot of discussion about
the strength of the "prior deployment" argument but I do not remember
a clear conclusion.