Subject: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

From: Rohit R Ranade <[email-masked]>
Date: Wed, 9 May 2018 02:31:15 +0000

Hi All,

1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?

2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.

3.  Section 3 mentions the text  "A common use case is the operational state datastore schema which is a
  superset of the schema used by conventional configuration datastores. ". ==> I think it should be "maybe a superset" based on Point 3 of "Objectives" section.

4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?

With Regards,
Rohit R Ranade

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 May 2018 08:30:34 +0200

> 1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?

              All non import-only modules of the schema are implemented
              with their associated features and deviations.

Modules in module-set/module are modules a datastore referencing the
module set implements, modules in module-set/import-only-module are
modules a datastore referencing the module set only imports from.
 
> 2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.

A module set is a self contained set of modules and import only modules.

>   superset of the schema used by conventional configuration datastores. ". ==> I think it should be "maybe a superset" based on Point 3 of "Objectives" section.

Perhaps 'which is commonly a superset'. But note that the point 3 in
the objectives also covers any future datastores such as ephemeral
datastores what may have data models that do not relate to
<operational>.

> 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?

The reason is that NMDA is a very generic architectural document and
as such it should not detail specifics of concrete notifications.
These details belong into the specific documents. The NMDA document is
a root of a document dependency tree, we should not create a mesh of
document dependencies.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 9 May 2018 09:12:12 +0000

Modules in module-set/module are modules a datastore referencing the module set implements, modules in module-set/import-only-module are modules a datastore referencing the module set only imports from.

[Rohit R Ranade] One use-case I thought of was that a client was concerned with only some data-stores. So they can download the schema of only those modules and their imported modules of their data-stores of interest. But if this was the case, then the "checksum" is of no use to them, as they will not know whether their intended data-store changed or not. Is there any other use-case for the import-only-module being part of module-set ?

>   superset of the schema used by conventional configuration datastores. ". ==> I think it should be "maybe a superset" based on Point 3 of "Objectives" section.

Perhaps 'which is commonly a superset'. But note that the point 3 in the objectives also covers any future datastores such as ephemeral datastores what may have data models that do not relate to <operational>.
[Rohit R Ranade] I agree, your suggestion for this change is better. 

> 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?

The reason is that NMDA is a very generic architectural document and as such it should not detail specifics of concrete notifications.
These details belong into the specific documents. The NMDA document is a root of a document dependency tree, we should not create a mesh of document dependencies.
[Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF NMDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the RFC 8342

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 May 2018 11:53:52 +0200

> [Rohit R Ranade] One use-case I thought of was that a client was concerned with only some data-stores. So they can download the schema of only those modules and their imported modules of their data…

The checksum indicates a change in YANG library. If a client is only
interested in some datastore schemas, then the client may reload data
even though the specific datastore schema did not change. There were
versions with more checksum objects but at the end we removed them and
kept only the one that is essential to keep. Note, if you use
RESTCONF, then ETAGS may help with more granular checks. (In fact,
instead of spreading checksum objects all over, it seems RESTCONF does
not really need them and if NETCONF needs more granular chance checks,
it seems a generic solution that can work on arbitrary subtrees is a
better solution than spreading checksum objects everywhere.

The use-case for import-only-modules being part of a module set is to
allow a module-sets to be referential complete, i.e., different
module-sets may have diffferent import-only-modules.
 
> [Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF NMDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the RFC 8342

Sorry for my mis-understanding. YANG library defines the checksum and
the checksum may trigger a netconf-capability-change notification, so
this is likely why talk about the netconf-capability-change notification
in YANG library.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 9 May 2018 17:15:12 +0100

Hi Juergen,

> better solution than spreading checksum objects everywhere.
+1 for a generic solution.

At the moment RFC 8040 states that ETAGS only apply to configuration, so 
they don't necessarily help with operational data.

Perhaps we should be introducing something like ETAG support for 
operational as well.  Although, we would need to careful consider the 
implementation performance impact.  Given that operational data may come 
from multiple daemons, it may be very hard to efficiently generate 
reliable ETAGs that span across large chunks of operational data.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 May 2018 18:47:35 +0200

On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote:
> Perhaps we should be introducing something like ETAG support for operational
> as well.  Although, we would need to careful consider the implementation
> performance impact.  Given that operational data may come from multiple
> daemons, it may be very hard to efficiently generate reliable ETAGs that
> span across large chunks of operational data.

Yes, there is fast changing data and slow changing data, there is
expensive data (in terms of instrumentation) and there is inexpensive
data. I think the solution is to let the server decide an which data
to provide etags (or something equivalent). HTTP also has all the
Cache-Control magic - I have no clue whether RESTCONF implementations
and in particular RESTCONF clients do honor HTTP caching mechanisms
and maintain local caches at the HTTP interaction level. It seems HTTP
has a lot to offer here (no surprise) and it is not clear what needs
backporting to NETCONF or whether we are better off making RESTCONF do
all the things NETCONF does - or we do both and the implementations
will ultimately decide. In the long run, maintaining two protocols
providing similar functionality does not seem to be effective.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 May 2018 18:53:46 +0200

> they don't necessarily help with operational data.

Do you refer to this:

   The server MUST maintain an entity-tag for the top-level
   {+restconf}/data resource.  This entity-tag is only affected by
   configuration data resources and MUST NOT be updated for changes to
   non-configuration data.

Well, this talks about {+restconf}/data and specifically the top-level
resource and draft-ietf-netconf-nmda-restconf-04.txt seems to be silent
about entity-tags for {+restconf}/ds/<datastore> resources...

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 9 May 2018 18:01:12 +0100

On 09/05/2018 17:47, Juergen Schoenwaelder wrote:
> to provide etags (or something equivalent).
This sounds like a reasonable starting point.

>   HTTP also has all the
> and maintain local caches at the HTTP interaction level.
I don't know either.

>   It seems HTTP
I think that having the flexibility of a binary encoding is likely to 
become more important over time, particularly for dynamic configuration, 
or streaming telemetry.  From the previous discussions, it looks almost 
trivial to add binary encoding support into RESTCONF, but a lot of work 
to add it to NETCONF.

One thing that I prefer in RESTCONF is being able to provide a config 
update as a single tree update that includes both merge and delete 
operations as annotations within the tree.  This seems like an efficient 
way to generate and send a delta of a configuration from a client to the 
server.

But possibly a useful discussion to have may be what the members of the 
NETCONF WG perceives is the future for the IETF network management 
protocols.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 May 2018 17:57:44 +0000

[+netconf, since this discussion regards a netconf draft]

> NETCONF WG perceives is the future for the IETF network management 

I'm an advocate for RESTCONF being as capable as NETCONF, and perhaps
more capable (e.g., binary encoding, etags, etc.).

It would be nice to consolidate on one protocol, but I don't know how
market forces would ever allow us to do that...

Kent // contributor