Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

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
>