> On 14 Jun 2017, at 11:21, Robert Wilton <[email protected]> wrote: > > > > 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.
So you are saying that one server can return the parameter but another may report "404 Not Found", correct? > > 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). Defaults are another can of worms. If we have an optional config false parameter with a default defined in YANG and the server doesn't implement the parameter (and hence doesn't send it), can the client assume that the server actually has the default value? Lada > > >> >>> 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 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
