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.


/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
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to