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
