[tsvwg] Éric Vyncke's No Objection on draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-tsvwg-transport-encrypt-20: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/



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

Thank you for the work put into this document. The document is excellent on the
readability, not a surprise from academic authors ;-)

Special thanks for the doc shepherd's write-up as it writes about the WG
consensus/discussion, which appears to be be painful (as expected on this
topic). Congratulations David !

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

First a generic comment (close to be a DISCUSS): what about the impact on ECMP
(or even LAG) ? Many ECMP hashes are based on a 5-tuple and encrypting the
transport header will force the use of a 3-tuple. There should be a section on
the important of getting some field with entropy per 'flow'.

-- Section 2 --
Unsure whether "Common issues concerning IP address sharing are described in
[RFC6269]." should be part of this document but this is just my opinion. Feel
free to ignore.

-- Section 2.2.1 --
This is an impressive text by its clarity while being short and dense.

I just wonder about the absence of in-band/in-situ measurements, only
active/passive probing is mentioned (see other IETF works such as
draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark -- the former only
briefly cited in section 3.3 and in more details n section 6 but should section
2.2.1 already touch the topic ?)

-- Section 2.2.2 --
About "IP address", this is probably where IP address sharing should be
mentioned (rather than in section 2) ?

Should the part about IPv6 extension headers also mention the draft that I
referred to in section 2.2.1 ?

-- Section 2.3.4 --
The DoS attack aspect is possibly too brief... (notably because it is only
against the infrastructure and not a volumetric DoS attack against a end-user
node). How to "scrub" suspicious traffic if the traffic in "uncharacterized" ?

-- Section 2.4 --
Please add LPWAN WG RFC 8724 in the compression section.

For many constrained network, compression is really important as well as
QoS/precedence of some traffic. Should there be a dedicated section about such
constrained network ? (for header compression and precedence/QoS setting)

-- Section 3 --

Generic comment: refreshing section about R&D ;-)

-- Section 6.1 --
Please consider defining a "Maintenance Domain"

== NITS ==

-- Section 6 --
OAM has already been expanded