Thanks Elwyn, I've updated the document in Github to address your nits ( https://github.com/tlswg/tls-subcerts/pull/108/files).
Best, Nick On Wed, May 25, 2022 at 5:20 AM Lars Eggert <l...@eggert.org> wrote: > Elwyn, thank you for your review. I have entered a No Objection ballot for > this document. > > Lars > > > > On 2022-4-9, at 3:18, Elwyn Davies via Datatracker <nore...@ietf.org> > wrote: > > > > Reviewer: Elwyn Davies > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-tls-subcerts-?? > > Reviewer: Elwyn Davies > > Review Date: 2022-04-08 > > IETF LC End Date: 2022-04-08 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > Ready with nits. Just a few editrial level nits. > > > > Major issues: > > None > > > > Minor issues: > > None. > > > > Nits/editorial comments: > > Abstract: The exact form of the abbreviation (D)TLS is not in the set of > > well-known abbreviations. I assume it is supposed to mean DTLS or TLS - > This > > ought to be expanded on first use. > > > > Abstract: s/mechanism to to/mechanism to/ > > > > s1, para 2: CA is used before its expansion in para 3. > > > > s1, next to last para: "this document proposes" Hopefully when it > becomes an > > RFC it will do more than propose. Suggest "this document introduces". > > > > s1, next to last para: "to speak for names" sounds a bit > anthropomorphic to > > me, but I can't think of a simple alternative word. > > > > s1, last para: s/We will refer/This document refers/ [Not an academic > paper!] > > > > s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ > > > > s4, definition of expected_cert_verify_algorithm: " Only signature > algorithms > > allowed for use in CertificateVerify message are allowed." Does this > need a > > reference to the place where the list of such algorithms is recorded? > > > > s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated > credentials > > sent as extensions to any other certificate." I would have though this > ought > > to be a MUST. There is an equivalent in s4.1.2. I am not sure what the > > client/server might do if it doesn't ignore the DC. > > > > s4.1.3, para 1: s/same way that is done/same way that it is done/ > > > > s4.2, para 1: s/We define/This docuent defines/ > > > > sS/s5.1: RFC conventions prefer not to have sections empty of text: Add > > something like: "The following operational consideration should be taken > into > > consideration when using Delegated Certificates:" > > > > > > > > -- > > last-call mailing list > > last-c...@ietf.org > > https://www.ietf.org/mailman/listinfo/last-call > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
