Subject: Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Apr 2018 12:57:25 +0200 (CEST)

Hi,

Thank you for your review.  Comments inline.

[email-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: [email-masked]
Date: Tue, 03 Apr 2018 14:17:10 +0200

Thanks, Martin;

A question in line:

Regards,
Ariel

Quoting Martin Bjorklund <[email-masked]>:

>> * 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)
>
>> * '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.
>
>> * 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:
>
>> * 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)
>>    ** and Section 5 of [RFC8341] (reminding administrators to set   
>> user rights accordingly, and giving their defaults values).
>
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?