[spring] Lars Eggert's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-spring-nsh-sr-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-spring-nsh-sr/



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


# GEN AD review of draft-ietf-spring-nsh-sr-12

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/pCpXOVzbOjel0Wrp8PjJ9sUeY98).

## Comments

### Section 1.1, paragraph 0
```
     The dynamic enforcement of a service-derived and adequate forwarding
     policy for packets entering a network that supports advanced Service
     Functions (SFs) has become a key challenge for network operators.
     For instance, cascading SFs at the 3GPP (Third Generation Partnership
     Project) Gi interface (N6 interface in 5G architecture) has shown
     limitations such as 1) redundant classification features must be
     supported by many SFs to execute their function, 2) some SFs receive
     traffic that they are not supposed to process (e.g., TCP proxies
     receiving UDP traffic) which inevitably affects their dimensioning
     and performance, and 3) an increased design complexity related to the
     properly ordered invocation of several SFs.
```
Could we perhaps find an IETF example to motivate this? It feels a bit odd
that the first paragraph in the introduction immediately points to a 3GPP
shortcoming, and it's the only motivational example given...

### Boilerplate

This document uses the RFC2119 keywords "SHOULD NOT", "NOT RECOMMENDED", "MAY",
"MUST NOT", "RECOMMENDED", "SHOULD", "OPTIONAL", "MUST", "REQUIRED", "SHALL",
and "SHALL NOT", but does not contain the recommended RFC8174 boilerplate. (It
contains some text with a similar beginning.)

### 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 `master`; alternatives might be `active`, `central`, `initiator`,
   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`

## 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-spring-sr-service-programming-05`, but `-07` is
the latest available revision.

### Grammar/style

#### "Abstract", paragraph 1
```
ce Function Chaining (SFC) in an efficient manner while maintaining separati
                           ^^^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

#### Section 1, paragraph 1
```
ose problems, and to decouple the services topology from the underlying phys
                                  ^^^^^^^^
```
An apostrophe may be missing.

#### Section 3, paragraph 11
```
ct forwarding paths for example). Further note that the above example can al
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Further".

#### Section 3, paragraph 17
```
n is used between SFF and SF). In addition the SFF strips the SR information
                                  ^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "addition".

#### Section 4, paragraph 7
```
H processing logic for SRv6. The pseudo code is shown below. When N receives
                                 ^^^^^^^^^^^
```
This word is normally 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