Hi Robert,
At 1:18 AM +0700 7/2/05, Robert Elz wrote:
| 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.
No, I didn't say that at all, ever. What I said was that the IESG should
have determined whether there was adequate documentation for the option.
That is, whether the documentation was clear, unambiguous, complete, and
would allow an implementation of the option by someone who wanted to
do that, or for someone to understand what the bits in the packets
passing through their network are suppsred to mean.
In what way would that differ from "Specification Required"?
This is _not_ the choice that was made in RFC 2780. They chose "IESG
Approval" instead.
| 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.
yes, that one is "there must be some documentation"
No. That one ("Specification Required") explicitly states that the
document must be permanent, readily-available and in sufficient
detail so that interoperability is possible.
| 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).
And that one is "there must be adequate documentation". Observe how
the IESG is expressly empowered to request more, or other materials
as required, and then obviously, should that not be forthcoming, or
still be inadequate, to refuse the registration.
There is absolutely no indication here regarding what criteria the
IESG should use to approve (or not approve) an IANA allocation. You
have arbitrarily decided that availability of the same documentation
described in "Specification Required" is the only criteria that the
IESG should be allowed use, and I don't know where that is coming
from... That would make "Specification Required" and "IESG Approval"
exactly the same requirement.
I personally believe that the IESG should use the same criteria that
we use for all of the other IESG decisions in the IETF (absent other
direction) -- we try to decide what is in the best interests of the
IETF and the Internet.
In this particular case, we felt that it was not in the best
interests of the IETF and the Internet for the IESG to approve this
allocation. If you disagree with that decision (although I think you
should read the document first before forming that opinion), you
could choose to appeal that decision. Alternatively, you could try
one of the other paths, probably "IETF Consensus" to request this
allocation.
| 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 --
Yes.
| in this case, my judgement about whether an IP option number should
| be allocated for this purpose without requiring an IETF consensus
| document.
No, the working group already made that decsion for you. They already
said that was OK, or they would have required IETF Consensus or standards
action processes to allocate the option. You don't get to simply
override the already published IETF processes, however much you would
like to.
The working group did _not_ make a decision about whether an IP
option number should be allocated _for this purpose_ (i.e. for this
particular option) without requiring an IETF consensus document.
They delegated that decision to the IESG by including "IESG Approval"
as one option in their IANA considerations section. If they wanted
to allocate a number to everyone who produces a permanent,
publicly available, detailed document, they would have chosen
"Specification Required".
The fact that a document gives the IESG the authority to approve
allocations in a particular registry does not obligate the IESG to
say 'yes' to every request that is received for that registry -- what
would be the point of that?. On the contrary, I think that the IESG
should be very conservative about taking action (such as allocating a
code point) on our own authority, and I personally believe that there
are enough complexities in this situation that an IETF Consensus
document and IETF-wide discussion should be required for this
particular allocation, if the allocation is made at all. IMO, this
is not a case of the IESG over-exercising our authority, it is a case
of us being conservative about exercising our authority in a complex
situation.
They did want judgement exercised. They wanted to make sure that
the option was properly documented, not just a web page somewhere that
hints at what the option might be used for.
This is a good description of "Specification Required". "IESG
Approval" indicates that the IESG may use our judgement about whether
(or not) to approve an allocation.
I actually recommend that he follow the appeal procedures in rfc2026
instead. and have the IAB tell you that you processed this incorrectly.
That is a choice that is open to you, Larry or anyone else who
disagrees with a decision of the IESG.
Margaret
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf