Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka <[e-mail]>]

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 <[e-mail]> writes:
> > 
> > > Ladislav Lhotka <[e-mail]> 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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67