Subject: Examples needed of IANA values in -bis documents

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Nov 2009 18:17:46 -0800

Greetings again. Yaron and I have an interesting situation in the IPsecME WG, and we are looking for historical experience from other WGs that might relate to it. We are doing a -bis revision to IKEv2 (RFC 4306). RFC 4306 contains many tables with values that were used to fill in the IANA IKEv2 registry. Our -bis document has carried those tables forward, but we have gotten some questions about what the tables mean given that the IANA registry now has additional entries added after RFC 4306 was published.

Some folks would like to see the values removed from the -bis document and statements added that developers should see the IANA registry. Some folks would like to leave the tables as they were. Some folks would like to see the tables left in and updated to match the current registry.

Yaron and I would like to find WGs that have already faced this issue and find out what you did, and whether it was considered a good idea afterward. We are *not* looking for more opinions; we have plenty of those already. What would be most useful to our WG is examples of what has happened in the IETF in the past. Thanks in advance!

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Taylor <[email-masked]>
Date: Sun, 29 Nov 2009 22:39:00 -0500

A situation like that is fairly routine in AVT. Have a look at the RTP 
registries, http://www.iana.org/assignments/rtp-parameters. Basically the bis 
RFC replaces the original as the primary reference in the directory where 
appropriate. Your choice on the added values is to include them in the bis 
document or leave the primary reference to whatever other RFC defined them, but 
it probably doesn't matter which you do unless you have conflicts to sort out.

Paul Hoffman wrote:
> Greetings again. Yaron and I have an interesting situation in the IPsecME WG,
> and we are looking for historical experience from other WGs that might relate
> to it. We are doing a -bis revision to IKEv2 (RFC 4306). RFC 4306 contains
> many tables with values that were used to fill in the IANA IKEv2 registry.
> Our -bis document has carried those tables forward, but we have gotten some
> questions about what the tables mean given that the IANA registry now has
> additional entries added after RFC 4306 was published.
> 
> Some folks would like to see the values removed from the -bis document and
> statements added that developers should see the IANA registry. Some folks
> would like to leave the tables as they were. Some folks would like to see the
> tables left in and updated to match the current registry.
> 
> Yaron and I would like to find WGs that have already faced this issue and
> find out what you did, and whether it was considered a good idea afterward.
> We are *not* looking for more opinions; we have plenty of those already. What
> would be most useful to our WG is examples of what has happened in the IETF
> in the past. Thanks in advance!
> 
> --Paul Hoffman, Director --VPN Consortium
> 
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Nov 2009 15:42:42 +0900

Hello Paul,

The LTRU WG's main job (as the name says: Language Tag Registry Update) 
was to update data in the IANA registry (two times, under two different 
charters).

The updates happened via Internet-Drafts. We separated the 'protocol' 
aspects (going to RFC as is) from the registry update data (going to IANA).

We were very concerned about people looking at a future RFC (frozen) 
rather than the IANA registry (actively updated). Therefore, the RFC 
Editor was instructed to remove the bulk of the 'registry update' draft 
before publishing it to an RFC.

See http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10 (close to 1000 
pages) vs. http://tools.ietf.org/html/rfc5645 (11 pages) for the most 
recent charter.

For the first charter, see 
http://tools.ietf.org/html/draft-ietf-ltru-initial-06 (118 pages) vs. 
http://tools.ietf.org/html/rfc4645 (7 pages).

In the first round, it took quite a bit of time to work this out, but I 
don't think anybody involved has any reasons to regret this aspect of 
our work, I think overall, it worked really well. As a consequence, none 
of the people involved had to spend unproductive time telling others 
"well, the RFC is incomplete/irrelevant, the IANA registry is what counts".

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Roni Even <[email-masked]>
Date: Mon, 30 Nov 2009 09:13:09 +0200

Just to add to Tom's suggestion. If you decide to review the registry you
should also try to remove unused values, this may be important in order to
address the issue of having interoperable applications that use them.
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Taylor
> Sent: Monday, November 30, 2009 5:39 AM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: Examples needed of IANA values in -bis documents
>

---

From: <[email-masked]>
Date: Mon, 30 Nov 2009 09:55:52 +0100

In TLS WG, the TLS 1.2 spec (RFC 5246) contains only the numbers that
are defined in RFC 5246 (but not the numbers defined in 15+ other
TLS-related RFCs).

(This means an implementor implementing RFC 5246 doesn't have to read
the IANA registry -- all the required numbers are in the RFC, too.)

The IANA considerations section asked IANA to update the references in
those registries to point to RFC 5246, and repeated the allocation
policies for convenience. 

Best regards,
Pasi

> Behalf Of ext Paul Hoffman
> Sent: 30 November, 2009 04:18
> To: [email-masked]
> Subject: Examples needed of IANA values in -bis documents
> 
> Greetings again. Yaron and I have an interesting situation in the
> IPsecME WG, and we are looking for historical experience from other WGs
> that might relate to it. We are doing a -bis revision to IKEv2 (RFC
> 4306). RFC 4306 contains many tables with values that were used to fill
> in the IANA IKEv2 registry. Our -bis document has carried those tables
> forward, but we have gotten some questions about what the tables mean
> given that the IANA registry now has additional entries added after RFC
> 4306 was published.
> 
> Some folks would like to see the values removed from the -bis document
> and statements added that developers should see the IANA registry. Some
> folks would like to leave the tables as they were. Some folks would
> like to see the tables left in and updated to match the current
> registry.
> 
> Yaron and I would like to find WGs that have already faced this issue
> and find out what you did, and whether it was considered a good idea
> afterward. We are *not* looking for more opinions; we have plenty of
> those already. What would be most useful to our WG is examples of what
> has happened in the IETF in the past. Thanks in advance!
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 30 Nov 2009 09:07:15 -0500

to me, the registries have their own life. Therefore, it is almost 
impossible to try to sync an RFC with a snapshot of a registry. They 
will always be out of sync. Therefore, I would highly suggest that:
a) the registry creating RFC contains the initial tables
b) any other RFC only specifies updates if any.

to me, a -bis document is b)

Marc.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Nov 2009 15:54:34 +0100

Paul, Mark, Others,

It seems to me it depends on the registry and the update policies, as 
well as the purpose of a -bis.  If the -bis is really meant to REPLACE 
the existing version, then a complete registry review would seem in 
order, so that you have a complete replacement.  We went through such a 
review process in Calsify, even though most of the registries didn't 
even exist.  One of the things we ended up reviewing was, in fact, the 
update policy to each table.

Warm regards from snowy (as of today) Switzerland,

Eliot

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 30 Nov 2009 10:03:29 -0500

> update policy to each table.

this is inline with what I just wrote. If you need a complete new 
registry (or a new version of a registry so different that it can be 
considered as a new registry), then specify the whole registry in the RFC.

if it is an update of a registry, do not specify the whole registry in 
the RFC.

to me, the fact that the RFC is a -bis does not have an impact to the 
rule above.

Marc.

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 30 Nov 2009 08:31:06 -0800

Hello Paul,

Just letting you know that I'm following the conversation and if there are any coordination efforts I can assist with please let me know.

Michelle Cotton
IANA

On 11/29/09 6:17 PM, "Paul Hoffman" <[email-masked]> wrote:

--Paul Hoffman, Director
--VPN Consortium