Subject: [tcpm] Completion of WGLC for draft-ietf-tcpm-fastopen-05

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:59:32 +0000

Hi all,

As an outcome of the WGLC for draft-ietf-tcpm-fastopen-05, a document revision is needed.

WGLC comments were submitted by:

* Gorry Fairhurst: Several remarks and questions, already some list discussion ==> Gorry will have to review follow-up version, possibly iteration required

* Donald Smith: Comment on Section 4.1.2, not discussed on list so far ==> Authors, any thoughts?

* Joe Touch: Objection to dedicated option codepoint, discussed on list and in meeting, including a consensus call with strong support for a dedicated codepoint ==> See below

* Bob Briscoe: Nits ==> Trivial to address

Regarding the assignment of a dedicated option codepoint, the rough but solid consensus in TCPM seems to be:

* Fast open is a useful TCP experiment for relevant applications, and it has the potential for wider experimentation and deployment

* There is no significant shortage of IANA-assigned TCP option codepoints for users following the IETF process: Out of 256 codepoints, IANA has only 14 codepoints assigned to an non-obsoleted RFC, 6 other registrations (probably legacy with unknown deployment state), 9 obsoleted codepoints (available for re-use?), and of the order of 10-15 known unauthorized uses

* In contrast, option space in the TCP SYN is an extremely scarce resource and using 16bit ExID for this TCP extension could harm other, future TCP extensions

* There is currently one well-known implementation in a major TCP stack that complies to the IETF process by using RFC 6994, but further adoption in other stacks is possible

* As a summary, to the TCPM community exceptional allocation of a codepoint to this non-STD-track TCPM document seems to be a reasonable trade-off

My understanding is that the TCPM chairs would have to provide this reasoning to the IESG and IANA, similar to http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01706.html . It is then up to the IESG to decide whether to approve this.

Please let me know if I missed something or if you have any comments.

Thanks

Michael (document shepherd)

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 13 Nov 2013 09:11:12 -0800

On Wed, Nov 13, 2013 at 8:59 AM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> * Gorry Fairhurst: Several remarks and questions, already some list
> discussion ==> Gorry will have to review follow-up version, possibly
> iteration required
>
ack

> * Donald Smith: Comment on Section 4.1.2, not discussed on list so far ==>
Sorry I forgot to reply his email b/c I was distracted by the other
(longer) discussions of code point in the same thread. I will reply soon.

>
> * Joe Touch: Objection to dedicated option codepoint, discussed on list
> and in meeting, including a consensus call with strong support for a
> dedicated codepoint ==> See below
>
ack

> * Fast open is a useful TCP experiment for relevant applications, and it
> has the potential for wider experimentation and deployment
>
> * There is no significant shortage of IANA-assigned TCP option codepoints
> for users following the IETF process: Out of 256 codepoints, IANA has only
> 14 codepoints assigned to an non-obsoleted RFC, 6 other registrations
> (probably legacy with unknown deployment state), 9 obsoleted codepoints
> (available for re-use?), and of the order of 10-15 known unauthorized uses
>
> * In contrast, option space in the TCP SYN is an extremely scarce resource
> and using 16bit ExID for this TCP extension could harm other, future TCP
> extensions
>
> * There is currently one well-known implementation in a major TCP stack
> that complies to the IETF process by using RFC 6994, but further adoption
> in other stacks is possible
>
> * As a summary, to the TCPM community exceptional allocation of a
> codepoint to this non-STD-track TCPM document seems to be a reasonable
> trade-off
>
> My understanding is that the TCPM chairs would have to provide this
> reasoning to the IESG and IANA, similar to
> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01706.html .
> It is then up to the IESG to decide whether to approve this.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>