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

--On Saturday, December 30, 2006 7:09 AM -0800 Michael Thomas 
<mat(_at_)cisco(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf