Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
Joe Touch <touch@isi.edu> Fri, 31 May 2013 00:49 UTC
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8850321F9922 for <tcpm@ietfa.amsl.com>; Thu, 30 May 2013 17:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.191
X-Spam-Level:
X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmVEWKum6zBP for <tcpm@ietfa.amsl.com>; Thu, 30 May 2013 17:49:32 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D593721F8C40 for <tcpm@ietf.org>; Thu, 30 May 2013 17:49:32 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r4V0nIAr020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 May 2013 17:49:18 -0700 (PDT)
Message-ID: <51A7F38D.1020509@isi.edu>
Date: Thu, 30 May 2013 17:49:17 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: l.wood@surrey.ac.uk
References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <CAK6E8=d_LTZgnGAncdWDAi+7ebd3Lo5aevPeGG0=KSbBMeBhcg@mail.gmail.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <E220F4B0-EE27-431C-BCBE-0A0C01C8B0EF@iki.fi> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <B3F294F6-8866-4155-98F6-0927B90346E4@iki.fi> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <DDB1E5C2-F806-45CF-80F8-AC3774523A5C@iki.fi>, <51A7855D.7020606@isi.edu> <290E20B455C66743BE178C5C84F12408223F494E97@EXMB01CMS.surrey.ac.uk>
In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494E97@EXMB01CMS.surrey.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 31 May 2013 00:49:37 -0000
On 5/30/2013 5:36 PM, l.wood@surrey.ac.uk wrote: >> REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't >> be treated the same way, but MUST is fine too. > > If the present tense is permitted, then the past tense (WAS REQUIRED) is also allowed. REQUIRED is an adjective, describing a state: Y is REQUIRED X REQUIRES Y is the present tense verb phrase equivalent of: Y is REQUIRED by X If you prefer to use only 2119 language, use the "Y is REQUIRED by X" variant. "was REQUIRED" means past tense, and doesn't thus describe a current constraint. I don't think that makes much 2119 sense. Joe > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] > Sent: 30 May 2013 17:59 > To: Pasi Sarolahti > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt > > Hi, all, > > On 5/30/2013 1:36 AM, Pasi Sarolahti wrote: >> On May 29, 2013, at 11:07 PM, Joe Touch <touch@ISI.EDU> wrote: > ... >> Nit: start of section 4.3 uses "REQUIRES" that should not be >> capitalized because it is not a RFC 2119 keyword. How about just saying >> something like "if PAWS algorithm is enabled, the following steps MUST >> be followed", or something. Sorry about splitting hairs, but I think we >> should be pedantic about the keywords. > > REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't > be treated the same way, but MUST is fine too. > >>>> " * If the Timestamps option is removed from the <SYN> or <SYN,ACK> >>>> segment, high speed connections that need PAWS would not have >>>> that protection. Successful negotiation of Timestamps option >>>> enforces a stricter verification of incoming segments at receiver. If >>>> the Timestamps option was removed from a subsequent data segment >>>> after a successful negotiation (for example, as part of >>>> re-segmentation), the segment is discarded by the receiver without >>>> further processing. Middleboxes should not remove the Timestamps >>>> option. One study found that 6% of measured HTTP connections had the >>>> Timestamps option removed from data segments [Honda11]." >>> >>> The last sentence seems out of place; why are you including that? >>> Ifthere are implications to the 6% drop then you should mention that, but >>> I would expect that elsewhere than the security considerations section. >> >> Because that paragraph talks about removal of timestamps option. But >> I agree that the proposed sentence doesn't sit there very well. How >> about including the reference in the beginning of the Middleboxes >> section of the text: >> >> "Some middleboxes have been known to remove the TCP options >> described in this document from the TCP segments [Honda11]." (changed <SYN> segment to TCP segments) > > Yup - that's better, IMO. > >> The main point is that the current text only talks about dropping >> options from SYN segments, but this happens also for data segments, as >> the paper shows. Since we have fairly recent quantified data about this, >> why not include the reference? > > That's fine, it was the placement issue. > > However, if your point is that they remove options from data segments > then you might point that out explicitly in the revised text. > > Question - is there a reason a midbox would let the option through on a > SYN and block it on the data segments? Or are you worried about path > changes whose data segments go through midboxes that the SYN didn't? > Again, if that's the case, then you might explain that in the text above > in the midbox section (1-2 sentences). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt internet-drafts
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Yuchung Cheng
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Yuchung Cheng
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Olivier Bonaventure
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Yuchung Cheng
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Christoph Paasch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… l.wood
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Fernando Gont
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Tim Shepard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Scheffenegger, Richard
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Andre Oppermann
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Yuchung Cheng
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Jakob Heitz
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Pasi Sarolahti
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch
- Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13… Joe Touch