Subject: Raising the Bar / Our Work Mode

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Jan 2019 14:28:14 -0700

Everyone,

We've previously talked about "raising the bar" for changes to the protocol; i.e., reflecting the group's desire for shipping a viable product in a reasonable timeframe by agreeing not to accept changes that don't have broad support as technically necessary, and not spending significant resources on issues that are not likely to meet that requirement.

To be clear, this is a Working Group decision, not something imposed by the IETF or the chairs. Effectively, it's forming consensus that shipping a viable protocol in a reasonable amount of time is itself a feature -- one that's more important than satisfying every itch that people have when minting a new protocol.

The chairs and the editors believe that we are now approaching that point for the Transport, Recovery and TLS drafts. In Tokyo, one of our agenda items will be a discussion and calls for consensus on:

* The -17 drafts of transport, recovery and TLS, delta the current issues list, reflecting working group consensus so far
* Raising the bar for changes to these drafts shortly after the meeting.

That brings up a discussion of work mode. Since we started QUIC, we've allowed the editors a significant amount of leeway in assessing our discussions, formulating their proposals and incorporating them into the published drafts; the presumption has been that it represents informal (i.e., non-called) consensus unless there's an objection (on-list or in the issues list). This has helped us to move at a reasonable pace; while we've already adjusted our timeline, we wouldn't be as far along if we hadn't taken that approach.

However, once we do "raise the bar", this presumption is no longer workable; it isn't fair to the editors. Therefore, afterwards we'll need change our work mode. 

What we'd like to see is having changes canvassed in GitHub issues *and* the mailing list to assure consensus (as judged by the chairs), only being incorporated into the drafts afterwards. That will mean that each draft after we adopt this change will effectively reflect working group consensus at that time. 

It also means that the chairs will become more active in managing the state of the issues; e.g., flagging those that have explicit consensus, and closing those which don't achieve it (including a review of the 'parked' issues).

It doesn't mean raising new issues is not possible -- we can always change based upon new information. However, the presumption will be that changes to the design need broad support within the working group to go forward.

We'll have more details and discussions at the meeting, but we wanted to get initial feedback and questions on the list; please have a think and reply with any concerns you have.

Cheers,

- Mark and Lars

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 12:42:25 +0900

> We'll have more details and discussions at the meeting, but we wanted to get initial feedback and questions on the list; please have a think and reply with any concerns you have.

Chairs, editors,

Thank you for all your work.

It's great to know that we have finally reached the point where we are
"raising the bar." I am looking forward to seeing that becoming real
in Tokyo.

OTOH, I would like to ask how editorial issues or clarifications
should be handled when we "raise the bar."

When opening a GitHub issue or PR that tries to address an editorial
issue, are we expected to also notify the mailing list?

Or if we feel uncertain in what the draft is saying, what is the
expected action for us to take: 1) open a GitHub issue, 2) open a
GitHub issue and send that to the mailing list, 3) send the question
to the mailing list?

Thank you in advance.

-- 
Kazuho Oku

---

From: Lars Eggert <[email-masked]>
Date: Thu, 17 Jan 2019 13:02:38 +0200

Hi,

> should be handled when we "raise the bar."

without having had a chance to discuss this with Mark, my proposal would be to keep editorial issues on GitHub only, in order to not swamp the list.

If an editor determines that such an issue is in fact not just editorial, it jumps tracks to what Mark has outlined in his email.

Does that make sense?

Lars

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Jan 2019 17:49:47 +0000

My understanding of the new work process is that editors can still merge editorial PRs without chair approval, so it would make sense to keep these on GitHub.  Just so we're on the same page, my definition of "editorial" would be that it does not:

  *   change bits on the wire
  *   add new mandatory behavior
  *   prohibit previously-permitted behavior
  *   permit previously-prohibited behavior

More controversially, I would consider converting a textual recommendation to a SHOULD or MAY as editorial, since the permission level of following or ignoring the behavior is the same.  Clarifying something that was previously ambiguous might need the design path just in case.

From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Thursday, January 17, 2019 3:03 AM
To: Kazuho Oku <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Raising the Bar / Our Work Mode

Hi,

On 2019-1-17, at 5:42, Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

Does that make sense?

Lars

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 17 Jan 2019 11:36:13 -0800

I agree with Lars and Mike -- editorial issues and PRs stay on github and
can be merged without going through the chairs. Editors and the wg needs to
be careful in recognizing behavior changes as such and move them to the
mailing list.

My understanding of what editorial is exactly matches Mike's description of
it, including the controversial bit.

On Thu, Jan 17, 2019 at 9:50 AM Mike Bishop <[email-masked]> wrote:

> My understanding of the new work process is that editors can still merge
> editorial PRs without chair approval, so it would make sense to keep these
> on GitHub.  Just so we’re on the same page, my definition of “editorial”
> would be that it does not:
>
>    - change bits on the wire
>    - add new mandatory behavior
>    - prohibit previously-permitted behavior
>    - permit previously-prohibited behavior
>
>
>
> More controversially, I would consider converting a textual recommendation
> to a SHOULD or MAY as editorial, since the permission level of following or
> ignoring the behavior is the same.  Clarifying something that was
> previously ambiguous might need the design path just in case.
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * Lars Eggert
> *Sent:* Thursday, January 17, 2019 3:03 AM
> *To:* Kazuho Oku <[email-masked]>
> *Cc:* Mark Nottingham <[email-masked]>; IETF QUIC WG <[email-masked]>
> *Subject:* Re: Raising the Bar / Our Work Mode
>
>
>
> Hi,
>
>
>
> without having had a chance to discuss this with Mark, my proposal would
> be to keep editorial issues on GitHub only, in order to not swamp the list.
>
>
>
> If an editor determines that such an issue is in fact not just editorial,
> it jumps tracks to what Mark has outlined in his email.
>
>
>
> Does that make sense?
>
>
>
> Lars
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jan 2019 12:39:23 -0700

Yes. The only thing I'd ask is that there always be an accompanying issue marked 'editorial', so that people have some visibility and can contest whether it *is* editorial (PRs often fall through the cracks).

Cheers,

> On 17 Jan 2019, at 12:36 pm, Jana Iyengar <[email-masked]> wrote:
> 
> I agree with Lars and Mike -- editorial issues and PRs stay on github and can be merged without going through the chairs. Editors and the wg needs to be careful in recognizing behavior changes as such and move them to the mailing list.
> 
> My understanding of what editorial is exactly matches Mike's description of it, including the controversial bit.
> 
> My understanding of the new work process is that editors can still merge editorial PRs without chair approval, so it would make sense to keep these on GitHub.  Just so we’re on the same page, my definition of “editorial” would be that it does not:
> 
> 	• change bits on the wire
> 	• add new mandatory behavior
> 	• prohibit previously-permitted behavior
> 	• permit previously-prohibited behavior
>  
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Jan 2019 19:57:50 +0000

>    Yes. The only thing I'd ask is that there always be an accompanying issue marked 'editorial', so that people have some visibility and can contest whether it *is* editorial (PRs often fall throug…
  
+1

And consider adding editorial issues to the summary emails now.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jan 2019 13:16:23 -0700

You mean the weekly summaries? I can do that.

> On 17 Jan 2019, at 12:57 pm, Salz, Rich <[email-masked]> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 17 Jan 2019 20:06:39 +0000

Sounds eminently sane.
-=R

On 1/16/19, 1:29 PM, "QUIC on behalf of Mark Nottingham" <[email-masked] on behalf of [email-masked]> wrote:

    Everyone,

    

    

    

    Cheers,
    
    - Mark and Lars

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 18 Jan 2019 13:07:01 +0900

Thank you all for the clarifications.

All your comments make sense to me.

-- 
Kazuho Oku