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.
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
