Subject: [Netconf] deprecated subtree in revised ietf-yang-library

From: Radek Krejčí <[email-masked]>
Date: Tue, 5 Sep 2017 11:43:16 +0200

Hi,
what is the idea behind the deprecated modules-state subtree in revised ietf-yang-library schema? According to RFC, the deprecated node permits continued implementation because of interoperability. So, is the idea that the data created according to the RFC7895, should work even with this schema? And vice versa, that with the 7895bis, modes-state subtree is not necessary and just yang-library subtree is enough? Because it does not currently work this way. The modules-state as well as yang-library subtrees contain mandatory nodes (module-set-id and checksum) so at least these nodes are necessary to have in valid data. Am I wrong the the compatibility idea or there should be a top-level choice?

Regards,
Radek

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 5 Sep 2017 12:40:52 +0200

I'm going to try to answer myself :) The compatibility should be for clients (old clients understand new servers), not for the servers (old server generate data valid according to the new schema), so my idea was wrong. The server is supposed to generate both subtrees (duplicating data) and client can pick the subtree it understands. If I'm still not right, please correct me.

Radek

Dne 5.9.2017 v 11:43 Radek Krejčí napsal(a):
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Sep 2017 13:18:16 +0200 (CEST)

> I'm going to try to answer myself :) The compatibility should be for clients (old clients understand new servers), not for the servers (old server generate data valid according to the new schema),…

The server is not required to implement deprectated nodes.  7950 says:

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

This text applies to both clients and servers.

/martin

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 5 Sep 2017 13:34:45 +0200

ok, so what is the reason to have the deprecated nodes in this case? How does it improve interoperability?

Radek

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : [email-masked]
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET, Association of Legal Entities
Zikova 4
160 00 Praha 6
Czech Republic

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Sep 2017 13:51:03 +0200 (CEST)

> ok, so what is the reason to have the deprecated nodes in this case? How does it improve interoperability?

What do you mean by "have" the deprecated nodes?  If you mean
"implement in the server", it helps old clients to be able to
continue to work.  If you know that you can upgrade all clients at the
same time as the server, you don't have to implement the deprecated
nodes.

/martin

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 5 Sep 2017 14:29:13 +0200

I meant "have" in schema, if the servers do not provide these nodes. But even "may provide" meaning is useful (which is what I tried to say in my answer)

so, to improve interoperability (no one in real world is able to guarantee that all clients were upgraded), the server is _supposed_ to generate both subtrees, as I wrote. But it is not _required_ to do that (as you wrote). However, in such a case there is no backward compatibility. Is this answer correct and complete now?

Radek

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Sep 2017 14:34:20 +0200 (CEST)

Radek Krejčí <[email-masked]> wrote:
> I meant "have" in schema, if the servers do not provide these
> nodes. But even "may provide" meaning is useful (which is what I tried
> to say in my answer)
> 
> so, to improve interoperability (no one in real world is able to
> guarantee that all clients were upgraded), the server is _supposed_ to
> generate both subtrees, as I wrote. But it is not _required_ to do
> that (as you wrote). However, in such a case there is no backward
> compatibility. Is this answer correct and complete now?

Ok.  Did you get the answer to your question?

/martin

> >>>> I'm going to try to answer myself :) The compatibility should be for
> >>>> clients (old clients understand new servers), not for the servers (old
> >>>> server generate data valid according to the new schema), so my idea
> >>>> was wrong. The server is supposed to generate both subtrees
> >>>> (duplicating data) and client can pick the subtree it understands. If
> >>>> I'm still not right, please correct me.
> >>>>> what is the idea behind the deprecated modules-state subtree in
> >>>>> revised ietf-yang-library schema? According to RFC, the deprecated
> >>>>> node permits continued implementation because of interoperability. So,
> >>>>> is the idea that the data created according to the RFC7895, should
> >>>>> work even with this schema? And vice versa, that with the 7895bis,
> >>>>> modes-state subtree is not necessary and just yang-library subtree is
> >>>>> enough? Because it does not currently work this way. The modules-state
> >>>>> as well as yang-library subtrees contain mandatory nodes
> >>>>> (module-set-id and checksum) so at least these nodes are necessary to
> >>>>> have in valid data. Am I wrong the the compatibility idea or there
> >>>>> should be a top-level choice?
> >>>>>
> >>>>> Regards,
> >>>>> Radek
> >>>>>

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 5 Sep 2017 14:41:08 +0200

> Ok.  Did you get the answer to your question?

I hope so :)

Radek