Hi Balazs,
> 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? The restconf-nmda draft states what a server must do in order to indicate it supports NMDA. Similar statements could be put into the nmda-netconf draft. But I think your question is more about how a server can implement the new yang library module while having the same operational behavior as before - right? Perhaps rfc7895bis could have an Appendix section that maps various scenarios (e.g., NETCONF with :candidate + :writable-running, RESTCONF as it is) to yang-library 'datastores' with 'properties'. Would this work? > 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. I'm unsure if the architecture document should be overly proscriptive on this. Currently we define mechanisms enabling the server to accurately describe what it does, with the new datastore properties (e.g., auto-persist), which then lets the market decide what's best. > 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 I'd like to think that we could extend subtree filtering to include metadata, but so far the config true/false attribute is not considered metadata. In lieu of that, perhaps <get-data> could take a 'content' parameter like https://tools.ietf.org/html/rfc8040#section-4.8.1. > draft-dsdt-nmda-guidelines-01 > ------------------------------------------- > I would love to see a plan for updating existing models. Please see Rob's 7/20 email on the netmod list. > Our priorities being ietf-system, ietf-interfaces ietf-interface is being worked on. Regarding ietf-system, Rob wrote: RFC 7317: A YANG Data Model for System Management ietf-sys...@2014-08-06.yang defines system-state => Model update looks to be trivial. Martin Bjorklund is one of the authors, so hopefully he can help issue a updated version. That said, with all that's going on, I don't imagine this module's update will be prioritized. If important, maybe you can submit an rfc7317bis I-D? > 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. I personally think the definitions are okay. What's missing is knowledge of if the server implements the deprecated nodes or not. Note that even the 'obsolete' definition allows for continued use. One way a client can determine it a server implements deprecated/obsolete nodes is by trying to get the node(s) with-defaults. But my guess is that a client that has the wherewithal to do that can just as easily move to support the module's new nodes. What are you asking for, errata on RFC 7950? > 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. Fixed in my local copy. > 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? I'm okay with this, but I'd hope that validating software would flag it with a warning. > 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. Good catch, the yang-library-change notification definition wasn't updated before. Regardless which node the leafref points to, /modules-state/module-set-id or /yang-library/module-sets/module-set/id, the node s of type 'string'. This notification enables clients to maintain a cached listing of the modules a server supports. To be backwards compatible, a server should only send this notification for when the module-set used by the conventional datastores is modified. However, just doing this doesn't support the new datastores. It seems like what is needed is a listing of datastores that use the module-set. What do you think? Kent // contributor _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
