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 <noreply@xxxxxxxx> 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-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
