Subject: When should a new IANA registry be created

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Dec 2004 11:58:35 -0800

There is the beginning of yet another debate on the SIMPLE mailing list
about do we need an IANA registry from some fields in a specific draft.
There does not seem to be a clear opinion on when to create a registry or
not and past activities are not 100% consistent. I'm sure this has come up
many times before. Are there some things I should go read that help shed
light on this?

Could the IAB give any advice here? Is it good to use IANA just as a
convenient place to go find links to all the RFC you might need to know
about? Should we only have a registry only if there is a real possibility to
two values being allocated to two different things (when the value was
supposed to be unique). Who can is in a good position to help sort this out
IAB? IESG? Other? 

Thanks, Cullen

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 20 Dec 2004 08:21:08 +0100

If there is something in an RFC that clearly is "a parameter", then it 
is not a bad idea to have an IANA registry. By creating a registry, you 
can yourself set the requirements for assignment. For example, is an 
RFC needed? Is IESG approval needed? Is just review on a mailing list 
(and an expert) enough?

My view is that any protocol parameter should be in a registry, so it 
is easy to go to ONE location and see what's up. Especially if the list 
of allowed parameters might be changed/updated in updates to the RFC 
you are writing.

       paf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Dec 2004 14:28:52 +0100

In general, any time you have a set of values that can change over time, 
and there is a reason for the community to know the currently-valid set of 
values, a registry is a Good Thing.

One example of when a registry is NOT needed: error codes in 
draft-ietf-rohc-sigcomp-nack, where the author says:

> RFC3320 is very explicit in calling out what conditions can lead to
> decompression failures. Quite simply, if a set of circumstances isn't
> detailed as a decompression failure in RFC3320, then it can't get
> reported in a NACK. By the working group's analysis, for version 0x02 of
> SigComp (defined in the draft being discussed), there are precisely 25
> things that can go wrong.
>
> This list of errors, then, can not change unless and until a new version
> of SigComp is issued. If you consider the NACK codes to be scoped to the
> version of SigComp being used, then the need for a registry disappears.

The same draft uses a registry for the version numbers for the SigComp 
protocol itself - here, people can encounter the value "2" when they 
expected "1", and can use the registry to figure out which document defines 
the new version:

5. IANA Considerations

   This document defines a new value for the IANA registered attribute
   SigComp_version.

   Value (in hex): 02

   Description: SigComp version 2 (NACK support)

   Reference: [RFCXXXX]

So the answer is "it depends".....

--On 18. desember 2004 11:58 -0800 Cullen Jennings <[email-masked]> wrote:

> about? Should we only have a registry only if there is a real possibility
> to two values being allocated to two different things (when the value was
> supposed to be unique). Who can is in a good position to help sort this
> out IAB? IESG? Other?
>
> Thanks, Cullen
>
>
>
>

---

From: Robert Elz <[email-masked]>
Date: Mon, 20 Dec 2004 21:52:53 +0700

Date:        Mon, 20 Dec 2004 14:28:52 +0100
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <55A053496CEEFA928DC9B120@B50854F0A9192E8EC6CDA126>

  | In general, any time you have a set of values that can change over time, 
  | and there is a reason for the community to know the currently-valid set of 
  | values, a registry is a Good Thing.

The one caveat is that the set of values needs to be stable enough
that maintaining a registry makes sense.

To take one example of the contrary case - multicast group IDs.
There is an IANA registry of blocks and their uses, and a few specific
groups - but most groups come and go with no registry (IANA registry)
action at all.

And yet, both conditions as stated by Harald are met - there is a set
of values that change over time (obviously) and the community have
reason to know the current set of values - both so they know what a
particular value maps into (so they can join the appropriate group),
and so they know what values are free (so an appropriate identifier can
be selected for a new group).

Yet an IANA registry of such values would not be a good thing, they often
survive for less time than it would take to get the registry updated - that
is, by the time the update could be done, the updated data is already
obsolete.

kre