Hi Roman, thanks for your comments, please see below.
Roman Danyliw via Datatracker <nore...@ietf.org> writes: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Valery Smyslov for the SECDIR review. > > I applaud the clever use of XSLT to autogenerate and keep the YANG module up > to > date. > > ** Section 5. Recommend refining the security considerations to defer > security > issues to the modules that use import the data types defined in this > document. > Roughly: > > OLD > This documents translates two IANA registries into YANG data types > and otherwise introduces no technology or protocol. Consequently, > there are no security issues to be considered for this document. > > NEW > > This document translates two IANA registries into YANG data types for use by > other YANG modules. When imported and used, the resultant module schema will > have data nodes that can be writable or readable via a network management > protocol. Access or modification to such data nodes may be considered > sensitive in some network environments, and this risk should be evaluated by > the importing module. > The iana-dns-class-rr-type module only defines data types, so it doesn't contribute any data nodes when imported or used. I suggest to use the following formulation, adopted from RFC 6991: NEW This documents translates two IANA registries into YANG data types and otherwise introduces no technology or protocol. The definitions themselves have no security impact on the Internet, but their use in concrete YANG modules might have. The security considerations spelled out in the YANG specification [RFC7950] apply for this document as well. Is it sufficient? Thanks, Lada > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
