Subject: [quicwg/base-drafts] Normative Text in Invariants (#3773)

From: martinduke <[email-masked]>
Date: Wed, 17 Jun 2020 16:21:08 -0700

I started a thread on the mailing list
https://mailarchive.ietf.org/arch/msg/quic/Zmu9uAyutk-dAz5wdAUjktTvfek/

And the general sense of it was that this text was insufficiently clear about the normative requirements it was creating. 

I believe this issue is editorial.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jun 2020 18:14:04 -0700

I agree that this is editorial, but I think that we should say something that is subtly different.

There are two parts to your PR.  One part that attempts to describe what is normative in the document.  The other part attempts to more clearly describe the intent of the document: basically that anyone who looks at QUIC from the outside can only see and use this much of the protocol.

For the "normative" piece, we can probably say something less concrete but more principled.  That is: a protocol that follows the requirements in this document may call itself QUIC.  And that any attempt to treat QUIC generically MUST be limited to using the characteristics that are included in this definition.

For the intent part, I would say that the goal is to carve out a space for endpoints to communicate without interference from others.  The goal is to design a protocol where participation by others only occurs with the express permission of endpoints.  (I think we should be careful not to say whether this is just one or both endpoints granting permission here, because QUICv1 is a little inconsistent on this point itself.)  That's somewhat stronger than the position you take.

Leaving "others" unspecified here is good.  I see that you have tried to define those others, but I don't think that's helpful.

The nice thing about this approach is that it requires far less text.  Your PR doubles the size of the draft.  

BTW, I do like the MUST regarding treatment of unknown versions.  That is, if an entity doesn't understand what is going on then it can only apply generic treatment.  But we all know that's RFC 6919 language.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773#issuecomment-645709658

---

From: martinduke <[email-masked]>
Date: Thu, 18 Jun 2020 09:22:03 -0700

@martinthomson, thanks for your thoughts.

> That is: a protocol that follows the requirements in this document may call itself QUIC.

I tried to avoid language like "The QUIC WG MUST observe these invariants in future versions of QUIC". It seemed futile to have the WG constrain its future self in this way, while requirements for intermediaries would at least be actionable.

> For the intent part, I would say that the goal is to carve out a space for endpoints to communicate without interference from others.

I will add a recommendation for explicit cooperation; this is a good idea. Though I think there are cases, like measurement, where it isn't necessary.

> Leaving "others" unspecified here is good. I see that you have tried to define those others, but I don't think that's helpful.

I think illustrative examples are helpful, but I'll revise to make it clear that the are non-exclusive examples, while leaving the exemption for proxies.

> Your PR doubles the size of the draft.

I'm not sure what to do with this comment; I think it's important that we make it crystal clear who this document is written for and what people are supposed to do with it. It's not long.

Revision is in flight.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773#issuecomment-646139799

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jun 2020 21:35:10 -0700

After discussing this a little more, I have come to realize that most of what you are proposing is covered already - in excruciating detail - in [the manageability draft](https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html).  Maybe the words and framing are different, and it might be less direct than what you propose, but the important concepts exist there.

What you propose here takes a small step toward moving that into invariants and I don't think that fits with my conception of the document.

The primary function for me is that of a commitment regarding the shape of future versions of QUIC.  That's a commitment that the IETF makes, and given what I know about how good we are at keeping those commitments, that's not worth a lot.  But if we accept the credibility of that commitment, it has value if it successfully constrains future QUIC versions.

Why we do that is in the hope that intermediaries will choose to respect the boundaries we set.  So you are right in calling out the fact that this is the line of tape dividing the apartment in two and the effect that has on curtailing the movements of both parties.  However, I don't want to say much about intermediaries (though some discussion exists in security considerations).

If anything, I would prefer to leave this at something less targeted and more concise.  Maybe the following as a new Section 4 "Scope":

> To the extent that other entities are able to participate in communication between endpoints, a goal of the QUIC design is to provide technical measures that prevent interaction with a QUIC connection by entities other than QUIC endpoints. However, these technical measures are limited in what they can protect and could vary between versions.
>
> This document defines what parts of the QUIC protocol are not permitted to vary between versions.  As a consequence, this also guarantees a minimal amount of information that is made available to entities other than QUIC endpoints.
> 
> Limited interaction with QUIC connections is permitted by entities other than endpoints, such as load balancers or measurement devices, where interactions are expressly enabled by endpoints.

After that, I think we're into either increasing the scope or taking material from the manageability draft, neither of which I think make this document better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773#issuecomment-648578787

---

From: martinduke <[email-masked]>
Date: Wed, 24 Jun 2020 09:07:15 -0700

Good catch on manageability, though that's an Informational draft, and the thread that spawned all this was a desire for normative text.

> The primary function for me is that of a commitment regarding the shape of future versions of QUIC. That's a commitment that the IETF makes, and given what I know about how good we are at keeping t…

This sounds like an informational purpose to me.

Your proposed text is fine.

As for my PR, I thought we'd gathered rough consensus that something to that effect was desirable, but I'm not going to lie down in the road over it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773#issuecomment-648914415

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 25 Jun 2020 18:28:23 -0700

My take on the invariants draft is the same as @martinthomson's: That is really about what future protocol versions of QUIC need to adhere to. I don't think we should be specifying what we are making available to intermediaries. That is merely a side-effect, and I don't think we should be changing the scope of the document.

These bits were not made available so intermediaries could use them. They were made available for the endpoints to pivot around, for the receiver to find the necessary information so that it could decrypt or reject the packet. The bits that are visible to third parties is a consequence, and this consequence is equally useful to intermediaries and sniffing tools.

@martinthomson : FWIW, I think the second paragraph in the proposed text is adequate. The first and third explicitly state things that don't really belong in the invariants draft IMO.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3773#issuecomment-649897966