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

Chris Wendt <chris-ietf@chriswendt.net> Fri, 26 March 2021 16:08 UTC

Return-Path: <chris-ietf@chriswendt.net>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5863A2224 for <acme@ietfa.amsl.com>; Fri, 26 Mar 2021 09:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp7vBht_QO-O for <acme@ietfa.amsl.com>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447D53A2220 for <acme@ietf.org>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id q9so3161274qvm.6 for <acme@ietf.org>; Fri, 26 Mar 2021 09:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 [192.168.0.244] (c-68-82-121-87.hsd1.pa.comcast.net. [68.82.121.87]) by smtp.gmail.com with ESMTPSA id o21sm5931946qtp.72.2021.03.26.09.08.22 (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.60.0.2.21\))
From: Chris Wendt <chris-ietf@chriswendt.net>
In-Reply-To: <161583881825.8641.7955612326367134151@ietfa.amsl.com>
Date: Fri, 26 Mar 2021 12:08:18 -0400
Cc: gen-art@ietf.org, acme@ietf.org, draft-ietf-acme-authority-token-tnauthlist.all@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AB75BF3-8BCA-4CBA-A63D-50425AAAD108@chriswendt.net>
References: <161583881825.8641.7955612326367134151@ietfa.amsl.com>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/HDPMwWGDLng2NMv7UI3tAb7zNKg>
Subject: Re: [Acme] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: 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.

-Chris

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