Hello,
Some comments to the NMDA drafts:
General: It should be more clearly describe how legacy devices that do
not wish to support NMDA should behave. They still need part of the
operational datastore, but might not (will probably not) have a separate
operational state for configuration from running/intended. Shall they
just present the running configuration as part of operational?
draft-ietf-netmod-revised-datastores-03
-------------------------------------------
4.1, 4.3) "If a device does not have a distinct <startup> and
non-volatile is
available, the device will typically use that non-volatile storage to
allow <running> to persist across reboots."
It has been a long standing problem for us that we don't prescribe how
and when the device persists configuration. "Typically" is a very week
word I would like to see a SHOULD or better a MUST.
draft-dsdt-nmda-netconf-00
-------------------------------------------
For us the most important part of the whole datastore restructuring is
the clean association of config and system-state data. We must be able
to issue a get-xxx operation to get ONLY the system-state data for a
particular branch. I don't see any way to filter a get-data on
config=false. Problem.
I think we should have a get-data filter based on origin
Yang model, get-data) IMHO 2 leafs are missing from get-data:
with-defaults and origin
draft-dsdt-nmda-guidelines-01
-------------------------------------------
I would love to see a plan for updating existing models. Our priorities
being ietf-system, ietf-interfaces
Page 8) "(c) For published models, the model should be republished with an
NMDA-compatible structure, deprecating non-NMDA constructs."
RFC7950 is very vague about what deprecated means (IMHO this is a
problem in the RFC).
"deprecated" indicates an obsolete definition, but it permits
new/continued implementation"
This does mean the fully functional implementation MUST still be in
place, it allows a node to remove it.
If we allow a node to remove e.g. /interfaces-state that is a problem.
What do we really mean in this case? We better state it explicitly.
draft-nmdsdt-netconf-rfc7895bis-01
-------------------------------------------
A lot of things should be mandatory and are not including module-name,
revision. They are needed by the user. It is even stranger that
deviations refer t modules by name, but the name is optional in the list
of modules.
Is it an error if a module containing only config=false data is listed
for the running datastore? IMHO not, it should just be ignored in the
running datastore?
The module-set-id only reference to the legacy part both in
/yanglib:yang-library-change/yanglib:module-set-id and
/yanglib:modules-state/yanglib:module-set-id. I assume this will change
also if something changes in the /yanglib:yang-library and the
notification will also be sent.
regards Balazs
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
