Re: [netmod] datastore-specific constraints

[Robert Wilton <[e-mail]>]

Hi Lada,

On 13/12/2018 09:58, Ladislav Lhotka wrote:
> On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
>> Ladislav Lhotka <[e-mail]> 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.

I don't actually see the contradiction here.

- SHOULD can be violated if there are good reasons to do so (otherwise 
it is a MUST)
- The MAY, and its associated condition, explains some conditions under 
which it is reasonable for the SHOULD to be violated.

Thanks,
Rob


>
>>     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 <[e-mail]> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> -- 
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>