[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-dns-zone-digest-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss (and comment!) points.  There are still
a few more threads to tidy up, but I'm happy with the direction we're
going.

Section 1

We (implicitly) mention "integrity" here as provided in the absence of
DNSSEC, but later in Section 1.1 we say that integrity can only be assured
when the zone is signed.  I leave it to Roman to say when his discuss is
resolved, but it seems likely that we should be consistent about which way
we go with it.

Section 1.1

It's perhaps unusual to follow "the motivation for this protocol" with "a
secondary motivation"; instead writing "the primary motivation" would reduce
the surprise at seeing a secondary motivation added later.

Section 2.2.2

This change seems to be a regression?  The value 1 in question is the
scheme value, not a Hash Algorithm value.  (I would make this a
Discuss point but I am sure we will get it resolved quickly.)

Section 3

(nit) Right now the literal reading of "identical" is that the ZONEMD and
the signature and the denial-of-existence records are identical, which
is of course nonsensical.  Perhaps adding "to the ones produced by this
procedure" or similar would reduce the stress for people who habitually
make sentence diagrams.

Section 4

I can't tell if there's a duplicate line in the XML source or not, here
(as an editing leftover), but that's my guess as to what happened.  In
particular, I'm not sure how one would query for a DS RR *in the anchor*.
If I'm reading the previous thread correctly we were only proposing to talk
about querying for (and validating) DS RRs in the parent zone, not the
anchor (whatever that means).

Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD
report" above and just say this:]"?  (I'd be fine with it, for what little
it's worth, but I don't think my opinion is anywhere close to the most
relevant one.)