I am only responding to the NETMOD specific comments. On Mon, Jul 17, 2017 at 12:38:27PM +0200, Balazs Lengyel wrote: > 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?
If the <applied> of a device _always_ equals <intended>, then reporting <intended> as <applied> is obviously correct. If <applied> and <intended> are only _mostly_ the same, well then customers will tell you at the end whether they want the differences to be visible. Note that a single say IP address list in <operational> may have entries from <intended> but also from other sources (e.g., IP addresses learned from DHCP or IP addresses generated by the system in addition to configured IP addresses). Focus on what is operationally used by a device when implementing <operational> and the question where this data is originating from should be a second thought. > 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. Our protocols are not very clear about this and we decided to live with this vagueness since we felt it is outside of the scope of our task to change/update protocols semantics. > 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. The plan I think is to revise the core modules as soon as we get to it. Not sure what you mean with 'node' above. Deprecated means that there is a new definition that should be implemented/used but the old definition has been kept to allow for a smooth transition. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
