Subject: [tcpinc] Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 28 Nov 2017 14:10:03 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-17: Yes

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-tcpinc-tcpeno/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'd like to echo what others have said, especially Adam's Section 4 comment,
and Benoit's "what is the actual experiment?" - if this doesn't explain what
the experiment will test, perhaps it should be Std Track? (Section 9, while
nice, doesn't really cover this). Just because it is new / untested doesn't
mean that it cannot be standard and then updated later.

I was also confused by the "option kind" - I'd assumed that it was simply a
term of art for TCP option, but seeing as Spencer is also mystified I'm
guessing not -- for my own education, can you please explain?

Also, once again a nice shepherd writeup from David.

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 Nov 2017 21:14:53 +0000

Hi Warren,

Many thanks for the Yes position and for the positive comments on the shepherd writeup ... two comments as shepherd are inline ...

Thanks, --David

> -----Original Message-----
> From: Warren Kumari [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2017 5:10 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Black, David <[email-masked]>;
> [email-masked]; Black, David <[email-masked]>; [email-masked]
> Subject: Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with
> COMMENT)
> 

[David>] "new/untested" is the major reason.  The Transport Area has a practice of applying Experimental status to TCP changes until there is sufficient "soak time" (e.g., operational experience) to demonstrate that they don't break anything.

> guessing not -- for my own education, can you please explain?

[David>] The "term of art" explanation is correct, e.g., see: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1 .

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Nov 2017 16:47:20 -0500

> [David>] "new/untested" is the major reason.  The Transport Area has a practice of applying Experimental status to TCP changes until there is sufficient "soak time" (e.g., operational experience) t…

Oh, well there you go then. Happy.

> [David>] The "term of art" explanation is correct, e.g., see: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1 .

Wow, somehow I'd missed that <embarrassed> -- I'd always thought that
they were just TCP Options and were Type-Length-Value. Rereading
RFC793 "Kind" is starting to feel a bit familiar though...

Thank you,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf