ietf
[Top] [All Lists]

Re: draft-housley-two-maturity-levels-06

2011-05-06 12:15:36


--On Friday, May 06, 2011 18:15 +0200 Martin Rex <mrex(_at_)sap(_dot_)com>
wrote:

The real problem tha the IETF is regularly facing are
constituencies that will fight hard against specifications
getting updated, improved or fixed, once they have been
published as RFC. 

Martin,

That is an interesting observation/ claim.  Because I don't
think I've seen that happen, I'd appreciate some examples.  

I have seen:

        * Insistence that any updated version of a document
        address all known outstanding issues, including
        insistence that the revised document not move forward
        until specific changes for which there is no clear
        consensus be included.  In other words, if there is
        community consensus for changes A and B to document X,
        but no consensus that change C is needed (or
        appropriate, or even correct) some people will try to
        block approval of an X-bis that incorporates only
        changes A and B until everyone agrees to C.  That is a
        very difficult problem in any standards body.  We have
        sometimes gotten around it by explicitly noting that
        issue C remains controversial, but rarely without some
        resistance.  But the problem isn't resistance to updates
        and improvements, only controversy about whether the
        changes are sufficient.
        
        * Insistence by various groups, often (at least
        apparently) only the IESG, that any document being
        revised be altered to conform to multiple requirements
        for content or editorial style that are more recent than
        the original document and in spite a no evidence that
        that older style or organization was causing any
        problems.  That clearly makes it more difficult to get
        an update with actual corrections, etc., issued than it
        might be.  But I've not seen anything that I interpret
        as evidence of resistance to change or updates once an
        RFC is published, only procedural and editorial
        requirements for publication of updated documents that
        sometimes create barriers that seem unnecessary and
        inappropriate.

        * Certainly WGs and others tend to run out of energy
        once initial RFCs are published.   If no one is willing
        to produce a new or updated draft and persuade others to
        review it, then revisions are not going to happen.  But
        your comment implies active opposition to such
        revisions: "no energy" is not active opposition.
        Indeed, while I don't think it is justified in today's
        environment, IIR part of what caused the 2026 "advance
        or die" provision was the belief that, if no one cared
        enough about a given specification to advance it, maybe
        we didn't need it any more.

As someone who has been responsible for several RFCs and who has
worked on updates to a large subset of them, I've seen a lot of
pushback asking for "more", but little or no pushback for the
idea of reviewing and revising specs.

While I see those issues as significant, none of them have
anything to do with this particular proposal: they apply equally
regardless of how many steps there are in the Standards Track,
apply to documents being recycled in grade, and even apply to
non-standards-track materials.

So you may be seeing things that I'm not (behaviors do differ
between areas and even among protocol families within an area)
but, if you are seeing active pushback on making revisions, I'd
be interested in hearing specifics about that, what you would
propose to do about it, and why this document is either helpful
or unhelpful in that regard.

regards, 
    john




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