Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

[Phillip Hallam-Baker <[e-mail]>]

It occurs to me that this thread demonstrates that a Standard is NOT
required. Nor has it ever been.

Anyone who wants to can choose any code point and use it. If they have
enough market presence they can make sure that nobody else wants that same
code point.


I do not agree with the need for a private use space. Private use just means
that each experiment will burn a minimum of one code point and if successful
will burn a second plue require a transition. We have been there with
X-headers. They didn't really work.


One of the problems with the DNS area is that there are far too many people
who think that they have a veto point on the Internet and that is just not
true (thank the deity).

I am not trying to pick on the DNS area, just point out that it is not only
governments who regard it as a chokepoint and thus the subject matter
inevitably attracts people who think that it is their mission in life to
protect the Internet from making the mistakes that they in their wisdom are
uniquely capable of recognizing.


I am willing to follow a process if an assignment process gives me a
reasonable chance of getting an assignment on a reasonable schedule. By
which I mean a small number of months as for RR code points. But do not be
mistaken: I am not recognizing a right of veto by doing so.

If the barrier is Standard required then I am simply going to tell people
the number I have picked. I didn't get to vote for anyone involved so they
should not exactly be surprised if I don't recognize their right to a veto.

Some of you know the political sympathies that got me involved in the
Internet in the first place: I believe in democracy. Do not be at all
surprised if my lack of tolerance for unaccountable decisions is not limited
to those of dictators and autocrats.

A consensus based approach can be appropriate if the remit of an
organization is limited to finding out what we can agree to do together. It
is not acceptable if the organization is going to presume to claim veto
power over what they do when agreement is not reached.


We have a similar situation with SRV prefixes which for various reasons have
not been properly tracked for the past ten years. Each time there are
proposals to rationalize the prefix registry people pull out absurd
technical and logistical issues until the enthusiasm for the proposal is
beaten into submission and lies bleeding and battered but not quite dead for
the next few years.

In the meantime every protocol designer who believes inthe SRV approach just
does what I have done in W3C and OASIS standards and writes the stupid code
points into the spec. There, done.


On Wed, Aug 31, 2011 at 7:47 AM, Andrew Sullivan <[e-mail]>wrote:

> On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacCárthaigh wrote:
> > On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan <[e-mail]>
> wrote:
> > > I actually don't care about the IETF process.  What I do care about is
> > > the potential for interoperability headaches later because of
> > > undocumented collisions in EDNS0 option code interpretation.  Avoiding
> > > that sort of headache is the exact reason we have a registry.
> >
> > How would you feel about proposing more relaxed registry criteria to
> > IANA (by way of an RFC), similar to how the ports registry works?
>
> In my personal, no-hat opinion, the registry rule could be made
> first-come, first-served until (say) 50% of the code space was used
> up.  I see no reason not to do this.
>
> The current edns0-bis draft actually moves things in the opposite
> direction: whereas now the rule is RFC Required, the current draft
> makes things Standards Action.  In my opinion (again no hat), this is
> the wrong direction to be moving.
>
> > EDNS0 option codes don't appear to be in much demand, so exhaustion
> > isn't as much of a concern.
>
> Right.  And we could solve that worry by making the relaxed rule
> automatically tighten after a certain number of the codes are gone
> anyway, just the way we did for the DNSSEC algorithm numbers.
>
> A
>
> --
> Andrew Sullivan
> [e-mail]
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>



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