ietf
[Top] [All Lists]

Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-09 09:35:13
SM:

s much as I would like to use the IESG as a scapegoat, the reality is that 
IETF working groups also work briskly to on impediments.  Section 4 mentions 
that "the rules that prohibit references to documents  at lower maturity 
levels are a major cause of stagnation in the advancement of documents".  I 
beg to disagree.  Quoting RFC 4897:

 "With appropriate community review, the IESG may establish procedures
  for when normative downward references should delay a document and
  when downward references should be noted."

There is an IESG statement [1] about that.  I'll highlight the following 
sentence:

 "Normative references specify documents that must be read to
  understand or implement the technology in the new RFC, or
  whose technology must be present for the technology in the
  new RFC to work."

Quoting RFC 2026:

 "Standards track specifications normally must not depend on
  other standards track specifications which are at a lower maturity
  level or on non standards track specifications other than referenced
  specifications from other standards bodies."

Let's take a document moving to Draft Standard as an example.  When we talk 
about "down-ref", it is the maturity that is the issue.  What it means, in my 
opinion, is that the  referenced (normative) Proposed Standard can be changed 
in ways which affect the stability of the "Draft Standard" document.  An 
implementation that is compliant with the Draft Standard may end up being 
incompliant overnight as the group that worked on the referenced Proposed 
Standard found some good reason for adding some requirements.   Having 
down-refs on the "No Fly" list can be an impediment.  By explicitly calling 
out the down-ref during a Last Call, the IETF offers a means to evaluate 
whether the document can live with the down-ref.

I commented a week ago on the down-refs in RFC 5953 which is being advanced 
to Draft Standard.  One of the down-refs could be fixed easily.  Another one 
could be addressed with some rewording.  Sometimes, such a change is not 
possible.  In a distant future, the IETF community might come to terms with 
the notion that down-refs are not evil.

My person experience with advancing documents is that downrefs are a 
significant hindrance.  As you point out, procedures have been adopted to 
permit downrefs, but they are not sufficient.  We often see Last Call repeated 
just to resolve a downref that was caught very late in the process.  These 
intoduce delay, and they almost never produce a single comment from the 
community.

Russ
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf