>>>>> "John" == John C Klensin <john@xxxxxxx> 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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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. 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. 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.
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.
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?
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf