Subject: IANA blog article

From: IETF Chair <[email-masked]>
Date: Fri, 3 Jan 2014 18:36:48 +0100

In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).  What is IANA, how does it work, how is it related to the IETF, and how has it evolved over time? How will it evolve in the future, and how can you participate in the discussion?

http://www.ietf.org/blog/2014/01/iana/

Jari

---

From: David Conrad <[email-masked]>
Date: Fri, 3 Jan 2014 15:27:08 -0800

Hi Jari,

> In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).  What is IANA, how does it work, how is it related to the…

Thanks for this.  I've often been surprised how few people know or understand the IANA functions, how they're performed and under what authority, and I suspect clarity on these issues is going to be increasingly important in the future.  

A few points:

- Perhaps it is merely your shorthand, but I've found that saying "IANA" as if it is a discrete entity rather than a set of functions performed by a contractor (or contractors) tends to confuse things.  For example, you say "... IANA then makes the actual allocations ...".  In actuality (as you note later on), ICANN, acting as the current IANA "protocol parameters function" operator makes the allocation. 

- As I suspect you're aware, ICANN, as the IANA function operator, performs a couple of other administrative duties that are considered (at least in the context of the IANA functions contract between the US Dept. of Commerce NTIA and ICANN, see http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf) outside of the protocol parameter, root zone management, and top-level Internet numbers allocation functions, i.e., administration of the .ARPA top-level domain and administration of the .INT top-level domain. Given past experiences, I hope these other functions are kept in mind as people think/talk about future frameworks associated with IANA functions evolution.

- Some nits in the sentence "For instance, 2000, the IETF and ICANN signed a contract about the protocol parameters aspect of the IANA function (RFC 2560)": I presume you meant "in 2000" and "RFC 2860".  Also, as opposed to the IANA functions contract between the USG and ICANN referenced above, 2860 is not a contract but a "memorandum of understanding" -- I've been told by lawyers that the distinction is important.

- I probably wouldn't say the system of IANA functions have "grown up" as that suggests no further growth is necessary/needed.  I'd agree that the system is maturing, however I believe still has a ways to go, albeit primarily in non-technical areas. In particular, it will be nice to clarify the current ... ambiguity, at least in the eyes of some, regarding the authority over IANA functions.

I look forward to seeing how things evolve in the future.

Regards,
-drc
(IANA General Manager, 2005 - 2010)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2014 01:15:53 -0500

On Fri, Jan 3, 2014 at 12:36 PM, IETF Chair <[email-masked]> wrote:

> In this article I wanted to highlight an important but often hidden part
> in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).  What is
> IANA, how does it work, how is it related to the IETF, and how has it
> evolved over time? How will it evolve in the future, and how can you
> participate in the discussion?
>

I think that the article needs to go back to some basic principles.

The whole point of the end-to-end architecture was that it enabled
innovation and diversity. In particular it was possible to add applications
to the Internet without going to some central authority to ask permission.
The IETF is not in the business of deciding how people use the Internet
except to the extent that doing so may harm others, it is only in the
business of setting standards that enable interoperability.

So when we look at the role of IANA, there are different concerns for
different protocol layers. The concerns at the IP layer are different to
the concerns of DNS which are in turn different to those of applications.

At the IP layer compact representation is vital and code points are a very
scarce resource by necessity. Allocation has to be carefully considered
because they potentially affect the routers at the core of the Internet
which are very difficult to change.

The DNS is an interesting case because the number of code points is
generous but finite. Less than 1% of code points are assigned.

At the application layer we have the curious situation that port
allocations are essentially exhausted so we use ports 80 and 443 for
everything. But in most cases the general rule should be that application
protocols should be designed so that code points are not a constrained
resource and the primary purpose of assignment should be to prevent
ambiguity arising and to provide as much documentation as is possible.

We have learned to our cost that X-Headers don't work. Telling people to go
experiment in a sandbox and then come to the IETF when the protocol is
ready and get issued a real code point has not worked. It guarantees we end
up with multiple code points.

The status quo for most registries is that they are permissive but there is
a large amount of difference in the criteria and there are experts involved
doing reviews for some systems but not others. There is a general lack of
consistency. A standards organization should look for consistency.

One important change is that every future application protocol proposal
should be required to have an effectively unlimited code space for
assignment. Another is that application protocols should be required to
reuse code points from common registries rather than define their own.

At the moment we have separate crypto registries for TLS, IPSEC, PEM, PKIX
and XML Digital Signature. The JOSE folk want to create another. There
should be a policy that tells people from the start that there will be no
new crypto registries.

Fixed length numeric assignment codes as TLS and IPSEC use should be
verboten and the text based registries merged into one common registry of
labels for all new assignments. So the SHA-3-256 text label would be the
basis for the URI form used by XML signature. The per-protocol registries
should then be closed to new registrations so that all crypto labels are
assigned from one registry on a first-come first-served basis.

One change that should be made is to separate out the assignment of code
points from the endorsement of code points. Assigning a code point should
mean no more than it won't be assigned for a different purpose. It should
not imply any form of endorsement.

Endorsement may be limited to an expert reviewer noting that a particular
document or institution should be considered the authoritative source of
the specification explaining a code point or it could be an IETF standards
action.

The IAB should be tasked with ways to reduce the number of separate
registries required. Reuse of an existing registry is almost always better
than defining a new one.

Coinsider the SMTP protocol. Even though the URI form for SMTP is actually
mailto:, it is obvious that the SMTP URI scheme could not possibly be
assigned to a different protocol without major confusion at the very least.
The same argument goes for .well-known.

Rather than have three separate registries and attempt to avoid conclusions
it would be better to have one registry for text labels so that
registration of a label automatically reserves the corresponding
.well-known, URI and SRV code points in one go.

If we took this to an extreme there would be only one registry of text
labels and the entries would describe the use(s) for which the label has
been assigned. If a label is assigned as an application protocol identifier
then it can't be a content type or an encryption algorithm. But it is
probably just sufficient to prune down the registries somewhat.

Finally, we need to change the assignment process for OIDs because it is
really hard to get a bunch of companies to agree on a draft if the OID
assignment is off one corporate arc. Rather than assigning arcs in the open
registration arc only to companies, they should be assigned to projects.

So in my Privacy Hardened scheme, I am going to need to define a new ASN.1
structure (puke) and some extension OIDs. In the current scheme I would
have to cut them off the Comodo arc (which makes getting buy in from
Symantec, etc. etc. harder) or my personal arc (Default Deny Security).
Both of which are likely to end up having all the entries renamed if the
proposal becomes an IETF working group. If instead I get a new arc for the
project, I can then hand over change control over the arc along with the
rest of the protocol if it is accepted by the IETF (or the same for W3C or
OASIS). If the project is not taken up then I keep control.

The objective of all these reforms is to emphasize that the role of the
IANA is to facilitate innovation, avoid unintentional collisions and not to
enforce control. It is not possible to prevent a use of the Internet by
withholding an assignment.

-- 
Website: http://hallambaker.com/

---

From: Jari Arkko <[email-masked]>
Date: Sat, 4 Jan 2014 09:19:05 +0100

Hi David,

> - Perhaps it is merely your shorthand, but I've found that saying "IANA" as if it is a discrete entity rather than a set of functions performed by a contractor (or contractors) tends to confuse thi…

Agreed… (I changed this in the article, btw.)

> - As I suspect you're aware, ICANN, as the IANA function operator, performs a couple of other administrative duties that are considered (at least in the context of the IANA functions contract betwe…

Ack.

> - Some nits in the sentence "For instance, 2000, the IETF and ICANN signed a contract about the protocol parameters aspect of the IANA function (RFC 2560)": I presume you meant "in 2000" and "RFC 2860".

Oops. Corrected.

> Also, as opposed to the IANA functions contract between the USG and ICANN referenced above, 2860 is not a contract but a "memorandum of understanding" -- I've been told by lawyers that the distinction is important.
> 

I do agree that "grown up" should not be taken as "evolution is done". Further growth and evolution is indeed needed. 

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 4 Jan 2014 09:29:32 +0100

> The whole point of the end-to-end architecture was that it enabled innovation and diversity. In particular it was possible to add applications to the Internet without going to some central authority to ask permission.

I very much agree with this principle. Although maybe that's a topic for another blog article or discussion… my article was mostly in the context of managing registries when we have already decided that it is one of those rare cases where a registry is needed, and have already decided what the rules and form of the registry is.

The wonderful thing about the Internet is indeed that most things do not need central control or registry.

A couple of responses below for the registry design question:

> We have learned to our cost that X-Headers don't work. Telling people to go experiment in a sandbox and then come to the IETF when the protocol is ready and get issued a real code point has not worked. It guarantees we end up with multiple code points.

I think I agree with this problem statement.

> The status quo for most registries is that they are permissive but there is a large amount of difference in the criteria and there are experts involved doing reviews for some systems but not others. There is a general lack of consistency. A standards organization should look for consistency.

I think we are trying. Can you be more specific about areas where there is lack of consistency? We can try to improve rules about specific IANA registries, provide more guidance to experts, etc. if we are not performing well enough in some area.

> One important change is that every future application protocol proposal should be required to have an effectively unlimited code space for assignment.

Agree.

> Another is that application protocols should be required to reuse code points from common registries rather than define their own.
> 
> At the moment we have separate crypto registries for TLS, IPSEC, PEM, PKIX and XML Digital Signature. The JOSE folk want to create another. There should be a policy that tells people from the start that there will be no new crypto registries.

Here I am not so sure. Registries for adding specific crypto algorithms are not merely number allocations; they go with specifications and code that actually runs, say, AES on IPsec or AES on TLS. It is not entirely clear to me that crypto across different protocols and use cases should proceed in lock step. And even if it were useful, it is a difficult change to make retroactively, when the code points in different protocols started out differently.

But maybe I'm misunderstanding your suggestion.

> Finally, we need to change the assignment process for OIDs because it is really hard to get a bunch of companies to agree on a draft if the OID assignment is off one corporate arc. Rather than assigning arcs in the open registration arc only to companies, they should be assigned to projects.
> 
> So in my Privacy Hardened scheme, I am going to need to define a new ASN.1 structure (puke) and some extension OIDs. In the current scheme I would have to cut them off the Comodo arc (which makes getting buy in from Symantec, etc. etc. harder) or my personal arc (Default Deny Security). Both of which are likely to end up having all the entries renamed if the proposal becomes an IETF working group. If instead I get a new arc for the project, I can then hand over change control over the arc along with the rest of the protocol if it is accepted by the IETF (or the same for W3C or OASIS). If the project is not taken up then I keep control.

This is interesting, and I could see a use case for it.

> The objective of all these reforms is to emphasize that the role of the IANA is to facilitate innovation, avoid unintentional collisions and not to enforce control. It is not possible to prevent a use of the Internet by withholding an assignment. 

This I agree with.

Jari

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Jan 2014 10:31:08 +0100

>> One important change is that every future application protocol proposal should be required to have an effectively unlimited code space for assignment.

I do not agree regarding the term "unlimited".

What is needed is that the specification do have a consequence analysis regarding expansion of use.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Jan 2014 07:10:40 -0500

--On Saturday, January 04, 2014 10:31 +0100 Patrik Fältström
<[email-masked]> wrote:

>>> One important change is that every future application
>>> protocol proposal should be required to have an effectively
>>> unlimited code space for assignment.
>> 
>> Agree.
> 

At least if it isn't unlimited, but I agree with Patrik.

Remember that the most important single protocol value space we
have is one that we've gotten wrong (at least) three times,
twice requiring complete replacement of the relevant protocols
themselves to expand the space (even though, especially the
first time, there were other reasons to do so).

Remember:
	-- We will never need more than 254 hosts.
	-- We can expand that a bit by using an IMP number/ host
		number pair.
	-- A 32-bit range will always be enough, even if we
		break it into octet-boundary Classes and thereby limit
		how much of it can actually be used.
	-- A prefix model and bit boundaries will save us for a
		while.

and, more recently,

	-- A 128-bit range will be enough forever, even if we
		allocate it in ways that make the actual number of
		usable addresses much smaller.

Maybe we are right about the last one, maybe not.  But any
requirement of "unlimited" would essentially require
variable-length addresses (or variable-length parameter fields
more generally, and that has always been considered a major
architectural decision.

So, yes, analysis of how big the space really is and needs to be
and what the consequences are if it turns out to be not
"unlimited" enough.

   john

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Jan 2014 13:24:57 +0100

On 4 jan 2014, at 13:10, John C Klensin <[email-masked]> wrote:

> But any

Exactly why I object to the term.

You John explain why very well and also point out the bad decisions we made that we should learn from -- including the IPv6 decisions that I am extremely nervous over. Where early players once again get much larger address space than those arriving late.

  Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sat, 04 Jan 2014 07:55:22 -0800

> - Perhaps it is merely your shorthand, but I've found that saying "IANA" as if it is a discrete entity rather than a set of functions performed by a contractor (or contractors) tends to confuse thi…

Glad you raised this.

Given the range of things that ICANN does and given the controversy some 
of that engenders and given that the IANA activities really are 
something that the IETF, itself, contracts to have done, I think it 
/better/ to refer to IANA as a discrete activity.

Labeling that set of functions as its own, IETF-assigned administrative 
identity can help to separate it from other other Internet 
administrative functions.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2014 12:15:13 -0500

On Sat, Jan 4, 2014 at 4:31 AM, Patrik Fältström <[email-masked]> wrote:

> assignment.

Please read my words as carefully as a wrote them.

There are excellent reasons why variable length IPv6 addresses would have
been a bad idea. That is why I separated considerations for IP layer, DNS
and Applications.

At the application layer, the concerns are very different. Variable length
identifiers are not a problem. We use them in RFC822, ASN.1, XML and JSON.

The only protocols above the bare IP layer where we don't use variable
length identifiers are IPSEC and TLS. But these are merely design mistakes
not to be repeated. Using fixed length identifiers in those protocols has
negligible performance advantages but even a 32 bit identifier space is not
big enough to make it a free for all. And so a technical choice creates an
ongoing administrative requirement.

The problem in TLS is worse because the algorithms are joined together in
suites and so there is a combinatorial issue. Since we have a key exchange
cipher, an encryption cipher and a MAC for each we actually have an average
of ten bits 32/3 per cipher. I can easily see us exhausting that.

What I would like is some architectural guidance from the IAB to the effect
that all future protocols MUST use an identification mechanism that puts
exhaustion of code points beyond the realm of practical possibility.

Since we are unlikely to be doing IPv7 any time soon and if we did it would
be a whole new ball game, this requirement would only apply to major
revisions of DNS, IPSEC, TLS like things and Application protocols.

I don't see an argument right now for a major revision of DNS. But if we
were to revisit it in a backwards incompatible way we would surely change
the protocol so that the number of possible resource records was more than
64K. The practical impact of the requirement is that the increase would
have to be from 64K to 'effectively unlimited' rather than to 4G (32 bits).

For other protocols the consequence would be to use one of the following:

1) Pseudo identifiers of 128 bits (or more), i.e. UUIDs
2) ASN.1 Object identifiers
3) Simple text labels (e.g. AES-128)
4) URIs

IP addresses will always be a special case because they have to operate
under some special constraints. We all use the same code point for
text/plain but we all have to use a different IP Address.

To respond to some points made by John and others later in the thread, mere
issue of a code point should not imply endorsement. I don't think that the
IETF should be in the business of endorsing cryptographic algorithms or
content types. There are certain cases where the IETF needs to be involved
in identifying the authoritative definition though. Is the definitive
definition of AES a document by NIST or someone else? Does Adobe define
application/pdf or ISO? (these are not questions I am asking, they are
illustration of the questions that IETF/IANA needs to answer).

I can certainly see potential for a situation where we start using some
open source content type and there is a fork where two different groups
claim to be the successor in interest and one true guardian of the spec.

For crypto, the situation is a little simpler and a lot more complicated
than assumed. The standards are in practice defined by running code. And
that code behaves in very particular ways.

If I add a crypto module to Windows (or most other well designed crypto
platforms), it will become available to all the applications running on
that platform. Which is all well and good of course. One consequence of
this is that the way S/MIME uses AES and the way TLS uses AES have to be
compatible. Otherwise large amounts of application code would need to be
rewritten to special case each algorithm. And not having to do that is the
objective of having a standard.

Fortunately the amount of variation possible is very small. There is the
byte ordering for keys and a few other endian issues that might be
underspecified or confused in the specs. But that is all. If an algorithm
needs more than that then it is not ready for use and should be discarded
(and new code points issued for the replacement).

What we do today is that we micromanage the process in ways that are
counterproductive. People write documents describing how to use the
<splunge> algorithm with IPSEC and S/MIME but any given platform is going
to have code based on one or the other. What appear to be two independent
specifications are in fact two variants of one specification since any
deviation between the two documents is unambiguously an ERROR.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2014 13:43:32 -0500

[trimmed to just the parts I am responding to]

On Sat, Jan 4, 2014 at 3:29 AM, Jari Arkko <[email-masked]> wrote:

> I very much agree with this principle. Although maybe that's a topic for
> another blog article or discussion…

I know that it is what everyone agrees on. But some people also see the
mission of the IETF as to protect the Internet from harmful
experimentation. This is silly for two reasons, first is is a LOT harder to
bring down the Internet than most people imagine, second the people who are
likely to cause such an issue accidentally don't taken any notice of the
IETF or IANA in any case.

> The status quo for most registries is that they are permissive but there
> is a large amount of difference in the criteria and there are experts
> involved doing reviews for some systems but not others. There is a general
> lack of consistency. A standards organization should look for consistency.
>
> I think we are trying. Can you be more specific about areas where there is
> lack of consistency? We can try to improve rules about specific IANA
> registries, provide more guidance to experts, etc. if we are not performing
> well enough in some area.

I see the problem mostly in the crypto area where the tradition has been
that each protocol defines its own registry of schemes. This is a bad
approach. I would like to see a single registry that keeps track of the
OID, text label and URI identifications of each algorithm and all crypto
applications should use the code points in that registry.

Choice of crypto algorithms is an ongoing maintenance task. It is not
therefore a task that can or should be performed by Working Groups unless
we want the Working Groups to become permanent.

IETF should only endorse a single core set of algorithms with a maximum of
one preferred and one alternative algorithm and this should be an IETF
consensus, not a WG consensus. A WG might add in additional recommendations
to support legacy interop, for example 3DES is still a defacto requirement
for S/MIME.

All other crypto maintenance should be achieved through a first-come common
registry.

The mere existence of a code point would not mean that it can or should be
used with IPSEC or S/MIME. None of us want to use MD2 or DES for example,
even though the code points are well known. All a code point means is that
the behavior of the protocol is defined. Caveat ingenio.

One case that will come up soon is this one
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/

For the sake of saving a few bytes in a protocol using a text based
encoding, the OpenID people decided to use their own text based identifiers
for crypto algorithms. So the JOSE working group is wanting to create a new
set of algorithm identifiers for all the existing algorithms.

This is not a good practice for a standards organization. We have a
perfectly good set of text based labels already from the PEM days. Even
though PEM is deader than a dodo, the code points are widely used and we
have an existing registry.

The response to the JOSE demand for a new registry should be the following:

1) Reserve the code points already assigned in OpenID in the common
registry for the use of OpenID alone.

2) Require all applications that are not OpenID to use the common registry.

There are some things that are legitimately Working Group decisions.
Forking the IANA crypto registries is not.

* Each code point should identify an algorithm (plus possible parameters)
unambiguously

* A single algorithm can be identified by multiple code points.

* Each algorithm should have a single canonical code point which MUST be
accepted by all conforming applications.

So OpenID implementations would still be free to (and indeed required to)
use the legacy code points for backwards compatibility. But they would be
required to accept the common labels as well.

I would further suggest that when we next do a major revison of TLS or
IPSEC that is going to affect the algorithm negotiation scheme, we insert
one new code point for 'suite indicated in an extension' and this be an
indirect to a scheme based on the common registry. It would still be
possible to support suite restrictions but these would be implemented in
code and could support expressions of the form

(RSA2048 or RSA4096) and (AES128 or AES192 or AES256) and (..)
or
(ECDSA-splunge) and (AES256)

etc.

> Another is that application protocols should be required to reuse code
> points from common registries rather than define their own.
> >
> > At the moment we have separate crypto registries for TLS, IPSEC, PEM,
> PKIX and XML Digital Signature. The JOSE folk want to create another. There
> Here I am not so sure. Registries for adding specific crypto algorithms
> are not merely number allocations; they go with specifications and code
> that actually runs, say, AES on IPsec or AES on TLS. It is not entirely
> clear to me that crypto across different protocols and use cases should
> proceed in lock step. And even if it were useful, it is a difficult change
> to make retroactively, when the code points in different protocols started
> out differently.
>

The definition of a code point is an administrative issue. The only case
where this is standards issue is when some doubt arises because a spec is
insufficient or misinterpreted.

The decision to require support of a specific algorithm set to enable
interoperability is not really WG material either because it is a decision
that has to be revisited over time.

I don't see much value in having an argument over the choice of crypto in
WG foo and then a year later start the whole debate from scratch on
protocol bar. Especially when it is the same set of people and the
arguments have not changed.

Crypto algorithms are by design a commodity. If they are not plug and play
then something is broken in the specification of the algorithm or the
protocol.

While crypto protocols are broken down into separate WGs, security is a
unified concern across all protocols and works as a system. It is
implemented in the same way.

The reason we change algorithm recommendations is that the security
evaluations of the protocols change. So when we deprecated DES, it was in
all IETF protocols, not just one.

We are currently phasing out use of SHA-1 across all deployed crypto
applications that rely on PKIX. This is not an IETF action or even a
CABForum action, it is the consequence of Microsoft deciding to bite the
bullet and declare that they are going to drop support for SHA-1 in certain
applications which will in turn force the entire WebPKI to follow suit.
Which is an outcome that the whole security community believes should
happen, the only dispute has been over timing.

>From an implementer point of view, having the IETF periodically issue an
RFC saying that the recommended crypto algorithms are X, Y and Z would be a
big help to us because then someone can take the OpenSSL (or Cryptolib etc)
library and subset it to only those ciphers knowing that they can support
all the IETF apps.

It would not be a particularly controversial project either. The consensus
in the crypto world today is clearly for the following set of required
algorithms:

Public Key Encryption:  RSA  (RSA-2048, RSA-4096)
Public Key Signature:  RSA  (RSA-2048, RSA-4096)
Public Key Exchange: DH (DH-2048, DH-4096)
Encryption: AES (AES-128, AES-192, AES-256)
Digest: SHA-2 (SHA-2-128, SHA-2-192, SHA-2-256)
MAC: HMAC-SHA2*

OK, the last we could argue on. We can also argue about the block cipher
modes and whether encrypt and authenticate modes are consensus. But those
are decisions where the application requirements do actually have an
impact. AES-CBC is not interchangable for AES-CFB.

And for alternatives we would essentially be looking at Suite-B plus SHA-3
with the massive caveat that IPR FUD is going to continue to make them
unusable for many applications for quite a while. However happy I am with
the litigation risk, the IPR holder can go after my customers. Since RIM is
up for sale and the patents likely to be bought by a troll, it is not a
risk the industry can currently take.

[Though if the NSA wants to say sorry for spying on the crypto community
and sabotaging standards, they could buy the patents themselves and make
them public domain]

That at any rate is what I mean by consistency. I think the IAB should look
at consolidation of IANA registries as one mechanism for achieving greater
consistency across protocols and avoiding unnecessary variations. The IAB
should not be responsible for deciding which algorithms we use (for
example) but they should take responsibility for deciding that the set of
algorithms will be decided in one place and not many.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Jan 2014 08:46:10 +1300

> At least if it isn't unlimited, but I agree with Patrik.

There's some discussion of what can go wrong in RFC 6709, Section 4.4
on "Parameter Space Design".

    Brian

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Jan 2014 22:52:05 +0100

> Please read my words as carefully as a wrote them.

I did :-)

> There are excellent reasons why variable length IPv6 addresses would have been a bad idea. That is why I separated considerations for IP layer, DNS and Applications. 
> 
> At the application layer, the concerns are very different. Variable length identifiers are not a problem. We use them in RFC822, ASN.1, XML and JSON.

I do not see we MUST have variable length addresses in whatever protocol we have.

In DNS for example, we do not. Yes, lots of them, but not unlimited number of them.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sat, 04 Jan 2014 13:59:52 -0800

> What is needed is that the specification do have a consequence analysis regarding expansion of use.

This statement probably should serve as a touchstone to the general 
topic of seeking "design considerations" for new specifications and for 
any "interesting" features or choices that are made.

(Whether such a discussion is part of the specification itself, part of 
a separate document, or merely a highlighted part of the working group 
archive, is a separate issue.)

However pressing groups to make it possible for these considerations to 
be easily reviewed by others could be at least as interesting as getting 
groups to do more/better privacy considerations...

This would not pre-determine the content of acceptable discussion -- 
such as demanding variable- or fixed-length values -- but it presses the 
group to be thoughtful enough to defend and document its choices ahead 
of the choices' being challenged.

d/

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Jan 2014 23:14:05 +0100

Not a complaint on Dave or anyone else specifically in this thread BUT:

1. Jari posted a blog post about IANA, and I ask myself why IETF (yes, "we") can not stay focused

2. Jari explicitly said where comments where to be sent, and it was not this list

Now, to the very interesting topic we are discussing ;-)

On 4 jan 2014, at 22:59, Dave Crocker <[email-masked]> wrote:

> This statement probably should serve as a touchstone to the general topic of seeking "design considerations" for new specifications and for any "interesting" features or choices that are made.
> 
> (Whether such a discussion is part of the specification itself, part of a separate document, or merely a highlighted part of the working group archive, is a separate issue.)
> 
> However pressing groups to make it possible for these considerations to be easily reviewed by others could be at least as interesting as getting groups to do more/better privacy considerations...
> 
> This would not pre-determine the content of acceptable discussion -- such as demanding variable- or fixed-length values -- but it presses the group to be thoughtful enough to defend and document its choices ahead of the choices' being challenged.

Yes, but I was more thinking of how good it would be *if* we start talk about scaling seriously in the form of the designer would talk about what design criteria was part of the design, and(!) what suggestions there are about changes if/when the address space is not large enough.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2014 21:44:24 -0500

> In DNS for example, we do not. Yes, lots of them, but not unlimited number

In my original post I set out three cases, IP, DNS and everything else. I
stated that the extensibility requirement should apply as a MUST only to
everything else and that it should only apply to DNS if there was a major
backwards incompatible change.

The response I got was that people cut the post to say all code points
should be effectively unlimited and then gave first IP as an example and
now you are giving DNS as an example.

DNS is not an application layer protocol, it is one of the layers on which
applications build.

---

From: manning bill <[email-masked]>
Date: Sat, 4 Jan 2014 22:16:06 -0800

Jari, you can’t be serious.  unlimited means -without- limit, not just the limits of your imagination.
Patrick,  perhaps more to the point, the ramifications (consequence analysis) of managing transitions between variable code/address realms.  
Its not just expansion, its flow between larger/smaller, and smaller/larger.
we are back to NAT/ALGs _again_

/bill
Neca eos omnes.  Deus suos agnoscet.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Jan 2014 09:06:23 +0100

> 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.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sun, 05 Jan 2014 13:56:04 +0100

Hi Phillip,

On 1/4/14 7:43 PM, Phillip Hallam-Baker wrote:

> IETF should only endorse a single core set of algorithms with a
> maximum of one preferred and one alternative algorithm and this should
> be an IETF consensus, not a WG consensus. A WG might add in additional
> recommendations to support legacy interop, for example 3DES is still a
> defacto requirement for S/MIME.

The 1+1 approach seems a good ideal from an interoperability
perspective.  What we the IETF lack is sufficient expertise to "endorse"
crypto.  Yes we have some people who know some stuff, but not at the
heavy math end of it, which is where you want it.  The benefit of
developing this expertise would be that there could be a go-to place
that is viewed by governments without the need to develop their own
specifications or endorse "in country" specifications.  But that will
take a long time.  This could also be done elsewhere, but the key would
be to follow the OpenStand principles.

How this stuff is endorsed (e.g., an IETF working group or by the whole
of the IETF) is an interesting question.  The question that must be
answered is whether all of our specifications would make use of the same
algorithm in the same way.  If the answer is yes, then we can shut down
registries.  I fear the answer is no, but the aspiration is still a good
one, when it is possible.  Arguably what you are really getting at is
that we need to have the right common building blocks to handle all of
encryption (e.g., TLS, S/MIME, and a few others).  Developers want to
reuse code.  My personal experience is that I have perhaps re-used code
(maybe as we all have) in ways that it was really not intended to be
used, hoping that the semantics were sufficiently close to intended use
(think RFC-5218 and "wildly successful").

Ok, that's my Sunday blather.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Jan 2014 12:36:03 -0500

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?

> Bill, it was not Jari, it was Phillip Hallam-Baker that said "unlimited",

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.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 05 Jan 2014 10:25:47 -0800

> 1. Jari posted a blog post about IANA, and I ask myself why IETF (yes, "we") can not stay focused

Email group discussions are easily distracted because:

    1) the group often does not share a strong sense of needing to stay 
focused, and

    2) no one carries the task of trying to help the group stay focused.

Neither of these is special to this mailing list, and we have all seen 
face-to-face meetings suffer the same problem.  However in normal group 
meetings, there is usually pressure to be productive.  We we typically 
have someone driving discussion and getting group agreement to have the 
focus created by that driving.

If we want IETF discussions to do a better job of staying focused, we 
need for a topic to have a facilitator who presses for that focus and we 
need them to do the usual summarizing and polling that we use elsewhere 
in the IETF.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jan 2014 08:01:29 +1300

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Jan 2014 14:47:39 -0500

I know it is there in theory from the IETF end and in practice at the IANA
end. I didn't see Jari advancing that as a goal in the article.

But that theory does not quite align with the current registry organization
with the crypto alg registries aligned to protocols rather than being
generic identifiers. And there is still an element that believes that the
purpose of the IETF is to protect the Internet from the mistakes of bad
wizards.

What I am doing is thinking through what it would take to make the theory a
reality. Right now we have a bizarre situation where W3C takes the IETF
crypto alg names, splices a URL prefix on the front and cuts a new URL.

The DANE folk just tried to define alg identifiers for their spec and found
that there were four different labels defined for SHA-2, 256 bit in the
IETF already.

On Sun, Jan 5, 2014 at 2:01 PM, Brian E Carpenter <
[email-masked]> wrote:

> >> Bill, it was not Jari, it was Phillip Hallam-Baker that said
> "unlimited",
> >> which I objected to.
> >>
> >

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 5 Jan 2014 21:13:07 +0100

I already asked/suggested the general area director to have WGs in the area
because I want focus as well, but I don't mind your suggestion to have
facilitators that help focus in discussion or to guide productivity. I
already commented in the 2013 review thread that the area need
more organise.

AB

On Sunday, January 5, 2014, Dave Crocker wrote:

> meetings, there is usually pressure to be productive.  We we typically have
> someone driving discussion and getting group agreement to have the focus
> created by that driving.
>
> If we want IETF discussions to do a better job of staying focused, we need
> for a topic to have a facilitator who presses for that focus and we need
> them to do the usual summarizing and polling that we use elsewhere in the
> IETF.
>
> d/
> --
> Dave Crocker

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Jan 2014 00:14:45 -0500

What Jari posted:

" What is IANA, how does it work, how is it related to the IETF, and how
has it evolved over time? How will it evolve in the future, and how can you
participate in the discussion?"

Excuse me but when someone invites me to engage in an open ended
conversation about the future of an Internet institution I intend to do
precisely that.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 6 Jan 2014 04:02:34 -0800

I don't mind discussion branching off to new directions, sometimes we discover useful new things because of that. Phillip had an angle about this topic that I think is worthwhile to think about.

Of course, it doesn't take away the need to discuss other angles. How we manage registries that we still need continues to be an important topic. We've gotten some feedback on that on this and the IAB list, and hopefully we'll get some more. One of my goals with the article was to get that discussion started, and draw attention to Olaf's document. Please keep those comments coming.

(And maybe there's a lesson there for other things that come up during the discussion. Writing a draft and making a proposal, building support for it are good things.)

Jari

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Jan 2014 12:56:26 -0500

Jari,
> Here I am not so sure. Registries for adding specific crypto algorithms are not merely number allocations; they go with specifications and code that actually runs, say, AES on IPsec or AES on TLS.…
I concur with your observation wrt crypto algs. One size (alg or even 
key length) does
not fit all. When we introduce new protocols we have more flexibility in 
adopting new
algs and it may make sense to mandate support for them. For existing 
protocols
insisting that new algs be supported impose a greater burden and perhaps 
a long
transition  process.  In some contexts a suite of new algs can be 
incrementally
deployed with minimal impact, whereas in other contexts changes must be 
adopted
globally.

Steve