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/