Barry, We've submitted a new (-09) version of the zone digest draft, which I think addresses your comments. This includes a few simple grammatical changes that you suggested earlier, as well as two clarifications from our conversation below.
This -09 version also includes some rearranging of text and sections as requested previously by Mike StJohns that weren't yet published before the working group last call completed. If any of that is unclear please let me know. DW > On Aug 19, 2020, at 7:21 PM, Barry Leiba <[email protected]> wrote: > >>>> — 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 > > I think the text should be clarified a little, to avoid what appears > to be a conflict. It should just take a few words, no? Hopefully this is clearer now. Section 2 now says: A zone MAY contain multiple ZONEMD RRs to support algorithm agility [RFC7696] and rollovers. When multiple ZONEMD RRs are present, each must specify a unique Scheme and Hash Algorithm tuple. 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. and in Section 3.1: When multiple ZONEMD RRs are published in the zone, e.g., during an algorithm rollover, each must specify a unique Scheme and Hash Algorithm tuple. and Section 4: 4. When multiple ZONEMD RRs are present, each must specify a unique Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains more than one RR with the same Scheme and Hash Algorithm, digest verification MUST NOT be considered successful. > >>>> — 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. > > Hm, I see. All I had been suggesting was changing "SHALL" to "MUST" > in order to be consistent, but now I see that it's a little more > complicated. > > On first thinking, it seems that the original (with the "MUST NOT") is > clearer. How about this?: > "If there are duplicate RRs with equal owner, class, type, and RDATA, > only one instance is included, and the duplicates MUST be omitted." Done, (with the addition of the xref): o If there are duplicate RRs with equal owner, class, type, and RDATA, only one instance is included ([RFC4034] Section 6.3), and the duplicates MUST be omitted. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
