Hi, Michael,
On 10/1/23 07:22, tuexen@xxxxxxxxxxxxxx wrote:
On 10. Jan 2023, at 01:34, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
Hi, Michael!
Thanks a lot for your feedback! In-line....
On 9/1/23 17:55, Michael Tüxen via Datatracker wrote:
Reviewer: Michael Tüxen
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
I have one point which is more than a nit, but not really an issue:
For some transport protocols transient numeric identifiers are covered
by encryption (like in the QUIC case), sometimes they are not (like in
the TCP case), sometimes it depends on the lower layer (like in the
SCTP/IP versus SCTP/DTLS/UDP case). The introduction discusses that
just encrypting the transient numeric identifiers does not solve all
issues.
Readers might focus on Section 5 and do not read the whole document.
Therefore, it would be good, if Section 5 would also mention, that
considerations for transient numeric identifiers have to be made even
in the case where the transient numeric identifiers are protected
by encryption.
How about adding, at the end of Section 5, a parenthetical note that says:
"NOTE:
As discussed in Section 1, use of cryptographic techniques for
confidentiality and authentication might not eliminate all the
issues associated with predictable transient numeric identifiers.
Therefore, the advice from this section should still be applied
for cases where cryptographic techniques are employed for
confidentiality or authentication of the associated transient
numeric identifiers."
?
One might also s/should/SHOULD/ or /should still/is to/
Please do let us know what looks best to you.
I would vote for s/should/SHOULD/. That would address my issue.
Will do.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
