[tcpm] Adopting draft-zimmermann-tcpm-undeployed?

[Pasi Sarolahti <[e-mail]>]

(Note: this is response to Alex’ mail, but I changed the topic, because there is an important question below)

On 21 Oct 2014, at 14:47, Zimmermann, Alexander <[e-mail]> wrote:

>> So why is it no longer recommended? The IESG statement also calls for explanation for the transition.
> 
> See for example this thread: http://www.ietf.org/mail-archive/web/ietf/current/msg81410.html
> (or http://marc.info/?t=137611379100002&r=1&w=2)
> 
> 	Wes: „There are probably security issues“
> 	Joe: „There are semantics issues to; see draft-touch-tcp-portnames-00 for information“
> 	Bob Braden: „Indeed, TCPMUX is quite historic… it represents a Road Not Taken“
> 
> Another source is: draft-touch-tcpm-sno-02.txt
> 
> If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine by me.
> I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community)
> opinion. 

Great, this is basically what I was looking for. So why not shortly summarize the security and semantics issues in the draft, to make things clear?

> Personally, I do not want to submit the draft as an individual draft. Basically due to the fact
> that today nobody knows how we can obsolete an RFC which comes out of the independent track.
> Could we start a call of adoption on the draft? The stuff we discuss right now are quite minor
> and easy to fix. I do not see a showstopper here

Yes, I think we should be able to take this through tcpm fairly quickly, but according to the normal procedure. So the plan would be that unless anyone objects within next couple of weeks, we will adopt this as TCPM document, and will start a WGLC soon after. (This is not to discourage further comments, so please take a look and send comments as usual — although currently there is not much text to comment on… :-)

We don’t need presentation slot in the next meeting, unless you want to, but let’s shortly check the status in the early part of the meeting (no slides required).

So, any opinions for or against adopting this draft as outlined above?

>>> The specification (RFC 6013) is not getting any better if we wait longer.
>>> There is no implementation in the wild available, it doesn’t follow RFC 6994 ,…
>> 
>> Right, it shouldn’t be hard to argue why the transition needs to be made. (but I still think it would help further evaluation steps if short reasoning was provided here)
> 
> Be concrete :-) What do you have in mind?

As you say, RFC 6994 specifies how experimental options should be used, so it supersedes the usage in RFC 6013. We also have ongoing work on extending option space that will likely differ from what RFC 6013 has (but we are not quite there yet). The extension mechanism probably also has issues with middleboxes, as recently discussed. (roadmap says that there is no wide deployment, but RFC 6013 is Experimental, so I don’t think wide deployment is even expected. Although probably there is no ongoing experiment either.)

- Pasi