The authors have discussed this issue
(https://github.com/netmod-wg/datastore-dt/issues/15), and their
proposal is to close this with no change to the NMDA draft with the
following justifications:
1) This assumption is that longer term all models would become NMDA
compliant and over time it would likely require that all modules would
need to have this extension added, creating a CLR.
2) Defining the extension would take time, and further delay the IETF
standardization of YANG models, but it is important that IETF actually
gets standard YANG models published as quickly as possible so that they
can be implemented by the industry.
3) NMDA devices can implement "non NMDA style" modules (but with
duplication of state), and non NMDA devices can implement "NMDA style"
modules (but with reduced functionality).
4) YANG Catalog can identify what type of style a particular module is,
by using some heuristically analysis of the structure of the model.
Thanks,
Rob
On 15/09/2017 13:21, Martin Bjorklund wrote:
Ladislav Lhotka <[email protected]> wrote:
t.petch píše v Pá 15. 09. 2017 v 12:29 +0100:
Looking at a YANG module in future, how can I tell whether or not it is
written to work with revised datastores?
Ideally, this ought to be a wrong question. A YANG module (or rather a YANG data
model) should specify constraints for a data tree, no matter where the tree
happens to reside.
I agree, and an old module can be implemented in an NMDA-compatible
server (with some redundant info), and a new modules can be implemented in a
non-NMDA-compatible server (with limited functionality).
But the truth is that modules are and will be designed to fit into
some environment (or "meta model"). For example, with NMDA, there
will be a single tree. If we had an annotation for "comments" on
nodes, you wouldn't see any leafs called "description". If we didn't
have the ability to create things in the protocol, our models would
have objects of type "RowStatus". Etc.
/martin
Coupling a data modelling language with rather specific aspects of an NM
application is a bad design.
Lada
If the module is written assuming revised datastores and the environment
does not support this in some regard, then we have a management
malfunction, which could be disastrous.
I think that there should be some mechanistic way, something that can be
automated, for a system to check whether or not a module is assuming
revised datastores or not. This is a bit like the change from YANG 1.0
to YANG 1.1; there needs to be a way of telling what environment the
module is written for, and so we have the
yang-version 1.1;
statement.
Revised datastores needs something similar in the module.
Tom Petch
----- Original Message -----
From: "Lou Berger" <[email protected]>
Sent: Friday, September 01, 2017 10:02 PM
All,
This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.
The working group last call ends on September 17.
Please send your comments to the netmod mailing list.
Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.
Thank you,
Netmod Chairs
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
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
