--On Thursday, 30 June, 2005 17:21 -0400 Sam Hartman
<hartmans(_at_)mit(_dot_)edu> wrote:
"John" == John C Klensin <john(_at_)jck(_dot_)com> writes:
John> Hans, I think this formulation is consistent with
what I, John> and others, have been trying to say. I
would, however, add John> one element.
John> However, especially since the IETF maintains
liaisons with John> at least a subset of the other
standards bodies involved, John> when the IESG decided
that a technical review was necessary, John> they should
have managed things so that one was performed. John>
Elements of such a review might have included contacting the
John> other organization and making a review plan with them
John> (including a document distribution plan if appropriate),
or John> discussions with the WGs involved on the IETF
side, or other John> work in the community, presumably
leading up to a Last Call John> or the equivalent.
John, this attitude really frustrates me.
That is surprising because, with one exception, I don't see
where we disagree.
The IETf has had a long tradition that deciding whether
technical review is required is a separate process from
deciding the management issue of whether to perform that
review.
Huh? In the critical edge cases, that would permit the IESG to
kill an idea by saying:
(i) That idea/request/documentcannot go forward without
technical review
(ii) We refuse to authorize or manage such a review,
therefore it will not occur and the idea or document is
dead.
While, presumably, that combination of actions could be
appealed, it would put us into a position in which we would be
managing by appeal. And that can't be a good idea.
This idea has even been codified in a specific case. RFC 3932
allows the IESG to say that some external contribution being
published conflicts with work within the IETF and would
require review within the IETF. However it explicitly says
that making such a statement is not a promise that such review
will or should be conducted. That decision is made through
our normal processes: RFC 2026 2418 and the specific operating
procedures of established working groups.
But RFC 3932 applies to one specific case -- consideration of
documents submitted by individuals (or groups of individuals) to
the RFC Editor. The expectation, at least when I read the
document on Last Call, was that the IESG might well say "well,
this document conflicts with work being done in the FOOBAR WG,
and that author should take it there and see if it gets any
traction". Certainly that is consistent with what you say
above. But note that WGs don't last forever, or at least are
not supposed to. Sooner or later, FOOBAR will presumably either
emit the document with which the submission conflicts. If the
author then comes back and says "I want to publish this as a
dissenting opinion", there is no longer a conflict, and the IESG
can ask (and I would assume the RFC Editor would require) that
the document be published with some clear disclaimer text that
indicates that the standards-track path lies elsewhere.
What I don't think the IESG is ethically permitted to do, even
under the provisions of 3932, is say "it conflicts with work
being done now in the IETF or that might be done in the future,
so it can't be published, but we won't identify the work or
facilitate a review". Probably the IESG could read 3932 to
permit that, but I would assume that the RFC Editor might ignore
such feedback (which might set off a crisis). And I would
assume that, if it happened with any frequency or relative to
something important, the community would move to clarify 3932 to
eliminate that possibility.
In fact in the RFC 3932 case, the IESG is explicitly encouraged
(perhaps required is a better term) not to engage in technical
review, only to determine whether technical review is needed.
It seems to me that the key text in 3932 is
In March 2004, the IESG decided to make a major change
in this review model. The new review model will have
the IESG take responsibility ONLY for checking for
conflicts between the work of the IETF and the documents
submitted; soliciting technical review is deemed to be
the responsibility of the RFC Editor.
That doesn't give the IESG even the authority to say "this needs
technical review" at all. All the IESG can do is say
"conflicts with work in the IETF"... or not.
The list in section 3 is not quite consistent with the above,
but it is very close. In particular, we have:
5. The IESG thinks that this document extends an IETF
protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG
approval.
Note also the subsequent section...
Redirection to the full IESG review path is not a
guarantee that the IESG will accept the work item, or
even that the IESG will give it any particular priority;
it is a guarantee that the IESG will consider the
document.
which I think is what you are referring to above. This path is
optional for the author, the IESG does guarantee to consider the
document, and the action considering it is, presumably,
appealable if necessary.
I can cite other examples from BCPs where these two issues are
separated. In a not identical but similar veign, our liaison
statement processes do not require us to conduct review
requested by other standards organizations; they explicitly
require us to respond to the request. However one of the
responses can be that we choose not to conduct the review in
question.
Absolutely. But, if you do not choose to conduct or manage a
review, the other body would presumably feel justified in doing
whatever it pleases, assuming that the IETF has no input of
substance. The IETF, and still less the IESG, can't both
control external behavior and refuse to comment substantively on
it.
The RFc 2780 procedures are a sparse. We'd all be happier if
the community had given us more advice on what criteria to use
when evaluating hop-by-hop option requests and on what
procedures were desirable. But in the absence of such
guidance, it is reasonable for the IESG to adapt a similar
procedure another area where we get external contributions and
requests. The IESG quickly determined if additional review is
required and gave some reasons why that review seemed
important.
And then proceeded to indicate, albeit in quite convoluted
language, that it thought such review was pointless. That is
where we are having a disagreement. I believe, and various
other writers believe, that can, and should, approve these "IESG
approval" registration requests when they seem reasonable.
Conversely, we do not believe that the IESG should be able to
block a registration without at least some minimal level of
community review and consensus. If I correctly understand your
comments and those of others, the IESG disagrees and believes
that the community has given it the authority, nay the
responsibility, to block registrations when it finds the
protocols inappropriate for any reason.
So, ok, we disagree. That should not be a problem once we
understand what we are disagreeing about. The normal IETF way
to deal with such a disagreement is to write a draft clarifying
the rules (one way or the other), discuss it in the community,
and see which interpretation gets consensus. When we get
through that process, presumably there will be no further
ambiguity or differences in interpretation. I don't see that
as a problem; I see it as progress. And it was exactly for
that purpose that Vint, Scott, and I wrote and posted
draft-klensin-iana-reg-policy-00.txt.
The IESG did not choose to allocate resources to that review.
You might not like that decision, but it is a decision it is
important for the IESG to be able to make. (It's also
important that the community be able to allocate the resources
if the community disagrees with the IESG--such disagreements
are not a process failure and should be expected to happen
from time to time.)
We agree.
The IESG is under significant pressure to improve the
management of the IETF. The community believes that the IESG
has management responsibility for the timeliness ande
appropriateness of the output of the IETF. If the IESG is
going to have this responsibility it should be given the tools
to act on this responsibility. The community should retain
the ability to override the IESG's initial judgment because
allocation of resources is in fact an area where judgment is
important and the IESG will make mistakes.
Ok.
One tool the IESG needs is to be able to set the bar fairly
high for new work in the IETF that is unlikely to gain
consensus. This is especially true when there is existing
conflicting work in the IETF. We don't value multiple
protocols for doing the same thing for the sake of having
multiple protocols. Clearly we sometimes do charter multiple
efforts to do the same thing, but we tend to require a higher
bar when that is the case. If the IESG does not have this
ability, then it will be forced to charter work that is more
likely to ultimately fail, consuming significant resources in
the process.
No one is trying to 'force' the IESG to do anything. Several of
the options that have been explicitly floated involve "post an
I-D, take it into the relevant WG, and see if your I-D gets
traction, either as a substitute for whatever than WG is doing
or as something that can inform the WG's work and provide a new
perspective". Presumably the IESG would not try to block such
an effort.
But the key issue here has nothing to do with the "it needs
technical review and we don't want to allocate the resources"
path down which we seem, again, to be going. The question is
"if party X intended to allocate protocol Y on the Internet,
with or without IETF approval, and has the resources,
implementations, and support to do so, is it appropriate that
the IETF ignore that effort or should we, instead, try to devise
some mechanism for recognizing their method so it can be
prevented from interfering with other things".
Some of us consider the "the try to ignore it" path to be naive
and dangerous, especially if its advocates assume that ignoring
it will cause it to go away. There is at least one, well-known
and well-established, technical method for preventing conflicts
between options that are mutually unknown. That method is to
assign both appropriate codes so that receiving systems can
accept one, the other, or neither without fear of ambiguity.
That particular mechanism of using registrations and options
doesn't need technical review; we have years of successful
experience with it. If the IESG wants to propose an alternative
for community review, that would be fine too, but such an
alternative would require technical review.
Put differently, I think the IETF has a moral obligation to
either accept registrations of methods and options that are
technically plausible (to determine that, we could use the
traditional tests of operational implementations and passing
laugh tests, neither of which are "technical review" or to
propose some alternative. "We don't like it so you don't get
it" is both impolite and almost certainly ineffective. Whether
it is worth doing the other work or the registration should be
accepted by default is a subject on which I hope that IESG would
have an opinion which it would express clearly to the community.
Committing to review any proposal that comes in from another
standards organization is not compatible with efficient
management of the IETF. There are cases where it is critical
that we engage in such work, but that is a management decision
that the IESG needs to have initial decision ability for if it
is going to have responsibility for the resulting work.
Concur, as long is that word "initial" is clearly understood.
And as long as it is understood that the other standards body is
likely to consider it reasonable to do whatever it wants to do
if the IETF declines to comment on or interact with its plans.
That, in fact, creates a problem of management and priorities.
And, again, I would hope and expect the IESG to have opinions on
the subject and to share those opinions with the community.
I do not feel comfortable discussing the reasoning that lead
to the particular management decision not to allocate
resources to this work item on a public list. There are parts
of any discussion of this type that do involve politics.
ok. please see below.
However I would like to look at what options the community has
in order to disagree with this decision. First, while the
option of appeal does exist, it seems like an inefficient
option to employ and there are better alternatives.
Yes. However, I would suggest that an appeal, focusing not on
failure to grant the codepoint but on the IESG's declining to
tell the community why it made the decision, might be in order
and appropriate.
Someone
could write an internet draft allocating the codepoint; if
they believe that we should allocate the codepoint without
technical review of the proposal, then they could contain few
details on that draft about the proposal but instead reference
the existing specification.
That would be reasonable except for the fact that the IESG has
appeared to send a clear message that the response to such an
I-D would be the statement that it needed technical review and,
presumably, that the IESG was not willing to try to seek or
allocate resources to get it done. That would take us back
around the loop we are in now, but with an action that would be
more easily appealed. I don't think either of us want to see
management by appeal.
If they believe the technical
details are important, they could include those details;
presumably reviewing the technical details would require the
support of Dr. Robrets.
If people believe that the guidelines
in RFC 2780 should encourage the IESG to assign options
whenever the use is sufficiently specified and there is likely
to be a significant deployment, then they could propose
revising RFC 2780 with those requirements.
Which is, in essence, what draft-klensin-iana-reg-policy-00.txt
proposes to do, although in a slightly different style and with
more flexibility than the way you state the issue above. The
interesting question is what will happen with that document.
There are people who agree with it. There are people who
disagree with it. Sooner or later, that balance will need to be
resolved via a Last Call. And the process by which the IESG
handles the Last Call request will be interesting in the extreme.
Yes, the IESG could abuse its power in the future. For
example if it failed to charter work for one of the previous
options in the presence of significant community support, then
the IESG would be abusing its power. If the IESG blocked such
a document with discusses that challenged the fundamental
premis of the document while there was community support then
the IESG would be abusing its power. If the IESG constructed
unreasonable process blocks or unfairly enforced process
issues against these documents then it would be abusing its
power. But if the IESG is going to have management
responsibility, it needs the authority to recommend against
things it believes are wastes of time. Some times the
community will disagree with those recommendations; so long as
the IESG does not block the community that's entirely fine and
will be a result of an open process.
We are in complete agreement here. And I notice that you use
the term "recommend", which appears to me to be rather different
from the decision made in this particular case.
I would like you to consider one thing with regard to the
specific proposal. We both seem to believe it is reasonable
for the IESG to require community review. That community
review is going to require the support of the IPV6 and
NSIS/QOS communities in order to build a rough consensus. So
far, I'm not hearing requests either from the IPV6 or QOS
communities for the opportunity to review this proposal. If
those communities don't want to support the proposal, it will
ultimately go nowhere within the IETF. Why should we be
spending effort on the proposal without interest from the
areas of the IETF that would ultimately review it?
Again, and I would again refer you to the Internet Draft, I
believe we need an affirmative reason to reject a registration
request. "No one cares about this option within the IETF" is a
good reason to not recommend the protocol, or put energy into
evaluating it, but it is not a sufficient reason to reject the
registration. If we are going to start rejecting registrations
we need, IMO, either an alternative or enough of a technical
review to push back strongly on the protocol itself. It is a
completely rational decision to decide to not do that work but,
again, unless we have a way to stop deployment of the protocol,
I think we have no alternative but to register it to protect
everyone else. And, as I have said elsewhere, the more odious
the IESG and/or the community consider the protocol to be, the
more important it is that it be registered, somehow.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf