On 14/06/2017 09:28, Ladislav Lhotka wrote:
On 14 Jun 2017, at 00:35, Alex Campbell <[email protected]> wrote:
Presumably a device is free to not implement an optional config=false node if
that node would never be returned in a response anyway - as this will make no
externally visible difference.
That's my view, too. However, this reasoning works if the parent container is
being retrieved but it is not very clear what is supposed to happen if the
client asks explicly for that optional parameter. This looks like a gap in the
architecture – most of the time, YANG pretends to be something like a schema
language in that it describes constraints on a valid data tree but conformance
issues like what parameters a server needs to implement are something different.
It would surely do the same thing as if a client requested any node in a
YANG data tree that doesn't exist.
RESTCONF has special semantics if a GET request is for a specific leaf
rather than a parent container, but I just regard this as a mistake in
the specification (i.e. the "restconf default handling" thread on the
NETCONF alias).
However, if the model states or implies that the node is present under certain
conditions (for example, the node is always present for Ethernet ports), and
the device can meet those conditions (i.e. it has an Ethernet port), then the
device must implement the node or it does not conform to the model.
Right, this could be written in a description, but I've been assuming it is not
the case.
Lada
Rob
Alex
From: netmod <[email protected]> on behalf of Andy Bierman
<[email protected]>
Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: [email protected]
Subject: Re: [netmod] Question on intefaces-state model
On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <[email protected]> wrote:
Andy Bierman <[email protected]> writes:
On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
[email protected]> wrote:
On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia -
BE/Antwerp) wrote:
We have a question regarding the statistics container as defined in the
interfaces-state model. This container defines one mandatory leaf
(discontinuity-time) while all other leafs are optional. What is the
rationale behind this leaf being mandatory and not an optional field?
It does not make a lot of sense to return a discontinuity-time value and
no
counters if none of the counters are relevant for a specific interface.
Another alternative could be to add, via a deviation, a when clause to
the
container indicating for which ifType(s) the container is (or is not)
present. But that would lead to not supporting the IETF interfaces model
to
the full extent.
The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.
The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
means
an <rpc-reply> must contain an instance of the mandatory leaf.
I don't think it is that confusing. RFC 7950 defines what a valid data
tree means and "mandatory" are among the constraints.
I agree though that in terms of a management protocol it means different
things for config true and false data, but this is true also for default
values and maybe other YANG concepts as well.
Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes. Only if-feature can make a node
optional to implement.
I don't think this interpretation is supported by any text in the YANG
spec. State data nodes that are optional needn't be implemented.
RFC 7950, sec 5.6 (Conformance) does not support your interpretation.
It defines basic behavior, optional (via features), and deviations as the only
mechanisms affecting conformance.
Lada
Andy
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
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, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka, 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
