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
- [Gen-art] Gen-ART Review of draft-ietf-bfd-base-08 Spencer Dawkins
- Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-ba… David Ward
- Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-ba… Eric Gray
- Re: [Gen-art] Gen-ART Review of draft-ietf-bfd-ba… David Ward