Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00

From: t.petch <[email-masked]>
Date: Mon, 7 Apr 2014 10:54:43 +0100

Kent

draft-ietf-netconf-rfc5539bis-03 had 

         +--rw tls
            +--rw enabled?     boolean

which draft-kwatsen-netconf-server-00 lacks.  Why?

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Apr 2014 16:47:34 +0000

>which draft-kwatsen-netconf-server-00 lacks.  Why?

This must've gotten dropped do to the draft-kwatsen-netconf-server model
having a didn't structure, but as the original 5539 had no model, I think
that it's a fair topic for discussion.

Personally, I'd rather stick with the original intent of presence
containers: "enabled" if-and-only-if  "configured".  We're using these
"enabled" configuration nodes as a substitute to having XML attributes for
metadata describing the node's enablement, such as is described in
draft-kwatsen-conditional-enablement.  At the time that draft was written,
there didn't seem to be much interest, but then later I heard some support
from Andy.  My thinking is to dust it off and get it going again, maybe
something simpler this time.

Again, I'm thinking that it's OK, and even a good thing, to just use the
original intent of presence containers for now, knowing that a more
complete solution (which is clearly in demand) is right around the corner.
 What do people think?  Is there support to work on
draft-kwatsen-conditional-enablement?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 18:53:34 +0200

The enabled with a default true leaf allows to disable a transport
without having to remove all config. There is currently no other
mechanism available in RFCs to do this and hence this pattern may
still have value.

/js

On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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: Andy Bierman <[email-masked]>
Date: Tue, 8 Apr 2014 10:16:23 -0700

> mechanism available in RFCs to do this and hence this pattern may
Is this something that can be fixed in YANG 1.1?
You are right -- there is no way to disable some sub-tree except
to add an ad-hoc "enabled" leaf somewhere.

IMO this is wrong because it distorts must/when expressions.
Objects that have dependencies on specific nodes within the
disabled subtree will appear to be active and valid.

The YANG validation statements are only supposed to consider
active configuration. leafref can only use valid instances of the path
object.

   leaf A {
      type leafref { path /B/C; }
   }

   leaf AA {
      type string;
      when "/B/enabled and /B/C = 'foo'";
   }

   list B {
      key C;
      leaf enabled { type boolean; }
      leaf C { type string; }
   }

The A leaf will be valid even for key entries in list B
that are disabled.  This is broken.  The when-expr in AA
has to account for the enabled flag or it would be broken.

IMO we are making a big mistake by using this approach instead
of the Conditional Enablement approach in Kent's draft.
The server has to treat the entire subtree as removed from the config,
not use an ad-hoc flag in the data model.

> /js

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Apr 2014 17:21:20 +0000

Right, and if we agree to that in principle, then it seems that we should stop polluting our data-models with the "enabled" flag.   That way we have less number of data-models to clean up later, if we even can update them without breaking backwards-compatibility.

Thanks,
Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 8, 2014 1:16 PM
To: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>, "t.petch" <[email-masked]<mailto:[email-masked]>>, NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00

On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
The enabled with a default true leaf allows to disable a transport
without having to remove all config. There is currently no other
mechanism available in RFCs to do this and hence this pattern may
still have value.

The YANG validation statements are only supposed to consider
active configuration. leafref can only use valid instances of the path object.

   leaf A {

   leaf AA {
      type string;

   list B {
      key C;

/js

Andy

On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Apr 2014 19:49:08 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 
> Right, and if we agree to that in principle, then it seems that we should stop
> polluting our data-models with the "enabled" flag.  That way we have less
> number of data-models to clean up later, if we even can update them without
> breaking backwards-compatibility.

While I do agree that "conditional enablement" would be best, I think
we have to design our data models for the mechanisms we have today.

In order for us to make use of conditional enablement in our data
models (i.e., NOT add enabled leafs), it has to be mandatory to
implement, probably part of the protocol itself.

So, for this particular issue, I think we should add the enabled
leaf.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Apr 2014 11:51:06 -0700

> So, for this particular issue, I think we should add the enabled
As long as we continue to do nothing, each short-term decision
will be the same (use enabled leaf).  If the leaf is written in
a protocol-specific way, that is a word-around (e.g. foo server will
not send or receive foo packets if set to 'false'), but confusing.

At a high-level we have to decide what nodes returned in a <get-config>
for the running configuration really mean.  What about leafrefs, etc.
where YANG validation rules ignore the enabled leaf?

The SMIv3/EoS effort failed spectacularly many years ago, in part
because of features that needed some data modeling work and
some protocol work to accomplish.  Neither WG would fix anything,
blaming it on the inability to control the other WG. We should avoid
the same procedural excuses.

The "enabled flag" is an ad-hoc flawed solution, although it is
mandatory-to-implement
and mandatory-to-use.  I agree we need a mandatory solution, but a good
solution.

Andy