Re: [tcpm] proceeding EDO draft

[Yoshifumi Nishida <[e-mail]>]

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]> 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]> *On Behalf Of *Yoshifumi Nishida
> *Sent:* Thursday, February 16, 2023 9:30 AM
> *To:* [e-mail] Extensions <[e-mail]>
> *Cc:* tcpm-chairs <[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
>