> On Jul 24, 2020, at 2:19 PM, Barry Leiba <[email protected]> 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!
>
> — 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.
Done.
>
> — Section 1.1 —
>
> internic.net site publishes PGP signatures along side the root zone
>
> Nit: I would say that “alongside” is one word.
Done.
>
> — 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.
Done.
>
> — 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?
Yes! Done.
>
> — 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?
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
>
> — 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?
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.
>
> — 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?
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.
> — 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?
How about this?
Certainly other RR types, such as DNSKEY, can result in larger amplification
effects.
(IMO "result" is appropriate)
>
> — Section 9 —
>
> The authors wish to thank David Blacka
>
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
