Re: [tcpm] proceeding EDO draft

["Scharf, Michael" <[e-mail]>]

Indeed, we have assigned codepoints for experimental options multiple times. And IMHO we can do so again if needed.

 

Note that my comment below on PS vs. EXP is not about the assignment of an option codepoint for EDO. I fully agree that EDO warrants the same considerations like other options. My concern is changing the meaning of the DO field in the main TCP header. I have argued in the past e.g. for AccECN that such changes in the main header are more appropriate on standards track.

 

As also already noted, I don’t object to EXP if it turns out that PS is not realistic.

 

Michael

 

 

 

From: [e-mail] <[e-mail]> 
Sent: Monday, March 27, 2023 5:19 AM
To: Yoshifumi Nishida <[e-mail]>
Cc: Scharf, Michael <[e-mail]>; [e-mail] Extensions <[e-mail]>; tcpm-chairs <[e-mail]>
Subject: 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 <http://www.strayalpha.com> 





On Mar 22, 2023, at 7:46 PM, Yoshifumi Nishida <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Yoshifumi Nishida
Sent: Thursday, February 16, 2023 9:30 AM
To: [e-mail] <mailto:[e-mail]>  Extensions <[e-mail] <mailto:[e-mail]> >
Cc: tcpm-chairs <[e-mail] <mailto:[e-mail]> >
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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/tcpm