--On Monday, 25 July, 2005 09:31 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
> 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.
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
> happened.
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".
> 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.
Noted, and noted in the working version of -02.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf