Subject: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

From: David Borman <[email-masked]>
Date: Fri, 26 Sep 2008 14:37:52 -0500

At Dublin a presentation was made on draft-ananth-tcpm- 
persist-00.txt.  Not a lot of people had read the document at the time  
of the presentation, but there didn't seem to be any objections to  
adopting it as a TCPM WG document.

The authors posted a summary to the mailing list, have responded to  
all issues that were raised, and have a new version of the document  
ready for publication.  We (Wes and I) feel that there is support for  
adopting this as a WG document, but as always, we need to verify this  
on the mailing list.  So, if you have any objections to adopting this  
as a WG document, please speak up now.  Also speak up if you support  
adopting it as a WG document.

I'll be the first to say I support adopting this as a WG document.  If  
there are no serious objections, the authors can submit their updated  
version next week and Wes and I will add it to our list of WG documents.

			-David Borman, TCPM WG co-chair

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Sep 2008 15:32:24 -0700

Dave,

I'm not sure any of us disagreed with the content. The question is
whether it's important, useful, or necessary (in that order) to address
this, or whether we feel that the existing specs are sufficient.

My conclusion was that applications can always terminate TCP
connections, and so can OS's - e.g., an OS can always just reboot.

This still sounds like an implementation guideline to me. It may be
useful, and may be useful to document, but since it's implementation
focused, I'm not sure I see it as a protocol document.

As a result, I don't think this needs to be a WG document (which is
where I thought things were from Dublin). We talked there about it
potentially being an errata to 1122, and even the problems with that
approach.

Finally, it is not clear this is even in scope - it's not a modification
to TCP, nor is it maintenance.

Joe

David Borman wrote:
> At Dublin a presentation was made on draft-ananth-tcpm-persist-00.txt. 
> Not a lot of people had read the document at the time of the
> presentation, but there didn't seem to be any objections to adopting it
> as a TCPM WG document.
> 
> The authors posted a summary to the mailing list, have responded to all
> issues that were raised, and have a new version of the document ready
> for publication.  We (Wes and I) feel that there is support for adopting
> this as a WG document, but as always, we need to verify this on the
> mailing list.  So, if you have any objections to adopting this as a WG
> document, please speak up now.  Also speak up if you support adopting it
> as a WG document.
>

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 14:56:44 -0700

> adopting it as a TCPM WG document.

I guess I don't have a strong objection to it in that I believe it's
technically correct, but I'm not sure I see a driving need for it.  I
worry that we're taking work from more pressing tasks.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: David Borman <[email-masked]>
Date: Mon, 29 Sep 2008 17:44:51 -0500

(WG co-chair hat on)

Its intended status is informational, so it isn't a protocol  
document.  The purpose is clarification of what the standards already  
say. Clarification of confusion is part of maintenance, even if the  
clarification is not needed by everyone.

(WG co-chair hat off)

I was one of the people pointing out that the implementation is  
separate from the protocol, and that though the protocol says that TCP  
must not abort connections in persist state, in the implementation the  
other parts of the OS or the application can abort a TCP connection at  
any time, which includes connections in persist state.  If this  
document helps to make that clearer for some implementors, then that  
is a good thing.

		-David

On Sep 26, 2008, at 5:32 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dave,
>
>> persist-00.txt.
>> all
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjdYvgACgkQE5f5cImnZrsMrACfTV5Bl9beeAJ29JDszVT6sVhY
> XQAAoN8VPIAizeB1Z+IgkD/6iwT1h+HP
> =jSx6
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Sep 2008 16:16:48 -0700

David,

I agree overall with your observations; information seems reasonable,
but it also seems like clarification of existing standards is a TSVWG
issue, not a TCPM issue.

Joe

David Borman wrote:
> (WG co-chair hat on)
> 
> Its intended status is informational, so it isn't a protocol document. 
> The purpose is clarification of what the standards already say.
> Clarification of confusion is part of maintenance, even if the
> I was one of the people pointing out that the implementation is separate
> from the protocol, and that though the protocol says that TCP must not
> abort connections in persist state, in the implementation the other
> parts of the OS or the application can abort a TCP connection at any
> time, which includes connections in persist state.  If this document
> helps to make that clearer for some implementors, then that is a good
> thing.
> 
>         -David
>

---

From: Ted Faber <[email-masked]>
Date: Mon, 29 Sep 2008 17:27:42 -0700

> but it also seems like clarification of existing standards is a TSVWG

FWIW, I disagree.  TCPM exists to offload TCP actions from TSVWG,
including informational ones.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 29 Sep 2008 23:25:10 -0500

As an individual, not a co-chair, it's my hope that part of "TCP maintenance" would include clarifying questions that implementers are bringing when it's legitimately the case that the original specification can be viewed as unclear or missing some commentary.  Amazingly, there are still new TCP implementations being written in 2008, and likely into the future, so it may prove useful.
 
My personal feeling is that the content of this particular draft is so easy to agree on (nobody has objected to it, at least), that it should ideally be very quick and easy to make a few editorial passes on it and and call it done.  It would probably take less time than debating over whether it's absolutely undeniably necessary or what WG it belongs to :).  As for where the work should be done, if it is done, I agree with Ted that TCPM exists to offload work from the RSVP maintenance and minor extensions working group aka TSVWG.

---

From: "John Heffner" <[email-masked]>
Date: Mon, 29 Sep 2008 23:10:01 -0700

On Fri, Sep 26, 2008 at 12:37 PM, David Borman
<[email-masked]> wrote:
> At Dublin a presentation was made on draft-ananth-tcpm-persist-00.txt.  Not
> a lot of people had read the document at the time of the presentation, but
> there didn't seem to be any objections to adopting it as a TCPM WG document.
>
> issues that were raised, and have a new version of the document ready for
> publication.  We (Wes and I) feel that there is support for adopting this as
> a WG document, but as always, we need to verify this on the mailing list.
>  So, if you have any objections to adopting this as a WG document, please
> speak up now.  Also speak up if you support adopting it as a WG document.
>
> I'll be the first to say I support adopting this as a WG document.  If there
> are no serious objections, the authors can submit their updated version next
> week and Wes and I will add it to our list of WG documents.

I have reservations about moving forward with this draft as a wg
document.  While the information is technically correct, it is overly
specific to the point of possibly being misleading rather than
clarifying.  An operating system may terminate a tcp connection at any
time, not just when the connection is in the persist state.  Further,
I would actually argue that terminating a connection *because* it's in
the persist state is a bad idea and should be discouraged.  (The
reason for termination should be for its use of resources, not TCP's
state.)

  -John