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 <dougb@xxxxxxxxxxxxx> 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 > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf