Subject: Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT)

From: "Black, David" <[email-masked]>
Date: Tue, 17 Oct 2017 21:49:47 +0000

Ben,

Thanks for the careful review, comments inline ... text changes are in my working version of what will become the -07 version of this draft.

I'll start a separate thread to follow up on the RTP requirement change concern.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, September 27, 2017 8:54 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-ecn-
> experimentation-06: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-tsvwg-ecn-experimentation-06: No Objection
> 
> 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.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Substantive:
> 
> General:
> 
>  I agree with Ekr's comment specifying RFC updates as text"patches" is
>  confusing and unfriendly to the reader. While I don't necessarily agree that
>  we should do bis drafts instead, I hope people will remember that we never
>  actually render an "updated" RFC with the patches applied. I think this sort
>  of thing would be easier to understand if we just spoke of the changes at a
>  conceptual level and avoid getting wrapped around changing specific words to
>  other specific words.  I don't expect that to change with this particular
>  draft, but I think the IESG should consider some guidance here. (And I fully
>  recognize that a lot of update drafts in ART do the same thing.)
>
[David>] Been there, tried that in earlier versions of the draft, received clear direction to spell out the details ...
> 
> -1, first paragraph: "An Experimental RFC MUST be published for any protocol
>    or mechanism that takes advantage of any of these enabling updates."
> 
> This seems like an odd use of 2119 language, at least for something other than
> a BCP.  Furthermore, I don't think this paragraph is the real authority on the
> matter, since there is much more precise text scattered through the draft about
> this particular requirement. Therefore, I suggest removing the 2119 language
> and stating this descriptively. (e.g. "Mechanisms that take advantage of these
> updates are to be specified in experimental RFCs.")
> 
[David>] Copied sentence from Abstract: " An Experimental RFC is required to take advantage of any of these enabling updates."

> Speaking of which, there are several references to requiring experimental RFCs.
> Are those expected to be IETF stream RFCs?
>
[David>] Yes, independent submissions (ISE stream) RFCs are Informational, and cannot be published as Experimental.
> 
> -5, first "patch":
> Are there existing implementations that would become noncompliant with the new text?
> 
[David>] I don't think so, but I will double check w/an RTP expert and back off MUST/MUST NOT to SHOULD/SHOULD NOT if there's any doubt.  As indicated in one of Mirja's comments, we (Transport folks) would prefer to prohibit this behavior.

> -9, 1st paragraph: "As a process memo that only removes limitations on proposed
>    experiments, there are no protocol security considerations."
> I am skeptical that removing limitations from experiments can be assumed to be
> security neutral on its face. Please consider documenting the thought process
> that led to that conclusion.
>
[David>] It's actually spelled out in the very next sentence: "Security considerations for the proposed experiments are discussed in the Internet-Drafts that propose them."
Should that be strengthened?  If so, please suggest text.
> 
> Editorial:
> -1, 2nd paragraph: " There is no need to make changes for protocols ...
> I'm a bit confused--those hypothetical standards track RFCs will need to make
> the sort of changes that this paragraph says are not needed. Is the point that
> _this_ document does not need to make those changes?
>
[David>] Almost - a standards track RFC has no need to rely on this document in order to make those changes.  New text:

There is no need for this memo to update RFC 3168 in order to enable protocols and mechanisms that are documented in Standards Track RFCs, as any Standards Track RFC can update RFC 3168 directly without either relying on updates in this memo or using a standards process exception.

> 
> -2, Congestion Response Difference: "As discussed further in
>       Section 4.1, an ECN congestion indication communicates a higher
>       likelihood that a shorter queue exists at the network bottleneck
>       node by comparison to a packet drop that indicates congestion
>       [I-D.ietf-tcpm-alternativebackoff-ecn]."
> 
> I'm not sure what is being compared here. Is it a high chance of shorter queue,
> or higher chance of a short queue?
>
[David>] The queue at the bottleneck is likely to be shorter when ECN is used at the bottleneck, or, in other words, the queue is likely to get longer before drops occur, even if ECN is not used.  This is all probabilistic, hence the use of "higher likelihood".  New text:

an ECN congestion indication communicates a higher likelihood that a shorter queue exists at the network bottleneck node by comparison to a longer queue that is more likely when a packet drop that indicates congestion occurs

> 
> -- (same paragraph): "(next bullet)"
> There are no bullets.
> 
[David>] Fixed: "(see next paragraph)"

> -2, Congestion Marking Difference:
> The first sentence is hard to parse. Please consider breaking it into simpler
> sentences.
> 
[David>] Simplified to: Congestion marking at network nodes can be configured to maintain very shallow queues in conjunction with a different sender response to congestion indications (CE marks),

> -3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified in experimental
>    RFC 3540 [RFC3540].
> This is hard to parse. In particular, I have trouble deciphering which part is
> supposed to be specified in 3168 vs 3540.
> 
[David>] Broke into two sentences, one for each RFC, rephrased slightly.  Thanks for noticing this!

> -- 2nd paragraph: "but might equally have been due to re-
>    marking of the ECN field by an erroneous middlebox or router."
> I think "erroneous" modified "re-marking" rather than "middlebox or
> router".
> 
[David>] Fixed

> -4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving conventional
>    traffic ...  "
> Is there a missing "from" between "traffic" and "starving"  Or maybe an "of"
> after "starving"?
> 
[David>] yes, added missing "from"

---

From: Ben Campbell <[email-masked]>
Date: Wed, 18 Oct 2017 11:14:48 -0500

> On Oct 17, 2017, at 4:49 PM, Black, David <[email-masked]> wrote:
> 
> Ben,
> 
> [David>] Been there, tried that in earlier versions of the draft, received clear direction to spell out the details …

Yeah, that comment wasn’t really for you  :-)

> [David>] Copied sentence from Abstract: " An Experimental RFC is required to take advantage of any of these enabling updates.”

WFM

> [David>] Yes, independent submissions (ISE stream) RFCs are Informational, and cannot be published as Experimental.

Right. Of course.

> [David>] I don't think so, but I will double check w/an RTP expert and back off MUST/MUST NOT to SHOULD/SHOULD NOT if there's any doubt.  As indicated in one of Mirja's comments, we (Transport folk…

That seem like a reasonable approach.

> Should that be strengthened?  If so, please suggest text.

(disclaimer: I don’t have the text in front of me right this moment): Would it be worth saying something to the effect that any future experiments need to do the same?

[Responses to my editorial comments all look fine.}

Thanks!

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Oct 2017 19:20:44 +0100

> [David>] Yes, independent submissions (ISE stream) RFCs are Informational, and cannot be published as Experimental.

Independent Stream RFCs can be Informational or Experimental.

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Oct 2017 21:38:49 +0000

That's a surprise, at least to me - I'm reasonably certain that we don't want to see this sort of experimentation done via ISE stream RFCs.

Thanks, --David

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2017 2:21 PM
> To: Black, David <[email-masked]>
> Cc: Ben Campbell <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked];
> Subject: Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-ecn-
> > [David>] Yes, independent submissions (ISE stream) RFCs are
> Informational, and cannot be published as Experimental.
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Oct 2017 22:11:45 +0000

> > [David>] It's actually spelled out in the very next sentence: "Security
> considerations for the proposed experiments are discussed in the Internet-
> Drafts that propose them."
> (disclaimer: I don’t have the text in front of me right this moment): Would it
> be worth saying something to the effect that any future experiments need
> to do the same?

Ok, I generalized the second sentence and ran the two sentences together to connect the concepts - paragraph now reads as follows in my working copy (NB: Draft title is being changed to "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation" as part of dealing with Benoit's Discuss):

As a process memo that only relaxes restrictions on experimentation, there are no protocol security considerations, as security considerations for any experiments that take advantage of the relaxed restrictions are discussed in the Internet-Drafts that propose the experiments.

Thanks, --David

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2017 12:15 PM
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-tsvwg-ecn-
> [email-masked]; [email-masked]; [email-masked]
> > Thanks for the careful review, comments inline ... text changes are in my
> working version of what will become the -07 version of this draft.
> >
> > [David>] Been there, tried that in earlier versions of the draft, received
> clear direction to spell out the details …
> 
> > [David>] Copied sentence from Abstract: " An Experimental RFC is required
> to take advantage of any of these enabling updates.”
> 
> WFM
> 
> >
> > [David>] I don't think so, but I will double check w/an RTP expert and back
> off MUST/MUST NOT to SHOULD/SHOULD NOT if there's any doubt.  As
> indicated in one of Mirja's comments, we (Transport folks) would prefer to
> prohibit this behavior.
> 
> > [David>] It's actually spelled out in the very next sentence: "Security
> considerations for the proposed experiments are discussed in the Internet-
> Drafts that propose them."
> (disclaimer: I don’t have the text in front of me right this moment): Would it
> be worth saying something to the effect that any future experiments need
> to do the same?
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Oct 2017 15:30:31 -0700

> On Oct 18, 2017, at 2:38 PM, Black, David <[email-masked]> wrote:
> 

Perhaps, but there are other valid experiments, eg using experimental code points. 

See www.ietf.org/iesg/informational-vs-experimental.html sec 4.2.1

Joe

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Oct 2017 22:52:46 +0000

> Perhaps, but there are other valid experiments, eg using experimental code points.

Well, if there were any unallocated ECN codepoints, assigning one for experimentation would be a fine move, IMHO.  Needless to say, there aren't ;-) - all four ECN codepoints are allocated, and this draft goes to considerable length to pry one of them, ECT(1), loose enough to be used for at least the L4S experiment.

Permanently designating ECT(1) for experimental usage seems like a bad idea, as there are no other codepoints available for successful experiments to employ when standardized.

> See www.ietf.org/iesg/informational-vs-experimental.html sec 4.2.1

Well, point 4 in sec 3 (Guidelines) of that document seems determinative here, as it describes what is going on with the experiments noted in this draft:

4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)

Thanks, --David

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2017 6:31 PM
> Cc: Alexey Melnikov <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> > That's a surprise, at least to me - I'm reasonably certain that we don't want
> to see this sort of experimentation done via ISE stream RFCs.
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Oct 2017 16:56:40 -0700

> On Oct 18, 2017, at 3:52 PM, Black, David <[email-masked]> wrote:
> 

Agreed. I was giving an example, not related to this doc, of a valid individual experimental RFC. 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2017 13:48:17 +1300

> That's a surprise, at least to me - I'm reasonably certain that we don't want to see this sort of experimentation done via ISE stream RFCs.

Ah, but that's why it's called the "independent" stream. It's rarely used that
way, but if there's a strong case that the IETF side of the house is being
unreasonably obstructive, the Independent stream is there as a safety valve.

The IRTF stream can also approve Experimental RFCs, iirc.

However, none of this can bypass BCP 26, so the applicable IANA policy
can trump the Independent and IRTF stream, if IANA registration is
needed.

   Brian

---

From: Ben Campbell <[email-masked]>
Date: Wed, 18 Oct 2017 19:52:03 -0500

> On Oct 18, 2017, at 5:11 PM, Black, David <[email-masked]> wrote:
> 

That WFM.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 18 Oct 2017 19:55:03 -0500

https://www.rfc-editor.org/about/independent/ confirms Alexey’s comment.

Does that mean this draft should explicitly require IETF stream experimental RFCs? 

Thanks!

Ben.

> On Oct 18, 2017, at 4:38 PM, Black, David <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2017 14:52:33 +1300

> Does that mean this draft should explicitly require IETF stream experimental RFCs? 

You could write that down, but the independent stream is, er, independent,
i.e. intentionally not controlled by the IETF.

I am not in the least arguing for doing any such experiments outside the
scope of the IETF. I expect that if such a draft came up in the Independent
stream, the IESG would advise the ISE that it should not be published. But
the ISE is intentionally entitled to ignore the IESG's advice.

ISEs I have known would undoubtedly have exercised common sense in such
a case, and told the author(s) to take the work to the IETF, *unless*
there was overwhelming evidence that the IETF was acting unreasonably
or unfairly. That's why we have the safety valve.

   Brian
   (speaking for myself, but I am a member of the Independent Series
   Advisory Board, https://www.rfc-editor.org/about/ISEB/)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 18 Oct 2017 21:39:53 -0500

> On Oct 18, 2017, at 8:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree with all of that. Maybe the word “require” was badly chosen.

But it’s worth considering that we can’t really enforce any part of the “you must document any use of this experimental code point in an experimental RFC” bit. People can run experiments without telling us. The best we can do is document the intent of the working group. (IIUC, the David plans to remove the 2119 language around this.) If the ISE decides to publish such a document anyway, so be it—but maybe writing down the intent will help inform that decision.

Ben.

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 Oct 2017 15:03:13 +0000

> But it’s worth considering that we can’t really enforce any part of the “you
> must document any use of this experimental code point in an experimental
> RFC” bit. People can run experiments without telling us. The best we can do
> is document the intent of the working group. (IIUC, the David plans to
> remove the 2119 language around this.) If the ISE decides to publish such a
> document anyway, so be it—but maybe writing down the intent will help
> inform that decision.

Indeed, I've removed the 2119 language on Experimental RFCs from my working draft, and I concur with the underlying point that the IETF can only enforce requirements on documents that the IETF controls.

What I've done in my working draft is a nearly-global text change from "Experimental RFC" to "Experimental RFC in the IETF document stream."  The upshot is that if someone wants to publish an Experimental RFC that takes advantage of the ECN requirement relaxation in this draft, then that Experimental RFC has to be in the IETF document stream and cannot be in the Independent Submission document stream.  The enforcement mechanism for this would be IESG conflict review oversight of the Independent Submission document stream, but I see no need to explain that in this draft.

I'm getting close to having initial edits that respond to all of the concerns and suggestions noted in IESG Evaluation - a -07 version should appear with those edits by late tomorrow as a baseline from which we can figure out what else needs to be done.

Thanks, --David

> Sent: Wednesday, October 18, 2017 10:40 PM
> To: Brian E Carpenter <[email-masked]>
> Cc: Black, David <[email-masked]>; [email-masked];
> [email-masked]; Alexey Melnikov <[email-masked]>; draft-ietf-
> [email-masked]; [email-masked]; The IESG
> <[email-masked]>
> But it’s worth considering that we can’t really enforce any part of the “you
> must document any use of this experimental code point in an experimental
> RFC” bit. People can run experiments without telling us. The best we can do
> is document the intent of the working group. (IIUC, the David plans to
> remove the 2119 language around this.) If the ISE decides to publish such a
> document anyway, so be it—but maybe writing down the intent will help
> inform that decision.
> 
> Ben.
> 
> >
> >   Brian
> >>> That's a surprise, at least to me - I'm reasonably certain that we don't
> want to see this sort of experimentation done via ISE stream RFCs.
> >>>
> >>> Thanks, --David
> >>>
> >>>>>> Speaking of which, there are several references to requiring
> experimental
> >>>> RFCs.