Re: IESG Success Stories (was: "Discuss" criteria)

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

 





--On Saturday, December 30, 2006 7:09 AM -0800 Michael Thomas <mat@xxxxxxxxx> wrote:

...
The other thing that occurs to me -- and I know this has been
brought
up in many different forms -- is that if an AD _was_ following
the
working group to some degree, why is it legitimate for them to
wait
for IESG evaluation to voice comments that affect the
protocol's
operation? That is, why aren't they held just like anybody
else to voice
those in WG last call when the WG is far more responsive to
dealing
with issues? These "IESG Surprises" really hurt the community
by
leading to the general perception that the IESG is capricious
in a
royally anointed kind of way.

Michael,

If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. I certainly would not expect it to happen often. But, IMO, we have an IESG and, indeed, an IETF rather than a collection of different organizations addressing per-area issues precisely to increase the odds of catching serious cross-area and cross-perspective issues before things go out. Like it or not, unless the relevant WG makes an effort to get broad reviews at critical "early" points, there will always be a risk of late surprises as someone --in the community during Last Call or on the IESG-- suddenly wakes up and says "but how does this relate to XYZ".

With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. As with late surprises, somewhat more proactive effort on the part of WGs could prevent many of the problems we see, but...

(1) While I think the worst problems got fixed, RFC 4714 can be seen as an effort to either de-skill the RFC Editor function or to recognize that our expectations of that function a decade ago are no longer consistent with today's realities. If we are not to publish documents that are incomprehensible, then someone has to have the responsibility and authority to either fix them or push back on them. If it is going to be the RFC Editor, then we should be pushing back every time an IESG member complains about an editorial matter smaller than "the document is incomprehensible and cannot be evaluated or implemented" ... and we should (again) be giving the RFC Editor the authority to refuse to publish an IESG-approved document because it cannot be safely edited into comprehensible form. If it isn't going to be the RFC Editor, then it probably needs to be the IESG --or some significant process changes-- and we should stop complaining.

(2) My comments about the expectation of good sense and community willingness to abuse and/or fire those who don't exercise it are very much applicable to the above. I don't have any idea how to write rules that will improve the situation without very high risk of tying ourselves in knots _and_ not solving the underlying problem.

    john




_______________________________________________

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]