Last Call Review of draft-ietf-sidrops-https-tal-07

Request Review of draft-ietf-sidrops-https-tal
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-03-18
Requested 2019-03-04
Authors Geoff Huston, Samuel Weiler, George Michaelson, Stephen Kent, Tim Bruijnzeels
Draft last updated 2019-03-22
Completed reviews Genart Last Call review of -07 by Pete Resnick (diff)
Opsdir Last Call review of -07 by Linda Dunbar (diff)
Rtgdir Telechat review of -07 by John Drake (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-ietf-sidrops-https-tal-07-genart-lc-resnick-2019-03-22
Reviewed rev. 07 (document currently at 08)
Review result Ready with Issues
Review completed: 2019-03-22


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.