On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <[email protected]> wrote:
> > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > > Hi Lada,
> > > I basically agree with Jan's suggestion.
> > > I don't think that I would use a when statement for this scenario since
> you
> > > want a leaf to report the operational value that is in effect, and one of
> the
> > > aims of NMDA is to try and get the configured and operational value onto
> the
> > > same path wherever possible.
> > > But, I think that the question about validity of must statements is more
> > > interesting. RFC 8342 states that these can be violated in operational,
> but
> > > the intention is that the constraints in <operational> should generally
> apply
> > > (but never be actually checked by the server). In this case, it might be
> > > useful to be able to annotate a must statement to indicate that it only
> > > applies to configuration data and not operational data.
> >
> > Another option could be that "must" constraints on config data do not apply
> in
> > <operational>, whereas constraints on "config false" data serve as binding
> > guidelines for implementors.
>
> Not sure what "binding guideline" means, but note that RFC 8342 says
> for <operational>:
>
> <operational> SHOULD conform to any constraints specified in the data
> model, but given the principal aim of returning "in use" values, it
> is possible that constraints MAY be violated [...]
According to the definition of SHOULD and MAY in RFC 2119, this sentence
contradicts itself.
>
> Only semantic constraints MAY be violated. These are the YANG
> "when", "must", "mandatory", "unique", "min-elements", and
> "max-elements" statements; and the uniqueness of key values.
It is nice to see "when" listed among semantic constraints. Note, however, that
in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true in
all data trees (despite my hefty protests in the past). So this is really weird.
Lada
>
> It would be useful with a YANG statement that indicates when the
> modeller's intention is that a constraint doesn't apply to
> <operational>. For now, this can be indicated in the description
> statement, for example:
>
> leaf foo {
> when "../auto-foo = 'false'" {
> description
> "This when expression does not apply to <operational>.";
> }
> ...
> }
>
>
>
> /martin
>
>
>
> >
> > Anyway, the logic of my example could then be implemented using "must". I
> agree
> > though that ignoring the configured value if auto-foo is true may be
> preferable.
> >
> > Lada
> >
> >
> > > Thanks,
> > > Rob
> > >
> > > On 12/12/2018 14:52, Jan Lindblad wrote:
> > > > Lada,
> > > >
> > > > Maybe you could just skip the when and explain the behavior in the
> > > > description? E.g.
> > > >
> > > > leaf foo {
> > > > ...
> > > > description "Foo controls bla, bla.
> > > > Any configured value will be ignored when auto-foo is true.";
> > > > }
> > > >
> > > > Best Regards,
> > > > /jan
> > > >
> > > > > On 12 Dec 2018, at 15:33, Ladislav Lhotka <[email protected]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > in some cases, constraints expressed with "when" or "must" may only be
> > > > > intended for configuration datastores. A typical example is an
> > > > > auto-negotiable parameter:
> > > > >
> > > > > leaf auto-foo {
> > > > > type boolean;
> > > > > default true;
> > > > > description "If true, parameter 'foo' will be auto-negotiated.";
> > > > > }
> > > > > leaf foo {
> > > > > when "../auto-foo = 'false'";
> > > > > ...
> > > > > }
> > > > >
> > > > > This means that if auto-foo is true, it is impossible to configure the
> > > > > foo parameter. However, even with auto-foo = true, it is desirable to
> > > > > see the auto-negotiated value in <operational>, so, ideally, the
> "when"
> > > > > constraint should not apply in <operational>.
> > > > >
> > > > > How can this logic be modelled under NMDA? Is an extra leaf
> > > > > "foo-operational" needed?
> > > > >
> > > > > Thanks, Lada
> > > > >
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [email protected]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
