Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-base-08

David Ward <dward@cisco.com> Wed, 07 May 2008 18:34 UTC

Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975EA28C690; Wed, 7 May 2008 11:34:03 -0700 (PDT)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2357028C690; Wed, 7 May 2008 11:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 SYyOiLPA2dfX; Wed, 7 May 2008 11:33:57 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 133AD28C6E6; Wed, 7 May 2008 11:33:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,450,1204520400"; d="scan'208";a="7598223"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2008 14:33:52 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m47IXqfQ000944; Wed, 7 May 2008 14:33:52 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m47IXqPT024307; Wed, 7 May 2008 18:33:52 GMT
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 14:33:52 -0400
Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 14:33:52 -0400
In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF0303CD50@eusrcmw721.eamcs.ericsson.se>
References: <02f901c8ac06$7650d7d0$ce7da40c@china.huawei.com> <9FBD0156-77A6-4156-AB2F-1E5E13D69A86@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF0303CD50@eusrcmw721.eamcs.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <BC317E35-DB12-458E-8BEA-454931A3DC72@cisco.com>
From: David Ward <dward@cisco.com>
Date: Wed, 07 May 2008 13:33:48 -0500
To: Eric Gray <eric.gray@ericsson.com>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 07 May 2008 18:33:52.0188 (UTC) FILETIME=[E60397C0:01C8B070]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4617; t=1210185232; x=1211049232; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20<dward@cisco.com> |Subject:=20Re=3A=20[Gen-art]=20Gen-ART=20Review=20of=20dra ft-ietf-bfd-base-08 |Sender:=20 |To:=20=22Eric=20Gray=22=20<eric.gray@ericsson.com>; bh=K5nmLIRtRp+9tKxHAsQzSQbkQcMdU7mWVE+Zm+dkGFs=; b=ZrV+uJ1LL4XDkRodfSHNvhK5rfQfJOXXf3TLPuhRQ0Nfgy4m55JS2BI0Tj uVE1+Bmy0I9fnd5BsdXnI2AQycGRMHmXM94pM+MxOo7PCKJTIiEbUy0VlniJ QH4NQobPHq;
Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: ietf@ietf.org, General Area Review Team <gen-art@ietf.org>, dkatz@juniper.net, Ross Callon <rcallon@juniper.net>, David Ward <dward@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-base-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org

Eric -


On May 7, 2008, at 1:26 PM, Eric Gray wrote:

> David,
>
> 	I agree with Spencer on the point of "system thoughts"
> verses "system states."  This may appear to be a style issue,
> but it is actually simply a matter of trying to be as precise
> as the language allows.  Who knows what a system "thinks"?
> But it should be clear if a system is in an appropriate state.
>

DW: Sorry, which comment is this in reference to?


> 	On the next issue, I don't understand your argument: are
> you saying that you believe it is necessary to explicitly say
> that "defending against operator error is out of scope"?
>

DW: Given we are talking about laws of physics and we have seen  
implementation and deployment issues, it seemed worthy of not  
removing the statement in this instance.


> 	Finally, Spencer's (last?) comment on use of "stronger"
> is (again) not a stylistic one, but an attempt to squeeze the
> little bit of precision that can be achieved in English.  It
> is apparent that you believe you are saying "Using SHA1 is
> believed to have stronger security properties than MD5" (as
> indeed is suggested by Spencer), but you are not (exactly).
> Change the statement to "drinking milk, as opposed to chewing
> rocks, leads to stonger bones" and you will see that what you
> have said makes no explicit comparison between SHA1 and MD5
> (or milk and rocks, in my example).  Because the statement is
> already in passive voice (whose belief is this?), and is vague
> enough as it is, then we should try to fix as much of it as we
> can.
>

DW: Finessing this sentence isn't an issue. Rocks for breakfast?

-DWard


> --
> Eric Gray
> Principal Engineer
> Ericsson
>
>> -----Original Message-----
>   --- [SNIP] ---
>>
>>>   packet to the correct BFD session after it is looped back to the
>>>   sender.  The contents are otherwise outside the scope of this
>>>   specification.
>>>
>>> 6.6. Demand Mode
>>>
>>>   Demand mode is requested independently in each direction by virtue
> of
>>>   a system setting the Demand (D) bit in its BFD Control packets.
> The
>>>   Demand bit can only be set if both systems think the session is
> up.
>>>
>>> Spencer (clarity): this doesn't seem quite right to me, because the
>
>>> statement requires that my system knows what the other system
>>> thinks. Is it correct to say "a system can only set the Demand bit
>>> when a session has transitioned to UP"? It might be preferable to
>>> delete the second sentence, because the following text explains
>>> this in greater detail, anyway.
>>>
>>
>> DW: This appears to be a style comment on "is up" vs "has
>> transitioned to UP," right?
>>
>>
>>>   The system receiving the Demand bit ceases the periodic
> transmission
>>>   of BFD Control packets.  If both systems are operating in Demand
>>>   mode, no periodic BFD Control packets will flow in either
> direction.
>>>
>>>   Note that this mechanism requires that the Detection Time
> negotiated
>>>   is greater than the round trip time between the two systems, or
> the
>>>   Poll mechanism will always fail.  Enforcement of this requirement
> is
>>>   outside the scope of this specification.
>>>
>>> Spencer (clarity): you're not describing a requirement, you're
>>> describing a constraint. Perhaps "Note that this mechanism will
>>> always fail unless the Detection Time negotiated is greater than
>>> the round trip time between the two systems", and drop the second
>>> sentence?
>>>
>>
>> DW: What we are trying to state is that BFD cannot keep an operator
>> from making a configuration error. There is a constraint due to
>> physics and a requirement that it be adhered to and ... BFD can't
>> stop anyone from doing something stupid. "Enforcing the requirement
>> to meet the constraint ..." may be clearer language although a nit.
>>
>   --- [SNIP] ---
>
>>>   transmission rate and/or the Detection Time).
>>>
>>> Security Considerations
>>>
>>>   Using SHA1 rather than MD5 is believed to have stronger security
>>>   properties.  All comments about MD5 in this section also apply to
>>>
>>> Spencer (clarity): "stronger than"? would this be correct if it
>>> said "Using SHA1 is believed to have stronger security properties
>>> than MD5"?
>>>
>>>   SHA1.
>>>
>>
>>
>> DW: This seems a style choice.
>>
>>
>> Many thanks for your thorough review.
>>
>> -DWard
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art