Re: "Discuss" criteria

Seems like grouping criteria might be helpful, to try to understand the core 
reason for for including them in the list... or considering exclusion:

A.  BASIC FAILURE  (Won't Work / Major Document Problem)
--------------------------------------------------------

> * The specification is impossible to implement due to technical or clarity 
> issues.

This probably means that there has been a fundamental failure of the entire IETF
WG and oversight process.

> * 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.

This probably means that something was missed, but can be fixed, or that the
document has a -- presumably fixable -- flaw that is a show-stopper.

> * It is unlikely that multiple implementations of the specification would 
> interoperate, usually due to vagueness or incomplete specification.

This is probably a variant of the first concern -- or possibly entirely
redundant with it -- albeit stated differently.  If, in fact, it is different,
it would help to clarify in what way.

> * Widespread deployment would be damaging to the Internet or an enterprise 
> network for reasons of congestion control, scalability, or the like.

Again, a concern of this type, during a late-stage step, indicates a fundamental
failure of the IETF process.

> * 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).

This seems to be a variant of the preceding point, but stated specifically in
terms of Security.  The obvious process question is why the working groupdid
not obtain an adequate security review earlier, and make changes accordingly?

> * 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 that
are 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.

B.  IMPURE
----------

(The title of this set might seem flippant, but I cannot think of a more useful
label.  This has to do with issues that likely are secondary, to not being able
to work.  Otherwise, one of the first set of criteria would be used.)

> * 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.

Since IAB architecture documents have no formal, normative status, it's not
clear how to pursue this.  When the IAB speaks on a topic, formally, certainly
the rest of the IETF needs to listen.  Perhaps the specification needs tobe
required to explain any deviance from IAB recommendations.

However it seems clear this criterion is not claiming that the specification
"won't work" but that it has a problem more in the abstract. To raise this as a
Discuss it seems that the AD ought to explain what the negative impact ofthis
specification will be.

C.  PROCEDURAL BREAKAGE
-----------------------

Everything in this section represent tactical show-stoppers, in that the problem
is with the working group's not having been diligent enough in doing required
steps. Clearly the steps must be taken before the document can progress, pending
good outcomes from those steps, of course.  (And also of course, is the small
question of how the document got to the IESG before the required work hadbeen
done?)

> * 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.

D.  CONSTITUENCY MISMATCH
-------------------------

> * The IETF as a whole does not have consensus on the technical approachor 
> 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 shouldbe on
>  how to forge a cross-IETF consensus.

Presumably, the working group has been populated by people interested in using
the specification in the near-term. If no such people are active in the working 
group, then why has a standards effort been pursued?

The above criterion says that these motivated participants' concerns are not 
sufficient, when weighed against the more detached desires of the active IETF 
community.

Asserting this criterion seems to represent an IETF failure at so many different
levels, that it raises fundamental questions about the nature and purpose of the
IETF.  By implication, it says that we do not care as much about the people who 
are going to depend upon the protocol, as we do about those who won't.

There certainly are times that the nature of Internet architecture permits
fielding only one proposal.  However there are plenty of examples of fielding
multiple solutions, and letting the market choose among them.  So the above
criterion would seem to impose a universal requirement for unanimity that was
most definitely not part of the IETF model, for example, 10-15 years ago.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf