Subject: Re: I-D ACTION:draft-klensin-iana-reg-policy-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jul 2005 09:31:42 +0200

I'm a bit surprised that this version retains without comment the
retroactive clause that several people commented adversely on:

    In summary, unless the "scarcity" rules of Section 3 apply, this
    document updates all "IANA registration" documents and "IANA
    considerations" sections of documents to clarify the point that
    registration review is to focus on the issues above, rather than on
    concerns about, e.g., whether one protocol approach is better than
    another one.

Without arguing about the guidelines for *future* IANA Considerations,
I really don't see how we can reasonably make a blanket revision of
existing ones, that were presumably developed intentionally in their
present form.

Thinking about it, the last clause of the paragraph above is quite
surprising. Even for IP version numbers, it wasn't done this way
(6, 7, 8 and 9 were all assigned to competing proposals for IPng).
I think this clause is worrying about something that never happened.

I would be happier if the above paragraph said something like

    In summary, unless the "scarcity" rules of Section 3 apply, this
    document describes the way in which "IANA registration" documents
    and "IANA considerations" sections of documents will be interpreted
    in future, to clarify the point that registration review is to focus
    on the issues above.

    Brian

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Jul 2005 14:55:29 -0400

--On Monday, 25 July, 2005 09:31 +0200 Brian E Carpenter
<[email-masked]> wrote:

> I'm a bit surprised that this version retains without comment
> the retroactive clause that several people commented adversely
> on:

> Without arguing about the guidelines for *future* IANA
> Considerations, I really don't see how we can reasonably make
> a blanket revision of existing ones, that were presumably
> developed intentionally in their present form.

Probably it should have been explicitly flagged, for which I
apologize.  But it intentionally said "clarify" and one cannot
"clarify" something that already clearly means something else.
The difficulty, IMO, is with the belief about intentions:  There
are probably exceptions, but the majority of the IANA
considerations sections that I looked at before writing that
section suffer, unsurprisingly, from the same core problem from
which, in retrospect RFC 2434 suffers: they specify who does the
evaluation, but not the criteria for making a decision.  To the
extent to which that is true, the above paragraph was intended
to supply missing evaluation criteria, which doesn't change any
existing and documented intentions.  It was not intended to
change either the established models of by whom and how the
evaluation is done or any clear statements about evaluation
criteria (if and where those exist).

Nor was this intended to change any registration that had
already been made.

In retrospect, it would have been better to write that statement
with something like "...in the absence of specific evaluation
criteria in the existing documents...".  I will mark something
equivalent to that into the working version in the event that
there is a -02.   But I suspect that change would not have made
"those who commented adversely" much happier.

> Thinking about it, the last clause of the paragraph above is
> quite surprising. Even for IP version numbers, it wasn't done
> this way (6, 7, 8 and 9 were all assigned to competing
> proposals for IPng). 

The IPng effort operated in a way that made all of those
competing proposals IETF efforts, developed (and their numbers
assigned) under the umbrella and leadership of IETF WGs and an
IETF special-purpose area.   These assignments were also made by
the "old" IANA, rather that under close technical supervision of
registrations by the IESG or its designees.  The IANA reg policy
document is intended to clarify things so that the registration
mechanisms are not used to stifle innovations that do not
originate in IETF processes, so it isn't clear to me that the
above example is relevant to the matter at hand.

> I think this clause is worrying about something that never

If there were no concerns about things that have happened and
the associated clear opportunities for misunderstandings and
accusations about abuse, the document never would have been
written.  If it addresses some issues that have not specifically
occurred, that is normally called "establishing principles" as
contrasted with "confining oneself to fighting the last war".

>     in future, to clarify the point that registration review

Noted, and noted in the working version of -02.

       john