Subject: [DNSOP] AD review of draft-ietf-dnsop-dns-zone-digest-08

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Jul 2020 17:19:43 -0400

I am serving as responsible AD for this document, because Warren is an
author, and so is recused.  Here’s my AD review.  Most comments are minor,
but I’d like to resolve the ones in Sections 2 and 3.1 before going to last
call, so I’ll set the substate to “AD Followup”.

— Section 1 —

   Zone files can
   also be distributed outside of the DNS, with such protocols as FTP,
   HTTP, rsync, and even via email.

Ultra-nit: this is a tricky one, but it’s actually not parallel.  It just
needs “and” before “rsync” to correct it.

— Section 1.1 —

   internic.net site publishes PGP signatures along side the root zone

Nit: I would say that “alongside” is one word.

— Section 1.2 —

   name server may need to send queries to validate a chain-of-trust.

Nit: “chain of trust” is a noun here, and shouldn’t be hyphenated.

— Section 1.3.1 —

   Reasons for doing so include privacy and reduced access
   time.  [RFC7706] describes one, but not the only, way to do this.

Should change this to 8806 now, no?

— Section 2 —

   It is recommended that a zone include only
   one ZONEMD RR, unless the zone publisher is in the process of
   transitioning to a new Scheme or Hash Algorithm.

This says “recommended”, and not even “RECOMMENDED”, but later we have, “If
the ZONEMD RRSet contains more than one RR with the same Scheme and Hash
Algorithm, digest verification MUST NOT be considered successful.”  So how
is this not a MUST, given that it will not interoperate if it’s violated?

— Section 3.1 —

   Implementations MAY want to set the
   Digest field to all zeroes anyway.

Why?  I certainly wouldn’t “want” to if there’s no benefit to doing so.  As
you mention it, I’m guessing there’s a reason.  Best to say?

— Section 3.4 —

   o  Only one instance of duplicate RRs with equal owner, class, type
      and RDATA SHALL be included ([RFC4034] Section 6.3).

It’s not wrong, but it’s slightly jarring that all the items around this
say “MUST” and this one says “SHALL”.  Any reason, or should we switch this
to “MUST” to match the others?

— Section 6.2 —

   Certainly other RR types result in
   larger amplification effects (i.e., DNSKEY).

Is DNSKEY the only one (“i.e.”)?  Or might there be others, as the text
implies?  Should this be “e.g.”?  And is “result” the right word here?

— Section 9 —

   The authors wish to thank David Blacka

Is that to distinguish him from David Blackb?

—
Barry

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 28 Jul 2020 15:32:39 +0000

> On Jul 24, 2020, at 2:19 PM, Barry Leiba <[email-masked]> wrote:
> 
> I am serving as responsible AD for this document, because Warren is an author, and so is recused.  Here’s my AD review.  Most comments are minor, but I’d like to resolve the ones in Sections 2 and 3.1 before going to last call, so I’ll set the substate to “AD Followup”.

Thanks Barry!

> Ultra-nit: this is a tricky one, but it’s actually not parallel.  It just needs “and” before “rsync” to correct it.

Done.

> Nit: I would say that “alongside” is one word.

Done.

> Nit: “chain of trust” is a noun here, and shouldn’t be hyphenated.

Done.

> Should change this to 8806 now, no?

Yes!  Done.

> This says “recommended”, and not even “RECOMMENDED”, but later we have, “If the ZONEMD RRSet contains more than one RR with the same Scheme and Hash Algorithm, digest verification MUST NOT be considered successful.”  So how is this not a MUST, given that it will not interoperate if it’s violated?

The difference is that the later text is specifically referring to RRs that have the same scheme and algorithm, but the earlier one is not.

Allowed:

    ZONMEMD 2018031500   1 1 FEBE..47DE
    ZONMEMD 2018031500 253 1 C680..ED71

Not allowed:

    ZONMEMD 2018031500   1 1 FEBE..47DE
    ZONMEMD 2018031500   1 1 C680..ED71

> Why?  I certainly wouldn’t “want” to if there’s no benefit to doing so.  As you mention it, I’m guessing there’s a reason.  Best to say?

I'm not sure there is a good reason to leave that sentence in.  Earlier revisions required the field to be zeroed, so it's probably just left over from that way of thinking.  It can just be removed I think.

> It’s not wrong, but it’s slightly jarring that all the items around this say “MUST” and this one says “SHALL”.  Any reason, or should we switch this to “MUST” to match the others?

Yes, the wording here is tricky.  Originally it was written like this:

   Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be included.

But that wasn't clear that you should include one instance of the duplicated RR.

It would probably be more clear in active voice such as "... MUST include only one instance of duplicate RRs..." but all these bullets are passive voice.

Open to suggestions.

> Is DNSKEY the only one (“i.e.”)?  Or might there be others, as the text implies?  Should this be “e.g.”?  And is “result” the right word here?

How about this?

  Certainly other RR types, such as DNSKEY, can result in larger amplification effects.

(IMO "result" is appropriate)

> Is that to distinguish him from David Blackb?

I'm having a "not sure if serious" moment, but David Blacka is a coworker of mine and coauthor of several RFCs.

> Barry

DW