Re: "Discuss" criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]