Paul Wouters via Datatracker <[email protected]> writes:
Hi Paul,
Sorry for the delay in getting back to you, but thank you for the
comprehensive review.
> Good document, nice to see operations feedback back into the IETF via a new
> BCP.
>
> comments:
>
> The algorithm field is not discussed by this document.
>
> Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are
> discussed?
Good idea. Paragraph changed to:
The algorithm field is not discussed by this document. Readers are
encouraged to read {{?RFC8624}} for guidance about DNSSEC algorithm
usage.
> The NSEC3PARAM flags field currently contains no flags, but
> individual NSEC3 records contain the "Opt-Out" flag
>
> This reads a little odd. Because the IANA NSEC3param registry lists 1 flat,
> the
> opt-out flag:
>
> https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1
>
> Maybe a sentence more clearly stating there is currently only one flag defined
> and that is opt-out and then discuss it.
I think by "flat" you really mean "reserved"?
How about this:
The NSEC3PARAM flags field currently contains only reserved and
unassigned flags. Individual NSEC3 records, however, contain the
"Opt-Out" flag {{RFC5155}}, which specifies whether that NSEC3 record
provides proof of non-existence.
> are encouraged to use a flags value of 0 (zero)
>
> And rewrite this to say "are encouraged to not use the opt-out flag" so if in
> the future we define another flag, we don't have to errata or Update: this
> document for this one line mentioning 0.
Yep, I actually noticed this exact bug too on a recent read. Agreed and
changed.
> The first
> hash is typically sufficient to discourage zone enumeration performed
> by "zone walking" an NSEC or NSEC3 chain.
>
> NSEC uses no hashing, so this sentence reads a little odd. Perhaps:
>
> The first
> hash with NSEC3 is typically sufficient to discourage zone enumeration
> performed by "zone walking" an unhashed NSEC chain.
>
> If NSEC3 must be used, then an iterations count of 0 MUST be used to
> alleviate computational burdens.
I think your first sentence is good, but the second sentence is a
duplicate with a later section.
> I think we need a sentence here (or in the section 2.4 above) that explains
> the
> iterations count of 0 means 1 hashing operation is done. Eg it is an "extra
> iteration count". I'd like to prevent implementors from thinking nsec3 can be
> unhashed completely.
You know, I'm sure we had a sentence about that in the past but must
have disappeared in some revision as I can't find it now. How's this:
Note that {{RFC5155}} describes the Iterations field to be "The
Iterations field defines the number of additional times the hash
function has been performed." This means that an NSEC3 record with an
Iterations field of 0 actually requires one hash iteration.
> Appendix D needs a note to the RFC Editor to remove itself.
Yep, already caught and added. Thanks.
> Appendix E lists a bunch of implementations. Normally, this would be placed in
> an Implementation Status section, that is removed before publication. Should
> this section really be contained within this document?
Yes, agreed per other discussions as well and guidance from RFC[mumble]
that talks about that it shouldn't be in the final document. I've
added a note for the RFCEditor to remove this section as well.
> "within the Internet" ? I'd probably use "on the Internet" :)
done
> "tamper-resistance proof" -> "tamper-resistant proof" ?
I figured out what you meant and changed it. :-P
> "repeating that hashing algorithm" -> "repeating that hashing using the same
> algorithm"
check
> Remove "ftp" from the example list in Section 2.3 as we deprecated it? The
> less
> credit we give it, the better :)
Ha, good point.
> in deploying both RFC4470 or NSEC3
>
> This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"
Done
>
> "and the zone resigned." -> "and the full zone needs to be
> resigned."
ok
> "and lower their default acceptable limits over time." -> "but lower their
> default acceptable limits over time."
gotcha
> There is a weird rendering of {RFC8914} instead of [RFC8914]
already fixed
> I think Petr Špaček would like to see his last name fixed :)
I'm sure he agrees.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
