Subject: [quicwg/base-drafts] Recovery-31 (#4178)

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Oct 2020 14:23:08 +0000 (UTC)

In Recovery-31 there are several references that I judge as normative and not informative ones.

- Section 7.8: "A sender MAY use the pipeACK method described in Section 4.3 of [RFC7661] to determine if the congestion window is sufficiently utilized." A normative reference necessary to follow if one selects to use the optional method.

- Sectiom 7.3.2: "Implementations MAY reduce the congestion window immediately upon entering a recovery period or use other mechanisms, such as Proportional Rate Reduction ([PRR]), to reduce the congestion window more gradually." Another case of a suggested mechanism, which if one is to follow it requires one to read that PPR reference. Secondly, why the alternative reference style.

- Section 8.3: "Markings can be treated as equivalent to loss ([RFC3168]), but other responses can be specified, such as ([RFC8511]) or ([RFC8311])." So RFC3168 is the normative specification for the treat it equal to loss. RFC8511 is the TCP alternative back-off an experimental specification for the alternative. And RFC8311 is the process for performing other experiments with alternative responses. I judge all necessary depending on what one intendeds to do. 

So to my understanding this results in two downrefs to experimental specifications. I think that is acceptable in the context they are used in this document. But to be tried in IETF last call. However, I think I don't want to generally recommend them to be acceptable as downrefs so I have no intentions to promote them for the Downref registry. 

-- 
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/4178

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 05 Oct 2020 16:51:43 -0700

Moving discussion from the PR to the issue.

- @ianswett says:

I'm not the expert on what should be normative, but these were intentionally marked as informative references since they're all TCP specific RFCs. The pipeACK reference in particular seems like an odd one.

If this is what the chairs want, then I'm ok with it as an editor, but these choices were intentional.

- @martinduke says:

I see what @gloinul is saying, but I also see some wiggle room in RFC 3967, Section 1.1:

When a reference to an example is made, such a reference need not
be normative. For example, text such as "an algorithm such as the
one specified in [RFCxxxx] would be acceptable" indicates an
informative reference, since that cited algorithm is just one of
several possible algorithms that could be used.
I am also somewhat concerned that trying to get the downrefs into the registry is more likely to run into trouble (Sec 3)

This procedure should not be used if the proper step is to move the
document to which the reference is being made into the appropriate
category. It is not intended as an easy way out of normal process.
Rather, the procedure is intended for dealing with specific cases
where putting particular documents into the required category is
problematic and unlikely ever to happen.

-- 
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/4178#issuecomment-703948760

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 05 Oct 2020 16:54:25 -0700

Thanks for digging up the relevant text, @martinduke. Based on that text from RFC 3967, it doesn't seem like we _need_ to make these references normative.

I agree that the pipeACK reference is odd, but I think that's probably because of the use of MAY there. I'm happy to replace the MAY with a can -- it is meant to present an option, not a permission -- and make that reference informative as well.

@gloinul : thoughts?

-- 
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/4178#issuecomment-703949424

---

From: mirjak <[email-masked]>
Date: Tue, 06 Oct 2020 02:55:02 -0700

I think at last RFC3168 should be referenced normatively somewhere (probably section 7.1 though) because you need to know what the ECN bits are in order to do anything with it. I guess because of section 7.1. RFC8311 should also be a normative reference.

-- 
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/4178#issuecomment-704161480

---

From: martinduke <[email-masked]>
Date: Tue, 06 Oct 2020 07:10:26 -0700

@mirjak RFC3168 is already a normative reference in the transport doc, which in my view is appropriate.

-- 
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/4178#issuecomment-704295324

---

From: mirjak <[email-masked]>
Date: Tue, 06 Oct 2020 07:50:16 -0700

Was wondering about this as well given the transport doc is of course a normative reference of this doc. However, as this doc uses terms like CE also directly itself I think the right practice is to also have it as a normative reference here, and as you have to read it no matter what, it definitely shouldn't hurt.

-- 
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/4178#issuecomment-704322174

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 06 Oct 2020 14:01:37 -0700

[Section 7.1](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-7.1) talks about ECN-CE markings, but really all of Section 7 talks about a response to an increase in ECN-CE count by the peer, which is defined in the transport doc. This does point to a small editorial issue. The text in Section 4.1 says:

```
This document specifies an endpoint's response when its peer receives packets with the ECN-CE codepoint.
```

This really should be:

```
This document specifies an endpoint's response when the peer-reported ECN-CE count increases.
```

-- 
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/4178#issuecomment-704550273

---

From: ianswett <[email-masked]>
Date: Tue, 06 Oct 2020 14:04:24 -0700

Good point on the editorial issue.

-- 
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/4178#issuecomment-704551678

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 06 Oct 2020 14:09:31 -0700

With that change, the only thing we're left with is [Section 8.3](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#name-misreporting-ecn-markings). This does require an understanding of ECN, and it has RFC 2119 keywords, but it's really an optional mechanism that is suggested. We could remove the RFC 2119 words there, since they're really unnecessary.

-- 
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/4178#issuecomment-704554030

---

From: mirjak <[email-masked]>
Date: Wed, 07 Oct 2020 02:13:49 -0700

My point is that RFC3168 should be normative because not matter what you need to understand what an ECN-CE mark is and that is defined/specified in RFC3168.

-- 
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/4178#issuecomment-704804314

---

From: Lars Eggert <[email-masked]>
Date: Wed, 07 Oct 2020 02:17:35 -0700

Mirja has a point, see https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

-- 
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/4178#issuecomment-704806407

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Oct 2020 02:19:54 -0700

> Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.

-transport is a normative reference.  So 3168 is already (transitively) a normative reference.  The question is whether this specific text requires anything from 3168 to understand.  I don't see that it does, especially given the suggested change, which talks about a concept defined in -transport, not 3168.

-- 
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/4178#issuecomment-704807685

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 08 Oct 2020 14:37:46 -0700

#4185 has made these editorial changes; @gloinul, can you see if anything else needs to be done here?

-- 
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/4178#issuecomment-705837217

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Oct 2020 05:18:18 -0700

I will note that it was never my intention to let any of theses Experimental or informational TCP specs to be added into the downref registry by this last call. 

So, the pipeack reference needs to be reformulated to not be a normative one. As currently stated it is a clear normative reference per IESG Statement ([https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/]) , and especially 
"Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. " You need to find a formulation that normative describes what the implementation MAY do, and then you can exemplify with the TCP version. 

Then one in Section 7.3.2 I can accept as still being informative as the MAY statement is related to the primary aspect of the sentence and the reference to PPR is exemplifying. Still this is very much on the border and may still generate a comment in IESG. 

For RFC 3168 I don't understand why not making it to a normative one. There are no issues with its status as it is proposed standard. And simply the security consideration section still implies that you need to know what a ECN-CE mark is to interpret this. So please make this one normative. 

-- 
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/4178#issuecomment-707085040

---

From: ianswett <[email-masked]>
Date: Mon, 12 Oct 2020 05:53:51 -0700

I'm ok with RFC 3168 being normative, but would like to avoid making the others normative.

-- 
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/4178#issuecomment-707101934

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Oct 2020 06:42:11 -0700

@ianswett if pipeack is not normative then a reformulation is necessary of that sentence in Section 7.8 to not state is as a mechanism that MAY be implemented. 

-- 
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/4178#issuecomment-707127551

---

From: ianswett <[email-masked]>
Date: Mon, 12 Oct 2020 07:03:41 -0700

The sentence currently has a can, not a MAY:
"A sender can use the pipeACK method described in Section 4.3 of {{?RFC7661}} to
determine if the congestion window is sufficiently utilized."

But I sent out PR #4190 to make it clearer that pipeACK is an example, PTAL and see if that helps.

-- 
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/4178#issuecomment-707140398

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Oct 2020 09:45:22 -0700

@ianswett what PR #4190 proposes removing that first sentence do resolve the pipeack to me. 
So merging #4190, and moving RFC3168 to normative will resolve this issue to my understanding.

-- 
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/4178#issuecomment-707229833

---

From: ianswett <[email-masked]>
Date: Mon, 12 Oct 2020 09:48:07 -0700

Thanks!  I'll update PR #4190 to include moving RFC3168 to normative.

-- 
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/4178#issuecomment-707231232

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Oct 2020 13:04:29 -0700

@larseggert @LPardue : I believe this is purely editorial, but I'd like to confirm.

-- 
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/4178#issuecomment-707319558

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 13 Oct 2020 12:57:06 -0700

We've meandered to a route that AFAICT makes reference types accurate to their existing intent, or avoids them becoming normative. I'm happy for this to be editorials. 

-- 
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/4178#issuecomment-707973380

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Oct 2020 13:43:24 -0700

Closed #4178 via #4190.

-- 
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/4178#event-3873462547