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

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call