Dave is probably correct that the specific criteria are of broader interest
than just ADs, WG chairs, editors, and process wonks, and might become even
more perfect with broader review, but that's another issue.
And, since the criteria are public, I'm sure the IESG would be interested in
feedback on the criteria, especially now that WGs and
Meta-point:
Something quite basic that is missing from the draft on
Discuss Criteria is a requirement that any Discuss not only
explain its precise normative basis, but that it give a clear
statement of what actions must be taken to clear the Discuss.
From the draft:
* The specification is impossible to implement due to technical or clarity
issues.
When this assertion is made, is it sufficient to cite existing implementations
based on the current version of the specification? Is the AD at least required
to explain the assertion in detail?
* The protocol has technical flaws that will prevent it from working
properly, or the description is unclear in such a way that the reader cannot
understand it without ambiguity.
Will demonstrations of interoperability be sufficient to counter this claim?
* It is unlikely that multiple implementations of the specification would
interoperate, usually due to vagueness or incomplete specification.
Will demonstrations of interoperability be sufficient to counter this claim?
* Widespread deployment would be damaging to the Internet or an enterprise
network for reasons of congestion control, scalability, or the like.
Beyond the simple assertion of this claim, what requirements are there for the
AD to substantiate it?
* The specification would create serious security holes, or the described
protocol has self-defeating security vulnerabilities (e.g. a protocol that
cannot fulfill its purpose without security properties it does not provide).
* It would present serious operational issues in widespread deployment, by
for example neglecting network management or configuration entirely.
There is often a failure to distinguish between new and peculiar problems
created by a particular specification, versus general problems that already exist.
A classic example of this is citing basic DNS problems, for specifications that
are merely consumers of the DNS and, hence, are not creating any new problems.
* Failure to conform with IAB architecture (e.g., RFC1958 (Carpenter, B.,
“Architectural Principles of the Internet,” June 1996.) [2], or UNSAF
(Daigle, L., “IAB Considerations for UNilateral Self-Address Fixing (UNSAF)
Across Network Address Translation,” November 2002.) [3]) in the absence of
any satisfactory text explaining this architectural decision.
This is an interesting item.
1. At what point in time did publication of IAB preferences take on the force
of law?
2. Note that the list gives some examples, but does not supply a complete list.
How are working groups to know which IAB documents have been declared normative
standards for all IETF work and which have not?
3. Why is the IAB allowed to create normative standards that cover all IETF
work, without requiring that they first gain IETF-wide approval?
* The specification was not properly vetted against the I-D Checklist.
Symptoms include broken ABNF or XML, missing Security Considerations, and so
on.
* The draft omits a normative reference necessary for its implementation, or
cites such a reference merely informatively rather than normatively.
* The document does not meet criteria for advancement in its designated
standards track, for example because it is a document going to Full Standard
that contains 'down references' to RFCs at a lower position in the standards
track, or a Standards Track document that contains only informational
guidance.
* IETF process related to document advancement was not carried out; e.g.,
there are unresolved and substantive Last Call comments which the document
does not address, the document is outside the scope of the charter of the WG
which requested its publication, and so on.
* The IETF as a whole does not have consensus on the technical approach or
document. There are cases where individual working groups or areas have
forged rough consensus around a technical approach which does not garner IETF
consensus. An AD may DISCUSS a document where she or he believes this to be
the case. While the Area Director should describe the technical area where
consensus is flawed, the focus of the DISCUSS and its resolution should be on
how to forge a cross-IETF consensus.
This is perhaps the scariest of the criteria. It says that a knowledgeable,
motivated constituency can spend months on solving a problem that it needs to
have solved, and then others who have not participated in the work can come
along and sabotage it.
Yes, I know that is not the intend of this criterion, but it is what the effect
will be -- and in some cases already is.
Once upon a time, the rule in the IETF was that working group consensus was what
mattered, absent a clear technical basis for saying that a specification "would
not work".
That is quite different from now saying that after a working group is done we
somehow must be assured that the specification has acquired an IETF-wide
politically correct acceptance.
If this last criterion is meant to be taken as it is stated, there is a pretty
straightforward basis for believing that ever bringing new work to the IETF is a
very questionable decision.
The criterion presumes that the IETF, as a whole, must agree on the One True
Solution to a problem.
In the IETF's history, that has been a requirement in some special cases, but
not others. The default view has been to let the market decide among choices.
Requirement for a single choice has been asserted only when there is a strong
argument that having multiple choices will cause damage.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf