> 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. Best regards Michael > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@xxxxxxxxxxxxxxx > PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
