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 <lars@xxxxxxxxxx> 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 <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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
