Subject: [netmod] datastore-specific constraints

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Dec 2018 15:33:15 +0100

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

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 12 Dec 2018 15:52:47 +0100

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-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 12 Dec 2018 15:23:52 +0000

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.

Thanks,
Rob

On 12/12/2018 14:52, Jan Lindblad wrote:
>> On 12 Dec 2018, at 15:33, Ladislav Lhotka <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 12 Dec 2018 15:30:56 +0000

Hi,

Should it be ignored or rejected?

Also not keen in foo-operational, since it’s in contradiction to NMDA’s goals.

Regards,
Reshad.

From: netmod <[email-masked]> on behalf of Jan Lindblad <[email-masked]>
Date: Wednesday, December 12, 2018 at 9:53 AM
To: Ladislav Lhotka <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] datastore-specific constraints

Lada,

leaf foo {
 ...

Best Regards,
/jan

On 12 Dec 2018, at 15:33, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

leaf auto-foo {
 type boolean;
 default true;

Thanks, Lada

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

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 12 Dec 2018 16:36:09 +0100

Reshad,

> Should it be ignored or rejected?

Ignored, IMO. A rejection policy would bring little value, but lead to complications for clients and servers alike.

> Also not keen in foo-operational, since it’s in contradiction to NMDA’s goals.

+1

/jan

>> On 12 Dec 2018, at 15:33, Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi,
>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Dec 2018 16:52:30 +0100

On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> 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.
> 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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Dec 2018 18:12:57 +0100

> "foo-operational" needed?

I think the later is the cleanest solution if the modeler insists on
the when statement, even if people do not like this. We discussed
cases like this a lot, the common example was Ethernet auto
negotiation of link speeds. And as far as I recall, the conclusion was
to handle these corner cases properly by defining additional suitable
config false objects that always report the negotiated value in use.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2018 09:51:39 +0100 (CET)

> 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 [...]

   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 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Dec 2018 10:58:43 +0100

On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> you
> but

According to the definition of SHOULD and MAY in RFC 2119, this sentence
contradicts itself.

>    "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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2018 11:24:54 +0100 (CET)

> According to the definition of SHOULD and MAY in RFC 2119, this sentence

It should probably have been "may" then...?

> It is nice to see "when" listed among semantic constraints.

Yeah, I was a bit surprised that this sentence classifies "when" as a
semantic constraint...

> Note, however, that
> all data trees (despite my hefty protests in the past).

Note that also uniqueness of keys is listed in 8.1 as true all data
trees, but relaxed by 8342.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Dec 2018 11:48:52 +0100

On Thu, 2018-12-13 at 11:24 +0100, Martin Bjorklund wrote:
> > > > > 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
> > > > > the intention is that the constraints in <operational> should
> generally
> > > apply
> > > > Another option could be that "must" constraints on config data do not
> apply
> > > in

With a sound definition of syntactic and semantic constraints, we could state
that data in <operational>

- MUST satisfy syntactic constraints
- SHOULD satisfy semantic constraints that apply to config=false data

(semantic constraints on config=true data are checked before the data get into
<running>)

> Yeah, I was a bit surprised that this sentence classifies "when" as a

Every truth will eventually be revealed. :-) 

> trees, but relaxed by 8342.

Well, section 8.1 only says this about keys:

   o  All key leafs MUST be present for all list entries.

Their uniqueness is not mentioned (an omission?). Anyway, it is IMO a typical
semantic constraint that shouldn't be enforced in <candidate>, but due to the
limitations of the NETCONF protocol it has to be.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Dec 2018 11:08:42 +0000

Hi Lada,

> According to the definition of SHOULD and MAY in RFC 2119, this sentence

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Dec 2018 12:58:47 +0100

> which it is reasonable for the SHOULD to be violated.

MAY means "truly optional" (e.g. "because the vendor feels that it enhances the
product"). Combining different RFC2119 terms is generally problematic.

Lada

> > > > Anyway, the logic of my example could then be implemented using "must".
> > > > I
> > > agree

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 13 Dec 2018 18:13:42 -0800

Hi -

On 12/13/2018 3:58 AM, Ladislav Lhotka wrote:
....
> product"). Combining different RFC2119 terms is generally problematic.

 From the perspective of the receiver, there is no difference.
"Good reasons" tend to be subjective and there's generally no
way for the receiver to know whether those conditions are true
for the sender or its implementer.

Consequently, for the code processing a protocol stream, a "SHOULD"
describing that stream is equivalent to a "MAY", since it only
says that the behaviour described is *possible*, and, that under
conditions to which the receiver will not be privy, other things
may happen.

Randy