Skip to main content

Last Call Review of draft-ietf-sidrops-https-tal-07
review-ietf-sidrops-https-tal-07-genart-lc-resnick-2019-03-22-00

Request Review of draft-ietf-sidrops-https-tal
Requested revision 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 G. Michaelson , Stephen Kent , Tim Bruijnzeels
I-D 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
Request Last Call review on draft-ietf-sidrops-https-tal by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 08)
Result Ready w/issues
Completed 2019-03-22
review-ietf-sidrops-https-tal-07-genart-lc-resnick-2019-03-22-00
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-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

Summary:

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:

None.

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.