Re: [netmod] Question on intefaces-state model
Alex Campbell <Alex.Campbell@Aviatnet.com> Tue, 13 June 2017 22:35 UTC
Return-Path: <Alex.Campbell@Aviatnet.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EA2131A34 for <netmod@ietfa.amsl.com>; Tue, 13 Jun 2017 15:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdpNHhWb1H5 for <netmod@ietfa.amsl.com>; Tue, 13 Jun 2017 15:35:25 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A9F131A2C for <netmod@ietf.org>; Tue, 13 Jun 2017 15:35:25 -0700 (PDT)
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Question on intefaces-state model
Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQCzfdcAAAJubIAAMwoVAAABUkEA//+9NFA=
Date: Tue, 13 Jun 2017 22:35:23 +0000
Message-ID: <1497393323725.99784@Aviatnet.com>
References: <AM2PR07MB06272FF9E8BA4D00B0669F9794CE0@AM2PR07MB0627.eurprd07.prod.outlook.com> <20170612172141.GA52797@elstar.local> <CABCOCHSK1h4HQ4LgkYd_Lxp3JYzxYBMmCka64_-iVjq2N_PR7g@mail.gmail.com> <m2d1a7iutf.fsf@nic.cz>, <CABCOCHS3cqEvyLaRGdk5T2TpkXGOjd_wEii-pREo3cpRwjiHHg@mail.gmail.com>
In-Reply-To: <CABCOCHS3cqEvyLaRGdk5T2TpkXGOjd_wEii-pREo3cpRwjiHHg@mail.gmail.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_149739332372599784Aviatnetcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vTnIg5SMUIlBVGvUSXXwEF7-7S0>
Subject: Re: [netmod] Question on intefaces-state model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jun 2017 22:35:28 -0000
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. 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. Alex ________________________________ From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com> Sent: Wednesday, 14 June 2017 7:30 a.m. To: Ladislav Lhotka Cc: netmod@ietf.org Subject: Re: [netmod] Question on intefaces-state model On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>> wrote: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> writes: > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> 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 >> netmod@ietf.org<mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- [netmod] Question on intefaces-state model Bogaert, Bart (Nokia - BE/Antwerp)
- Re: [netmod] Question on intefaces-state model Juergen Schoenwaelder
- Re: [netmod] Question on intefaces-state model Andy Bierman
- Re: [netmod] Question on intefaces-state model Vladimir Vassilev
- Re: [netmod] Question on intefaces-state model Ladislav Lhotka
- Re: [netmod] Question on intefaces-state model Andy Bierman
- Re: [netmod] Question on intefaces-state model Alex Campbell
- Re: [netmod] Question on intefaces-state model Ladislav Lhotka
- Re: [netmod] Question on intefaces-state model Robert Wilton
- Re: [netmod] Question on intefaces-state model Robert Wilton
- Re: [netmod] Question on intefaces-state model Juergen Schoenwaelder
- Re: [netmod] Question on intefaces-state model Ladislav Lhotka
- Re: [netmod] Question on intefaces-state model Robert Wilton
- Re: [netmod] Question on intefaces-state model Bogaert, Bart (Nokia - BE/Antwerp)
- Re: [netmod] Question on intefaces-state model Igor Bryskin
- Re: [netmod] Question on intefaces-state model Igor Bryskin
- Re: [netmod] Question on intefaces-state model Vladimir Vassilev