Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01

[Joe Touch <[e-mail]>]

On 12/18/2013 2:29 AM, Per Hurtig wrote:
> (i) Should we have a section in the draft describing a socket option?
>
> This was suggested during the tcpm meeting, but we also got comments in the
> hallway that maybe this was not needed. Controlling RTO restart on a per socket
> basis may be useful, but it is partly an implementation decision. Our current
> Linux patch has both a sysctl and a socket option to aid in experimentation.
> Looking at other RFCs the SCTP RFCs are quite careful to define socket options
> whereas the TCP RFCs often leave it out. We don't have any strong opinions
> regarding this. We are more than happy to add an API section if the working
> group wants one, but we are not sure that it is necessary.

IMO, you should definitely indicate whether this variant should be 
default, whether it should apply to all connections, and whether it 
should be configurable to apply to specific connections.

That is, IMO, required as part of the API of this protocol - and yes, as 
with RFC 793, I think such APIs are mandatory for all protocols (despite 
IETF confusion on this point, esp. in the past).

However, describing it as a "socket option" or specifying the Unix-style 
interface should be at best in an appendix as one example, but I would 
prefer to not include that level of detail at all.

I definitely feel strongly that RFC2119 keywords should never be used to 
describe such APIs in the context of a specific OS.

Joe