Re: [tcpm] proceeding EDO draft

FWIW, it’s both EDO and SYN-EDO that need decisions.

Given how other TCP options have been assigned for experimental RFCs, maybe that leaves the window for us as well:

	MPTCP (original RFC)
	TCP-FastOpen Cookie
	TCP-ENO
	Quickstart response

I don’t much care, but IMO both of these docs (which use the same option kind) warrant the same consideration as the options above.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 22, 2023, at 7:46 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
> 
> Hi Michael,
> 
> I just would like to thank you for providing very detailed feedback on the draft. 
> This is very helpful for the chairs to think about how to proceed.
> It would be great if we can get more feedback from the community.
> 
> Thanks,
> --
> Yoshi
> 
> On Tue, Mar 21, 2023 at 7:23 AM Scharf, Michael <Michael.Scharf@hs-esslingen.de <mailto:Michael.Scharf@hs-esslingen.de>> wrote:
>> Hi all,
>> 
>>  
>> 
>> I have read version -13. To trigger some discussion, here are my thoughts regarding the questions below…
>> 
>>  
>> 
>>  
>> 
>> Regarding 1: Do we need to update the draft in order to proceed? Are there any outstanding comments to be addressed?
>> 
>>  
>> 
>> I have some comments (see below), but I don’t think that they are difficult to address.
>> 
>>  
>> 
>>  
>> 
>> Regarding 2: Do we need some conditions to proceed with the draft, such as existing implementations or operational experiences?
>> 
>>  
>> 
>> Of course, running code has always been very important in TCPM – for good reasons.
>> 
>>  
>> 
>> Yet, formally, I think it is up to the IESG to decide whether there is sufficient operational experience. Thus, one option for TCPM would be to ship the document to the IESG and let them make the call. Of course, the shepherd writeup would have to be very clear regarding implementations and operational experiences.
>> 
>>  
>> 
>> And at least some past requests for more option space came from outside TCPM. To some extent, the IETF as a whole needs to make a call whether this problem needs to be solved by TCPM. And if the answer is “no”, then let it be.
>> 
>>  
>> 
>>  
>> 
>> 3: Is the current intended status of the draft (PS) the reason for the slow progress?
>> 
>>  
>> 
>> The bar for PS in TCPM is traditionally very high – again, for good reasons.
>> 
>>  
>> 
>> Yet, I personally think the document could head for Proposed Standard status when being shipped to the IESG.
>> 
>>  
>> 
>> As of today there may be no apparent urgent need for this standard in TCPM. But TCPM has repeatedly seen requirements in this space in the past, and the document makes a proposal how to address this. It is the best known solution for the reasons documented in the document. There have been other cases for RFCs that got relevant, but not at the time of writing.
>> 
>>  
>> 
>> Personally, I prefer documenting the best known solution and its limitations instead of not documenting any solution.
>> 
>>  
>> 
>> I’d also be fine with an EXP or INFO document in that space, e.g. to document the challenges. Yet, as already noted in the past for other documents, I don’t think the main TCP header should be modified outside standards track. So, the scope of an EXP or INFO document would have to be discussed very carefully.
>> 
>>  
>> 
>>  
>> 
>> 4: Any other ideas/suggestions for this?
>> 
>>  
>> 
>> Some comments:
>> 
>>  
>> 
>> It is not clear to me if the document (if heading towards PS) needs to formally update RFC 5925. The wording “augment” in the document is a bit ambiguous. (Disclaimer: I haven’t checked whether some wording in RFC 5925 would be affected.)
>>  
>> 
>> Section 6.6 on ICMP seems like a good catch. Without that explanation, I would probably have missed the impact on ICMP. This sort of details is to me one of the reasons why the document is valuable. Yet, the document could expand a bit better whether ICMP could be affected. Are we sure no RFC needs to be updated?
>>  
>> 
>> Section 10 Security Considerations is short and a bit hard to parse. For instance, it could make sense to add some pointers to other sections in the document that could be relevant for security. Also, some additional explanation on the “covert channel” problem could make sense.
>>  
>> 
>> Some nits:
>> 
>>  
>> 
>> Section 2 should reference RFC 8174 in addition to RFC 2119
>>  
>> 
>> The acronym for Multipath TCP should be spelt consistently (I know it as “MPTCP”)
>>  
>> 
>> Thanks
>> 
>>  
>> 
>> Michael
>> 
>>  
>> 
>>  
>> 
>> From: tcpm <tcpm-bounces@ietf.org <mailto:tcpm-bounces@ietf.org>> On Behalf Of Yoshifumi Nishida
>> Sent: Thursday, February 16, 2023 9:30 AM
>> To: tcpm@ietf.org <mailto:tcpm@ietf.org> Extensions <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>> Cc: tcpm-chairs <tcpm-chairs@ietf.org <mailto:tcpm-chairs@ietf.org>>
>> Subject: [tcpm] proceeding EDO draft
>> 
>>  
>> 
>> Hi folks,
>> 
>>  
>> 
>> As the next IETF meeting is approaching, I think it's a good time to bring this up again.
>> 
>> I've been thinking about the status of the EDO draft.
>> 
>> As it is hanging around for a while, I am wondering what the best way to proceed with the draft.
>> 
>> As the first step, I would like to understand the current status a bit more.
>> 
>> If some folks give some inputs for the following questions, I would be very grateful.
>> 
>>  
>> 
>> 1: Do we need to update the draft in order to proceed? Are there any outstanding comments to be addressed?
>> 
>> 2: Do we need some conditions to proceed with the draft, such as existing implementations or operational experiences?
>> 
>> 3: Is the current intended status of the draft (PS) the reason for the slow progress?
>> 
>> 4: Any other ideas/suggestions for this?
>> 
>>  
>> 
>> I highly appreciate your inputs. Thank you!
>> 
>> --
>> 
>> Yoshi
>> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm