[netmod] NMDA comments

[Balazs Lengyel <[e-mail]>]

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: [phone]              email: [e-mail]