Re: draft-klensin-iana-reg-policy (Re: S stands for Steering)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Perhaps things have settled down sufficiently for me to express an opinion...

I am not an IANA weenie. But I think registries should register things.

We have a decent amount of running code (for example, http://www1.ietf.org/mail-archive/web/ietf/current/msg35953.html) that says our attempts to limit what gets deployed by limiting what gets registered don't work reliably.

It is frustrating for operators to have less clue about what's happening on their networks because parameters weren't registered. If an operator freaks out at the thought of carrying the option requested way back on the beginning of this thread, it would be easier to filter this traffic confidently if the option was registered. It would also be easier for an operator to figure out who is using the option, and how often, especially if there weren't two sets of traffic using the same option to mean two different things - and that is where unregistered deployed options will take us, especially if neither option generates a multi-day mail thrash on the IETF mailing list (I suppose THIS option will never be squatted on by anyone else - it's infamous, even if it's not registered).

What I would like to see is a clear distinction between IANA as a registry and the IETF as a protocol standards organization.

People who I respect have expressed concerns that allocating values in a registry for lame protocols will be confused with endorsing lame protocols. I'm not sure this is true, but if it is, in the past what we've done in similar situations is to publish RFCs like ftp://ftp.rfc-editor.org/in-notes/rfc1796.txt, when we were concerned about people thinking that all RFCs are standards.

It may be time to publish a similar RFC, with a title like "Not all registry allocations support wonderful protocols". That would be fine. I can draft something along those lines - it should be a page long, modulo boilerplate. If you have an opinion on this, please e-mail me privately.

It may also be time to add a registry policy for parameters that we wouldn't register, but people are deploying them anyway, just as a public service announcement. We could call it the "Damn the Torpedoes, Full Speed Ahead" policy (DTFSA), and no one could say they weren't warned.

I also note that one of the many "wireless is special" things I've seen in the past decade was the WAP Interim Naming Authority (WINA), now resurfacing as the Open Mobility Naming Authority (OMNA) (see http://www.openmobilealliance.org/tech/omna/index.htm). There are probably other pseudo-IANAs I don't know about. Our choke-hold on the parameters the world uses isn't quite as tight as it needs to be in order for us to use IANA as an enforecment tool.

Thank you,

Spencer

("Damn the torpedoes! Full speed ahead" is a historical reference - details at http://en.wikipedia.org/wiki/David_Farragut. It's also a killer Tom Petty album - details at http://en.wikipedia.org/wiki/Damn_the_Torpedoes_%28album%29)


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]