Re: [Teas] Comments on draft-ietf-teas-lsp-diversity-02

["Zafar Ali (zali)" <[e-mail]>]

Dear Lou- 

Thanks for the comments.

I agree, we will resolve your comments before the LC starts. More later.

Thanks

Regards Š Zafar




On 10/27/15, 9:40 PM, "Lou Berger" <[e-mail]> wrote:

>Hello,
>	As part of Shepherding draft-ietf-teas-lsp-diversity I have reviewed
>this document and have some comments/questions.  Most of my
>comments/questions are editorial/minor in nature.
>
>First some general questions:
>
>- You define a number of "Notify Error" subcodes, but only sometimes say
>what the upstream node should do.  I think this needs to be covered in
>all cases. You might find RFC5710 a helpful reference.
>
>- Separate DI type values are defined for V4 and V6. As DI type is
>defined with address family specific subobject, there appears to be no
>technical basis for this.  Am I missing something, i.e., is there any
>reason to have AF specific values rather than just defining 1-3 in an AF
>family agnostic values?
>
>- Assuming you make the previous change you can also combine the
>respective object/field definitions along the lines of what you have in
>section 2.3. This will have better consistency for the objects and the
>document.
>
>I have the following editorial/minor comments:
>
>- ID nits, see
>https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-tea
>s-lsp-diversity-02.txt
>, has 3 warnings that need to be addressed.
>
>Line numbers are from the idnits URL
>
>- Section 2.1.1 and 2.1.2 contain definitions of fields defined in other
>documents.  These should be replaced with simple references to the
>original definition rather than being repeated.  Interestingly, Section
>2.3 already does this.
>
>- Section 2.1.1, line 443.  Drop the word "border" as it applies to any
>node performing the expansion
>
>- Section 2.1.1.. lines 470/1.  Doesn't the "Note:" apply to all
>
>- Section 2.1.1., Section 2. PAS - as this document defines PAS there
>should be some guidance and/or guidelines for their creation and use.
>For example, one may conclude that PAS need to get propagated similar to
>SRLGs - but I'm sure this isn't the current intent.
>
>Section 2.2. What happens when a processing node encounters and unknown
>DI type?  This should be documented.
>
>Line 703: s/EN/a node/
>
>Lines 716,720.  As this is a procedures section shouldn't conformance
>language be used rather than "shall" and "do not need"?
>
>Line 821: S/PSR/Path_State_Removed flag (PSR) [RFC3473]
>
>Section 2.3.  Are the error subcodes the same for XRO and EXRS
>processing? I suspect not.
>
>I think that's it.  I think it makes sense to resolve these prior to
>last call so that folks can review a version that is slightly more ready
>for publication.
>
>Lou
>