Date: Mon, 27 Jun 2005 13:28:24 -0400
From: Thomas Narten <narten@xxxxxxxxxx>
Message-ID: <200506271728.j5RHSOK4010945@xxxxxxxxxxxxxxxxxxxxxxx>
| What 2434 says about "IESG approval" is:
|
| > IESG Approval - 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 on a case-by-case basis).
|
| (as an author) I agree that the "must" wording is poor and would be
| better replaced by something like "may".
I wouldn't object to that change. As worded, it may imply that the IESG
has no option but to approve any request made to it, which I would agree
was never the intention.
However:
| I would also add wording saying that "IESG Approval" is intended for
| unusual circumstances, with the preferred approval through something
| involving IETF review (e.g., "Standards Action").
I would certainly do nothing at all like that, and would not agree to
any such change.
2434 has a list of "example" policies for RFC authors to select from,
that is, overall, so comprehensive, that almost no-one bothers to
think up any others.
In 2434 there's the complete range, from "Private Use" (which amounts to
"no-one cares, do whatever you like, no registration possible" through
"FCFS" (anyone can ask, the first to ask for a particular value, gets it),
all the way up to "IETF standards action" (only specifications approved
by the IETF as being "good things" can get values assigned).
The working group that defines the field in which the value is to
be used gets to select which mechanism is appropriate to use for
that particular field (with IETF review via last call and all of
that of course).
There are 5 main levels of requirement that make sense,
1. anything goes (no registration)
2. anyone can register (fcfs)
3. anything properly documented can be registered
4. anything published as an RFC can be registered
5. anything that is on the IETF standards track can be registered
These give increasing levels of "review required" to be applied
to the particular field, from none at all (the first two, except
that 2 at least requires a contact point, and general description
of purpose), through "must be documented" (basically so others
can implement it) but with no rules as to how that documentation is
necessarily done, to any RFC, so now we have rules about what the
doc must be, and how it gets published, but informational RFCs and
even experimental, qualify, and will generally mean that nothing that
is actually harmful to the protocol stack will be included, and finally,
standards action, which implies IETF approval that the proposal that
uses the new code is a "good thing" and worth of being added to the
stack.
In 2434 terms those more or less equate to
1. Private Use, and Hierarchical Allocation
2. First Come First Served
3. Specification Required (maybe Expert Review)
4. IETF Consensus
5. Standards Action
The question then arises, just where does "IESG Approval" fit
in this scheme of things, as it is the one being used here.
Your suggestion is that it is a last resort escape clause, almost a
way for the IESG to decide to ignore the rules for special cases
where they would cause hardship.
But that's not supported by any evidence whatever. First, that isn't
what 2434 actually says, it doesn't even hint that. Rather, IESG Approval
is placed in the list of increasing "reviewedness" right between "specification
required" and "IETF Consensus", it isn't held to the end as a last resort,
or placed in a separate section.
What's more, no exception clause like that is required, RFC2026 already
has the "Variance Procedure" by which the rules can be waived, or temporarily
altered, in circumstances that really require that.
So, my interpretation would be, that "IESG approval" means just what it
appears to mean in 2434 - that is, something that ranks between specification
required, and IETF consensus. That is, it expressly does not require
the IETF to agree that the proposal is even good enough to publish as an
experimental protocol.
We get now to what should be involved in the approval part of "IESG Approval".
The IESG seems to be taking that to mean that they can do whatever they
like, and if they don't like the the specification, they can, and some have
said, even should, or must, reject the application.
That's clearly nonsense. You quoted the paragraph above, but to save people
scrolling back through this long message, I will quote it again...
IESG Approval - 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 on a case-by-case basis).
That is, what is going on here, is clearly (to the point where it could
hardly be any clearer) all about documentation, and what documentation
is available.
Note, it quite clearly says "there is no requirement that the request be
documented in an RFC" - so the current suggestions that the proposal be
written up as an I-D, and submitted to (some unknown) IETF working group
for consideration are patently not required for an allocation under
this procedure.
As it says in the paragraph quoted from 2434, the IESG's role here is
to make certain that there is adequate documentation, and to request
more documentation, or other required supporting materials, as needed,
to satisfy the request.
Absolutely nothing about whether the request is for a protocol that
anyone on the planet cares anything about - were I to properly document
an option that would be used in the HBH options field and which would
cause routers processing the option to all explode with maximum
violence, the IESG has no grounds whatever for refusing to register
an option code for that option. Now, I don't see many router vendors
being ready to implement my "explode and kill the network, and any
people standing in the vicinity" option (though I suspect there are
plenty of people who'd appreciate it if I'd test my option for
effectiveness), but there's no reason whatever for it not to be
allocated an option code.
The working group, when 2780 was written, explicitly did NOT require
standards action for new option codes to be registered, it didn't
even require publication of an RFC (though either of those are other
ways to obtain option codes). All it requires is IESG approval, and
that means, IESG approval that the documentation is adequate, not that
the proposal is a good one.
| This all suggests that the case at hand is rather unusual and does not
| reflect the common case.
No-one has ever suggested that this is a common case. What is usually
done, in the common cases, is therefore irrelevant. This is clearly an
unusual case, everything about it is unusual. Being unusual doesn't
mean that we then have to attempt to force it to act just like all the
normal cases. Nor does it mean that we should reject it because it
is unusual, or because someone has their nose out of joint that anyone
would dare to step on what the IETF (or at least the current IESG) regards
as its private turf.
What the IESG did in this case was clearly way out of line. And once
again, I don't care what the protocol is that plans on using this option
(I still have not looked at the web site, where, contrary to what some
people keep saying, the use of the option is apparently documented for
anyone to see) as it simply does not matter what that protocol is.
Nor do I have any idea whether that documentation is actually sufficient to
allow the option to be allocated. Nor do I know if the option requested
might happen to be an (almost) duplicate of some other option that exists
(though there are currently so few, that being a duplicate would seem
unlikely). So, I am not saying, and never said that the IESG was required
to approve the application.
But, what I continue to claim, and nothing whatever that I have heard or
read has in any way made me doubt, that the IESG's actual actions, and
certainly their public response to the request, was way outside their
authority, and totally inappropriate, and MUST be corrected, either by
the IESG, or upon appeal, by the IAB.
If that doesn't happen, I would expect, and even encourage, the applicants
to simply pick their own option code, and inform IANA what they picked,
and are consequently using. At least that way, IANA can use its
discretion in allocating numbers to future requests to avoid colliding
with this one. The lack of the existence of this option in the IANA
registry will be something for which the (current) IESG will be totally
responsible - the applicants have done everything that the procedures
require them to do (or at least, there is currently no evidence to the
contrary).
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf