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@xxxxxxxxxxxxxxx> wrote: > Hi, > > "Scott O Bradner <sob@xxxxxxxxx>" 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/