Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00

Fernando Gont <fernando@gont.com.ar> Sat, 08 November 2008 23:00 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC043A681A; Sat, 8 Nov 2008 15:00:37 -0800 (PST)
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 C9C183A6407 for <tcpm@core3.amsl.com>; Sat, 8 Nov 2008 15:00:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.126
X-Spam-Level:
X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808]
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 SHfTIz0L3Rr6 for <tcpm@core3.amsl.com>; Sat, 8 Nov 2008 15:00:35 -0800 (PST)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 908B53A63D2 for <tcpm@ietf.org>; Sat, 8 Nov 2008 15:00:33 -0800 (PST)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F1D776B6559; Sat, 8 Nov 2008 20:00:33 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA8N0FPj001169; Sat, 8 Nov 2008 21:00:16 -0200
Message-Id: <200811082300.mA8N0FPj001169@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 08 Nov 2008 19:54:31 -0300
To: Joe Touch <touch@ISI.EDU>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <4915D19A.4070404@isi.edu>
References: <200810280000.m9S00h4E029878@venus.xmundo.net> <A56C813C-B46D-4A02-A905-DD6B7E163156@windriver.com> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 08 Nov 2008 20:00:32 -0300 (ART)
Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman <david.borman@windriver.com>, ayourtch@cisco.com
Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
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: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 02:51 p.m. 08/11/2008, Joe Touch wrote:

> > Again: Do you really expect anybody to change their stacks so that they
> > become RFC1122-compliant in this respect???
>
>I expect that, even if the IETF had a compliance process, the specs are
>always out of sync with what is deployed, and represent what
>implementations should try to achieve.

I understand what you mean, but I believe that there's a difference 
between simply being out of sync (i.e., the specs simply being ahead 
of time), and the specs specifying stuff that the implementations 
will never even try to implement.



> >> If you want merely to document "what is", that's a fine description for
> >> a man page, but it doesn't provide utility in a standards body.
> >
> > Well, I guess that depends whether you want the specs to be useful for
> > implementers, or not. I just hope that some of the kernel hackers that
> > send comments off-list post something in this respect on-list.
>
>Implementers should design protocols to specs; they should design
>applications to specs together with man pages and errata that discuss
>where the two diverge.

Man pages? We are talking about what is sent on the wire. We're 
talking about the semantics of the urgent pointer. Why should, e.g. a 
UNIX man page state whether the urgent pointer points to the last 
byte of urgent data vs. the byte following the last byte of urgent data??



>IMO, the specs cannot constantly be downgraded to represent what is
>implemented solely for that reason; downgrading can - and should - occur
>if we, as a community, decide to change what we *want* the protocol to do.

Joe, why do you imply that simply updating RFC1122 such that it 
states that the UP points to "the byte following the last byte of 
urgent data" is a downgrade? Could you please elaborate a little bit 
on why you think it would be a downgrade?

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm