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 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.