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 revision 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
I-D 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
Request Last Call review on draft-ietf-dnsop-multi-provider-dnssec by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/OufEQGupwsl7kIWGS4fd5rDaBVQ
Reviewed revision 04 (document currently at 05)
Result Ready
Completed 2020-03-31
review-ietf-dnsop-multi-provider-dnssec-04-genart-lc-resnick-2020-03-31-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-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.