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

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

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



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

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

Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that I am
wrongly asserting the lack of IPv6 support for CurveCP else the easy way to
clear my DISCUSS would be to mention this limitation in section 3 even if the
focus of this I-D is on the API.

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

I hope that this helps to improve the document,

Regards,

-éric

== 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. (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).