[Idr] Éric Vyncke's No Objection on draft-ietf-idr-bgpls-srv6-ext-12: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-bgpls-srv6-ext-12: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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


# Éric Vyncke, INT AD, comments for draft-ietf-idr-bgpls-srv6-ext-12
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Susan Hares for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status.

Other thanks to Timothy Winters, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-12-intdir-telechat-winters-2022-12-07/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 3.1

I second John's point on the lack of specification for the Flag field. This
document does not specify how to interpret the values. It happens that the
IS-IS and OSPFv3 specify a 16-bit value with currently the same semantic
associated to the 16-bit but I fear that this is quite dangerous to have the
*same* field specified in several documents. Strongly suggest creating a IANA
registry for this 16-bit field shared by (at least) 3 IETF drafts.

The same comment applies to many other values in the document.

### Section 4.2

Suggest to replace the very specific "LAN" to the broader "broadcast link" ?

### Section 5.1

```
   As specified in [RFC8986], an SRv6 SID comprises Locator, Function
   and Argument parts.
```
Does the above text assume that *all* SIDs are network programming SIDs ?
Suggest to qualify as in "a network programming SRv6 DIS"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments