Benoit,
Thanks for this!
WG,
Now would be a good time to take a look at, and comment on,
draft-dsdt-nmda-guidelines
<https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/> also
consider how this document impacts draft-ietf-netmod-rfc6087bis
(particularly section 5.23). Optimally we could have a proposed
revision to draft-ietf-netmod-rfc6087bis discussed on the list prior to
Prague, but I know I'm being optimistic.
Lou and Kent
On 6/9/2017 9:56 AM, Benoit Claise wrote:
> Dear all,
>
> Now that the new NETMOD and NETCONF charters have been approved, it's
> time to think about the guidelines for YANG module authors.
>
> The Network Management Datastore Architecture (NMDA) addresses the
> so-called "OpState problem" that has been the subject of much
> discussion in the IETF. NMDA is still in development, and there will
> be a transition period before NMDA solutions are universally available.
>
> The NETMOD Datastore Design Team and the Routing Yang Architecture
> Design Team have worked with Alia and Benoit to create initial
> guidelines for how the NMDA, as defined in
> draft-ietf-netmod-revised-datastores
> <https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>,
> impacts Yang models. The draft-dsdt-nmda-guidelines
> <https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/>
> individual draft was foundational in helping creating those guidelines.
>
> If you have questions or concerns on how these guidelines should apply
> to work of interest, please contact your WG Chairs or ADs.
>
> It is our strong recommendation, as ADs with agreement from the NETMOD
> WG Chairs, that models SHOULD move as quickly as possible to the NMDA.
> The specific approach to be taken for models being developed now and
> during the NMDA transition period should be based on both the expected
> usage and the maturity of the data model.
>
> 1. New models and models that are not concerned with the operational
> state of configuration information SHOULD immediately be structured to
> be NMDA-compatible.
>
> 2. Models that require immediate support for "in use" and "system
> created" information SHOULD be structured for NMDA. Then derived
> versions of these models SHOULD be created, either by hand or with
> suitable tools, that follow the current modeling strategies. In some
> cases, the non-NMDA model may be an existing model and not derived
> from the NMDA model. In all cases, the NMDA and non-NMDA modules
> SHOULD be published in the same document, with NMDA modules in the
> document main body and the non-NMDA modules in an Appendix. The use of
> the non-NMDA model will allow temporary bridging of the time period
> until NMDA implementations are available. The non-NMDA module names
> should include ’-state’ appended.
>
> We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin
> Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen
> Schoenwaelder, and all others who helped develop these guidelines.
>
> Regards,
> Alia Atlas, Routing AD
> Deborah Brungard, Routing AD
> Alvaro Retana, Routing AD
> Warren Kumari, Operations & Management AD
> Benoit Claise, Operations & Management AD
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
