Hi, I have a few comments about phrasing in DELEXT, particularly things that tripped me up on my first read. None of this is directly about the protocol itself, just the wording.
In the last paragraph of section 6.3.1 (Clarifications on Nonexistence Proofs) it says: > Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence > of any RRs below that zone cut, which include all RRs at that original owner > name, other than types authoritative at the delegation point (DS and > Delegation Types), and all RRs below that owner name regardless of type. I found it difficult to parse the comma separated clauses. For example, an incorrect interpretation could be: > Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence > of any RRs below that zone cut, which include all RRs at that original owner > name, other than: > 1. types authoritative at the delegation point (DS and Delegation Types) > 2. all RRs below that owner name regardless of type While this interpretation doesn't make sense, the correct meaning is still harder to grasp because it can be misread. I expect someone more familiar with RFC 6840 might find this more natural, but on my first review I refenced the section of RFC 6840 being updated to be sure I understood exactly what the updated version was trying to say. RFC 6840 says: > Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence > of any RRs below that zone cut, which include all RRs at that (original) > owner name other than DS RRs, and all RRs below that owner name regardless of > type. potential fix: reordering to get rid of a comma separated clause: > Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence > of any RRs below that zone cut, which includes all RRs below that original > owner name (regardless of type) and all RRs at that original owner name with > types not authoritative at the delegation point (all types except DS and > Delegation Types). --- In section 6.4 (Insecure Delegation Proofs), I initially found the requirements from the third and fourth paragraph unclear. The third paragraph specifies "MUST", then the fourth paragraph starts "Alternatively, the validator must". The lowercase "must" on a separate line made it slightly confusing to parse precisely what is required: > This document updates [RFC4035] and [RFC6840] to specify that the validator > MUST check for the presence of the NS or Delegation Type bits in the matching > NSEC (or NSEC3) RR (proving that there is, indeed, a delegation). > > Alternatively, the validator must make sure that the delegation with an NS > record is covered by an NSEC3 RR with the Opt-Out flag set. Once again, this is clearer after reading the section RFC 6840 being updated: > The validator also MUST check for the presence of the NS bit in the matching > NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or > alternately make sure that the delegation is covered by an NSEC3 RR with the > Opt-Out flag set. potential fix: combining it into one sentence with explicit options: > the validator MUST either (a) check for the presence of the NS or Delegation > Type bits in the matching NSEC (or NSEC3) RR (proving that there is, indeed, > a delegation), or (b) make sure that the delegation with an NS record is > covered by an NSEC3 RR with the Opt-Out flag set. --- Both sections were clear after referencing RFC 6840, but hopefully these suggestions can help make it clearer regardless. -Brie Van Rosendale
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
