--On Monday, 27 June, 2005 17:00 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
> The debate (except that since the work hadn't been brought to
> the IETF,
> the debate hasn't happened) is whether the proposed mechanism
> will interfere
> with existing or other proposed mechanisms. It isn't about the
> option number
> in itself (apart from the normal need for careful stewardship
> of all finite numbering spaces).
But, Brian, that is not, IMO, a proper way to frame the question
as I, and a number of people going back to kre's initial note,
have been trying to suggest. My impression from the above is
that we just have not been communicating: IESG appears to be
focused on one concern and most of the comments on the list on
anohter. In the hope that we can get close enough to be
discussing the same topic, let me try again.
There are two, almost completely separate, issues here:
(1) The quality and utility of the proposed mechanism
and where it falls on a scale that runs from "greatest
idea in computer networking ever" to "the connection of
a single device supporting this mechanism to the public
Internet will cause an immediate meltdown after which no
traffic will flow again, ever".
(2) Whether or not it an option number should be
assigned to it.
Now, what you say above is that the debate is, or should be,
about the mechanism and how it relates to other work. That is a
really important question or group of questions and the IESG
would be, IMO, negligent in its responsibilities if it did not
try to get an answer to it. The only objection I've seen on the
list to the IESG's intervening on that matter --although I have
seen it several times and quite clearly-- is the view that the
IESG should not be taking a position, presumably on behalf of
the IETF, on the subject of protocol quality and interactions
without public consultation with the relevant WG(s) and the
community. In addition, there have been some opinions expressed
about steps the IESG should have taken or should take now,
including sending formal liaison statements to ITU-T SG13
explaining that the nature of this mechanism is such that they
should not approve it without asking for, and getting, IETF
review and comments.
But all of that is part of the first question above. Its only
interaction with the second question is that if, for example,
the IESG were to send such a liaison note off to SG13, or tell
the applicant that they needed to make a good-faith effort to
get together with the relevant WGs to see if the issues could be
sorted out, it would be reasonable to defer (but not reject) the
registration/ option number request until there was some
conclusion from those processes. Obviously, if the proponents
can be persuaded to drop this idea, or to modify it sufficiently
that the IESG no longer considers it problematic, the landscape
would change.
However, what I, and at least some others, are concerned about
is the second question. The appearance of a number in a
seven-bit option field that we've heard at least one expert
claim is sufficiently unimportant that maybe the field should be
abolished is not going to cause a serious problem for the
Internet, even if the mechanism it identifies, if used, would
cause serious, immediate, and irreversible problems. Unless
the IESG has some mechanism for preventing the mechanism from
being deployed, it is arguably better to assign an option code
than to no do so. Indeed, the more hostile, incompatible, and
dangerous the mechanism is seen as being, the more important it
is that it get an option code if there is a reasonably chance
that it will be deployed.
It seems to us that the IESG has confused "protocol quality"
(the first question) with "registration appropriateness" (the
second) and, in the process, gotten to the wrong answer and,
worse, done so without adequate community consultation. And
_that_, and not the protocol quality issues themselves are what
we think the debate is about.
In an attempt to sharpen the focus on the second set of issues,
I've been working intensely over the last couple of days with a
couple of collaborators to frame an Internet Draft that would
clarify the evaluation processes of IANA registries for which
IANA depends on the IETF for direction. It does not change any
of the category types in RFC 2434, nor does it change the review
processes and required levels of signoff in RFC 2780 and other
documents. But it does clarify the generic criteria to be used
in making those evaluations and the separation between the above
two questions.
The first draft of the document was submitted for posting about
90 minutes ago, under the name
draft-klensin-iana-reg-policy-00.txt. We hope it will prove
helpful to the community and to the IESG in optimizing
registration request evaluation to meet the needs of the
Internet as it is, rather than some Internet in which IETF
disapproval of an idea causes that idea to disappear.
regards,
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf