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

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

 



--On Friday, May 06, 2011 18:15 +0200 Martin Rex <mrex@xxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


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