Re: [tcpm] draft-ietf-tcpm-urgent-data-06

Joe Touch <touch@isi.edu> Tue, 19 October 2010 22:21 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3581C3A6914 for <tcpm@core3.amsl.com>; Tue, 19 Oct 2010 15:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level:
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l72kQXqRBLJ0 for <tcpm@core3.amsl.com>; Tue, 19 Oct 2010 15:21:01 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id F08043A6868 for <tcpm@ietf.org>; Tue, 19 Oct 2010 15:21:00 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o9JMMJII004761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 19 Oct 2010 15:22:19 -0700 (PDT)
Message-ID: <4CBE1A1B.6040306@isi.edu>
Date: Tue, 19 Oct 2010 15:22:19 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <FCF0200B-A1AF-4902-A110-D7EC08C39FEC@nokia.com> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <C304DB494AC0C04C87C6A6E2FF5603DB481FB1C732@NDJSSCC01.ndc.nasa.gov> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> <4CBE1853.9020502@piuha.net>
In-Reply-To: <4CBE1853.9020502@piuha.net>
Content-Type: multipart/mixed; boundary="------------040206020807040400090603"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2010 22:21:03 -0000

Hmm. That was the issue that the discuss I thought that Ron was holding 
was focused on (see attached)

Ron?

Joe

On 10/19/2010 3:14 PM, Jari Arkko wrote:
> Joe, I think I agree with you. I was not planning on holding on to a
> Discuss for that part, however.
>
> Jari
>
> Joe Touch kirjoitti:
>>
>>
>> On 10/15/2010 3:00 PM, Jari Arkko wrote:
>>> Joe,
>>>
>>> Just a quick response on one point:
>>>
>>>> - based on the note from Jari, I can't tell whether the
>>>> doc is recommending SHOULD NOT for new apps or not
>>>
>>> My text did not change that aspect in any way. The new text is in the
>>> introduction and has no keywords. The formal requirement is later in the
>>> document. IIRC the current text there says SHOULD NOT for new apps.
>>
>> Correct. In that case, the note was not responsive to the thread I
>> raised discussing the point that this is a new and substantial change,
>> one that I feel suggests that the title, abstract, and overall
>> structure should be inverted to focus on SHOULD NOT as the key point.
>>
>> It's hard to understand a doc that basically focuses on a change to
>> the spec, and includes the SHOULD NOT almost parenthetically.
>>
>> Joe
>>
--- Begin Message ---
Joe,

I think that you have hit the nail on the head. Reading through Sections 1-5, I thought that we were trying to fix the feature. Only in Section 6 did I realize that we really wanted to drive a stake through its heart.

Maybe if we changed the title and added some test to the abstract and introduction, this would be better. Otherwise, people may spend time and money fixing the TCP Urgent option instead of just avoiding it.

                                                         

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Thursday, September 23, 2010 10:18 PM
> To: John Heffner
> Cc: Ronald Bonica; tcpm@ietf.org
> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
> 
> 
> 
> On 9/23/2010 6:00 PM, John Heffner wrote:
> > My understanding is that deprecating urgent data is exactly what this
> > document is doing.  In section 5: "... new applications SHOULD NOT
> > employ the TCP urgent mechanism."  The rest of the document is
> largely
> > a justification for deprecating the mechanism.
> 
> And a clarification as to what byte the urgent data actually starts at.
> The spec doesn't match any of the implementations, and since there's no
> benefit to either variant, the WG decided to change the spec to match
> the extant implementations. See section 4.
> 
> This is NOT an enhancement, and is NOT intended to make future apps
> more
> likely to use the urgent mechanism. See section 6, which deprecates the
> feature.
> 
> Is there a question that, e.g., the title be updated to reflect the
> primary intent, i.e.,"Deprecating TCP's Urgent Mechanism", with a few
> other related changes (e.g., update the abstract/intro, move section 6
> forward, and then explain that the remainder of the doc is to document
> how existing apps work?)?
> 
> I could see how the current doc reads more like "we're updating the
> spec
> first. oh yeah, and don't use this", which seems inverted; the WG
> conclusion was more like "deprecate this. and oh yeah, here's how it
> really works in the few apps that we know of that actually use it"
> 
> Joe
> 
> >
> >    -John
> >
> >
> > On Thu, Sep 23, 2010 at 5:10 PM, Ronald Bonica<rbonica@juniper.net>
> wrote:
> >> Folks,
> >>
> >> The purpose of this email is to encourage the TCPM working group to
> deprecate the feature described in draft-ietf-tcpm-urgent-data-06.
> >>
> >> I understand the following statements to be true:
> >>
> >> - The WG discourages new applications from using the feature.
> >> - Many middle-boxes defeat the feature by removing the urgent data
> indicator. Therefore, when an application indicates that data is
> urgent, it is never sure that that indication will reach the remote
> TCP.
> >> - Only three applications have been identified as using the feature.
> These are a proprietary application, telnet and ftp. More elegant
> mechanisms are available to Telnet and FTP.
> >> - The feature is rarely implemented as specified.
> >>
> >> Finally, there are more elegant ways to bring urgent data to
> applications.
> >>
> >> IMHO, this feature should be deprecated, not enhanced. Let's not
> pass up this opportunity to simplify the TCP stack.
> >>
> >>                                                            Ron
> >>
> >> _______________________________________________
> >> 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
--- End Message ---