Subject: [QUIC] Charters that include text on recharter

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Sep 2016 10:38:45 -0700

On 13 September 2016 at 09:42, Spencer Dawkins at IETF
<[email-masked]> wrote:
> #10 - I was able to use much of the proposed changes to the description of
> the first work item, although I also got other changes to this text that I
> needed to include. I would still like to give the working group some
> expectations about partial reliability, and I don't think that capability is
> limited to enabling FEC, is it? So I tried to soften language about a
> potential rechartering. Please see what you think. I removed the final list
> (since all the elements now appear somewhere else in the text).

This is a personal bugbear of mine, but I find the notion that the
charter declares that the group might be rechartered to be entirely
redundant.  "the group may consider a recharter to" is a truism at
best.

We already have ample provision in process for rechartering.  I would
prefer to have the entire paragraph on FEC and partial reliability
removed.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 12:57:09 -0500

Hi, Martin,

> redundant.  "the group may consider a recharter to" is a truism at

What working group charters say about rechartering varies widely between
areas, and even between working groups within an area, but I'd agree that
working groups can be rechartered whether the charter says anything about
that or not.

> prefer to have the entire paragraph on FEC and partial reliability

The QUIC charter is at that awkward stage between what the BOF proponents
proposed and what the IETF community agrees to do (call it the teen years).
I'm happy to hear more about what the IETF community would agree to do,
which is actually what matters, when the IESG charters a working group.

I would like to send this charter for IETF community review Real Soon Now,
because the vast majority of the relevant community isn't on the QUIC
mailing list, and isn't seeing these exchanges. Do you think we need to
discuss removing this text on the QUIC mailing list, before the IESG
approves it for IETF community review?

Spencer

p.s. I'm going to go out on a limb and guess that we may get feedback from
the community, so I don't think anyone expects version 00-03, that I'm
about to submit, will be approved without changes :D ... this is not the
last chance to express opinions.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Sep 2016 10:58:03 -0700

Martin,

I don't have a strong argument here, but I'm going to make my weak one.
This text has lesser to do with the recharter itself than with what
features are currently excluded but we know we are likely to hit in the
future. It's only useful as something to keep in the back of the wg's
collective mind.

- jana

On Tue, Sep 13, 2016 at 10:38 AM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 13:00:16 -0500

For what it's worth,

> future. It's only useful as something to keep in the back of the wg's

That's what I was thinking as well.

Spencer

> - jana
>
> On Tue, Sep 13, 2016 at 10:38 AM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 Sep 2016 10:02:16 -0800

> future. It's only useful as something to keep in the back of the wg's

Sure, and it can be mentioned as items to be considered
for future work, or as work that's been considered but
excluded.  There's definitely value in recording those
at charter time, but I agree that the fact that the group may
be rechartered is self-evident.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Sep 2016 18:03:02 +0000

> > I don't have a strong argument here, but I'm going to make my weak one. This text has lesser to do with the recharter itself than with what features are currently excluded but we know we are likely to hit in the future. It's only useful as something to keep in the back of the wg's collective mind.

> That's what I was thinking as well.

It seems to me that having a statement of things that are 'out of scope for now' is a good clarifying thing to have.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Sep 2016 11:28:08 -0700

> It seems to me that having a statement of things that are 'out of scope for now' is a good clarifying thing to have.

That's a better framing, I think.  Perhaps:

Features that are out of scope for this version of the protocol are:
partial reliability, forward error correction (FEC), and protocols
other than HTTP.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 14:37:12 -0500

Hi, Martin,

On Tue, Sep 13, 2016 at 1:28 PM, Martin Thomson <[email-masked]>
wrote:

> > It seems to me that having a statement of things that are 'out of scope
> for now' is a good clarifying thing to have.
>
>

Okay on partial reliability and FEC, but ...

I was involved in conversations that sounded like "maybe we should do two
protocols, HTTP/2 and something else" (DNS was mentioned, but ignore that
for now) "because if we're only doing HTTP/2, we may end up with a very
HTTP/2-centric QUIC".

That was The Road Not Taken, but I'm reading "protocols other than HTTP are
out of scope" as saying that the working group would be fine if it ended up
with a very HTTP/2-centric QUIC, and that (for extra credit) the chairs can
shut down discussion about other protocols because it's out of scope.

Am I (1) misrepresenting previous discussions about doing two protocols,
and/or (2) confused about what people want QUIC to be useful for?

Thanks,

Spencer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Sep 2016 12:54:29 -0700

> and/or (2) confused about what people want QUIC to be useful for?

Honestly, I don't care if you remove that clause.  My recollection of
those discussions wasn't good and I shouldn't have presumed any
particular outcome.

(Personally, I think that if this protocol is going to deliver on its
promise of rapid iteration, then protocol/2 over quic/2 would be a
much better proof of success than having QUIC support two different
protocols from the outset.  That's true even if quic/1 ~= quic/2.)

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Sep 2016 23:37:33 +0000

I think, however it's worded, the fundamental requirement from the BoF is that QUIC itself remain flexible enough to enable multiple mappings.  We briefly tried to have that as a pseudo-requirement of the HTTP/2 framing layer, but we eventually kicked that out for one simple reason:  A different protocol using the same framing layer format would still be *a different protocol*.  They could be distinguished from each other by a different TCP port and/or a different ALPN string.  And that protocol could make whatever modifications it needed to the setup of the framing layer to accommodate the new protocol.

QUIC aims to have that requirement from the start.  We don't want to have to replicate the QUIC spec in each mapping that gets defined, or say "like in RFC XXXX, but with these changes:"

Capability/version negotiation is a key component of this.  Protocol 1 is going to enable a set of features that it requires, and require a minimum version of QUIC that supports all of them.  Protocol 2 is going to enable an overlapping-but-different set of features that are important to it, and probably require an updated/extended version of QUIC.  The features that Protocol 2 enables will need to be defined by the time the Protocol 2 mapping is defined, but if they're not needed by 1, the requirement is simply that the negotiation enable you not to break 1 as you add them.

At the BoF, it was suggested that the shortest path to ensuring we don't foreclose future mappings is to require that we actually define more than one mapping.  Maybe the charter should call out the goal, rather than the mechanism?

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, September 13, 2016 12:54 PM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Salz, Rich <[email-masked]>; [email-masked]; Jana Iyengar <[email-masked]>
Subject: Re: [QUIC] Charters that include text on recharter

On 13 September 2016 at 12:37, Spencer Dawkins at IETF <[email-masked]> wrote:
> That was The Road Not Taken, but I'm reading "protocols other than 
> HTTP are out of scope" as saying that the working group would be fine 
> if it ended up with a very HTTP/2-centric QUIC, and that (for extra 
> credit) the chairs can shut down discussion about other protocols because it's out of scope.
>
> Am I (1) misrepresenting previous discussions about doing two 
> protocols, and/or (2) confused about what people want QUIC to be useful for?

Honestly, I don't care if you remove that clause.  My recollection of those discussions wasn't good and I shouldn't have presumed any particular outcome.

(Personally, I think that if this protocol is going to deliver on its promise of rapid iteration, then protocol/2 over quic/2 would be a much better proof of success than having QUIC support two different protocols from the outset.  That's true even if quic/1 ~= quic/2.)