Gen-ART LC review of draft-ietf-pce-path-key-03

[Ben Campbell <ben at estacado.net>]

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-pce-path-key-03
Reviewer: Ben Campbell
Review Date:  2008-10-13
IETF LC End Date: 2008-10-22


Summary:

This draft is almost ready for publication as a proposed standard. I  
have a few nits and editorial comments that should be considered first.

Comments:

Section 2.1, paragraph 3:

The last sentence is confusing. "...until the LSR that can process  
it." does not seem to describe an event that one can wait "until".  
Should it say "...until it reaches the LSR..."?

Section 2.2, paragraph 1:

 s/ingress/"ingress LSR"

Sections 3.1.1 and 3.1.2

No explicit definitions for "Path Key" in either section. If the  
intent is for the language in section 3.1 to serve as the definition  
in each of these subsections, it would be good to have something like  
"Path Key: See section 3.1".  (Although just reprinting it here would  
allow each of the formal subobject definitions to stand alone a little  
better.)

Section 4:

The section covers actions in failure cases, i.e. if the PCE does not  
recognize itself, or if the requesting LSR receives a negative reply.  
The actions taken in the success case may seem to obvious to state,  
but it would be good to state them explicitly anyway :-)

Section 5, third bullet point in first list:

Do you mean "DoS attacks" rather than "DNS attacks"?

Section 6.1, paragraphs 2 and 3:

Can you either restate the suggested default, or reference the  
section? Otherwise, this requires a bit of an easter egg hunt on the  
part of the reader.

6.2, paragraph 1:

If I read this right, you state a normativFrom ietf-bounces at ietf.org  Mon Oct 13 14:41:40 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-web-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A29913A69E2;
	Mon, 13 Oct 2008 14:41:40 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0EA1B3A69E2;
	Mon, 13 Oct 2008 14:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
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 RBUJ305t9sX5; Mon, 13 Oct 2008 14:41:39 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net
	[IPv6:2001:470:1f03:266::2])
	by core3.amsl.com (Postfix) with ESMTP id 9AEE23A68B6;
	Mon, 13 Oct 2008 14:41:38 -0700 (PDT)
Received: from dn3-228.estacado.net (dn3-228.estacado.net [172.16.3.228])
	(authenticated bits=0)
	by estacado.net (8.14.2/8.14.1) with ESMTP id m9DLgLwI060823
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 13 Oct 2008 16:42:22 -0500 (CDT)
	(envelope-from ben at estacado.net)
Message-Id: <BDBDE566-8D82-4A71-B70A-3549B35C2938 at estacado.net>
From: Ben Campbell <ben at estacado.net>
To: General Area Review Team <gen-art at ietf.org>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Gen-ART LC review of draft-ietf-pce-path-key-03
Date: Mon, 13 Oct 2008 16:42:21 -0500
X-Mailer: Apple Mail (2.929.2)
Cc: rcallon at juniper.net, adrian at olddog.co.uk, rbradfor at cisco.com,
	JP Vasseur <jpv at cisco.com>, ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-pce-path-key-03
Reviewer: Ben Campbell
Review Date:  2008-10-13
IETF LC End Date: 2008-10-22


Summary:

This draft is almost ready for publication as a proposed standard. I  
have a few nits and editorial comments that should be considered first.

Comments:

Section 2.1, paragraph 3:

The last sentence is confusing. "...until the LSR that can process  
it." does not seem to describe an event that one can wait "until".  
Should it say "...until it reaches the LSR..."?

Section 2.2, paragraph 1:

 s/ingress/"ingress LSR"

Sections 3.1.1 and 3.1.2

No explicit definitions for "Path Key" in either section. If the  
intent is for the language in section 3.1 to serve as the definition  
in each of these subsections, it would be good to have something like  
"Path Key: See section 3.1".  (Although just reprinting it here would  
allow each of the formal subobject definitions to stand alone a little  
better.)

Section 4:

The section covers actions in failure cases, i.e. if the PCE does not  
recognize itself, or if the requesting LSR receives a negative reply.  
The actions taken in the success case may seem to obvious to state,  
but it would be good to state them explicitly anyway :-)

Section 5, third bullet point in first list:

Do you mean "DoS attacks" rather than "DNS attacks"?

Section 6.1, paragraphs 2 and 3:

Can you either restate the suggested default, or reference the  
section? Otherwise, this requires a bit of an easter egg hunt on the  
part of the reader.

6.2, paragraph 1:

If I read this right, you state a normative requirement that another  
draft be updated. That seems an odd use of normative language. In any  
case, am I correct in assuming that someone is ensuring that this  
update happens?

References:


Outdated reference: draft-ietf-ccamp-inter-domain-recovery-analysis  
has been published as RFC 5298.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


e requirement that another  
draft be updated. That seems an odd use of normative language. In any  
case, am I correct in assuming that someone is ensuring that this  
update happens?

References:


Outdated reference: draft-ietf-ccamp-inter-domain-recovery-analysis  
has been published as RFC 5298.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf