Subject: [netmod] rfc6087bis S4.23 replacement text

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Aug 2017 19:53:46 +0000

Hi,

During the meeting in Chicago, the NMDA authors took an action to 
propose some text for S4.23.  After a little review, the following
emerged.  Yes, it's short, but was anything left anything out?

=====START=====

4.23 Operational Data

Operational data includes both config "false" nodes as well as,
on servers supporting <operational> [draft-ietf-netmod-revised-datastores],
the applied value of config "true" nodes.
 
YANG modules SHOULD be designed assuming they will be used on 
servers supporting <operational>.  With this in mind, YANG
modules SHOULD define config "false" wherever they make sense
to the data model.  Config "false" nodes SHOULD NOT be defined
to provide the operational value for configuration nodes, 
except when the value space of a configured and operational
values may differ, in which case a distinct config "false" 
node SHOULD be defined to hold the operational value for the
configured node.

=====STOP=====

One question that came up is if "operational data" is a well-defined
term.  This string appears 10 times in rfc6087bis.  Most interestingly,
appendix Section A.8. (v05 to v06) includes this line item:

    Changed term "operational state" to "operational data"

So it seems to be deliberate...

Kent  // contributor

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Aug 2017 16:32:14 -0400

Kent/WG,

    This seems a bit terse to me and not provide needed guidance during
the current transition period.  I understood  the discussion ended up 
with the options being to either (1) provide the guidance as a
standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
pointer to it from 6087bis or (2) just move those sections to 6087 bis. 
Either way, we'll need a new bis once the full NMDA solution makes it to
publication (request).

I thought the plan was to do (s).  If so, we need the full text. 
Looking at the current repo
(https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
it would be:

    4.23 Operational Data

    The following guidelines are meant to help modelers develop
    YANG models that will maximize the utility of the model with
    both current implementations and NMDA-capable implementations
    [draft-ietf-netmod-revised-datastores].

    (a) New models and models that are not concerned with the
    operational state of configuration information SHOULD
    immediately be structured to be NMDA-compatible.

    (b) Models that require immediate support for "in use" and
    "system created" information SHOULD be structured for NMDA.  A
    non-NMDA version of these models SHOULD exist, either an
    existing model or a model created either by hand or with
    suitable tools that mirror the current modeling strategies.
    Both the NMDA and the non-NMDA modules SHOULD be published in
    the same document, with NMDA modules in the document main body
    and the non-NMDA modules in a non-normative appendix.  The use
    of the non-NMDA model will allow temporary bridging of the
    time period until NMDA implementations are available.

    (c) For published models, the model should be republished with
    an NMDA-compatible structure, deprecating non-NMDA constructs.
    For example, the "ietf-interfaces" model in ^RFC7223^ will be
    restructured as an NMDA-compatible model.  The
    "/interfaces-state" hierarchy will be marked "status
    deprecated".  Models that mark their "/foo-state" hierarchy
    with "status deprecated" will allow NMDA-capable
    implementations to avoid the cost of duplicating the state
    nodes, while enabling non-NMDA-capable implementations to
    utilize them for access to the operational values.

    (d) For models that augment models which have not been
    structured with the NMDA, the modeler will have to consider
    the structure of the base model and the guidelines listed
    above.  Where possible, such models should move to new
    revisions of the base model that are NMDA-compatible.  When
    that is not possible, augmenting "state" containers SHOULD be
    avoided, with the expectation that the base model will be
    re-released with the state containers marked as deprecated.
    It is RECOMMENDED to augment only the "/foo" hierarchy of the
    base model.  Where this recommendation cannot be followed,
    then any new "state" elements SHOULD be included in their own
    module.

    To create the temporary non-NMDA model from an NMDA model, the
    following steps can be taken:
   
    - Rename the module name by postpending "-state" to the
      original module's name
    - Change the namespace by postpending "-state" to the original
      namespace value
    - Change the prefix by postpending "-s" to the original prefix
      value
    - Set all top-level nodes to have a "config" statement of
      value "false"
    - add an import to the original module (e.g., for typedef
      definitions)
    - modify any imports, used for leafrefs or identityrefs, to
      import the -state version of the module
    - remove any 'typedef' or 'identity' definitions
    - prefix any uses of the typedefs and identities accordingly
    - update leafref and augment paths to use the new "-s" prefix

For me (with any/all hats) the key downside is that we'll need to  rev
this text (again) in the not too distant future, but that we don't have
an alternative as LC on the full solution is still a bit away.

What do people think?  

Lou

On 8/22/2017 3:53 PM, Kent Watsen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Aug 2017 08:17:09 +0200

My preference is to have the guidelines say what people should do,
namely design NMDA models. I would prefer to keep any transition
aspects out of the guidelines. If people want to include transition
aspects, it should be in the appendix (i.e., easy to remove / ignore
later on).

I understand that there is a timing issue. The question is what you
mean with "NMDA solution makes it to publication (request)". If you
mean the core NMDA document, this is pretty much in reach and keeping
this guidelines document on hold until then may be an option. If you
mean the complete solution set, including model updates and moving the
protocol extensions in NETCONF to publication request, then this may
take a bit more time.

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Aug 2017 08:07:28 -0400

Juergen,

On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
<[email-masked]> wrote:

> aspects out of the guidelines.

Well, this approach works for those who are deeply enmeshed in netmod
and the IETF, it doesn't help those designing models/solutions during
the current transition period.  IMO we can't forget about this important
class of model developers and users.

> If people want to include transition
I don't see a material difference here.  Either way the document needs
to be updated. See below for a specific proposed wording update.

> protocol extensions in NETCONF to publication request, then this may
I mean the time when implementors can reasonably be told that the old
way has been replaced by a fully defined (and able to be implemented)
NMDA solution.  I think includes both netconf and restconf NMDA
definitions.  I don't think it's reasonable to require implementation of
drafts that are in-flux.

>>     [draft-ietf-netmod-revised-datastores].
remove (a) and re-letter rest of list
>>     immediately be structured to be NMDA-compatible.

Add:
   The remaining options MAY be followed during the time that
   NMDA mechanisms are being defined.  These options will be
   removed in a future update of this document once this definition
   is complete.

Does this work for you?  Moving it to an appendix just makes it harder
for the reader and, again, the document needs to be revised either way
in the future.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Aug 2017 14:58:55 +0200

Lets do it this way then. If we plan to revise this again in ~1 year,
so be it. We started this revision in Feb 2014. ;-)

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Aug 2017 16:38:16 +0000

Just wondering, but is an RFC the appropriate vehicle for this content?  Would a wiki be better?

K.

--

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Aug 2017 09:55:59 -0700

Hi,

I think Lou's text is a good start for the replacement text.
We should finish the details and finish this document.
Ongoing tips and guidelines should go on a wiki.

The IETF cannot declare an official start and stop date for NMDA transition.
The community outside the NETMOD WG has yet to learn or care about NMDA.
Write exactly what you what them to do, as if they have not read the 14000
emails
that provide the context needed to know what "NMDA-compatible" means.

Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Aug 2017 17:19:17 -0400

My view is wikis are fine for folks "in the know" but RFCs are good for
the wide distribution of interoperability standards and information
related to their implementation. 

It seems to me that this is a case of the latter.

Oh, RFCS are also sometimes used to ensure community consensus on IETF
operation.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Aug 2017 14:27:19 -0700

> Oh, RFCS are also sometimes used to ensure community consensus on IETF
This work item is over 3 1/2 years old already.
The feature-creep just doesn't end.

Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Aug 2017 17:52:37 -0400

> The feature-creep just doesn't end.

This is a hugely valid point.  This was the major gating item. If it'll
help I'll make the change as proposed and send you a pull request.

I have heard two other issues:  avoiding submodules and use of common
regex, IMO let's get NMDA and whatever changes we can in in the next
week or two and then restart LC.  (Note Kent is Shepherd)

Lou

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Aug 2017 15:01:22 -0700

> help I'll make the change as proposed and send you a pull request.
OK

> week or two and then restart LC.  (Note Kent is Shepherd)
The regex text looks good. I am not saying the WG does not continue
to come up with new details that would benefit from further clarification.
(The opposite -- the WG will ALWAYS come up with more issues)

If there is a wiki it can be mentioned in 6087bis, and new issues can go to
the wiki.

Lou
Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Aug 2017 18:05:54 -0400

On 8/23/2017 6:01 PM, Andy Bierman wrote:
> If there is a wiki it can be mentioned in 6087bis, and new issues can
> go to the wiki.
>

That's an interesting idea, i.e., replace the contents of the current
6087 bis with one line that says go look at a wiki.  My only reservation
is will this work for other SDOs, e.g., IEEE or BBF produced models?

Lou

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Aug 2017 15:12:46 -0700

> is will this work for other SDOs, e.g., IEEE or BBF produced models?
I did not mean that.
I meant just a note to look to the wiki for new guidelines.
The RFC can be updated every few years.
If wait long enough, then this draft can be held up until YANG 2.0 is done
in 2021. ;-)
For people looking for stable references instead of work-in-progress, the
delays are  too long.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Aug 2017 17:56:57 +0000

I have the same preference.  The suggested text doesn't seem to provide
actual modeling recommendations.  Aren't there details beyond how or when
a module transitions to NMDA that should be mentioned?  For instance, the
text doesn't say anything about how to best locate config false nodes, or
how to handle the case when the value-space for a node's configured and
operational values differ.  Is the plan then to remove this section 
entirely once the NMDA-transition is complete?

As I recall, the main reason why we are not progressing the guidelines 
draft is because we didn't want the short-term text in an RFC.  Putting
essentially the same text into another RFC seems inconsistent.  But,
if this is what people want, I suppose it's better to churn this document
than to introduce a distinct "guidelines" RFC...

K.  // contributor

--

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Aug 2017 11:21:28 -0700

> entirely once the NMDA-transition is complete?

Obviously NMDA cannot be used for objects where the configuration value set
and the operstate value set differ, such as with the interface
admin-status/oper-status.
Do you want a sentence added that says to use config false leafs as needed
within the
configuration entry? A sentence that says operational data is embedded in
the
configuration entry?

> than to introduce a distinct "guidelines" RFC...

6087bis was supposed to be a minor update, not a living draft that doubles
as a YANG tutorial and ongoing issues list.

K.  // contributor
Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Aug 2017 19:11:07 +0000

On 8/25/17, 2:21 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

> and the operstate value set differ, such as with the interface admin-status/oper-status.
> Do you want a sentence added that says to use config false leafs as needed within the
> configuration entry? A sentence that says operational data is embedded in the
> configuration entry?

Yes, and any other general guidelines around using config false.   The text I posted
when starting this thread had some of that.  The original RFC6087 text might have
some more.

> as a YANG tutorial and ongoing issues list.

 ;)

As much as I like RFCs, I think this content would be better served by a Wiki.   If
we were starting for scratch (no RFC6087), then that might make sense but, given
where we are, not so much.  So, I guess we're committed to frequent updates on this
document until YANG settles down.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Aug 2017 12:17:09 -0700

Hi,

I think there should be text about admin-state/oper-state objects.
It is fairly common that the oper-state enums will differ from the
admin-state enums.
The only linkage between these objects is description-stmt text.

Not only does NMDA ignore this linkage problem, it acutally makes it worse.
Look at rfc7223bis for an example.

How does the client know that the get-data result for the
/interfaces/interface/admin-status
leaf in the operational datastore is worthless, and that
/interfaces/interface/oper-status
should be used instead?  What is an NMDA server supposed to return for the
operational
value of admin-status?

Should 6087bis mention that NMDA allows the YANG library to be different on
each datastore?
And that the same module can be different revisions, features, and
deviations on each datastore?
Should the advice to client developers be "Have fun with that."

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Aug 2017 12:31:57 -0700

On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen <[email-masked]> wrote:

>
>
>
>
> On 8/25/17, 2:21 PM, "Andy Bierman" <[email-masked]> wrote:
>
>
>

OK -- I will work on adding in text from -12, your text, and Lou's text.

> document until YANG settles down.

It is better to have as few moving targets (and normative references) as
possible.
YANG modules in an RFC have to conform to a specific version of the YANG
guidelines.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Aug 2017 18:08:28 -0700

Hi,

Here is the proposed rewrite of 4.23.
I changed a few details in the temporary non-NMDA procedure.
This module cannot duplicate the NMDA module as read-only.
Only the top-level config=false nodes that would have been exposed pre-NMDA
need to be present.

4.23.  Operational State

   The management of YANG operational state has been refined over time.
   At first, only data that has a "config" statement value of "false"
   was considered to be operational state.  This data was not considered
   to be part of any datastore, which made YANG XPath definition much
   more complicated.

   YANG operational state is now modeled according to new NMDA, and is
   now conceptually contained in the operational datastore, which also
   includes the operational values of configuration data.  There is no
   longer any need to duplicate data structures to provide separate
   configuration and operational data sections.

   This section describes some data modeling issues related to
   operational state, and guidelines for transitioning YANG data model
   design to be NMDA-compatible.

4.23.1.  Combining Operational State and Configuration Data

   If possible, operational state SHOULD be combined with its associated
   configuration data.  This prevents duplication of key leafs and
   ancestor nodes.  It also prevents race conditions for retrieval of
   dynamic entries, and allows configuration and operational state to be
   retrieved together with minimal message overhead.

   Not NMDA-Compliant:

      container foo {
        ...
      }

      container foo-state {
        config false;
        ...
      }

   NMDA-Compliant:

      container foo {
        ...
        // contains config=true and config=false nodes that have
        // no corresponding config=true object (e.g., counters)
      }

4.23.2.  Representing Operational Values of Configuration Data

   If possible the same data type SHOULD be used to represent the
   configured value and the operational value, for a given leaf or leaf-
   list object.

   Sometimes the configured value set is different than the operational
   value set for that object.  For example, the "admin-state" and
   "oper-state" leafs in [RFC7223].  In this case a separate object MAY
   be used to represent the configured and operational values.

   Sometimes the list keys are not identical for configuration data and
   the corresponding operational state.  In this case separate lists MAY
   be used to represent the configured and operational values.

   If it is not possible to combine configuration and operational state,
   then the keys used to represent list entries SHOULD be the same type.
   The "leafref" data type SHOULD be used in operational state for key
   leafs that have corresponding configuration instances.  The
   "require-instance" statement MAY be set to "false" (in YANG 1.1
   modules only) to indicate instances are allowed in the operational
   state that do not exist in the associated configuration data.

   If all the data model properties are aligned between configuration
   data and operational state, then it can be useful to define the
   configuration parameters within a grouping, and then replicate that
   grouping within the operational state portion of the data model.

       grouping parms {
          // do not use config-stmt in any of the nodes
          // placed in this grouping
       }

       container bar { // bar config can exist without bar-state
         config true;
         uses parms;
       }

       container bar-state {  // bar-state can exist without bar
         status deprecated;
         config false;
         uses parms;
       }

   The need to replicate objects or define different operational state
   objects depends on the data model.  It is not possible to define one
   approach that will be optimal for all data models.

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.  The
   "description" statements for both the configuration and the
   operational state SHOULD be used for this purpose.

4.23.3.  NMDA Transition Guidelines

   YANG modules SHOULD be designed assuming they will be used on servers
   supporting the operational datastore.  With this in mind, YANG
   modules SHOULD define config "false" wherever they make sense to the
   data model.  Config "false" nodes SHOULD NOT be defined to provide
   the operational value for configuration nodes, except when the value
   space of a configured and operational values may differ, in which
   case a distinct config "false" node SHOULD be defined to hold the
   operational value for the configured node.

   The following guidelines are meant to help modelers develop YANG
   models that will maximize the utility of the model with both current
   and new implementations.

   New models and models that are not concerned with the operational
   state of configuration information SHOULD immediately be structured
   to be NMDA-compatible, as described in Section 4.23.1.

   The remaining are options that MAY be followed during the time that
   NMDA mechanisms are being defined.

   (a) Models that require immediate support for the NMDA "origin" meta
   data, such as "in use" and "system created" information, SHOULD be
   structured for NMDA.  A non-NMDA version of these models SHOULD
   exist, either an existing model or a model created either by hand or
   with suitable tools that mirror the current modeling strategies.
   Both the NMDA and the non-NMDA modules SHOULD be published in the
   same document, with NMDA modules in the document main body and the
   non-NMDA modules in a non-normative appendix.  The use of the non-
   NMDA model will allow temporary bridging of the time period until
   NMDA implementations are available.

   (b) For published models, the model should be republished with an
   NMDA-compatible structure, deprecating non-NMDA constructs.  For
   example, the "ietf-interfaces" model in [RFC7223] will be
   restructured as an NMDA-compatible model.  The "/interfaces-state"
   hierarchy will be marked "status deprecated".  Models that mark their
   "/foo-state" hierarchy with "status deprecated" will allow NMDA-
   capable implementations to avoid the cost of duplicating the state
   nodes, while enabling non-NMDA-capable implementations to utilize
   them for access to the operational values.

   (c) For models that augment models which have not been structured
   with the NMDA, the modeler will have to consider the structure of the
   base model and the guidelines listed above.  Where possible, such
   models should move to new revisions of the base model that are NMDA-
   compatible.  When that is not possible, augmenting "state" containers
   SHOULD be avoided, with the expectation that the base model will be
   re-released with the state containers marked as deprecated.  It is
   RECOMMENDED to augment only the "/foo" hierarchy of the base model.
   Where this recommendation cannot be followed, then any new "state"
   elements SHOULD be included in their own module.

4.23.3.1.  Temporary non-NMDA Modules

   A temporary non-NMDA module allows a non-NMDA aware client to access
   operational state from an NMDA-compliant server.  It contains the
   top-level config=false data nodes that would have been defined in a
   legacy YANG module (before NMDA).

   A server that needs to support both NMDA and non-NMDA clients can
   advertise both the new NMDA module and the temporary non-NMDA module.
   A non-NMDA client can use separate "foo" and "foo-state" subtrees,
   except the "foo-state" subtree is located in a different (temporary)
   module.  The NMDA module can be used by a non-NMDA client to access
   the conventional datastores, and the deprecated <get> operation to
   access nested config=false data nodes.

   o  Change the module name by appending "-state" to the original
      module name

   o  Change the namespace by appending "-state" to the original
      namespace value

   o  Change the prefix by appending "-s" to the original prefix value

   o  Add an import to the original module (e.g., for typedef
      definitions)

   o  Retain or create only the top-level nodes that have a "config"
      statement value "false".  These subtrees represent config=false
      data nodes that were combined into the configuration subtree, and
      therefore not available to non-NMDA aware clients.  Set the
      "status" statement to "deprecated" for each new node.

   o  The module description SHOULD clearly identify the module as a
      temporary non-NMDA module

4.23.3.2.  NMDA Module Examples

   Example: Create a New Module

   Create an NMDA-compliant module, using combined configuration and
   state subtrees, whenever possible.

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo-";

       container foo {
         // configuration data child nodes
         // operational value in operational datastore only
         // may contain config=false nodes as needed
       }
    }

   Example: Convert an old Non-NMDA Module

   Do not remove non-complaint objects from existing modules.  Instead,
   change the status to "deprecated".  At some point, usually after 1
   year, the status MAY be changed to "obsolete".

   Old Module:

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo";

       container foo {
         // configuration data child nodes
       }

       container foo-state {
         config false;
         // operational state child nodes
       }
    }

   Converted NMDA Module:

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo-";

       container foo {
         // configuration data child nodes
         // operational value in operational datastore only
         // may contain config=false nodes as needed
         // will contain any data nodes from old foo-state
       }

       // keep original foo-state but change status to deprecated
       container foo-state {
         config false;
         status deprecated;
         // operational state child nodes
       }
    }

   Example: Create a Temporary NMDA Module:

   Create a new module that contains the top-level operational state
   data nodes that would have been available before they were combined
   with configuration data nodes (to be NMDA compliant).

     module example-foo-state {
       namespace "urn:example.com:params:xml:ns:yang:example-foo-state";
       prefix "foo-s";

       // import new or converted module; not used in this example
       import example-foo { prefix foo; }

       container foo-state {
         config false;
         status deprecated;
         // operational state child nodes
       }
    }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Aug 2017 12:11:11 +0200

> Only the top-level config=false nodes that would have been exposed pre-NMDA

Thanks for taking the time to produce detailed text. Some comments
inline.
 
>    The management of YANG operational state has been refined over time.

I think you mean:

  The modeling of operational state with YANG has been refied over time.

>    YANG operational state is now modeled according to new NMDA, and is

I think we do not have the term 'YANG operational state'. Hence:

  Operational state is now modeled using YANG according to ...

>    approach that will be optimal for all data models.

Well, having bar (config true) and bar-state (config false) is what
NMDA tries to avoid. Even in NMDA, bar can exist in <operational>
without having <bar> in say <running>. (Example, no IP addresses
statically configured but IP addresses learned from DHCP or created by
the system.) I am not sure the discussion starting with "If all the
data model properties" is needed.
 
>    supporting the operational datastore.  With this in mind, YANG

It is actually called the 'operational state datastore'.

>    operational value for the configured node.

Perhaps the text needs to say somewhere very clearly that the
operationally used values of configuration objects are part of the
operational state datastore and hence config false nodes SHOULD NOT be
defined to provide the operational value for configuration nodes...

>    models that will maximize the utility of the model with both current

Do we generally talk about YANG modules or YANG models in the guidelines
document? Are these used as synonyms? Just wondering...

>    structured for NMDA.

Not sure I parsed this correctly. What does 'in use' and 'system
created' information refer to? I think in general models should follow
NMDA (once it went through the approval process), no?

>    A non-NMDA version of these models SHOULD

I do not think that it is always a SHOULD to have a non-NMDA model but
then I did not understand the condition of (a). RFC 8194 for instance
is NMDA compatible and this is good enough. If an implementation needs
to expose applied configuration, it will have to implement NMDA.

>          // may contain config=false nodes as needed

Why would the prefix be "foo-" and not just "foo"?
 
>    Do not remove non-complaint objects from existing modules.  Instead,

compliant

>        namespace "urn:example.com:params:xml:ns:yang:example-foo";

"foo-" vs "foo"

>          // operational state child nodes

Perhaps put the examples in separate sections 4.23.3.2, 4.23.3.3,
4.23.3.4 so that they are more clearly separated?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Aug 2017 09:24:17 -0700

>   The modeling of operational state with YANG has been refied over time.

fixed

>   Operational state is now modeled using YANG according to ...
fixed

> data model properties" is needed.
removed "If all the data" .. through groupings example

> It is actually called the 'operational state datastore'.

Except that we never use that term.
It is always called operational datastore when we talk about it in meetings.
Hence, the new NMDA terms section:

 ** NMDA Terms

The following terms are defined in the
Network Management Datastore Architecture
(NMDA) ^I-D.ietf-netmod-revised-datastores^.
and are not redefined here:

- configuration
- conventional configuration datastore (also called conventional datastore)
- datastore
- operational state
- operational state datastore (also called operational datastore)

IMO these alternates should be put in the RD draft since they reflect the
terms we actually use.

> defined to provide the operational value for configuration nodes...

I think the text from Lou is OK.

> document? Are these used as synonyms? Just wondering...

changed models to modules. -- here and several other places

> NMDA (once it went through the approval process), no?

This is from Lou. I just pasted in his text here, but added the origin
metadata part.
See new fix below.

> to expose applied configuration, it will have to implement NMDA.

Please do implement it -- especially the client-side, which got much more
complex
because of NMDA.

I think the first sentence refers to the temporary non-NMDA module.

NEW:

(a) Modules that require immediate support for the NMDA features
SHOULD be structured for NMDA.  A temporary non-NMDA version of these
models SHOULD exist, either an
existing model or a model created either by hand or with
suitable tools that mirror the current modeling strategies.

> >    Do not remove non-complaint objects from existing modules.  Instead,
fixed

> >        namespace "urn:example.com:params:xml:ns:yang:example-foo";

fixed

OK

Andy

> > >> > Obviously NMDA cannot be used for objects where the configuration
> value
> > >> set
> > >>
> > >> > configuration entry? A sentence that says operational data is
> embedded
> > >> in the
> > >>
> > >> > configuration entry?
> > >>
> > >>
> > >>
> > >> As much as I like RFCs, I think this content would be better served
> by a
> > >> Wiki.   If
> > >>

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 14:40:59 -0400

Hi Andy,

> >    retrieved together with minimal message overhead.
I find the inclusion of the non NMDA form in this section a bit
confusing, do you have any objection to dropping the following?

> >         config false;

Thanks,
Lou

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Aug 2017 11:54:09 -0700

> confusing, do you have any objection to dropping the following?
removed

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 14:58:48 -0400

Thanks!

On 8/28/2017 2:54 PM, Andy Bierman wrote:
>
>
> On Mon, Aug 28, 2017 at 11:40 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Aug 2017 21:20:05 +0200

> IMO these alternates should be put in the RD draft since they reflect the

I know that we tend to be sloppy in meetings and often in emails but
in written RFCs (specifications) I would personally prefer to use a
single term.

> suitable tools that mirror the current modeling strategies.

I am not sure about the second SHOULD. I think the temporary non-NMDA
version is more a MAY than a SHOULD. 

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Aug 2017 12:38:41 -0700

> in written RFCs (specifications) I would personally prefer to use a

So change it in the RD draft to the term we actually use "operational
datastore".

> version is more a MAY than a SHOULD.
OK -- changed 2nd SHOULD to MAY

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Aug 2017 21:49:37 +0000

> So change it in the RD draft to the term we actually use "operational datastore".

A lot of effort went into defining the terms.  Having "foo configuration datastore" (not "foo datastore") is really important, because it binds to the term for "configuration".  FWIW, I think that "the operational state datastore" fell out more for symmetry - because it clearly doesn't bind to either "system state" or "applied configuration" ;)

The end of the 'operational state datastore' term says "This datastore is commonly referred to as "<operational>".   And <operational> expands colloquially to "the operational datastore", albeit one may utter the full expansion if desired. 

So, the net-net (I think) is that, in writing, we have <operational> and "the operational state datastore" but, when spoken, we have "operational" and "the operational datastore".

Makes sense?

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Aug 2017 15:26:06 -0700

On Mon, Aug 28, 2017 at 2:49 PM, Kent Watsen <[email-masked]> wrote:

> A lot of effort went into defining the terms.  Having "foo configuration
> datastore" (not "foo datastore") is really important, because it binds to
> the term for "configuration".  FWIW, I think that "the operational state
> datastore" fell out more for symmetry - because it clearly doesn't bind to
> either "system state" or "applied configuration" ;)
>
> The end of the 'operational state datastore' term says "This datastore is
> commonly referred to as "<operational>".   And <operational> expands
> colloquially to "the operational datastore", albeit one may utter the full
> expansion if desired.
>
> So, the net-net (I think) is that, in writing, we have <operational> and
> "the operational state datastore" but, when spoken, we have "operational"
> and "the operational datastore".
>
> Makes sense?
>
>
rather confusing, since this <operational> notation is not defined anywhere.
If the term 'state' added any value, we would use it more often, but I will
change the text just to get done faster.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Aug 2017 23:01:46 +0000

> rather confusing, since this <operational> notation is not defined anywhere.

A bit, yes.  I tried to get the <foo> syntax defined in RD, but my co-authors
didn't think it was necessary.  I acquiesced as well just to move things along.

> change the text just to get done faster.

Exactly.

K.