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

David Borman <david.borman@windriver.com> Wed, 20 October 2010 02:17 UTC

Return-Path: <david.borman@windriver.com>
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 A9CAC3A697B for <tcpm@core3.amsl.com>; Tue, 19 Oct 2010 19:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.424
X-Spam-Level:
X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pACqJ3ijNVZg for <tcpm@core3.amsl.com>; Tue, 19 Oct 2010 19:17:23 -0700 (PDT)
Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B21F43A693E for <tcpm@ietf.org>; Tue, 19 Oct 2010 19:17:23 -0700 (PDT)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o9K2IoMt004360; Tue, 19 Oct 2010 19:18:51 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Oct 2010 19:18:50 -0700
Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Oct 2010 19:18:50 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: David Borman <david.borman@windriver.com>
In-Reply-To: <4CBE1739.6040203@isi.edu>
Date: Tue, 19 Oct 2010 21:18:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDC37D09-FD62-496B-BE62-919F94CD6515@windriver.com>
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>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1081)
X-OriginalArrivalTime: 20 Oct 2010 02:18:50.0736 (UTC) FILETIME=[228E6F00:01CB6FFD]
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, 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: Wed, 20 Oct 2010 02:17:24 -0000

On Oct 19, 2010, at 5:10 PM, Joe Touch wrote:

> 
> 
> 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.

We're not trying to deprecate the URGENT pointer.  The goal is to first align the spec with the implementations, and then point out issues with the URGENT pointer, which is how the doc is currently structured.  I don't want the "SHOULD NOT" to be the main point of this document, it is a secondary point due to the issues listed.  The SHOULD NOT applies to new applications, and it means "If you really want to make use of the URGENT pointer, make sure you understand and have addressed all the issues pointed out in this document."

The SHOULD NOT for application writers using the URGENT pointer, not for the URGENT pointer support in the TCP implementations.  I have no objections to the additional highlighting of this, but that doesn't make it the key point of the document.  I say leave the document as it is.

			-David Borman

> 
> Joe