Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 08:54:47 +0100 (CET)

Hi,

"Acee Lindem (acee)" <[email-masked]> wrote:
> 
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen <[email-masked]> wrote:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >><[email-masked] on behalf of [email-masked]> wrote:
> >> 
> >>> 
> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
> >>>><[email-masked]> wrote:
> >>>> 
> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >>>> 
> >>>>> I hope that nobody disagrees that the operational state design and
> >>>>>how 
> >>>>> to structure the models are the two blocking factors to publish YANG
> >>>>> models. If you disagree or don't see this, let me know, I should
> >>>>> communicate better.
> >>>> 
> >>>> Even if it may spoil your day, I disagree that there is a blocking
> >>>> factor that should stop us from publishing models. There seem to be
> >>>> ways to address the requirements without having to block all work or
> >>>> to redo what that we have published. But sure, if you make it a
> >>>> blocking factor, it will be one.
> >>> 
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >> 
> >> 
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
> 
> I’d like to point out that we also have the requirement to allow retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state.

I don't agree with the conclusion that changes are needed due to this
requirement.

Solution #1 ("openconfig") requires changes to handle applied config.
Solution #2 ("kent's") does not.

Both solutions #1 and #2 use separate nodes for derived state.

It might appear as #1 and #2 are very different in their handling of
derived state, since #1 put all config false nodes directly under the
config true nodes, whereas #2 in some cases have a top-level
"xxx-state" config false node.

But in fact #2 allows the solution in #1 as one special case.  The
reason that RFC 7223 has a separate list for derived state interfaces
is to allow for non-configured interfaces to be monitored.  If this
was not a requirement, all config false nodes could (would) have been
defined in the config true interface list.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Jan 2016 12:57:55 +0000

Hi Martin, et al, 

>defined in the config true interface list.

I see that this is discussed in the latest version of
draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
the operational state in the same subtree as the config state if it would
not exist if not configured. Is “appropriate” a recommendation?

   Careful consideration needs to be given to the location of
   operational state data.  It can either be located within the
   configuration subtree for which it applies, or it can be located
   outside the particular configuration subtree.  Placing operation
   state within the configuration subtree is appropriate if the
   operational values can only exist if the configuration exists.

However, we currently have many YANG models in progress where the config
and state trees are separate subtrees. If we all agree with the opstate
requirement for derived state, perhaps it is time to get the word out and
modify these models.

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Jan 2016 14:10:20 +0100

> On 08 Jan 2016, at 13:57, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Martin, et al, 
> 

I don't think that we all agree. :-)

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2016 15:30:01 +0100

> I don't think that we all agree. :-)

+1

And in many cases, state can exist without config being present. It
would be truely backwards if systems would start to hide operational
state in order to comply to some new overarching rules to make work
with operational state 'easier'.

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