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

[Warren Kumari <[e-mail]>]

On Wed, Nov 29, 2017 at 4:14 PM, Black, David <[e-mail]> wrote:
> 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:[e-mail]]
>> Sent: Tuesday, November 28, 2017 5:10 PM
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; Black, David <[e-mail]>;
>> [e-mail]; Black, David <[e-mail]>; [e-mail]
>> Subject: Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with
>> COMMENT)
>>
>> 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.
>
> [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.

Oh, well there you go then. Happy.

>
>> 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?
>
> [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

>
>> Also, once again a nice shepherd writeup from David.
>>
>



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