Re: [tcpm] poll for adoption of draft-ananth-persist-02

Ok, I misunderstood the reference, my mistake.

This email discussion is for the adoption, and we are making a case for it purely based on the recommendation of 1122, and the consequent behavior of the widely deployed implementations out there under these conditions (wait indefinitely).
Given this data, it beats me as to where the disagreement about adoption can be.

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Monday, March 22, 2010 11:58 PM
To: Murali Bashyam
Cc: John Heffner; Mahesh Jethanandani; tcpm@ietf.org
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

First, John is talking about Section 7 of your doc.

Second, there are a few parts of the doc that do need to be discussed, notably anything that goes beyond "and it's always been the case that a TCP connection can be terminated by the OS". In particular, Section 7 defines an API that is beyond the scope of this recommendation, IMO.

But that's separate from taking this doc on. Let's finish that decision first, right?

Joe

Murali Bashyam wrote:
> There is no Section 7 in RFC 1122. 
> 
> Section 4.2.2.17 states that "As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open." This is the guideline that implementations have followed.
> 
> 
> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf 
> Of John Heffner
> Sent: Monday, March 22, 2010 7:15 PM
> To: Mahesh Jethanandani
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
> 
> On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani <mahesh@cisco.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John,
>>
>> On 3/22/2010 2:41 PM, John Heffner wrote:
>>> I read the new version of this draft.  For the record, my opinion 
>>> hasn't changed since the -00 version, which is that publication of 
>>> this draft as an RFC would be harmful.  I don't object to the simple 
>>> clarifying statement that a connection may be aborted while in the 
>>> persist state.  (I'm not sure this requires a new RFC.)  However, 
>>> this draft goes beyond that, implying that connections should be 
>>> aborted
>>> *because* they are in persist state.
>> Where in the draft do we imply that "connections should be aborted
>> *because* they are in persist state"? We are not implying that 
>> connections SHOULD be aborted because they are in persist state. 
>> Instead we are suggesting that connections should be *allowed* to be 
>> aborted in persist state. Currently RFC 1122 language is ambiguous in 
>> this regard when connections go into indefinite wait in ZWP condition.
> 
> I'm pretty sure Section 7 describes automatically aborting connections 
> because they are in the persist state for some period of time.
> 
>   -John
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm