(I've changed the subject line because this topic might interest
members of the community who have long since tuned out the
"Pointers to IANA..." topic.)
Below...
--On Thursday, April 22, 2010 11:50 +0200 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)de> wrote:
...
In some cases there's also a considerable amount of
fine-tuning post-IESG approval (*), both with individual ADs
to get them clear their DISCUSSes, and with the RFC Editor
team. For transparency it would be good if this was more
visible.
In particular, the idea of attaching "RFC Editor instructions"
instead of just providing a clean new ID is ... odd.
Best regards, Julian
(*) It's probably always well-intended, but there's a risk of
making changes after the community has stopped paying
attention.
I think it is safe to say that the topic of what changes are
reasonable to make after all of the Last Call comments are in
without at least issuing a new draft and possibly repeating the
Last Call has been debated on and off for many years. Similar
arguments have been going on for nearly as long about what
changes are appropriate in AUTH48. The AUTH48 process has
gradually expanded from "none" (once the IESG or other process
handed a document off to the RFC Editor, its edited form was
published without any intermediate review), to an author-only
review for unintended editorial changes, to including authors,
WG Chairs, and ADs. One supposes that each new review
opportunity and reviewer has increased quality; it has certainly
increased the length of time it takes to get documents published
after they enter that supposedly 48 hour review.
At one extreme, one would like to be sure there is rough
community consensus for every change. At the other, there is an
argument for efficiency and for not adding months to the
document production process.
My own personal view is that we would be better off if there
were no "RFC Editor notes" more substantive than "we have found
the following editorial nits in reviewing the document; please
pay attention to them in editing" and that anything else is
better dealt with by issuing a new I-D and handing the RFC
Editor clean copy. Generating new I-Ds typically doesn't take
long these days. Conversely if a delay is needed, I'd rather
see that delay before the document goes to the RFC Editor rather
than in quibbling at AUTH48.
If a new I-D were posted and the AD, WG, or other concerned
parties noticed a problem, they would have the opportunity to
complain.
But I think my view of adding more formal review steps is
similar to Jari's -- adding more review steps or sign-off
activities would cause significant further slow-downs to a
process that is too slow already in order to catch (maybe) a
very small number of significant problems. I think that would
be a lousy tradeoff; YMMD.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf