Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-tls-subcerts-12

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@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 <noreply@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-call@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>
>