I see no value in deallocating code point spaces and a huge amount of
potential harm.
Except at the very lowest levels of the protocol stack (IP and BGP)
there is really no technical need for a namespace that is limited. We
do have some protocols that will come to a crisis some day but there
are plenty of ways that the code space for DNS, TLS etc can be
expanded if we ever need to.
The Internet is driven by innovation and experiment. There are
certainly people who think that the role of this organization is to
protect the Internet from the meddling of people who might not get it
but they are wrong.
Even more wrong is the idea that IANA can actually act as suggested.
IANA only exists by mutual consent. I am happy to register a code
point if there is a reasonable procedure to do so. But if the idea is
to force me to kiss someone's ring then I'll pick a number and ship
the code and let other folk work out the problems later.
This already happens on a significant scale in the wild. SRV code
points being a prime example. There are far more unofficial code
points than recognized ones. Some of them are in standards I wrote at
W3C and OASIS. It would be best if IANA tracked these but I think it
rather unlikely anyone is going to accidentally overwrite the SAML or
the XKMS SRV code points.
It has happened with other registries too. Back in the day there was
an attempt to stop the storage manufacturers using ethernet IDs on
their drives. So the drive manufacturers simply declared a block of
space (Cxxxxxx) as theirs and the IEEE has since been forced to accept
this as a fait accompli. It has happened in UPC codes as well, when
the Europeans decided that the US authority was charging them
ridiculous fees they just extended the code by an octet and set
themselves up as a meta-registry.
The only role of IANA is to help people avoid treading on each other
by accident. If it starts issuing code points that have been 'lightly
used', the value of IANA is degraded. I certainly don't want my
protocol to have to deal with issues that are caused by someone's
'experiment' that has not completely shut down. The only value of
going to IANA rather than choosing one myself is to avoid
contamination with earlier efforts.
The only area where I can see the benefits of re-allocation
outweighing the risks is in IP port assignments but even there I think
the real solution has to be to simply ditch the whole notion of port
numbers and use SRV type approaches for new protocols.
IANA is not a control point for the Internet. A fact that people need
to keep in mind when the ITU attempts to grab control in Dubai later
on this year.
Weakness is strength: The registries are not the control points people
imagine because they only have authority as long as people consent.
On Thu, Apr 19, 2012 at 5:17 PM, David Conrad <drc(_at_)virtualized(_dot_)org>
wrote:
Hi,
"Scott O Bradner <sob(_at_)sobco(_dot_)com>" wrote:
encouraging a report is fine
Agreed.
retracting the code points seems to add more confusion than it is worth
unless the code space is very tight
Disagree. From my experience at IANA, trying to figure out who to contact to
remove a code point gets harder the longer the code points are not being
used. Unless the code space is unlimited, I'd argue that you want to
deallocate as soon as an experiment is over. I'd even go so far as to say
that the original proposal for experimental code points should have explicit
revocation dates (which can, of course, be refreshed similarly to IDs).
and I see no reason to obsolete the experimental rfc or move it to historic
status unless the report is that some bad thing happens when you try it out
- updating the old rfc is fine
Having been involved with RFC 6563, I think in general it is quite useful to
signal "hey, you really don't want to implement this". If this can be done
by updating the old RFC, that's fine.
and I agree with Elliot about the nature of research - it is very common to
not reach a conclusion that something is bad (as in bad for the net) - and
that is the only case where I think that an experiment should be flagged as
a don't go there situation
Agreed, with the proviso that limited resources (whether they are scarce or
not) should be reclaimed.
Regards,
-drc
--
Website: http://hallambaker.com/