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(_at_)frobbit(_dot_)se>
wrote:
On 5 jan 2014, at 07:16, manning bill <bmanning(_at_)isi(_dot_)edu> 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.