[RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt
Leeyoung <leeyoung@huawei.com> Fri, 07 October 2011 21:23 UTC
Return-Path: <leeyoung@huawei.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8221F8BC4 for <rtg-dir@ietfa.amsl.com>; Fri, 7 Oct 2011 14:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level:
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 YSfDNiUgPvPb for <rtg-dir@ietfa.amsl.com>; Fri, 7 Oct 2011 14:23:45 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3221F8B85 for <rtg-dir@ietf.org>; Fri, 7 Oct 2011 14:23:45 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00KQ6SWXO2@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 07 Oct 2011 16:26:58 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LSP00GJ0SWX9K@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 07 Oct 2011 16:26:57 -0500 (CDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 07 Oct 2011 14:26:50 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 07 Oct 2011 14:26:48 -0700
Date: Fri, 07 Oct 2011 21:26:48 +0000
From: Leeyoung <leeyoung@huawei.com>
X-Originating-IP: [10.47.145.96]
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_tXMVwi30F0F02JUwJr7Zbg)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt
Thread-index: AcyFN9I6RzuixG9cRq+U3ev6WtQUxw==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Cc: "draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org" <draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2011 21:23:46 -0000
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-attribute-bnf-02.txt Reviewer: Young Lee Review Date: 7 October 2011 IETF LC End Date: 10 October 2011 Intended Status: Standard track Summary: I have no major concerns about this document that I think should be resolved before publication. Comments: This document is clearly written and easy to understand. Major Issues: No major issues found. Minor Issues: Section 3.2.1 I am not sure if I understand this compatibility section written as follows: A node that does not support the LSP Attribute object formatting as defined in this section will interpret the first present LSP Attribute object as representing LSP operational status even when it is intended to represent S2L sub-LSP status. It is unclear if this is a significant issue as the LSP Attribute object is currently considered to be an unsuitable mechanism for reporting operational status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. The intent of this document is to correct this limitation and it is expected that networks that wish to make use of such operational reporting will deploy this extension. If the node that does not support this new LSP attribute object, how can it interprets the first Present LSP Attribute object as LSP operational status if the LSP attribute object is not a suitable mechanism currently for reporting operational status of P2MP LSPs? It sounds like a contradictory statement as I read. Please clarify this section if needed. Nits: None identified