Subject: Internet Draft block on post-IETF LC IDs

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jul 2017 09:44:04 +0000

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.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 3300 467500  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Jari Arkko <[email-masked]>
Date: Tue, 4 Jul 2017 14:27:32 +0300

ADs regularly grant such requests, and you have a very good reason.

The question is if code should be added to not have a submission block
when tracker state is past WG process (e.g., Waiting for Writeup,  Waiting
or AD Go-Ahead, IESG Evaluation, IESG Evaluation - Defer, or
Approved-announcement to be sent).

Maybe. (But it is also not a big load on the ADs, and they’d probably
still want to make exceptions on case-by-case basis.)

Personally, I think there are a lot of cases where updates should just
be allowed. For instance, you published a big update in time for the
meeting and for your topic to get on the WG agenda; you should be
allowed to fix bugs that people report to you as they prepare for the
meeting. Then again, many people are doing this on github anyway,
so the importance of a particular draft version is diminishing a bit,
along with the significance of the blocking period.

Jari

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Jul 2017 10:56:44 -0400

--On Tuesday, July 04, 2017 9:44 AM +0000 "Dearlove, Christopher
(UK)" <[email-masked]> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jul 2017 08:33:40 +1200

On 05/07/2017 02:56, John C Klensin wrote:
...
> a heads-up to reopen the Last Call if needed).  

I don't think that quite works. When trying to understand and clear
DISCUSS ballots, I would much rather that changes are unambiguously
displayed for everybody to see, rather than being buried in quite
complex email threads (or in non-standard places such as GitHub).

Of course you are 100% correct that substantive changes need to pass
the rough consensus test, at least on the WG list and possibly at Last
Call level, under the AD's responsibility. But I don't think that
making it harder to post updates after Last Call is a feature.

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Jul 2017 16:43:29 -0400

--On Wednesday, July 05, 2017 8:33 AM +1200 Brian E Carpenter
<[email-masked]> wrote:

>> insufficiently important to justify reopening the Last Call
>> (or a heads-up to reopen the Last Call if needed).  
> 
> I don't think that quite works. When trying to understand and
> clear DISCUSS ballots, I would much rather that changes are
> unambiguously displayed for everybody to see, rather than
> being buried in quite complex email threads (or in
> non-standard places such as GitHub).
> 
> Of course you are 100% correct that substantive changes need
> to pass the rough consensus test, at least on the WG list and
> possibly at Last Call level, under the AD's responsibility.
> But I don't think that making it harder to post updates after
> Last Call is a feature.

Didn't intend "harder".  I just think it is important to have a
clear (and, btw, appeal-able) chain of responsibility and
accountability for changes made after IETF LC review.   We are
in complete agreement about both complex mail threads and
non-standard places, but, IMO, the IESG is supposed to be making
decisions about documents and the state of IETF consensus about
those documents, not conversations that no one can follow and
that may not be documented.

best,
    john