Subject: Re: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call.

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 3 Nov 2010 20:59:44 -0500

Replying to this as an individual (not WG co-chair), my feeling about this "Programming Considerations" section is that if it stays in, it at least needs more introduction to explain that this socket API extension is only needed in the case where you want to make the TCP implementation (i.e. in the kernel) capable of taking this action on its own and allow it to reap sockets on behalf of the application.  It should be clearly noted that other protection can be implemented in the application as an alternative and that socket support described here is not mandatory.

I wasn't quite comfortable with the way that section 5 ("Conclusion") points to this as the implementation guidelines, rather than a potential implementation.

As WG co-chair, I hope more people can share their views on this, so we can see consensus and wrap this draft up in the near term.  Especially if people plan to implement (or have already implemented) the API extension described here, it would be good to know (or if people explicitly don't plan to implement it).

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Anantha Ramaiah (ananth) [[email-masked]]
Sent: Saturday, October 23, 2010 10:43 PM
To: [email-masked]
Subject: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call.

Hi,

  Following is the summary (from the authors perspective) as to where we
stand w.r.t this draft. We believe, this short and harmless draft is
ready for the last call.

 During the last review of the persist draft, some folks were not happy
about the API section (section 7) of the document.  The authors
discussed this concern among themselves and also have received some
other reviews (both internal and external) and are kind of confused as
to why the presence of an API guideline (for illustration purpose
mainly) should be of any concern. Following reasons as to why we think
why some illustration (like API) would be nicer to have :-

- This is an informational draft. The purpose of the API section is to
illustrate what how an application can do something about connections
which are stuck in persist state. The objective is NOT to recommend any
sockets API syntax or format (again we are not standardizing anything),
it is purely there to illustrate the essence of the draft.

- There was some talk about SO_LINGER API etc.,. I think we have
clarified earlier that SO_LINGER comes into play only when the
application tries to close the socket. SO_LINGER with 0 value is like
causing an abort of the TCP connection. Here we acknowledge that there
is a way (possibly more ways) that exists which can be used to abort the
TCP connection. This is orthogonal to the current API discussion which
we are having which simply illustrates how an application can abort the
TCP connection without violating any RFC (793 or 1122)

In a nutshell, we don't see any reason why mentioning an API example is
violation of the RFC. We believe adding an API example would not deter
that simplicity in any way, but that is just our take.

Maybe there is some scope to rewrite that section if folks think
otherwise.

We would like to move forward on getting closure on this aspect as this
seems to be the last hurdle in getting this draft to the last call
process.

Sorry about the delay in getting back.

Thanks,
-Anantha
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm