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