Hi, Rohit Ranade <rohitrran...@outlook.com> wrote: > Hi Martin, > > > > For below point: > > “ > > > 4. NETCONF has some "rpc" which work on multiple mount-instances. > > > > ==> For example <edit-config> , <get-config> or <lock>. Whether we need > > to give a > > > > guideline for how to handle such "rpc", so that other protocols which > > implement schema mount also adapt accordingly ? > > > > Eg: Something like, for transaction management, better to operate on one > > mount-instance. > > This would not be correct. I think you are assuming one use case; > where schema mount is used in a (primitive) orchestrator that actually > talks to multiple devices (w/o transaction control). > > Note that this document just defines how the *schema* is built; not > how instance data is stored or accessed. > > ” > > As per example shown in section 4: > > +--rw network-instances > > +--rw network-instance* [name] > > +--rw name > > +--rw root > > +--rw routing > > > > Considering “root” as mount point : > > > > When querying data from schema mounted models: > > > > <get-config> > > <filter> > > <network-instances> > > <network-instance> > > <name>1</name> > > <root> > > <routing/> > > > > And > > > > <action> > > <network-instances> > > <network-instance> > > <name>1</name> > > <root> > > <get-config> -- having ietf-netconf ns > > <filter> > > <routing/> > > > > Will these two give the same result ?
Yes, provided that the ietf-netconf module is mounted. /martin > > > > With Regards, > > Rohit R > > > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > > > ________________________________ > From: Martin Bjorklund <m...@tail-f.com> > Sent: Thursday, April 5, 2018 6:13:49 PM > To: rohitrran...@outlook.com > Cc: netmod@ietf.org > Subject: Re: [netmod] Comments on schema mount draft > > Hi, > > > Rohit Ranade <rohitrran...@outlook.com> wrote: > > Hi Martin, > > > > > > > > Thank you for your responses. > > > > I have gone through the LNE draft and YANG 1.1 and found some more > > suggestions. > > > > > > > > 1. Section 5 > > > > "If a mounted YANG module defines an RPC operation, clients can invoke > > > > this operation as if it were defined as an action for the > > > > corresponding mount point" > > > > ==> Below is the example from Yang 1.1 Section 7.15 > > > > > > > > <rpc message-id="101" > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > <action xmlns="urn:ietf:params:xml:ns:yang:1"> > > > > <server xmlns="urn:example:server-farm"> > > > > <name>apache-1</name> > > > > <reset> > > > > <reset-at>2014-07-29T13:42:00Z</reset-at> > > > > </reset> > > > > </server> > > > > </action> > > > > </rpc> > > > > > > > > <rpc-reply message-id="101" > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > <reset-finished-at xmlns="urn:example:server-farm"> > > > > 2014-07-29T13:42:12Z > > > > </reset-finished-at> > > > > </rpc-reply> > > > > ==> Here rpc-reply only has the namespace and action name > > defined in the mount-instance's module. > > > > The client needs to store information of the mount-instance > > for which the RPC request was sent and only then it can validate the > > rpc-reply against the data-model. > > > > To avoid this work of client, whether we can think of adding > > meta-data to rpc-reply to provide this information to client. > > If the client invokes an action, it is expected that it knows how to > interpret the result. This does not change with the introduction of > schema mount. The client obviously knows the name and input > parameters of the action, so it seems resonable to expect that it > knows the output parameters as well, w/o any additional meta data. > > > 2. Section 5 > > > > I would prefer the approach taken by Yang 1.1 where statements followed > > by XML examples to help in clarity. > > > > Especially for the RPC and notification section, it is better to add > > clear examples > > > > in a "Usage Example" sub-section for this section. > > The examples are given in the appendix, and there is a forward > reference to the appendix from section 5. > > > > 3. Yang RPC and ACTION statements: > > > > If we need to view the RPC defined in a module as an ACTION after schema > > mount, then > > > > Whenever there is update to RPC in say YANG 1.2, then the corresponding > > changes must be present in ACTION also, introducing a coupling between RPC > > and ACTION statements. > > This module is written using YANG 1.1. Unless this module is updated, > it doesn't matter what YANG 2.0 or whatever does. > > > 4. NETCONF has some "rpc" which work on multiple mount-instances. > > > > ==> For example <edit-config> , <get-config> or <lock>. Whether we need > > to give a > > > > guideline for how to handle such "rpc", so that other protocols which > > implement schema mount also adapt accordingly ? > > > > Eg: Something like, for transaction management, better to operate on one > > mount-instance. > > This would not be correct. I think you are assuming one use case; > where schema mount is used in a (primitive) orchestrator that actually > talks to multiple devices (w/o transaction control). > > Note that this document just defines how the *schema* is built; not > how instance data is stored or accessed. > > > > /martin > > > > > > > > > > > > > > > > > With Regards, > > > > Rohit R > > > > > > > > ________________________________ > > From: Martin Bjorklund <m...@tail-f.com> > > Sent: Thursday, March 29, 2018 12:59:53 PM > > To: rohitrran...@outlook.com > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Comments on schema mount draft > > > > Hi, > > > > Rohit Ranade <rohitrran...@outlook.com> wrote: > > > Hi Martin, > > > > > > W.r.t <get-schema> on the main device, it will mean that for > > > successful <get-schema> for all the schema of mounted devices, the > > > main device must be upgraded to higher version first and must contain > > > ALL the schema of all the devices behind the main device. > > > > This is not the intention, and as you note, in many cases this is just > > not possible. > > > > The client can look at the "location" leaf in the mounted YANG library > > (in YLbis; in old YL it was called "schema") and get the module from > > there. > > > > If the mounted schema also mounts "ietf-netconf-monitoring", the > > client can invoke the mounted <get-schema> as an action, and retrieve > > the specific version of the module that is mounted there. > > > > > This point may prove to be tricky as the whole topology upgrade has to > > > be considered always. I feel we can add some text regarding this. > > > > > > Also how to “mount” an instance of a mount-point ? Because once this > > > draft is out, each implementer may define private RPCs for mount and > > > un-mount if this module does not define it. Whether any plan about it > > > ? > > > > Note that schema mount is not about mounting devices; that would be a > > future specialization of this mechanism. > > > > In the LNE and NI drafts, entities are "mounted" by creating entries > > in the corresponding lists. There is no need for a "mount" rpc in > > these cases. > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > With Regards, > > > Rohit R > > > > > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for > > > Windows 10 > > > > > > From: Martin Bjorklund<mailto:m...@tail-f.com> > > > Sent: 26 मार्च 2018 13:41 > > > To: rohitrran...@outlook.com<mailto:rohitrran...@outlook.com> > > > Cc: netmod@ietf.org<mailto:netmod@ietf.org> > > > Subject: Re: [netmod] Comments on schema mount draft > > > > > > Hi, > > > > > > Thank you for these comments, replies inline. > > > > > > Rohit Ranade <rohitrran...@outlook.com> wrote: > > > > Hi All, > > > > > > > > Please find some comments for the schema mount draft. If I find any > > > > other will send in another mail. > > > > > > > > Editorial: > > > > ============ > > > > 1. Section 3.1 > > > > "The "mount-point" statement MUST NOT be used in a YANG version 1 > > > > module." > > > > ==> It is unclear why such a restriction is placed. > > > > > > The reason is that YANG 1 doesn't support inline actions and > > > notification, which means that top-level rpcs and notifs in the > > > mounted module cannot be invoked using the mechanism described in > > > section 5. I will try to clarify this. > > > > > > > 2. Section 3.2 > > > > "state data in the "yangmnt:schema-mounts"" > > > > ==> Here the yang tree diagram is not yet introduced. I feel better > > > > to > > > > introduce > > > > this diagram as it makes it easier to understand the data-nodes > > > > > > Ok. I moved section 8 to a new section 3.2. > > > > > > > 3. Section 3.2 > > > > "Data in this container is intended to be as stable as data in the > > > > top-level YANG library" > > > > ==> What is the meaning of "as stable" as ? As a developer , I am > > > > unclear what needs > > > > to be done here. Please clarify. > > > > > > Kent also had a comment around this, and the text about stable is now > > > removed. > > > > > > > 4. Section 3.2 > > > > "i.e., instances of that mount point MUST NOT contain any data above > > > > those that are defined in the parent schema." > > > > ==> Here "any data above", means "above" in the hieararchy ? > > > > > > No, this was just wrong; it should be "except". > > > > > > > Not > > > > clear, this is similar > > > > to having a USB slot, but no device mounted on it as yet in UNIX > > > > terms. Right ? > > > > The query output on parent-schema should give empty data. > > > > > > > > 5. Section 3.2 > > > > "If multiple mount points with the same name are defined in the same > > > > module - either directly or because the mount point is defined in a > > > > grouping and the grouping is used multiple times - then the > > > > corresponding "mount-point" entry applies equally to all such mount > > > > points." > > > > ==> As per tree diagram, "mount-point" has two keys. So each module > > > > can have multiple > > > > mount points. So how to apply it "equally" ? Not clear. > > > > > > Note that the sentence starts with "If multiple mount points with the > > > same name are defined in the same module" -- so this clearly doesn't > > > apply to mount points with different names, right? > > > > > > For example, you can have: > > > > > > container foo { > > > yangmnt:mount-point my-mnt-point; > > > } > > > container bar { > > > yangmnt:mount-point my-mnt-point; > > > } > > > > > > There is just one entry in the "mount-point" list, so that entry > > > applies to both these mount points. Both are either "inline" or > > > "shared-schema". > > > > > > > > > > 6. Section 3.2 > > > > Instead of "inline" and "shared-schema", I suggest to use > > > > "variable-schema" and > > > > "same-schema" > > > > Reason: The key difference between the two is that in one case, the > > > > schema MAY be different > > > > while in the other the schema is same. The name can be similar to the > > > > reason. > > > > > > At this point, we have to live with these terms. This was part of the > > > compromise leading to this solution; there are other documents in the > > > RFC editor's queue that depend on these terms. > > > > > > > Logical Point: > > > > 1. Consider the topology where 1 main device is present with N logical > > > > devices behind it. > > > > When the mounting is done, it is quite possible that some of N > > > > devices > > > > are having different > > > > versions of modules. > > > > This can lead to each instance of mount point, having different > > > > schema. > > > > How can the client understand the schema of each mount-point instance > > > > ? Preferably get-schema of these devices and then know the model ? > > > > > > This draft says that each instance will have its own YANG library > > > instance. So there the client can detect which versions of the > > > different modules each instance supports. Then <get-schema> can be > > > invoked to get the modules, if it is supported. > > > > > > > > > /martin > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
