--On Tuesday, July 04, 2017 9:44 AM +0000 "Dearlove, Christopher
(UK)" <chris.dearlove@xxxxxxxxxxxxxx> wrote:
> I (and co-authors) have an Internet Draft that's reached the
> IESG stage. It's due an update. In fact we have a specific
> request from our AD to update it before telechat this week.
> Done that update but can't submit due to pre-meeting block.
> There are reasons for that, but they really don't apply to
> anything post-IETF LC stage, specifically IESG review.
>
> Of course I've sent a copy to the AD, and he may be able to
> bypass. But I'd actually like to keep his load down - and I
> expect another update soon (possibly after telechat, hence not
> waiting to do both together).
>
> Is it worth considering if/how this can be allowed? More work
> to create the capability I appreciate (and having to make sure
> interface makes it clear that only such IDs will work). But
> aiming to take a bit of work off one of the most critically
> loaded part of the system.
Hi. One addition to Jari's comments, with which I agree.
There is always a danger when documents are updated/ replaced
after IETF Last Call, which is that the changes might turn out
to be significant enough that the document a WG submitted and on
which the IETF reached consensus (or at least had a discussion)
might be different in some substantive way from what the IESG
ends up reviewing. That has happened although all of the cases
I'm aware of have been mistakes, not an attempt to work around
the system. I assume the relatively recent requirement for AD
signoff on changes made at AUTH48 were dictated by similar
concerns.
So, with or without the posting deadline, I would prefer that
there be explicit AD signoff on _any_ I-D revision during or
after IETF Last Call. Such permission means that the AD has
reviewed the document and found that the changes are
insufficiently important to justify reopening the Last Call (or
a heads-up to reopen the Last Call if needed).
Certainly that is an inconvenience for the AD and the author(s),
but it seems to me to protect the consensus process and to be
far less of an inconvenience than an appeal about the IESG
approving something the community had not reviewed (or even a
discussion about whether such an appeal is necessary).
Similarly, wrt AD workload, the workload for signing off on a
late posting (and maybe entering a note in the tracker as to why
it was approved) is almost certainly less than the effort that
would be required if someone, especially another AD, questions
the changes.
The suggestion to provide automatic permission falls, IMO, into
the "be careful what you wish for" category.
best,
john