Subject: Re: [QUIC] Benoit Claise's Block on charter-ietf-quic-00-01: (with BLOCK)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Sep 2016 08:27:28 -0500

I'm sure we will talk about this on the telechat, of course. Having said
that ...

On Thu, Sep 1, 2016 at 7:29 AM, Benoit Claise <[email-masked]> wrote:

> Benoit Claise has entered the following ballot position for
> charter-ietf-quic-00-01: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-quic/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> Disclaimer: I come late to the game (back from vacation) and I haven't
> had the chance to review QUIC as much as I wanted/needed.
>
> What about the operational aspects (as Joel mentioned in his COMMENT)?
> I would like to DISCUSS this point during the telechat.
>

The last word I have from the BOF proponents on these issues is that QUIC
is no different from other DTLS-UDP-based protocols, so discussion about
operational aspects of DTLS/UDP-based protocols doesn't belong in QUIC -
for instance, the RTCWeb SCTP/DTLS/UDP data channel is no more or less
opaque to operators than QUIC/DTLS/UDP.

I would love to figure out how to have a conversation about these issues
for DTLS-UDP-based protocols, and PLUS was the attempt to do that at IETF
96, but that particular approach didn't go well, so people were backing up
and rethinking what is possible (in addition to taking well-deserved
vacations after IETF 96, which most of us did). If there's a plausible
proposal for IETF 97, I'd sponsor it.

More broadly, I would love to have a story about Managing Radio Networks in
an Encrypted World (TM IAB), but that hasn't happened yet. I hope we're
able to make that happen.

Thanks,

Spencer

---

From: "Benoit Claise" <[email-masked]>
Date: Thu, 01 Sep 2016 05:29:39 -0700

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Sep 2016 16:15:14 -0500

Hi, Benoit,

> https://datatracker.ietf.org/doc/charter-ietf-quic/

I've made changes to the QUIC charter as discussed on last week's informal
telechat, along with other comments received during Internal Review.

Could you let me know if charter-ietf-quic-00-02 addresses your BLOCK?

Thanks!

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Sep 2016 22:48:04 +0100

Hi Spencer,

Thanks for making those changes. I think they're improvements.
Two non-blocking comments:-

1) For the text describing the AS, I think "may be applied"
would be better as "may safely be used." I'd also be happy
if the 0RTT issue were called out as an example, but that'd
maybe be too specific - my suggested change is intended to
get at that issue though.

2) The Nov 2019 goal for WG adoption of a draft for the AS
seems late to me, to the point where I'd bet that the energy
will not exist to do the work. (Despite us all now having
the best intentions.) I think it'd be better to aim to have
the AS processed in parallel with the HTTP/2 mapping draft,
i.e. sending the AS to the IESG in late 2018 or early 2019.
I'd argue that the WG will know enough at that point to make
progress on an AS, and that it's likely the HTTP/2 document
will ensure there are sufficient folks with energy involved
in the WG at that time. (While by no means guaranteeing that
folks will still want to do the AS.)

Again, these are non-blocking, so if they don't resonate
with folks, that's ok.

Cheers,
S.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 13 Sep 2016 10:09:42 -0700

On 9/12/16 2:15 PM, Spencer Dawkins at IETF wrote:
> Hi, Benoit,
>
> On Thu, Sep 1, 2016 at 7:29 AM, Benoit Claise <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     <https://datatracker.ietf.org/doc/charter-ietf-quic/>
>
>
>
> I've made changes to the QUIC charter as discussed on last week's
> informal telechat, along with other comments received during Internal
> Review. 
>
I think it might be a little easier if the ops and management folks were
a little more expclict about what manageability considerations are.

My strawman for the things I actually care about are:

Manageability considerations include  inner transport header format.
parsability in flow export, acl application, hashing of "flows" and
directional signaling of flow installation and tear down.

obviously there might be better ways to express that.

joel

---

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

Hi, Stephen,

> get at that issue though.

I'd be OK with "may be safely used". I was cribbing language out of RFC
2026 that described an AS, but that was just my first hack at it.

> folks will still want to do the AS.)

Yeah, I was hurling about that, too. My first hack was based on our "gotta
know what protocol we're applying to write an applicability statement"
discussion on the informal call, and I was probably being excessively
cautious. And literal.

I'll bring the AS forward in parallel with the HTTP/2 mapping draft.

And thanks.

Spencer

> informal

---

From: Benoit Claise <[email-masked]>
Date: Tue, 13 Sep 2016 19:24:53 +0200

> directional signaling of flow installation and tear down.
Adding that sentence would solve my BLOCK. Thanks Joel.

Also, you should clarify one of the key goals "- Enabling deployment 
over unmodified Internet paths", I'm not sure how to read this.

And I agree with Stephen on the 2019/2020 milestone dates.

Regards, Benoit

---

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

Hi, Benoit,

On Tue, Sep 13, 2016 at 12:24 PM, Benoit Claise <[email-masked]> wrote:

> Also, you should clarify one of the key goals "- Enabling deployment over
> unmodified Internet paths", I'm not sure how to read this.

I agree about this last sentence.

I can propose replacing it with

- Requiring only changes to path endpoints to enable deployment;

Do people think that "key goal" meant something else?

Thanks,

Spencer

---

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

Hi, Benoit,

> Do people think that "key goal" meant something else?

I've posted 00-03, containing Joel's proposed text, with a couple of
editorial changes. Does that address your BLOCK?

To all - I've also reflected comments that have popped out on the mailing
list since the IESG conferred about version 00-01. The easiest place to see
those edits is at
https://datatracker.ietf.org/doc/charter-ietf-quic/history/.

What I'd LIKE to do, is have the IESG approve this for External Review,
send this version out for community feedback, and go from there. So, it
would be helpful if we waited for an e-mail announcing a call for comments,
and moved further discussions to the IETF Discussion list ([email-masked]).

As I mentioned earlier today, it is not too late to provide feedback, so ...

Thanks,

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Sep 2016 21:57:09 +0100

Sorry all, but I do have an issue with Joel's additional text.

The part that troubles me is:

"Manageability
includes inner transport header format, parsability in flow export, ACL
application, hashing of "flows" and directional signaling of flow
installation
and tear down."

I'm fine that those issues be discussed, but, to me, (and sorry
if I'm being overly sensitive), that reads like saying that the
final QUIC had better make inner transport headers visible to
middleboxes, etc. which I do not think is what we want.

I'd be fine with s/Manageability/Traditional manageability/ and
if we added something to the effect that QUIC changes that picture
and the impact of such changes is a valid topic for discussion in
the WG.

Cheers,
S.

On 13/09/16 21:44, Spencer Dawkins at IETF wrote:
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 13 Sep 2016 14:08:38 -0700

> middleboxes, etc. which I do not think is what we want.
and this is where we get into word-smithing. I believe what I am
referring to is the quic public header. which I believe to be what is
necessary to distinguish flows. inner in this cases means inside the udp
header.

---

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

Joel,

> necessary to distinguish flows. inner in this cases means inside the udp

That's a helpful clarification. Thank you for sending it.

Spencer

> >>>>>>      When responding, please keep the subject line intact and reply
> to
> >>>>>> all
> >>>>>>      email addresses included in the To and CC lines. (Feel free to
> cut
> >>>>>>      this
> over

---

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

Dear All,

> necessary to distinguish flows. inner in this cases means inside the udp

That's the term in the current protocol specification, as I understand it.
That would be much clearer. I can (and should) make that change.

Spencer

---

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

Hi, Stephen,

> and the impact of such changes is a valid topic for discussion in

So, with Joel's clarification the result would look like this.

Manageability
includes the QUIC Public Packet Header format, parsability in flow export,
ACL
application, hashing of "flows" and directional signaling of flow
installation
and tear down.

Does that help?

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Sep 2016 00:00:08 +0100

Hiya,

> application, hashing of "flows" and directional signaling of flow

Sorry, but I'm not sure.

I'm not really sure what "Manageability includes" is meant to
mean here. Is that a generic statement that folks interested in
management think about such things? Or that the QUIC protocol
has to treat all of these things as first order requirements?
Or something in between?

I think we'd be better off focusing, in the charter text, on
things that are in-scope for discussion (which include Joel's
list) and to not have charter text that can be read to pre-judge
what the WG might conclude from such discussions. For example,
in the text above, I think it'd be controversial to assume that
hashing of flows will always be possible in whatever is the
end product of the WG. We know some people do that now, and
want to keep doing that, but I don't believe we now know that
the WG will come to consensus that that's still needed in the
same way it's currently done.

So again I'd say re-phrasing all this in terms of "Traditionally,
we did <foo, bar, baz>. QUIC may affect those. The WG will need
to discuss that" will be better.

Cheers,
S.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Sep 2016 17:05:34 -0700

I have the same concerns Stephen voices here, which is what I was trying to
articulate during the IESG telechat. I definitely prefer a version of the
re-phrasing he suggests. How about: "The Applicability Statement will
discuss QUIC's impact on network management and operations that have
traditionally used information visible in TCP headers."

---

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

Hi, Stephen and Jana,

On Sep 13, 2016 19:05, "Jana Iyengar" <[email-masked]> wrote:
>
> I have the same concerns Stephen voices here, which is what I was trying
to articulate during the IESG telechat. I definitely prefer a version of
the re-phrasing he suggests. How about: "The Applicability Statement will
discuss QUIC's impact on network management and operations that have
traditionally used information visible in TCP headers."

We're chatting about text Joel provided, so let's let him provide feedback
before I decide what to do here ...

Thanks,

Spencer

> On Tue, Sep 13, 2016 at 4:00 PM, Stephen Farrell <

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Sep 2016 06:49:03 +0000

+1

> On 2016-09-13, at 22:57, Stephen Farrell <[email-masked]> wrote:
> 
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 14 Sep 2016 00:12:29 -0700

SGTM.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Sep 2016 17:18:26 +1000

> On 14 Sep 2016, at 9:00 AM, Stephen Farrell <[email-masked]> wrote:
> 

+1 to that phrasing.

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

---

From: Brian Trammell <[email-masked]>
Date: Wed, 14 Sep 2016 10:33:41 +0200

Hi, all,

(Returning from the wilderness for a moment; my availability remains severely limited at least through September, so replies may be delayed.)

Perhaps a reference to 7258 could be helpful here? Paragraph 6 of section 2 addresses this issue pretty directly:

   While PM is an attack, other forms of monitoring that might fit the
   definition of PM can be beneficial and not part of any attack, e.g.,
   network management functions monitor packets or flows and anti-spam
   mechanisms need to see mail message content.  Some monitoring can
   even be part of the mitigation for PM, for example, certificate
   transparency [RFC6962] involves monitoring Public Key Infrastructure
   in ways that could detect some PM attack techniques.  However, there
   is clear potential for monitoring mechanisms to be abused for PM, so
   this tension needs careful consideration in protocol design.  Making
   networks unmanageable to mitigate PM is not an acceptable outcome,
   but ignoring PM would go against the consensus documented here.  An
   appropriate balance will emerge over time as real instances of this
   tension are considered.

To turn this into a concrete paragraph in the charter:

"The working group will consider the impact of the protocol on network management practices, in line with RFC 7258 [see section 2 para 6, though I'm not sure we want to quote chapter and verse in the charter]. Current network management of transport protocols includes the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these features as presently applied to TCP, but the working group must consider the tradeoffs between manageability and other goals for each feature."

In addition, perhaps having a list of RFCs to cite for each identified feature (i.e. 7011 for "flow information export") would make it clear that this is intended to be an exhaustive list: hooks for LI, for instance, are not considered "network management" in the IETF sense per 2804. In this case, I'd want Benoit and Joel to make sure the list is indeed exhaustive.

Cheers,

Brian

> On 14 Sep 2016, at 09:18, Mark Nottingham <[email-masked]> wrote:
> 
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 14 Sep 2016 06:36:46 -0700

>> to discuss that" will be better.
i'm ok  with that.
These are management properties that we find to be desirable properties
of the tcp/udp/ip protocol stack, the original text as bad as it was,
was intended to provide clarification that was both specific and
actionable for consideration, as opposed to what to my mind were not
actionable inclusion of management considerations that came about from
the discussion on the call.

These consideration weren't actually requirements of the design of the
ip protocol stack though the ability to implement them at least
initially comes as a consequence of it's design. we're better off if as
the operators of end systems if we don't lose access to functions on
which we have come to depend without at least having a serious
discussion about them first.

I am generally confident that public protocol header and the visible
connection oriented semantics of quic are sufficient. That doesn't mean
that the working group won't change them or that evaluating them with
respect to  applicability is now done (since the working group has yet
to be formed, complete it's work etc),

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 09:44:54 -0500

> to be formed, complete it's work etc),

Thanks, Joel, I'll reflect this in 00-04.

I also thought Brian's suggested pointer to RFC 7258 was useful.

More, soon.

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Sep 2016 17:21:56 +0200

+1 to what Brian stated.