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

[Kent Watsen <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 8, 2014 1:16 PM
To: Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>, Kent Watsen <[e-mail]<mailto:[e-mail]>>, "t.petch" <[e-mail]<mailto:[e-mail]>>, NetConf <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00




On Tue, Apr 8, 2014 at 9:53 AM, Juergen Schoenwaelder <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf