Last Call Review of draft-ietf-dnsop-multi-provider-dnssec-04
review-ietf-dnsop-multi-provider-dnssec-04-genart-lc-resnick-2020-03-31-00

Request Review of draft-ietf-dnsop-multi-provider-dnssec
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-03-31
Requested 2020-03-10
Authors Shumon Huque, Pallavi Aras, John Dickinson, Jan Včelák, David Blacka
Draft last updated 2020-03-31
Completed reviews Secdir Last Call review of -04 by Daniel Migault (diff)
Genart Last Call review of -04 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick 
State Completed
Review review-ietf-dnsop-multi-provider-dnssec-04-genart-lc-resnick-2020-03-31
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/OufEQGupwsl7kIWGS4fd5rDaBVQ
Reviewed rev. 04 (document currently at 05)
Review result Ready
Review completed: 2020-03-31

Review
review-ietf-dnsop-multi-provider-dnssec-04-genart-lc-resnick-2020-03-31

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-dnsop-multi-provider-dnssec-04
Reviewer: Pete Resnick
Review Date: 2020-03-31
IETF LC End Date: 2020-03-31
IESG Telechat date: 2020-04-09

Summary: Ready.

Good to go. A straightforward document easy enough for this non-expert to get. Thanks to the shepherd for a straightforward writeup; it made the review even easier.

Major issues: None

Minor issues: None

Nits/editorial comments:

Just two comments, neither of them should stop progress on the document in any way:

1. I could see this document being a BCP, since the advice in here seems pretty prescriptive. I think it will still be perfectly useful as an Informational document, but it does seem to have important operational advice.

2. In section 3, it occurs to me that another thing you might add to the problem list is the issue of some servers caching BAD Data. Paul Hoffman was nice enough to point me to section 4.7 of RFC 4035. Perhaps a reference to there from this document would be useful.

Again, take them for what they're worth. If you decide not to do either, I feel the document could go forward as-is without a problem.