Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-23

Thank you for the work on this document.

Similar to draft-ietf-tsvwg-ecn-encap-guidelines-21, I am wondering why this document contains the disclaimer for pre-RFC5378 work.

Thanks for this impressive spec. I have just a few comments/questions. 

- I am quite bemused by the proportion of this document devoted to exegesis rather than specification, but at least it makes an interesting read. 

- In,

         For those not under IETF
   control, it is RECOMMENDED that implementations of encapsulation and
   decapsulation comply with RFC 6040.  It is also RECOMMENDED that
   their specifications are updated to add a requirement to comply with
   RFC 6040 (as updated by the present document).

I don’t think you can point a BCP 14 “RECOMMENDED” at the owners of those specifications and expect it to have any force, any more than you can update their specifications, for the same reason.  This seems to be an exuberant use of all caps to mean “we really do suggest this quite enthusiastically”, but that’s not what BCP 14 is. 

- Has this work been liaised to 3GPP (and any other SDOs I might have missed that are potentially affected)?

Thank you, Bob, for having addressed my previous DISCUSS ballot, for archive:
https://mailarchive.ietf.org/arch/msg/tsvwg/kbVI8WUQ4-bOpBliAwVqKl0fYmE/

# 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

Hi,

Thanks for this document, I found it interesting to read.  A couple of minor comments for you to consider:

(1) p 5, sec 4.  Making a non-ECN Tunnel Ingress Safe by Configuration

      Whether or not an ingress implementation claims compliance with
      RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP
      (v4 or v6), if possible, the operator MUST configure the ingress
      to zero the outer ECN field in any of the following cases:

As a minor comment, I wonder whether RFCs should be specifying requirements on people (i.e., operators), or whether it would be better to place the requirement on the deployment.


(2) p 10, sec 6.1.1.  L2TP (v2 and v3) ECN Extension

   L2TP maintainers are RECOMMENDED to implement the ECN extension to
   L2TPv2 and L2TPv3 defined in Section 6.1.1.2 below, in order to
   provide the benefits of ECN [RFC8087], whenever a node within an L2TP
   tunnel becomes the bottleneck for an end-to-end traffic flow.

Similarly to my previous comment, should the RFC 2119 requirement be placed on the maintainers, or should it be placed on an updated versions of L2TP?

Regards,
Rob