On 7/1/05 at 3:16 PM -0400, Margaret Wasserman wrote:
At 1:18 AM +0700 7/2/05, Robert Elz wrote:
...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"?
"Specification Required" requires "an RFC or other permanent and
readily available reference". In other words, an I-D (however
complete the work it documents) or a web page (however fully
specified the protocol it describes) or copyrighted proprietary
material (which could never be "readily available") would not suffice
for "Specification Required".
And in all honesty, I had always read the "IESG Approval" clause in
2434 to be an escape clause for those sorts of folks who did not have
an RFC (or other *permanent* document), such that the IESG could say
to IANA, "This registration request is from folks who have enough
documentation to satisfy the registration requirements even though it
is not the sort of documentation that IANA can independently verify
is 'permanent and readily available' enough to satisfy the
'Specification Required' requirement." I never expected IESG to be
judging the technical merits and worthiness of any such request. And
I do remember reviewing 2434 when it was being worked on.
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.
Personally, I find nothing in 2026 which indicates "in the best
interests of the IETF and the Internet" as a criteria for the IESG to
evaluate much of anything. And I think that is part of the concern
you are hearing expressed in the objections to the decision process.
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
Nobody, and I mean *nobody*, has ever suggested this. Why is this
repeatedly being brought up as an argument against folks who disagree
with the IESG decision process? The question is over the basis for
the "no", not that "no" is an impossibility.
Yes, that fish in the school is awfully red. Let's move along and
ignore it now, shall we?
On 7/1/05 at 4:19 PM -0400, Theodore Ts'o wrote:
And of course, at the end of the day, implementors can always ignore
IANA. Lack of registration certainly has not stopped various
vendors, including Microsoft, to create and sell products with
unregistered code points in Telnet, DHCP, and other IETF protocols.
Well, exactly. And we have even learned in the past that when the
registration process is perceived as too burdensome for some, we not
only end up with unregistered code points, we end up with them
purposely conflicting with IETF registered code points (cf. VRRP and
CARP).
But if the IESG is going to "approve", that certainly implies a
certain assumption of the quality of the assignment.
No. Assignments don't have a "quality". You don't mean "quality of
the assignment", you mean "quality of the protocol". Any that's not
what the IESG is asked (in 2434) to judge. To repeat: My
understanding is that if there's a choice of "Specification Required"
and "IESG Approval" in a document IANA is to go to the IESG if they
can't find "an RFC or other permanent and readily available
reference". Approval of a registration is not equivalent to approval
of a protocol. And I think people who keep saying, "Approval of the
registration will be equated with approval of the protocol and people
will start deploying it even if it's a bad idea" really need to
present some evidence that such has happened with IANA registrations
in the past.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf