[Sidrops] Genart last call review of draft-ietf-sidrops-https-tal-07

Pete Resnick via Datatracker <noreply@ietf.org> Fri, 22 March 2019 18:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 917B0131451; Fri, 22 Mar 2019 11:37:47 -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: draft-ietf-sidrops-https-tal.all@ietf.org, sidrops@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Pete Resnick <resnick@episteme.net>
Message-ID: <155327986751.23063.11928780401443919371@ietfa.amsl.com>
Date: Fri, 22 Mar 2019 11:37:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yIq5Bg1ruMZ1lBkt00csJwki3qk>
Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-https-tal-07
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 18:37:48 -0000

Reviewer: Pete Resnick
Review result: Ready with Issues

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-sidrops-https-tal-07
Reviewer: Pete Resnick
Review Date: 2019-03-22
IETF LC End Date: 2019-03-18
IESG Telechat date: 2019-04-11


I MUST say that this document is quite MUSTy. I only noted those that caused me
confusion or seemed useless. All of these are either minor issues or nits.
Either way, the document is generally ready.

Major issues:


Minor issues (or might be nits):

In 2.3:

   The validity interval of this trust anchor SHOULD reflect the
   anticipated period of stability...

Are there cases where it wouldn't reflect the period of stability? If so, it
would be good to give an example. If not, then s/SHOULD reflect/reflects.

Similarly for:

   Thus, the entity that issues the trust anchor SHOULD issue a
   subordinate CA certificate that contains...

In this case, that SHOULD might even be a MUST.

In section 4, in the last full paragraph and the bullets, I'm not at all clear
why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems
like you should explain circumstances (at least in general terms) where an
implementation would choose to do deviate from these.

Nits/editorial comments:

In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some
important implementation advice that someone wouldn't otherwise notice in the
protocol. But it's a nit if ever there was one.