[tsvwg] Éric Vyncke's Discuss on draft-ietf-tsvwg-rfc6040update-shim-21: (with DISCUSS and COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-tsvwg-rfc6040update-shim-21: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-rfc6040update-shim-21

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Gorry Fairhurst for the shepherd's detailed write-up
including the WG consensus *but it lacks* the justification of the intended
status.

Other thanks to Donald Eastlake, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tsvwg-rfc6040update-shim-20-intdir-telechat-eastlake-2023-11-22/
(and I have noticed Bob's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Wrong BCP14 ...

Section 2 MUST use the correct BCP 14 (I told you that this was trivial)


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


# COMMENTS (non-blocking)

## Section 3.1

It is just a comment, no need to reply, but I do not agree with `Digging to
arbitrary depths to find an inner IP header within an encapsulation is strictly
a layering violation`, the encapsulating routing is probably doing the encaps
based on the future inner IP header (routing to a tunnel interface). Anyway,
just a comment.

## Section 6

Suggest removing the long expired draft-ietf-intarea-gue (and possibly others).

Suggest to add RFC 8986 as it also has a Ethernet next-header.

## Section 6.1.2

Please note that NHRP, RFC 2332, is sometimes used to set up GRE tunnels.

## Section 6.1.3

Teredo... a glimpse of the past back in 2023 ? More seriously, I do not mind
having this section, but Teredo is no more used. Writing `existing Teredo
deployments safe` in an IETF document looks so weird.

# NITS (non-blocking / cosmetic)

## Use of v4 and v6

While I usually say "v4" or "v6", I strongly suggest to write "IPv4" and "IPv6".