Subject: Re: IANA assignments

From: Thomas Narten <[email-masked]>
Date: Fri, 16 Jan 2004 07:13:44 -0500

>   All I am saying is, IANA can have a guideline for long lived
>   drafts, such as:
>   
>      If there is a shipped implementation with an old deprecated
>      value, that value MUST be reserved to prevent future misuse.
>      It MUST be noted in the subsequent drafts and final RFC.

Well, a more proper way to express the above (process wise) would be
to have an IANA considerations Section (for the name space at issue)
of something like:

   values in the range 0-128 are assigned via Standards Action or
   Expert Review. The purpose of Expert Review assignments is for the
   assignment of code points in cases where the document is expected
   to become published as a standards track RFC (e.g., it is a Working
   Group document), but for which experimentation is desired before
   the RFC is published.

Tune further as appropriate. Then, when a WG needs an assignment, it
asks IANA to make the assignment, IANA checks with the expert, and
assuming the request is proper, the assignment gets made.

The point is that there are ways for the WG to retain control over
assignments that IANA is managing. That is what IANA Considerations
sections are for.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 16 Jan 2004 07:12:18 -0500

>   Is it possible for IANA to initiate a discussion in the mailing-list
>   before publishing a value, at least, for long lived drafts ?

Not really practical. Please see RFC 2434, where it talks about
mailing lists. Bottom line: IANA doesn't have the resources or
subject-matter expertise to read mailing list discussions and make
sense out of the diverse opinions that tend to get expressed.

But one can certainly write an IANA considerations section (again see
RFC 2434) that specifies that a Designated Expert should make the
evaluation, and one of the steps of that process could be to check
with relevant WGs first, and so forth.

WGs have a lot of flexibility in defining how they want their name
spaces managed. But IANA certainly can't guess what the right thing to
do is. That's why it's so important the authors/WGs pay attention to
IANA considerations and specify them carefully.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 16 Jan 2004 07:16:42 -0500

> The priority here is simple: the *IETF* has asked IANA for assignment
> of a code point; the most reasonable value of that code point *based
> on implementations of the IETF draft/RFC* is 4.

This may well be a correct statement, prior to IANA having made the
assignment. Now that they have published 3 as the "correct" value,
things are no longer so simple.

> The OIF is *not* a standards organization; for the IETF to change
> what is the right decision based on premature actions of the OIF is
> a sign of weakness.  In any case, 'signs of weakness' should NOT be
> our guiding principle -- we should do what is right and reasonable.

This is not about weakness. A fundamental property of assignments is
that they are stable and do not change. Once IANA makes an assignment,
it needs to have very very very good reasons for backing out and
making a change.

> BTW, to put this in perspective, OIF UNI1.0 uses a code point value
> of 4.  If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
> seems to me that the OIF really jumped the gun: the RFC has not been
> published and discussion of code point assignments is not complete.

Actually, the IANA assignment step and RFC publication are
different. The IANA step occurs when IANA announces its assignment
(whether via email, by posting a message, by updating their web pages,
etc.). An RFC can't be published until after IANA makes any relevant
assignments. So even though the RFC may not be out, the code point
assignment has been completed, officially.

> Perhaps the OIF can approve (as soon as we complete the discussion and
> reach the right conclusion) UNI1.0r3 with the correct value.

It would be extremely useful for someone to ask OIF about the
feasibility of this. And to comment on what other organization may
have picked up the IANA-published value at this point.

> I stand by my recommendation that IANA assign a value of 4 for the
> SDH/SONET C-Types for FLOWSPEC and TSPEC.

I think we all agree that would have been the logical assignment.
Problem is, we're past that point now and reversing an assignment is
not so simple.

Thomas