[Acme] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07

Pete Resnick via Datatracker <noreply@ietf.org> Mon, 15 March 2021 20:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: acme@ietf.org
Delivered-To: acme@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 474A53A0D43; Mon, 15 Mar 2021 13:06:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Pete Resnick via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: acme@ietf.org, draft-ietf-acme-authority-token-tnauthlist.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161583881825.8641.7955612326367134151@ietfa.amsl.com>
Reply-To: Pete Resnick <resnick@episteme.net>
Date: Mon, 15 Mar 2021 13:06:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/QPpqnM5zy_H4iGz9nE4le1aXHYQ>
Subject: [Acme] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2021 20:06:58 -0000

Reviewer: Pete Resnick
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-acme-authority-token-tnauthlist-07
Reviewer: Pete Resnick
Review Date: 2021-03-15
IETF LC End Date: 2021-03-16
IESG Telechat date: Not scheduled for a telechat

Summary:

Looks fine. Some of the MUSTs look weird or superfluous to me and could
probably use a scrub, and a couple are a bit confusing, but none is so bad that
I would raise them as an "issue"; call them "nits/editorial comments".

Major issues:

None

Minor issues:

None

Nits/editorial comments:

Section 1: It's not clear to me what the purpose of the third paragraph in the
intro is. It sounds like it's just describing section 9 of RFC 8226, but it is
not distinguishing it from or comparing it to this document. Is it really
needed?

Section 3:

Instead of a reference to 7.4 of RFC 8555, perhaps a reference to section 7
generally would help, or perhaps a reference later in this section to 7.1.4.
Once I got down to the examples, I had to go look at 7.1.4 to familiarize
myself with the operation to understand what I was looking at.

Total nit, and just a personal pet peeve: It always seems silly to me to use
MUST where the meaning of that word is "MUST do what the protocol we are hereby
defining says to do". So instead of "MUST include", it could simply be
"includes", and "MUST be" could be "is" in the two places it occurs. These
three did not cause any significant confusion, whereas the ones is section 4
and 5.4 did cause some (see below). Either way, you should review all of them
in the document and decide what is truly needed.

Section 4:

Where it says, "a CA MUST use the Authority Token challenge type of "tkauth-01"
with a "tkauth-type" of "atc"", I am left to wonder what other choice the CA
might make such that you have to warn it that it MUST use these. Why is "uses"
not sufficient?

Conversely, when you say that the "token-authority" parameter is "optional"
(did you mean OPTIONAL): Is that really true? Is it that it MUST be used "in
cases where the VoIP telephone network requires the CA to identify the Token
Authority" (in which case it's not OPTIONAL), or is that simply an operational
consideration, and protocol-wise it is truly OPTIONAL? On the other hand, the
MAY and MUST at the end of the paragraph seem more appropriately to be "can"
and "can only". And the MUST in the following paragraph seems like another of
the ones in which you could change "MUST respond" to "responds".

Section 5:

The last paragraph seems superfluous.

Section 5.4:

The MUST NOT in the third bullet actually caused me a bit of confusion: I tried
to read it as a requirement of this document. I think you mean "is not" instead
of "MUST NOT be".

Section 5.5:

   The response to the POST request if successful MUST return a 200 OK
   with a JSON body that contains, at a minimum, the TNAuthList...

I think instead you mean:

   The response to the POST request if successful returns a 200 OK with
   a JSON body that MUST contain, at a minimum, the TNAuthList...

Then you won't need the "...however..." bit at the end of the next sentence.

In the last paragraph, why "SHOULD" and not "MUST"?