--On Monday, February 28, 2022 15:24 -0800 Benjamin Kaduk
<kaduk@xxxxxxx> wrote:
> On Tue, Mar 01, 2022 at 12:17:24AM +0100, Carsten Bormann
> wrote:
>> > A full review should not be necessary.
>>
>> I wish that were true...
>
> IMO a full review is necessary, not least to ensure that the
> document remains self-consistent and that any changes applied
> during editing are uniformly applied to all relevant parts of
> the document, not just in the subset of places that the editor
> noticed.
>
> This is analogous to a situation that arises when doing code
> review. If you change an API's semantics, you had better go
> around and check all the callers of that API to see if they
> need adjustments, not just the callers of the API that your
> test suite happens to exercise. With specifications we do not
> have the rigid rules of function names to identify the places
> to check, and the safe thing to do is read the whole document
> with any changes that were made fresh in mind.
Carsten,
(1) Full agreement with Ben. I'd add that, long ago, we went
directly from IESG approval to the RFC Editor to publication
without an intervening check like AUTH48. The check was
instituted after the IESG and community were very unhappy with
how a few documents came out of that process.
(2) The alternative to something very much like AUTH48 (as Ben
describes it) is to hand the document over to the RPC when we
(the IESG or a WG) would otherwise decide it was ready for Last
Call, get it edited into final form (plus or minus RFC rather
than I-D boilerplate), and then do the Last Call and IESG review
on the edited and finished document. Of course that means
that, if _any_ substantive changes show up during or after Last
Call, the document would need to be edited again and go through
Last Call again.
After noting that some other SDOs do things quite similar to
that, the community has looked at similar options several times
and concluded that the additional time and costs it would
introduce are just not worth it. Certainly the odds that it
would save time relative to the current model are very low. At
least most times when people have argued for going down that
path in the past, the argument as been that it would improve
quality. Whether that is true or not, and whether the quality
improvements would be worth the costs, would probably depend on
how closely IETF participants look at those supposedly final
documents.
john
