Re: [tcpm] draft-zimmermann-tcpm-undeployed

["Zimmermann, Alexander" <[e-mail]>]

> Am 21.10.2014 um 13:09 schrieb Pasi Sarolahti <[e-mail]>:
> 
> 
> On 21 Oct 2014, at 12:57, Zimmermann, Alexander <[e-mail]> wrote:
> 
>> 
>>> Am 20.10.2014 um 13:38 schrieb Pasi Sarolahti <[e-mail]>:
>>> 
>>> On 20 Oct 2014, at 13:09, Zimmermann, Alexander <[e-mail]> wrote:
>>> 
>>>> at the IETF 90 we got some feedback from Yoshifumi and Gorry no the draft (see minutes). We incorporated those feedback in version 01. From our point of view the draft is ready. I would like to know how we proceed w/ the draft? I don’t think that we need to discuss the draft again in Honolulu.
>>> 
>>> Just wanted to check one thing: isn’t TCPMUX supported by [x]inetd implementations? It’s probably not much used, but there seem to be deployed implementations, so perhaps it isn't correct to call it obsolete? Any opinions?
>> 
>> Making something as obsolete != not deployed in implementation
> 
> Yep. But the title is „Moving Undeployed TCP Extensions to Historic…” :-)

OK, we should fix that :-)

> 
>> * A document is labelled Historic when what it describes is no longer considered current:
>> no longer recommended for use.“
>> 
>> The latter point is exactly what we would like to express: no longer recommended for use
> 
> 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. 

> rfc4614bis explains the case for the other documents pretty well, but the reasons for obsoleting TCPMUX are not given there. (it might not harm if the important explaining sentences from rfc4641bis would be shortly repeated also here for each document)

I can do that. NP.

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

> 
>>> Also, RFC 6013 strikes as quite recent for a “Historic” document, although I fully agree with its description in the roadmap.
>> 
>> 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?

Alex
 

> 
> - Pasi
>