Thanks, Martin;
A question in line:
Regards,
Ariel
Quoting Martin Bjorklund <[email protected]>:
Hi,
Thank you for your review. Comments inline.
[email protected] wrote:
Hi members,
I comment on that draft:
* Instead of "it is often necessary that an existing module (or a
set of modules) is added to the data model starting at a non-root
location", this would read better: "it is often necessary that an
existing module (or a set of modules) be added to the data model at
locations other than the root." (Section 1)
Ok, fixed.
* 'The "mount-point" statement MUST NOT be used in a YANG version 1
module' Why this documents keeps YANG 1 off from its scope?
(Section 3.1)
The reason for this is that otherwise it is not possible to invoke
mounted RPC operations, and receive mounted notifications. I have
clarified this in the text.
* 'Specifically, a server that doesn?t support the NMDA, MAY
implement revision 2016-06-21 of "ietf-yang-library" [RFC7950]
under a mount point' [RFC7895] defines "ietf-yang-library", not
[RFC7950] (Section 6)
Fixed.
* Why not "Tree Diagram" instead of "Data Model"? The wording has
become a Best Practice (Section 8)
I don't think I have seen "Tree Diagram" as the title of such a
section. See e.g. RFC 8344.
* Idem, "This document...has the following diagram" captures better
the Best Practice than "This document...has the following
structure" (Section 8)
The full text is:
This document defines the YANG 1.1 module [RFC7950]
"ietf-yang-schema-mount", which has the following structure:
it says that the *module* has a structure.
* Same remark on restricting to YANG 1.1: "The ?mount-point?
statement MUST NOT be used in a YANG version 1 module, neither
explicitly nor via a ?uses? statement (description of the extension
"mount-point")
See above.
* Should this sentence refers only to [RFC6020]? "This document
registers a YANG module in the YANG Module Names registry
[RFC6020]" (Section 10)
This is correct.
* The document cites /schema-mounts as "The schema defined by this
state data provides detailed information about a server
implementation may help an attacker identify the server
capabilities and server implementations with known bugs" I think
this section should warn also on:
** Section 2.1.2 and 4 of [RFC7895] (the list 'module' contains
the leaf 'schema': from which anyone may retrieve a YANG module)
** Section 3 of [RFC6022] (it defines the RPC 'get-schema'; with
which anyone may get a YANG module)
** and Section 5 of [RFC8341] (reminding administrators to set
user rights accordingly, and giving their defaults values).
There is an ongoing discussion about adding text re. mounted modules
and how NACM is used to protect them. I think this needs to be
handled in a generic way, rather than listing some mounted modules.
I find the [RFC6022], [RFC7895], and [RFC8341] worth to be mentioned
in the Security Considerations. Does the discussion intend to include
them in that section?
/martin
Regards,
Ariel
[RFC6020] https://tools.ietf.org/html/rfc6020
[RFC7895] https://tools.ietf.org/html/rfc7895
[RFC7950] https://tools.ietf.org/html/rfc7950
[RFC8341] https://tools.ietf.org/html/rfc8341
-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
