Hi Rob,

Thanks for clarification. 
By using the deviation, I can remove the containers I don't need, and I could 
also remove some data nodes within the container, right?

BTW, your reply provides a good guideline. Is it possible to include those text 
into the draft? 

BR,
Amy
-----Original Message-----
From: Robert Wilton [mailto:[email protected]] 
Sent: Tuesday, March 27, 2018 6:33 PM
To: Yemin (Amy) <[email protected]>; [email protected]; [email protected]
Subject: Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09

Hi Amy,


On 27/03/2018 04:47, Yemin (Amy) wrote:
> Hi all,
>
> I also have a question/comment regarding this draft, maybe if it's discussed 
> already.
>
> If there a model A, which I would like to use just part of model A in another 
> model B, what should I do?
> The draft states that "This document allows mounting of complete data models 
> only.  Other specifications may extend this model by defining additional 
> mechanisms such as mounting sub-hierarchies of a module."
> It seems that the current schema mount doesn't support such usage.
That is correct.

>   
>
> Then I'm thinking that using deviation to create a new sub-module A', then 
> mount the sub-module A' in model B.
> Will it be a possible way out?
If you have a module A, then you could create another module, A-deviations, 
that used deviation delete statements to remove parts of A's schema.

Then a server could mount both modules A and A-deviations, hence excluding 
parts of module A at the mount point.

However, this approach would not allow you to only mount a descendant subtree 
in A.  E.g. You couldn't just directly mount the 
"interfaces/interface/statistics" container from RFC 8343, but you could mount 
the ietf-interfaces module and then deviate delete all nodes except for the 
interfaces/interface/statistics container.

Thanks,
Rob


>
> BR,
> Amy
> -----Original Message-----
> From: netmod [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Monday, March 26, 2018 7:18 PM
> To: [email protected]
> Subject: [netmod] Comments on draft-ietf-netmod-schema-mount-09
>
> 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)
>
> * '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)
>
> * Why not "Tree Diagram" instead of "Data Model"? The wording has 
> become a Best Practice (Section 8)
>
> * Idem, "This document...has the following diagram" captures better the Best 
> Practice than "This document...has the following structure"
> (Section 8)
>
> * 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")
>
> * Should this sentence refers only to [RFC6020]? "This document registers a 
> YANG module in the YANG Module Names registry [RFC6020]"
> (Section 10)
>
> * 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).
>
> 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
> .
>

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

Reply via email to