Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100: > Hi Lada, > > > On 19/09/2017 14:37, Ladislav Lhotka wrote: > > Martin Bjorklund <m...@tail-f.com> writes: > > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > Hi, > > > > > > > > I support the adoption but I propose two conceptual changes: > > > > > > > > 1. Introduce a new module name and namespace so that it is not > > > > necessary to carry along the deprecated baggage. If readability is > > > > the primary concern, this is IMO the way to go. Instead of > > > > "ietf-ip-2", I'd suggest something like "ietf- ip-nmda". > > > > > > > > 2. Avoid obsoleting RFC 7277. I believe the old modules may continue > > > > to be used > > > > in areas where NMDA is an overkill, such as open source home > > > > routers. > > > > > > Why wouldn't NMDA be appropriate in an open source home router? Note > > > that the new model really just have a single tree instead of two > > > trees, so the data that needs to be instrumented is more or less the > > > same. > > > > It is quite likely that some parts of the data models will be > > implemented only as configuration but not state data. In the "old style" > > modules it is easy to add a deviation for the node(s) under -state but > > in NMDA style this is not possible because we only have one node. > > The new YANG library allows different sets of modules to be available > for <conventional> datastores vs <operational>. The operational > datastore can also have different features supported and different > deviations vs the conventional datastores.
OK, I missed the 7895bis draft, sorry. Then there could be differences in mandatory/optional (e.g. a node is optional in configuration but mandatory in state data) or the data type of a leaf can differ. How can these be handled? Lada > > So, the device can make the same deviations to remove the state leaves > from <operational>. Or if they don't want to support the module in > operational at all then a device could just list it as being supported > in the conventional datastores and not <operational>. > > > > > There are subtle differences in the schemas for configuration and state > > data that the NMDA concept doesn't address. If you want another example, > > ietf-routing-2 has the "router-id" leaf that is conditional via the > > "router-id" feature. If this feature is not supported, router-id cannot > > be explicitly configured (it is assigned by the system) but in state data > > "router-id" needs IMO be present in any case. But the if-feature > > isn't able to differentiate between configuration and state data if > > there is only one node for both. > > The new YANG library also supports this: > > The "router-id" feature would be disabled for the conventional > datastores, but enabled for <operational>. > > > > > > In fact, if we claim that the new architecture is not appropriate for > > > some devices I think we have failed, especially if the conclusion is > > > that we need to maintain two versions of all modules going forward. > > > > I am not asking for this but, on the other hand, if NMDA versions used a new > > module name and namespace (my item #1, which is what ietf-routing-2 > > does), then I don't see any pressing need for obsoleting the old style > > modules. > > I think that creating a "-2" versions of these models at this time might > be a mistake. I actually think that the "deprecate state leaves" -> > "obsolete state leaves" -> "delete state leaves" path is a better choice. > > Thanks, > Rob > > > > > > Lada > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > NMDA > > > > implementors should be aware of the new modules but there is no need to > > > > eradicate the old data models. > > > > > > > > #2 applies also to other modules for which the NMDA version is underway. > > > > > > > > Lada > > > > > > > > PS. The subject is wrong, it shoud be -rfc7277bis- > > > > > > > > Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400: > > > > > All, > > > > > > > > > > This is start of a two week poll on making > > > > > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please > > > > > send email to the list indicating "yes/support" or "no/do not > > > > > support". > > > > > If indicating no, please state your reservations with the > > > > > document. If > > > > > yes, please also feel free to provide comments you'd like to see > > > > > addressed once the document is a WG document. > > > > > > > > > > The poll ends Oct 2. > > > > > > > > > > Thanks, > > > > > > > > > > Lou (and Kent) > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
