[Taps] Éric Vyncke's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-taps-transport-security-11: 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-taps-transport-security/



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

Thank you for the work put into this document. It is really easy to read.

After discussion with Magnus and Barry, I have cleared my DISCUSS but I still
hope for a fix to my previous DISCUSS

Please find below some non-blocking COMMENTs. An answer will still be
appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== previous DISCUSS ==

I question the inclusion of CurveCP in the mix as per
https://curvecp.org/addressing.html it does not seem to support IPv6. At the
bare minimum, the I-D should mention this restriction in section 3 or rename
section 3 from "protocol descriptions" into something less exhaustive.

(and I hope to be corrected about CurveCP IPv6 support).

== COMMENT ==

Please respond to the IoT-directorate review by Mohit:
https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian:
https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I +
Gorry Fairhurst's about GRE

Generic comment about the intended transport: all protocols analyzed in this
document are point to point (no multicast), this should probably be mentioned
in the introduction.

-- Section 1 --
Is there any reason why the integrity property of IPsec AH is not mentioned ?
Same also applies in section 2 when "security protocol" is defined.

-- Section 3 --
Use the wording of "record protocol" generically while the term "record
protocol" is defined in section 2 as a blocked data transport (like in TLS).
Suggest the use of "data transfer protocol" ?

An important property of such protocols is to be able to traverse a NAPT box
(that I hate)... I suggest to mention whether the analyzed protocols support
NAT-traversal in this description section or even in the analysis parts as
having a different view (application and network layers seeing possibly
different IP addresses so a potential impact on the API).