Reviewer: Charlie Kaufman
Review result: Has nits

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document prescribes a change to the automated procedure for updating DNSSEC delegation trust maintenance as described in RFC7344 and RFC7477. The existing procedure calls for updates to be automated in the parent zone if signed instructions exist in the child zone *ON ANY* authoritative name server, while the new procedure calls for those updates to be done only when consistent signed instructions exist *ON ALL* authoritative name servers (or at least on the functioning ones).

The intent of this change is to reduce the probability changes will occur in the parent zone before they take place on all child zones which could lead to valid data being rejected if the condition persists or if updates are made incorrectly. There is particular concern in the case where there are multiple independent zone operators and an error (or even a malicious change) by one makes the zone unavailable from the others. The cost is that this may delay the automated changes sufficiently that the zone operator will have to revert to a manual interaction with the parent zone to get the changes made.

It is hard to judge how important this is without understanding how robust DNS is in the event that multiple providers of a single zone accidentally or maliciously diverge, and how likely administrative errors are. I'm suspicious as to the practicality of this design in solving the problem. If these zone updates are automatically propagated to all peer zone providers, then this change will not prevent errors from propagating to the parent zone. If they do not, this requirement may create an undue burden on those maintaining zones to manually propagate the changes to their peer providers. But this is not my field, so I have to assume the designers know what they are doing.

NIT: Section 2.2: CYSNC -> CSYNC