Phill, that is built into clause 1 of our MoU with ICANN (RFC 2860).
I assume that when the IETF Chair writes about IANA, he's writing
about the part of IANA that we control under that MoU.
Brian
On 06/01/2014 06:36, Phillip Hallam-Baker wrote:
> One of the points that I should have made in response to Jari is that a
> major limitation in his thinking is that he sets out the function of IANA
> as an IETF support service rather than an Internet support service.
>
> The distinction is important as there is no reason that IANA should only be
> used by the IETF. The IETF is not the only Internet standards making
> organization and I hope to see many, many more. There is a natural limit to
> the size of organizations and the IETF is at that point. So are OASIS and
> W3C. We cannot attempt to scale the development of cool Internet uses by
> increasing the size of the IETF and it is counterproductive to try.
>
> If we look at the wider context, there are now communities focused on
> single applications that are roughly the size of IETF areas. The Linux
> plumbers is the size of the IETF at a similar stage in IETF growth. They
> will soon grow to about the same size.
>
>
> We can't scale organizations but we CAN scale the IANA. The function of the
> protocol registries is simply to avoid ambiguous name assignments. Why
> limit scope to just protocol?
>
>
> On Sun, Jan 5, 2014 at 3:06 AM, Patrik Fältström <paf@xxxxxxxxxx> wrote:
>
>> On 5 jan 2014, at 07:16, manning bill <bmanning@xxxxxxx> wrote:
>>
>>> Jari, you can’t be serious. unlimited means -without- limit, not just
>> the limits of your imagination.
>>
>> Bill, it was not Jari, it was Phillip Hallam-Baker that said "unlimited",
>> which I objected to.
>>
>
> And I excluded the very protocols you used as examples in your counter
> argument. So complaining about Bill mistaking attribution is a bit rich.
>
> And I said 'effectively' unlimited which means without effective limit,
> i.e. sufficiently large that there is no conceivable circumstance in which
> we would need more. So suggesting that the identifiers need to be
> infinitely long is yet another straw man.
>
> RFC822 header tags are not in fact unlimited, I can't remember the limit
> offhand but for practical purposes it is 20 bytes. But that is still enough
> space to encode a 100bit random identifier in base32 which is certainly
> 'effectively unlimited'.
>
>
> The test is whether the risk of code point exhaustion is justification for
> limiting registrations. If someone can make the argument that 'we might run
> out' then obviously the number of code points is not effectively unlimited.
>
> What I am trying to get away from here is the expectation that every
> protocol is going to have a separate registry for every item that might
> need to be identified.
>
> Shaving a few bytes should not be an excuse to create a new ongoing
> maintenance requirement for IANA and creating an extensibility nightmare
> which is what short fixed length codes do.
>
>
> Now what we could do that would achieve most goals for most people would be
> to have a single registry of text labels. Each entry would have four pieces
> of information:
>
> 1) The label itself
> 2) A unique numeric code
> 3) The purpose for which the label is defined
> 4) References
>
> So "AES" would have the entry
>
> "AES" 4242 Algorithm/Encryption FIPS-yada-yada
>
> There might then be additional information in the Algorithm/Encryption
> registry which would continue to provide additional information (e.g. the
> OID assignment, modes etc).
>
>
>
>
> Signup would be by simply entering filling out a web form, similar to the
> allocation of OID arcs.
>
>
> The advantage of this approach is that if someone wants to simply reserve a
> label to prevent a conflicting use, this is easily done. It is not even
> necessary to specify the use.
>
> The numeric codes can be used for the handful of protocols where byte
> shaving is a real concern. A new protocol using the technique would have to
> make provision for allowing 64 bit codes but it is unlikely the
> registrations would exceed a 4 byte space any time soon.
>
> Another use for the codes would be to define an OID assignment and a URI
> form of the same label. Since some codes already have OID and URI forms,
> these need to be tracked but that would be best done separately.
>
> I would do this with two registries, one for OIDs, the other for URIs which
> would list the code points that are synonyms for codes listed in the text
> label table and whether they are canonical.
>
>
> The current situation suffers from the hierarchical fallacy which is the
> mistaken belief that it is useful to separate identifiers by category. The
> prime example of this failed notion being the .com, .net and .org
> registries in DNS which do nothing but confuse.
>
> Separating the registration of encryption algorithms from other crypto
> algorithms does not help because it should be obvious that if FOO is a
> symmetric encryption algorithm identifier, it cant be a digest algorithm
> either. It is also the case but somewhat less obvious that the FOO label
> can't then be a RFC821 command or a RFC822 header either. At least not
> unless the use of FOO in the other context is completely specified and
> constrained by the symmetric encryption spec.
>
>
> If we rationalize the operation of IANA we can reduce the amount of work
> required in both the IETF space and the IANA. More importantly we can
> encourage all the other standards organizations to rely on IANA to register
> code points.
>