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

Chris Wendt <> Fri, 26 March 2021 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC5863A2224 for <>; Fri, 26 Mar 2021 09:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wp7vBht_QO-O for <>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 447D53A2220 for <>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
Received: by with SMTP id q9so3161274qvm.6 for <>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=83RedRB1jTST0Z66wAvTTYr21FWJksBkyff2XZcD3HY=; b=2KATvY5FhIt78BepkDlGP/vRpBMDcuw0fhb3WM/WaP1Oam0t+fl3vMOipDYsL/cyCA s+Gzs1vwfdo4QxAtmDVg0ybCq1RrSJ4/h9CVOBmhFhMeTcmXL8DVb+o1mvMGYN2SzFTc SpWpPD2q9JoQ4ulAsh4c2CGtUmlyvWrFvrhqih0Gjhfpl8htmurVS+iVxc/JRM3hNmOe 69tGc2QJdI7zznkpO835wlI13TtjpgeI23ZqWTucLl1R1HtcT6q4CvwaM3I/bR55k2Ax q6VijicjQJzLajqMgY7TgIvPHiH8ZXlAtwOzCMPu7yygRlA/I0ZxvEDv34K/CCRePiah 1QuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=83RedRB1jTST0Z66wAvTTYr21FWJksBkyff2XZcD3HY=; b=dfGqmK3P11Zun57TyCzz/vKn3TW6Na4aYBMp7imCJOVgdJEBr3QA6zwoqEJqx301un fgp1U5GPrces7yyD3OpqZFR46rUzC4lnVCTOYkChbsFrcQQWELiFOa+ayQBYhawuelb4 tgdvqhWmASW4RUUxgPgUXq9Tso6sBPmPAaRNZkONQ1dfe1O3lIySigf1w7nb6Tk7rqsj TWQQL4R5fw8lgZ80XOYmVPjsW55ZS+dG3zhOqeXO+bycsGxboqEEF8j/W8kWnupn1fnj y09an4aPkv6vVPUD7eFanbxC43/fmoTAewmEfXBpGRkKCXFRPkTtlnS6TdKlLykt71fW CzWw==
X-Gm-Message-State: AOAM530FfAsDWRmuVliAEDLMUoHUDBuRrM9lb3F2zq267sHK4t+K0i1E lPEsRECDEYvx4jELCgm/Ty+PCSc/BZE45kjl
X-Google-Smtp-Source: ABdhPJw3ztpDrit5QnFHyEkKplqeQCFH7KgGw+lOxu3ayMW/kE9w0246NmcYb86+KILyTP6csRTHZQ==
X-Received: by 2002:a0c:b9a5:: with SMTP id v37mr14191795qvf.46.1616774903561; Fri, 26 Mar 2021 09:08:23 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o21sm5931946qtp.72.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Mar 2021 09:08:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Chris Wendt <>
In-Reply-To: <>
Date: Fri, 26 Mar 2021 12:08:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Pete Resnick <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Acme] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Mar 2021 16:08:30 -0000

Thanks Pete for the review i have addressed the nits, including the abundance of MUSTs :) and will release in a next version 08 include other review comments.


> On Mar 15, 2021, at 4:06 PM, Pete Resnick via Datatracker <> wrote:
> 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
> <>.
> 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"?