Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[John Leslie <[e-mail]>]

Scharf, Michael (Michael) <[e-mail]> wrote:
> 
> Meeting attendance is not required. Still, I don't understand why not
> running an adoption call about two weeks after posting -00 really
> holds up work.

   (I don't understand how you're measuring "two weeks".)

   To me, it's more a question of how putting this question off until
the rush of IETF week can possibly help.

   We need to determine whether this work can get traction it TCPM; and
we need to get IETF support for doing this work in TCPM -- whose charter,
lest we forget, is quite clear about us doing "small" TCP changes.
  
> TCPM is not the only working group that has a high bar for adopting
> new work,

   A 30-second hum after a ten-minute presentation isn't my idea of
what "a high bar" should mean.

> and I think being conservative regarding std track TCP changes has
> always been a community consensus (e.g., our previous charter even
> told us that every new TCPM milestone requires IESG approval -
> that was certainly too conservative).

   The IESG today doesn't require "milestone" changes to come before
a formal telechat; but I can imagine some concern about whether this
particular change (invalidating the "Data offset" field) fits within
our charter or requires a change to the charter wording. I'd much
prefer that such a question not be squeezed into the IETF week rush.

> Also, in TCPM review cycles are unfortunately a rather scarce resource,
> and the chairs have to consider this as well when adopting new work.

   Absolutely: new work should not be started without commitments for
enough review cycles!

> Regarding draft-touch-tcpm-tcp-edo, I am particularly interested in
> more feedback from implementers and users before starting the formal
> adoption call.

   Ah, but _what_ feedback?

   Commitment to review, certainly.

   Do you need data on how crowded the option space is?

   Do you need security considerations? Does that include what happens
as the IP-layer path changes to include more or less middleboxes?

   Do you need analysis of how this sort of change interacts with
MPTCP?

   Do you need analysis of which middleboxes can't be modified to
recognize this proposed option?

   Please be specific.

> We usually get very valuable feedback from implementers during
> meetings, and that would be one reason not to rush right now -

   I really don't follow why adoption as a Working Group Draft would
get in the way of considering such feedback.

> but it is the feedback I am interested in, not the meeting. If
> corresponding aspects are discussed on the list before the next
> meeting, I'll be more than happy as well.

   Fair enough!

> Thus, instead of further arguing about process aspects, I am more
> interested in thoughts on:
> 
> * From designers of TCP extensions requiring more option space: Is
>   draft-touch-tcpm-tcp-edo a good solution for your needs and thus
>   the right way to move forward?

   We're desperate! We'll get behind anything!

> * From implementers: Are there deployment issues beyond what is
>   described in the draft already?

   Good lord, yes! (That deserves a separate thread -- but again,
surely that can be discussed for a WG Draft as easily as for an
individual draft, can't it?)

> And, would this mechanism be implemented in the Internet? 

   I'd be astounded if it wouldn't be implemented in Linux!

   What beyond that do you need?

--
John Leslie <[e-mail]>