> On 10. Jan 2023, at 19:59, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > 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. Great, thanks a lot. Best regards Michael > > 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
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
