Date: Thu, 7 Jul 2005 22:25:18 -0700 (PDT)
From: "C. M. Heard" <heard@xxxxxxxxx>
Message-ID: <Pine.LNX.4.10.10507071808220.2427-100000@xxxxxxxxxxxxxxxxxx>
| Would it be unreasonable to ask that you point to some text in the
| document to support your claim? Or lacking that, to point to some
| publically archived discussion (e.g. last call comments) that
| support your position?
My memory isn't good enough for last call comments, certainly not 7 years
ago. I actually doubt that there were many, 2434 as it stands isn't
something that would have evoked much controversy I suspect.
The relevant part is from section 2, basicly all of page 5 of the doc.
The section that starts "The following are example policies..." and goes to
the end of section 2 (into page 6) - though the last paragraph of
section 2 isn't really material (that just says about being able to
have some parts of a name space assigned under one policy and other
parts under a different one - which 2780 does not do for IPv6 options).
All that text in 2434 is just 'examples' but becomes normative when
incorporated by reference in another rfc (like 2780) which is quite
common.
Read the "examples" (which have turned into the de-facto policy choice
list) to see the text in question.
Every one of the 'examples' is about what documentation is required.
This is no surprise - what's being done is to give working groups
example policies that show what is reasonable to give as a policy to
IANA in order to register a "name" in one of the registries.
The range from nothing at all (not even any registry, just self
assignment) at the begining to the existance of a standards track
RFC at the high end. I suspect that many people are getting
confused by the process necessary to get a standards track RFC,
and assuming that all of the review that happens there is relevant.
It is, but only to the process of defining the protocol, IANA does
not need to care about any of that - for IANA, the simple existence
of a standards track RFC that calls for (or assigns) a name from
a registry is enough for a "Standards Action" 'example' registry.
Everything between is about documentation requirements, just read
them ...
"Anyone can obtain an assigned number, so
long as they provide a point of contact and a brief
description ..."
"Values and their meaning must be
documented in an RFC or other permanent ..."
"New assignments must be approved by the IESG, but
there is no requirement that the request be documented in an
RFC (though the IESG has discretion to request documents or
other supporting materials ..."
"...new assignments are made via RFCs approved by the IESG...."
"Values are assigned only for Standards Track RFCs ..."
They're all centred around the documentation that needs to be available
(or does not need to be available). There isn't one word about any
other criteria for IANA to use (or anyone else to use) when deciding
on assignments. Nothing about refusing assignments from blue haired
Klingons on alternate Thursdays, or anything else like that. True,
it doesn't explicitly say that hair colour of the applicant cannot be
considered, as it doesn't say that lots of other things cannot be
considered - but nor does it need to.
There's no question but that a WG could, if it wanted, impose any
kind of bizarre requirements (there is no requirement to stick to the
list of example assignment policies), but to do so it would have to
justify what it wants when asked during last call, and anything
"peculiar" (such as: "only to protocols that we approve of") would
likely get considerable pushback.
The bulk of the doc is advice to working groups about which policies
might be useful under what circumstances, and some requirements that
WG's must handle in order to get IANA to create a registry and
perform parameter assignment. That's all relevant when a WG is
creating a new registry (or modifying one) and not relevant at all
right now.
kre
ps: I believe this is my last word on this topic. It has gone on
long enough. I have no idea what is currently happening with the
request for this particular option, but I certainly hope that an
IAB appeal is under way (as the IESG have quite clearly refused to
reconsider their position, I would take it that that part of the 2026
requirememts of the appeal process is now well and truly satisfied).
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf