--On Thursday, April 22, 2010 13:27 -0500 Spencer Dawkins
<spencer(_at_)wonderhamster(_dot_)org> wrote:
I might drift slightly toward "there should be a published
Internet-Draft that differs only in formatting-as-an-RFC from
what is published as an RFC", but would be willing to listen
to arguments that this is too strict - but I broadly agree
with what's said below.
Unless you have a plan about how to improve the writing skills
of every person who takes on editing responsibilities in the
IETF --and that is intended to very explicitly include a lot of
people who are native, first-language speakers of one of the
languages called "English"-- I think it is in everyone's
interest that the RFC Editor be permitted to edit. The
real/original purpose of AUTH48 was supposed to be a mechanism
for checks that the editing process did not introduce
substantive technical errors. Some of us have appreciated the
opportunity to use it to arm-wrestle with RFC Editor staff over
some editing changes, but I'd argue that even that is secondary.
We could make a requirement that a pre-AUTH48 I-D be posted that
reflects the final, edited, content of a soon-to-be-published
RFC prior to switching formatting and boilerplate (note that
difference is _required_ to these days), but I think,
personally, that I'd be against it unless:
(i) it could somehow be guaranteed to neither increase
costs nor add delays
(ii) there was some way to ensure that any comments that
amounted to reopening issues about the substantive
content of the document or that were _intended_ to delay
it stayed out of the system and, in particular, off the
IETF list, and, if such issues came up, that they did
not turn into opportunities for more process, more
delays, possible appeals, etc.
The former is impossible if only because it would effectively
require busy authors and editors to do two final reviews --this
one and the AUTH48 one (which does contain the final
boilerplate, etc.). The reasons why the latter is only
slightly more plausible are left as an exercise.
I think it is lots better, and lots more efficient, to make sure
that the draft that goes to the RFC Editor is correct and
complete substantively and then to expect those who participate
in the AUTH48 review on a given document to exercise
self-discipline about making changes that second-guess the
substance of that approved draft. Put differently, we would be
well-served by establishing a principle that AUTH48 is for
resolving editorial issues only and not for making substantive
changes of any sort without review by the approving stream. For
documents in the IETF stream that required Last Call as part of
the approval process, substantive changes after approval ought
to require at least an opportunity for community [re]review.
The one change that, IMO, might be worth making in this regard
would be to explicitly empower the RFC Editor to push back, if
necessary by going back to the community, if, in their judgment,
substantive changes that deviate from the approved document are
requested at AUTH48. My own view is that they have always had
the ability to do that although I don't believe it has been
exercised since the AUTH48 procedures were created. I have no
opinion as to whether there are cases in which it should have
been.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf