Subject: [ippm] Fwd: [netmod] Important: Guidelines for YANG module authors

From: Greg Mirsky <[email-masked]>
Date: Sun, 11 Jun 2017 10:27:32 -0700

Dear All,
wonder how Network Management Datastore Architecture (NMDA) impacts our
data models. Could we get advice, suggestions from NETMOD WG? Invite
someone to our session? Add as one of topics on Sunday?

Regards,
Greg

---------- Forwarded message ----------
From: Alia Atlas <[email-masked]>
Date: Fri, Jun 9, 2017 at 8:05 AM
Subject: Fwd: [netmod] Important: Guidelines for YANG module authors
To: "[email-masked]" <[email-masked]>

At IETF 98 in RTGWG, I mentioned the need for clear guidelines to handle
the changes coming for structuring YANG models.  This is the resulting
guidance.

Regards,
Alia

---------- Forwarded message ----------
From: Benoit Claise <[email-masked]>
Date: Fri, Jun 9, 2017 at 9:56 AM
Subject: [netmod] Important: Guidelines for YANG module authors
To: NETMOD Working Group <[email-masked]>

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-masked]
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 11 Jun 2017 13:53:14 -0700

Greg,

The first place would be read the following two drafts:

draft-dsdt-nmda-guidelines <https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/>
draft-ietf-netmod-revised-datastores <https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>

The first one has the guidelines on how existing models need to change. I would be happy to answer any questions folks might have.

> On Jun 11, 2017, at 10:27 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Dear All,
> wonder how Network Management Datastore Architecture (NMDA) impacts our data models. Could we get advice, suggestions from NETMOD WG? Invite someone to our session? Add as one of topics on Sunday?
> 
> Regards,
> Greg
> 
> From: Alia Atlas <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> 
> At IETF 98 in RTGWG, I mentioned the need for clear guidelines to handle the changes coming for structuring YANG models.  This is the resulting guidance. 
> 
> Regards,
> Alia
> 
> 
> From: Benoit Claise <[email-masked] <mailto:[email-masked]>>
> To: NETMOD Working Group <[email-masked] <mailto:[email-masked]>>
> 
> 
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtgwg <https://www.ietf.org/mailman/listinfo/rtgwg>
> 
> 
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

Mahesh Jethanandani
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 11 Jun 2017 14:08:16 -0700

Hi Mahesh,
I've surely started with these two documents. My first question How we view
measurement results? And second, How we view computed metrics,i.e., loss
ratio, jitter? Are these operational?

Regards, Greg

On Jun 11, 2017 1:53 PM, "Mahesh Jethanandani" <[email-masked]>
wrote:

Greg,

draft-dsdt-nmda-guidelines
<https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/>
draft-ietf-netmod-revised-datastores
<https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>

The first one has the guidelines on how existing models need to change. I
would be happy to answer any questions folks might have.

Dear All,

Regards,
Greg

---------- Forwarded message ----------
From: Alia Atlas <[email-masked]>
Date: Fri, Jun 9, 2017 at 8:05 AM
Subject: Fwd: [netmod] Important: Guidelines for YANG module authors
To: "[email-masked]" <[email-masked]>

Regards,
Alia

---------- Forwarded message ----------
From: Benoit Claise <[email-masked]>
Date: Fri, Jun 9, 2017 at 9:56 AM
Subject: [netmod] Important: Guidelines for YANG module authors
To: NETMOD Working Group <[email-masked]>

Dear all,

Regards,
Alia Atlas, Routing AD

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Jun 2017 00:12:52 +0200

> ratio, jitter? Are these operational?

I assume you do not configure measurement results, hence these things
are all operational state (I assume the corresponding leafs are all
config false in YANG lingo).

A key benefit of revised datastores is that the new model makes it
safe to have config false data (e.g. measurment results) next to the
node in the YANG tree where you configure parameters used to obtain
measurement results. Before we had revised datastores, it was in some
cases not safe to have config false data next to config true data and
hence there was a recommendation to have separate config true and
config false trees in a YANG module.

>From a quick look at draft-ietf-ippm-twamp-yang-03.txt, it seems the
ietf-twamp module already has a mixed tree, so there might no change
be needed.

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