4 Sep 2011 05:03
Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00
Phillip Hallam-Baker <hallam <at> gmail.com>
2011-09-04 03:03:17 GMT
2011-09-04 03:03:17 GMT
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 <ajs <at> anvilwalrusden.com> wrote:
On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacCárthaigh wrote:In my personal, no-hat opinion, the registry rule could be made
> On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan <ajs <at> anvilwalrusden.com> 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?
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.Right. And we could solve that worry by making the relaxed rule
> EDNS0 option codes don't appear to be in much demand, so exhaustion
> isn't as much of a concern.
automatically tighten after a certain number of the codes are gone
anyway, just the way we did for the DNSSEC algorithm numbers.
A
--
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Website: http://hallambaker.com/
_______________________________________________ dnsext mailing list dnsext <at> ietf.org https://www.ietf.org/mailman/listinfo/dnsext
RSS Feed