Date: Fri, 1 Jul 2005 11:39:05 -0400
From: Margaret Wasserman <margaret@xxxxxxxxxxxxxx>
Message-ID: <p06200745beeb0518c843@[10.0.0.171]>
| 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.
| 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"
| 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.
| 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.
That's true. But once again, you're asusming that you (the IESG) get
to choose the criteria to use when making that decision. That is, you
get to do whatever you like, without recourse. That would truly be
amazing, as it would be the only place in the IETF where that kind of
power was given to the IESG. That is not supportable.
| 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".
That's fine. I prefer the Oxford myself (occasionally Macquarie), but I
doubt it is going to make a difference to the definition of that term.
Nor is it the issue - the question is what should be examined when
deciding if the request is approved, and what should not be.
| 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.
| 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.
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.
| 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.
That's fine. And if that had been the basis for the IESG's decision,
I would not have complained. And Dr Roerts would have known exactly
what was required of him in order to get the option allocated. As I
said, many times now, I haven't read any of the documentation, I have
no idea if an option code should have been allocated or not, all I know
is that the IESG followed the incorrect path in rejecting it. There
may easily have been a perfectly reasonable way to do that (this time --
one expects that if the reason had been that the doc was inadequate,
it would only have taken a month or so to rectify that and ask again).
| 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).
I actually recommend that he follow the appeal procedures in rfc2026
instead. and have the IAB tell you that you processed this incorrectly.
That way, the same issue won't arise again, the next time someone
follows this course of action (for this code point space, or another).
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf