[tcpinc] Call for adoption of draft-rescorla-tcpinc-tls-option-05

[Mirja Kühlewind <[e-mail]>]

Hi all,

please indicate if you support adoption of
draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item, or not, by

	Monday, Nov 2, 2015.

draft-rescorla-tcpinc-tls-option is one candidate for tcpinc where the first 
version of this draft was proposed more than a year ago. Verison -04 was 
release about three weeks ago and specifies the TLS 1.3 profile as well as 
the use of draft-rescorla-tcpinc-tls-option with tcp-eno. Since then this 
draft received a lot of discussion. The lasted update was provided yesterday, 
but only changes a few minor fixes.

Similar as before, if you do not support adoption of this document because 
you think it is not in scope for the wg or has fundamental technicals flaws 
and would therefore harm the goals of the wg, it would be great if you could 
given some reasoning/explanation with your response.

This is solely an adoption call for draft-rescorla-tcpinc-tls-option 
independent of any other documents. If you have a personal preference for a 
different approach that should not be a reason to reject this adoption. 
Forcing the wg to make a decision has not worked previously, and even though 
both proposed approaches have evolved, I do not see any indication that the 
wg is now ready to make a decision. The goal of this adoption call is to 
figure out if there is enough interest and energy to further follow the 
approach as outlined in draft-rescorla-tcpinc-tls-option-05.

This process may lead to the situation where the wg will adopt and work on 
two solution approaches. This does not mean that the wg will publish two 
(incompatible) approaches, as this would not fulfill our charter. If we end 
up adopting more than one approach, I currently see three way to proceed:

1) Both approaches (naturally) converge into one approach.

2) We work on both approaches to get them into a (similar) state where the wg 
is able to make a decision (and withdraw the other doc).

3) We publish both approaches as different 'versions' of tcpinc that can be 
negotiated in the tcp-eno handshake, where at least one of them is mandatory 
to support/implement.

Thanks!
Mirja