Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]