[Gen-art] Genart last call review of draft-ietf-tls-subcerts-12

Elwyn Davies via Datatracker <noreply@ietf.org> Sat, 09 April 2022 00:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C243A0959; Fri, 8 Apr 2022 17:18:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: draft-ietf-tls-subcerts.all@ietf.org, last-call@ietf.org, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164946350444.3243.13599547539306150042@ietfa.amsl.com>
Reply-To: Elwyn Davies <elwynd@dial.pipex.com>
Date: Fri, 08 Apr 2022 17:18:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s>
Subject: [Gen-art] Genart last call review of draft-ietf-tls-subcerts-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2022 00:18:25 -0000

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:"