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

[Andy Bierman <[e-mail]>]

On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder <
[e-mail]> 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.
>
>
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


>
> On Tue, Apr 08, 2014 at 04:47:34PM +0000, Kent Watsen wrote:
> >
> >
> >
> > >draft-ietf-netconf-rfc5539bis-03 had
> > >
> > >         +--rw tls
> > >            +--rw enabled?     boolean
> > >
> > >which draft-kwatsen-netconf-server-00 lacks.  Why?
> > >
> > >Tom Petch
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>