[tsvwg] Lars Eggert's No Objection on draft-ietf-tsvwg-rfc6040update-shim-22: (with COMMENT)

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

Lars Eggert has entered the following ballot position for
draft-ietf-tsvwg-rfc6040update-shim-22: 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-tsvwg-rfc6040update-shim/



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

# GEN AD review of draft-ietf-tsvwg-rfc6040update-shim-22

CC @larseggert

## Comments

### Boilerplate

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

Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
needed?

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

### Typos

#### Section 4, paragraph 6
```
-          decribed in [decap-test]);
+          described in [decap-test]);
+            +
```

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://bobbriscoe.net/

### Grammar/style

#### Section 1, paragraph 1
```
y encapsulate an inner IP header. Instead they can encapsulate headers such
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Instead".

#### Section 3, paragraph 7
```
entations that predated the RFC. Therefore it would have been unreasonable t
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".
(Also elsewhere in the document.)

#### Section 3.2, paragraph 4
```
ket forwarded beyond the tunnel. Otherwise the non-ECN egress could discard
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".
(Also elsewhere in the document.)

#### Section 4, paragraph 11
```
ogic, copying the ECN field as a side-effect of copying the DSCP is a serious
                                 ^^^^^^^^^^^
```
Did you mean "side effect" (=adverse effect, unintended consequence)? Open
compounds are not hyphenated.

#### Section 6.1.1.2.1, paragraph 8
```
cification will need to be followed, e.g Explicit Congestion Marking in MPLS
                                     ^^^
```
The abbreviation "e.g." (= for example) requires two periods.

#### Section 6.1.2, paragraph 4
```
N field in the outer IPv6 header. However the specification does not mention
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

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