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

[Leeyoung <[e-mail]>]

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
> 
>  
>