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(_at_)dougbarton(_dot_)us> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf