Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt

[Lou Berger <[e-mail]>]

Thanks.

Lou

On 10/10/2011 1:32 PM, Leeyoung wrote:
> Lou,
> 
> That's better. I have no more issue with this document. 
> 
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Monday, October 10, 2011 8:20 AM
> To: Leeyoung
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt
> 
> Young,
> 	Thank you for the comments.  Please see below for in-line responses.
> 
> Lou
> 
> On 10/7/2011 5:26 PM, Leeyoung wrote:
>> 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.
> 
> Does the following revision clarify the paragraph?
> 
> OLD:
>>  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.
> NEW:
>     A node that supports [RFC4875] and [RFC5420], but not this
>     document, will interpret the first LSP Attribute object present in
>     a received message, which is formatted as described in this
>     document, as representing LSP operational status rather than S2L
>     sub-LSP status.
> 
> Lou
> 
>>  
>>
>> *Nits:*
>> None identified
>>
>>  
>>
> 
> 
> 
>