Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)
draft-ietf-idr-bgpls-srv6-ext-14

# Internet AD comments for draft-ietf-idr-bgpls-srv6-ext-12
CC @ekline

## Comments

### S7.1

* "Endpoint Behavior: 2 octet field.  The Endpoint Behavior code
   point for this SRv6 SID as defined in section 10.2 of [RFC8986]."

  Would it be more correct to say/add that support values are those from
  the "SRv6 Endpoint Behaviors" IANA registry (as established via section
  10.2 of RFC8986)?

I apologize for my tardiness in clearing my DISCUSS. Thanks for your reply and update, this looks good. I have a couple of minor comments below, which don't require a document update unless you choose (the first is optional, the second is something I'm sure the RFCEd will catch).

## COMMENT

### Global

In many cases, you changed "derived" to "copied", in some others you left it "derived". I'm just observing this, I don't think it's a must-change, the definition you supplied in Section 2 and the change of "and" to "or" already makes the document clear enough. But it seemed worth pointing out.

### Section 4.2

"For a LAN interface, an IGP node announces ordinarily only its"

should be

"For a LAN interface, an IGP node ordinarily announces only its"

(reverse word order)

The shepherd writeup says:

--
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure. Yes
--

...but the ones it lists are drafts aimed at the Standards Track.  Why are they "downward"?

I concur with Zahed's question about the number of authors.

Nice job on Section 9, which is typically one of my favorite places to complain lately.

Thank you to Stephen Farrell for the early SECDIR review.

Thanks for working on this specification. I haven't noticed TSV related issue in my reviews.

I have two minor comments/observations -

*  First the number of authors, I understand editor has been updating the document communicating with other authors listed. I was wondering if we have that active editor then why can't we more the other authors to contributor section. Has this been discussed in the WG as a potential option?

* Section 4.2 : The length of this TLV is variable, I think it would be more clear if there is a description of why this length is variable, even if there are obvious reasons.

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

Firstly, thanks for the document.

I support John's discuss with a suggestion/minor variation.

In the flags field - if running both ISIS and OSPFv3 - I would assume that there are two entries in LS for these protocols - if this is NOT the case - let me know
If this IS the case - then the wording should probably be changed to somethinglike:
  *  Flags: 2 octet field.  The flags are derived from the SRv6
      Capabilities sub-TLV/TLV of IS-IS (section 2 of
      [I-D.ietf-lsr-isis-srv6-extensions]) or OSPFv3 (section 2 of
      [I-D.ietf-lsr-ospfv3-srv6-extensions]), whichever is relevant.

This would apply anywhere in the document where the AND is used in similar context.

From reading John's discuss I believe this should address many of his concerns - but he can comment further.

# GEN AD review of draft-ietf-idr-bgpls-srv6-ext-12

CC @larseggert

## Comments

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-lsr-isis-srv6-extensions-18`, but `-19` is the
latest available revision.

### Grammar/style

#### Section 5.1, paragraph 4
```
ibutes for the given SRv6 Locator. Currently none are defined. 6. SRv6 SID NL
                                   ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 7.2, paragraph 14
```
egistry group as described in the sub-sections below. 9.1. BGP-LS NLRI-Types
                                  ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 10, paragraph 3
```
sions is limited to consumers in a secure manner within this trusted SR domai
                              ^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

#### Section 10, paragraph 3
```
nts. The authors would also like to thanks Susan Hares for her shepherd revi
                                 ^^^^^^^^^
```
Did you mean "to thank"?

#### Section 14.1, paragraph 3
```
 interface even when the peering is setup using the interface IP addresses.
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

Thanks for this document.

Alvaro has already answered the only question that I had.

Also thanks to Dan for the OPSDIR review.