Hi,
At 12:53 PM +0700 7/1/05, Robert Elz wrote:
Failing to register whatever parameter they need, because the protocol
proposed is disgusting, even if true, helps absolutely no-one. On
the other hand, if the documentation of what the parameter means, or
how to use it, is inadequate, then refusing registration makes sense.
It is also immediately clear to the applicant what they need to do to
correct the problem - simply fix the quality of their documentation.
You seem to be arguing that the only thing that the IESG _should_
have done regarding this allocation was to determine whether or not a
document exists. You have indicated that the IESG should not have
assessed the technical properties of this specification, but, IMO,
your view is not supported by the categories in RFC 2434.
There are two different categories that will allow allocation based
on a non-RFC specification:
Specification Required - Values and their meaning must be
documented in an RFC or other permanent and readily available
reference, in sufficient detail so that interoperability
between independent implementations is possible.
Examples: SCSP [SCSP]
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).
The first of these (Specification Required) only means that the
specification must exist in a "permanent and readily available" form
and be sufficient detailed for interoperability. If the community
had wanted to allocate an IP option number to any individual or
standards body that could point to a permanent and readily available
document, then I personally assume that the community would have been
competent enough to make that choice, and would have left the
question of IESG approval out of this altogether.
But, what _the community_ actually chose as the lowest level of entry
to obtain an IP option number is "IESG Approval". IESG approval
can't mean that we have simply determined that there is a detailed
document -- that would be covered by "Specification Required". IESG
approval means that the IESG _approves_ of the allocation. And, in
this case, we did not do so.
According to my local Webster's dictionary, the word "approve" means:
"to have or express a favorable opinion of", "to accept as
satisfactory", or "to give formal or official sanction to".
So, it doesn't seem to me that someone can obligate me to approve of
something by pointing to the existence of a document. If you ask me
to approve something, you are asking me to exercise my judgement --
in this case, my judgement about whether an IP option number should
be allocated for this purpose without requiring an IETF consensus
document. If the community did not want the IESG to exercise
judgment in this particular situation, they should have chosen a
different threshold for IP option number allocation.
As an aside, I am not sure that this particular request would meet
the requirement for "Specification Required", either, as we have been
pointed to a non-archival document on Larry Robert's web site. If
there is a version of this document that currently exists in a
"permanent and readily available" form, I am not certain that I have
received a pointer to it. (I did get a pointer to another version of
the document, but I am not sure if that version is either archival or
publicly available).
BTW, for the people who may be asking "If the IESG didn't think they
could approve this themselves, why didn't they just immediately start
an IETF review process?" We can't start that process without an I-D.
The two available options are:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek
input on prospective assignments from appropriate persons
(e.g., a relevant Working Group if one exists).
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
Family Identifiers [BGP4-EXT].
Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG.
Both of these options would require Larry Roberts (or someone) to
submit an I-D. As I read the first one, I believe that he could
submit an I-D that makes the allocation and normatively refers to an
archival, publicly-available ITU specification (if one exists) for
information about how this option should be interpreted/used -- as
long as the ITU specification is permanent, readily available and
sufficiently detailed, I believe that this could consist of little
more than an IPR section, a reference to the ITU specification,an
IANA Considerations section and a normative reference.
The second choice would require that Larry (or someone) produce an
I-D for the option itself for standardization within the IETF. This
would seem like an odd choice for something that is under development
within the ITU.
I suppose that the IESG could have written back to Larry and said
"the IESG did not approve this document, please submit an I-D so that
we can bring it to the IETF for review", but we instead thought that
it would be wrong to encourage Larry to do more work when we consider
the possibility of IETF Consensus to be very low. Maybe it was wrong
(or confusing) of us to communicate that opinion in our response (and
if so, I apologize for my part in that).
At this point, the only decision that the IESG has actually made is
that we (the IESG) do not choose to approve this IP option number
allocation via the "IESG Approval" mechanism, and that any allocation
of this number will have to be done via the "IETF Consensus" or
"Standards Action" mechanisms. It is now up to Larry Robert's to
decide if he wishes to pursue one of the other options listed in RFC
2780 (and above).
Margaret
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf