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