Hi Catherine,
Op 09-12-2022 om 23:17 schreef Catherine Meadows via Datatracker:
The security considerations section gives a number of reasonable authentication
and privacy requirements, but does stops short of the use of the word MUST. Is
MUST avoided because it is not yet practical?
We think that the precise privacy and security requirements are very
diverse for the variety of different deployments currently and in the
future. Some zones and list of zones may have the requirement to be
published publicly without authentication (such as the zones managed by
IANA). We don't want to rule anything out. Therefore we deemed it
unpractical to have hard MUST requirements. Instead, we've tried to
enumerate all the considerations (and measures) as completely as we could.
Also, regular zone transfers (RFC5936) don't currently have MUST
requirements w.r.t. authentication or encryption. Encrypted zone
transfers (RFC9103) MUST be authenticated though.
We did fortify the requirements a little bit by changing that
"consumer(s) SHOULD scope the set of admissible member zones" instead of
"MAY".
Nits: There are a lot of unexplained acronyms, especially at the beginning:
RR, SOA, NS RR, RDATA, PTR, and so on. These should be spelled out the first
time they are used at the document. It would also help to have the more
important ones described in more detail in the terminology section.
This has been addressed in version -09 by adding the text that was
suggested by Joe Abley:
"This document makes use of terminology that is specific to the DNS,
such as for transfer mechanisms (AXFR, IXFR), for record types (SOA, NS,
PTR), and other technical terms (such as RDATA). Since these terms have
specific meanings in the DNS they are not expanded at first use in this
document. For definitions of those and other terms, see [RFC8499]."
Thank you for your review and kind regards,
Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones
co-authors.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
