Subject: [Netconf] yang library and schema mount and yang library checksum

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2018 13:14:44 +0100

Hi,

I like to raise an issue that started to puzzle me when I read the
schema mount I-D last week. I am raising this issue here since YANG
library belongs to NETCONF (even though the issue was triggered by a
NETMOD document).

draft-ietf-netmod-schema-mount-08 says:

   Data in this container is intended to be as stable as data in the
   top-level YANG library [RFC7895].  In particular, it SHOULD NOT
   change during the same management session.

draft-ietf-netconf-rfc7895bis-03 says:

   YANG library information can be different on every server and can
   change at runtime or across a server reboot.

   ....

   If the value of this leaf changes, the server also generates a
   "yang-library-update" notification.

My first observation was that the schema mount statement makes a
promise that is not made in YANG library document. But what does the
"SHOULD NOT change during the same management session" mean for an
implementor?

  - For a client implementor, it likely means "I can reasonably assume
    that the schema does not change as long as I am using the same
    management session".

  - For a server implementor, it is unclear what this statement
    implies. If something causes a chance of YANG library (i.e., a
    license is enabled or a software update is installed), in order to
    implement the SHOULD, do I (a) postpone the change until there is
    no management session anymore or (b) do I force a termination of
    management sessions in case the change of a YANG library can't be
    postponed, or (c) do I take the easy way out since its a SHOULD
    and so what happens happens.

  - It remains somewhat unclear what a management session is with
    RESTCONF. (And the details about existing management sessions may
    not be easily accessible by the code that say installs an update
    or reconfigures the management subsystem.)

To me, it seems that (a)-(c) are all bad if we want robustness, even
if we manage to define what a management session is.

Looking at the I-Ds, it seems YANG library has the model that YANG
library content can chance and it provides a notification so that a
client that cares about this can get informed (at the price of having
to subscribe for the notification). It seems that schema mount follows
a different model where it likes to have some server make a promise to
a client that a YANG library wont change during (a not well defined)
management session.

My first thought was that it is not good if two documents give
different advice to implementors and that we should get this aligned.

On second thought, it seems that the solution is perhaps more complex
than it needs to be. For clients that care about the schema used by
server, would it not be easier and more efficient if there would be a
way to send the yang library checksum cached by the client with get
and edit requests to the server and to have the server fail requests
if the library checksum provided with the request does not match the
server's current library checksum? We could add an optional
yang-library-checksum parameter to NETCONF operations that can be used
by clients that want to ensure they work with the current YANG library
information. We could add a similar option to RESTCONF requests. With
such an approach, we have clear semantics and clients can decide
whether they want to yang library checksums verified during normal
interactions (and we may not even need the notification).

Comments? I think we should at least align the two documents such that
they follow the same basic model. (And my proposal would be to remove
the SHOULD statement from the schema mount document.) Whether we want
to define additional parameters or options for get and edit requests
to validate yang-library-checksums, I do not know. But this should be
possible to do even at a later stage (if we remove the unclear SHOULD
statement from the schema mount document.)

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Feb 2018 13:47:06 +0100 (CET)

Hi,

>     and so what happens happens.

Just to be clear, this is not a new problem.  We had to deal with
this problem even as we implemented NETCONF 1.0 (some 12 years
ago...).  There we had the <hello> message which had all server
capabilities including data model capabilities, now we have protocol
capabilities + yang library data, but the problem is the same.

In our server we now do (a) and (b).  Having a client be prepared for
capability and schema changes on-the-fly seems terribly complex (to
implement in the client).  See more below.

> if we manage to define what a management session is.

I'm not sure I agree.  In the worst case a client will get a transport
close, and do a reconnect.  This is something robust clients need to
do anyway.

As for RESTCONF, things are tricker, I agree.  Use NETCONF instead ;-)

> interactions (and we may not even need the notification).

What if the capabilities or schema change in the middle of an
operation?  Or would you wait with changing capabilities and schema
until there are no ongoing operations (a') or force a termination of
ongoing operations (b')?

> the SHOULD statement from the schema mount document.)

I agree with this.

I think we should focus on getting YLbis and SM out, and have this
discussion later.

/martin

> Whether we want
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 01 Feb 2018 13:53:30 +0100

Hi,

I think that a reasonable stability of the metadata describing the data model is
generally a good thing - it shouldn't change haphazardly because otherwise the
data model as a contract between the server and client would be laughable.

To give an extreme example, a server implementor could enforce a "dynamic"
schema - as soon as an instance is accessed, its schema is modified in YANG
library and corresponding data returned. This should IMO not be permitted.

I think some notion of stability should be stated even though it seems difficult
to give some concrete terms. I agree that the session isn't suitable for
RESTCONF.

In the case of schema mount, we wanted to distinguish the lifecycle of the two
cases - inline and use-schema.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67