Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Roman,

Thanks for your review. I've updated the draft for all your comments and please check inline below for response.

The version 16 of the draft has been posted to address your and other comments from the IESG review:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16 

Thanks,
Ketan

-----Original Message-----
From: Roman Danyliw via Datatracker <[e-mail]> 
Sent: 12 June 2019 07:01
To: The IESG <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Roman Danyliw's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-ext-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 2.0.  Does the sentence, “This document adds additional BGP-LS Attribute TLVs in order to encode SR information” imply that this document should explicitly update RFC7752?

[KT] As clarified by Alvaro, this document only add new TLVs to BGP-LS for SR functionality. As such, it does not update RFC7752.

(2) Add more detailed citations
-- Section 2.x.  Section 2.1.x.  When citing a reference to explain a given TLV/sub-TLV, consider adding the relevant section number to improve readability.  For example:

OLD: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in [I-D.ietf-isis-segment-routing-extensions].

NEW: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in Section 3.2 of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.1.2  Per the octet of flags, please specify the specific section number of [I-D.ietf-isis-segment-routing-extensions].

-- Section 2.2.*.  Consider adding the appropriate section number in the references when described the flags field.

[KT] The section references were previously there in the tables in sections 2.4 and 2.5 but were later removed as part of the AD review. Now adding back the same sections inline.

(3) Section 2.1.4.  Per “SID/Label sub-TLV (as defined in Section 2.1.1) which encodes the first label in the range”, why is this just the first label?  Isn’t there the potential of a series of labels each in a distinct SID/Label sub-TLV?

[KT] The Range TLV can carry multiple sub-ranges and it should be read as "first label in the sub-range". I've clarified this text in the update.

(4) Section 2.2.2.  Is there a reference to explain the semantics of the weight field?

[KT] It is described in section 3.4 of RFC8402 and I've added the same reference.

(5) Section 2.3.1.  Is there a reference to explain the semantics of the algorithm field?

[KT] It is described in section 3.1.1 of RFC8402 and I've added the same reference.

(6) Editorial Nits:
-- Section 2.1.1.  Missing word:
s/The TLV and has the following format:/ /The TLV and sub-TLV has the following format:/

[KT] Fixed

-- Section 2.1.5.  Typo.  s/a unsigned/an unsigned/

[KT] Fixed.