Subject: Stop the process trolls ! Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Feb 2011 09:46:52 -0800

This protocol has established a legacy base, as in it is going to be a part of the infrastructure we have to work round for decades even if Apple abandon it tomorrow.

It is now futile to attempt modification of the protocol except in limited ways that do not impact the legacy base.

Therefore we need to have a description of the protocol as a standard used on the Internet.

If people here want to be jerks and make that process painful, they can. But they are damaging the organization in ways tbat they either do not understand or do not care about.

If IETF wants to be relevant, it has to give a timely response. Endless fillibustering with nits has to stop.

People have a choice in standards organizations. The IETF has no special position of control. If Stuart had waited for the IANA to issue his DNS codes, bonjour would never have deployed and he would be out of a job. And the only people who benefitted would be the process trolls.

I have a proposal in at the moment, CAA. I have a party that is going to release code before Prague. The expert review should take six weeks, it has taken twice that.

Now i am willing to solicit advice, but at some point the other party is going to release their code and tell me the RR they have decided to assign. 

If this organization wants to be involved in the development of the Internet the advice has to be timely. As it is the process trolls have reduced the role of the IETF to documenting what others do and grumbing about why the developers did not complete the correct obessiances in the correct order.

Ship it. Ship it now.

Sent from my iPad

On Nov 23, 2010, at 13:32, Doug Barton <[email-masked]> wrote:

> On 11/23/2010 13:17, Paul Hoffman wrote:
>> At 12:55 PM -0800 11/23/10, Doug Barton wrote:
>>> In the theoretical perfect world the reason for producing a spec is so that vendors can _create_ interoperable versions of the service. That motivation doesn't apply here, so one wonders what the time pressure is.
>> 
>> That is "a" reason, not "the" reason. Another is so that vendors can assure interoperability of their systems after they are deployed. Saying "you have to figure out how to interoperate with all other implementations" does not lead to that interoperability. A stable RFC can help greatly, as has been shown repeatedly in the IETF.
> 
> That's a motivation for creating the draft, yes. It's not a motivation for publishing the RFC before it's ready.
> 
> Please understand, I'm not saying "don't publish," I'm not even saying "fix _all_ the problems." I'm saying, "Fix the obvious, glaring protocol error that has potential to do more damage down the road, and while you're at it here are some other minor suggestions to improve the quality of the document if you choose to accept them. THEN publish the RFC."
> 
> And now I've repeated myself sufficiently so I will spare the list members any more responses to ad absurdum replies.
> 
> 
> Doug
> 
> -- 
> 
>    Nothin' ever doesn't change, but nothin' changes much.
>            -- OK Go
> 
>    Breadth of IT experience, and depth of knowledge in the DNS.
>    Yours for the right price.  :)  http://SupersetSolutions.com/
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 18 Feb 2011 13:10:33 -0500

> Therefore we need to have a description of the protocol as a standard used on the Internet.

Does not follow.   Having a description of the protocol, as it was deployed, documented is usually a good idea.   Having it as standard, not necessarily so.  There are a great many protocols which have "established a legacy base" which are not suitable for standardization.

> If people here want to be jerks and make that process painful, they can. But they are damaging the organization in ways tbat they either do not understand or do not care about.

The most effective way to damage the IETF, is to insist that the IETF endorse technically flawed protocols as standards.

> People have a choice in standards organizations. The IETF has no special position of control. If Stuart had waited for the IANA to issue his DNS codes, bonjour would never have deployed and he woul…

If the IETF has no special position of control, then it doesn't matter if IETF declines to standardize something.

Anytime I see someone making these kinds of arguments to support standardization of something, it tells me that there is very probably something seriously wrong with the proposal, and that at the very least it needs further scrutiny.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Feb 2011 15:08:54 -0500

Hi,

> I have a proposal in at the moment, CAA. I have a party that is going to release code before Prague. The expert review should take six weeks, it has taken twice that.

I want to apologize here, publicly to Phillip and those who are
waiting on this assignment.  I'm the chair who is supposed to be
managing that expert review, and ensuring that the expert returns in a
timely fashion.  I have obviously failed.

This is just a bureaucratic foul-up on my part, and I'm sorry for it.
I'm doing everything I can to get the review completed reasonably
quickly now.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 08:30:29 -0800

On Fri, Feb 18, 2011 at 10:10 AM, Keith Moore <[email-masked]>wrote:

> > This protocol has established a legacy base, as in it is going to be a
> part of the infrastructure we have to work round for decades even if Apple
> abandon it tomorrow.
> >
> > It is now futile to attempt modification of the protocol except in
> limited ways that do not impact the legacy base.
> >
> Does not follow.   Having a description of the protocol, as it was
> deployed, documented is usually a good idea.   Having it as standard, not
> necessarily so.  There are a great many protocols which have "established a
> legacy base" which are not suitable for standardization.

Internet Standards are what run on the Internet.

The reason that I keep proposing process and document changes is because I
would like the IETF to be more effective in playing a leadership role in
Internet Standards making.

But take a look at the events in Egypt and Tunisia. The events that are
beginning in Lybia and Bahrain. The Web was originally designed and deployed
in the aftermath of the year of miracles, 1989, the year the Berlin Wall and
the iron curtain fell.

The Web is bigger than one person or one organization.

So expecting to control its growth or development is as futile for us as for
anyone else.

Which if people think about it, is rather a good thing. If the IETF had the
ability to control the development of the Web, the tyrants and the dictators
who are murdering their own people as I write would be attacking the IETF as
well.

-- 
Website: http://hallambaker.com/

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Feb 2011 12:43:13 -0500

On Feb 19, 2011, at 11:30 AM, Phillip Hallam-Baker wrote:

> On Fri, Feb 18, 2011 at 10:10 AM, Keith Moore <[email-masked]> wrote:

Lots of things run on the Internet that are not standard.

> The reason that I keep proposing process and document changes is because I would like the IETF to be more effective in playing a leadership role in Internet Standards making.

Ideally, IETF's role is to provide advice that helps the Internet and Internet-based protocols work well.   Merely blessing things that do not work well is not playing a leadership role.

> So expecting to control its growth or development is as futile for us as for anyone else.

Control has nothing to do with it.   But if IETF doesn't fairly reliably give good advice, its reputation will decline and IETF will become less relevant.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Feb 2011 08:03:45 -0500

> Ideally, IETF's role is to provide advice that helps the Internet and Internet-based protocols work well.   Merely blessing things that do not work well is not playing a leadership role.

Let us look at the case of mDNS.  Apple has actively listened to the
advice it has been given and worked within the limits of its deployed
base to make alterations.  If the IETF had been a little more
responsive, actually, the deployed-base problems might not have been
so bad (this is not to say that the IETF bears all the responsibility
for how this document has languished, note: the authors have not
always been quick to respond either).  What else do we want from our
standards procedure?

It seems to me that the documents should therefore be published.  It
is IMO better that they be published on the standards track, but who
cares?  The distinction between Informational and Standards Track when
a document actually is a protocol is one that IETF arcana fans and
nobody else in the universe cares about.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.