Subject: Re: [TLS] request for early IANA assignment for ALPN

From: Sean Turner <[email-masked]>
Date: Tue, 09 Apr 2013 12:13:44 -0400

On 3/27/13 3:16 AM, Nikos Mavrogiannopoulos wrote:
> On 03/27/2013 01:41 AM, Sean Turner wrote:
>
>
>> Based on the WG adopting the TLS-based upper-layer protocol negotiation
>> mechanism working item in Atlanta, what looks like consensus to me on
>> using ALPN, and the fact that we're not exactly running out of code
>
>
> The advantage of no point registration during draft stage is that
> contributors are not limited by arguments like "this is now implemented
> and deployed - too difficult to change". The disadvantage is no
> interoperability testing.
>
> However, I'd find it nice to easily reserve points for ciphersuites or
> other TLS IANA managed points at an early stage of a draft for
> interoperability testing. Those points could be reserved for a limited
> time and kept if the RFC is identical to the draft. So I think that such
> process should be generalized, if possible, rather than applied only for
> ALPN.

There's a process for this that is documented in RFC 4020 ;)

One can request an early IANA code point assignment if the registry 
supports it, the draft is stable, the processing rules are clear, and 
there's pre-RFC deployment interest, etc.  According to RFC 4020 
registries eligible for early assignment are Standards Action.  IANA 
will also accept IESG approved requests for IETF Consensus.  When RFC 
4020bis is out it will open up to "Specification Required" (where an RFC 
will be used as the stable reference), "RFC Required", "IETF Review", or 
"Standards Action".

It's obviously more complicated than just requesting a value in a 
registry with particular rules.  The request process is documented here:
https://tools.ietf.org/html/rfc4020#section-3.1.

Note the final point in s3.1:

  5) IANA makes an allocation from the appropriate registry, marking it
     as "temporary", valid for a period of one year from the date of
     allocation.  The date of allocation should also be recorded in the
     registry and made visible to the public.

So basically, what you're asking for is this, assuming I understand your 
request.

Now before everybody starts flooding me with request, if it's TLS 
related I'm going to be redirecting the request to the WG chairs to 
first determine whether the draft should be a WG draft.  If so, then 
it'll need to be adopted by the WG (or about to be adopted), be stable, 
be well-documented, and there's sufficient interest in pre-RFC 
deployment etc..  That'll all get weighed by the chairs.  If the WG 
isn't interested in adopting the draft as WG item, I'm likely still 
going to be coming back to the WG later to make sure it won't break 
anything similar to how cipher suites LCs get shared with the WG.

spt

---

From: Yoav Nir <[email-masked]>
Date: Wed, 10 Apr 2013 05:23:27 +0000

On Apr 9, 2013, at 7:13 PM, Sean Turner <[email-masked]> wrote:

> One can request an early IANA code point assignment if the registry supports it, the draft is stable, the processing rules are clear, and there's pre-RFC deployment interest, etc.  According to RFC 4020 registries eligible for early assignment are Standards Action.  IANA will also accept IESG approved requests for IETF Consensus.  When RFC 4020bis is out it will open up to "Specification Required" (where an RFC will be used as the stable reference), "RFC Required", "IETF Review", or "Standards Action".
> 
> It's obviously more complicated than just requesting a value in a registry with particular rules.  The request process is documented here:
> So basically, what you're asking for is this, assuming I understand your request.
> 
> Now before everybody starts flooding me with request, if it's TLS related I'm going to be redirecting the request to the WG chairs to first determine whether the draft should be a WG draft.

But ALPN is already a WG draft (although it wasn't when the question was asked):
http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00

>  If so, then it'll need to be adopted by the WG (or about to be adopted),

Done.

> be stable, be well-documented, and there's sufficient interest in pre-RFC deployment etc..  That'll all get weighed by the chairs.  If the WG isn't interested in adopting the draft as WG item, I'm likely still going to be coming back to the WG later to make sure it won't break anything similar to how cipher suites LCs get shared with the WG.

It's hard to say about stable, as this is a -00 version based on a -02 version. But there definitely is interest in deploying sooner rather than later.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 10 Apr 2013 09:17:35 +0200

> There's a process for this that is documented in RFC 4020 ;)

Didn't know that. That's indeed pretty useful process. Thank you for
bringing that up.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 10 Apr 2013 12:54:19 +0200

On Tue, Apr 9, 2013 at 6:13 PM, Sean Turner <[email-masked]> wrote:

> there's pre-RFC deployment interest, etc.  According to RFC 4020 registries
> eligible for early assignment are Standards Action.  IANA will also accept
> IESG approved requests for IETF Consensus.  When RFC 4020bis is out it will
> open up to "Specification Required" (where an RFC will be used as the
> stable reference), "RFC Required", "IETF Review", or "Standards Action".
>

btw. may I ask what is the process to propose another NameType to be used
in the server_name extension of RFC6066. I am thinking of using that field
in order to distinguish between different servers under the same host_name
using a UUID as a distinguisher. However, my understanding is that this
isn't possible as there is no registry to extend.

This is related to my question in
http://www.ietf.org/mail-archive/web/tls/current/msg09265.html

regards,
Nikos