IETF Logo Mail Archive

Re: [yang-doctors] question regarding conditional/optional statements

"Acee Lindem (acee)" <acee@cisco.com> Mon, 21 August 2017 17:33 UTC

Return-Path: <acee@cisco.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05651323C9 for <yang-doctors@ietfa.amsl.com>; Mon, 21 Aug 2017 10:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 vgLcYtV3pjbO for <yang-doctors@ietfa.amsl.com>; Mon, 21 Aug 2017 10:33:35 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EEF1323C0 for <yang-doctors@ietf.org>; Mon, 21 Aug 2017 10:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1503336815; x=1504546415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h4lJyr1vdRTj59hXfZqrENEeritKBZd4C3Sub0PFaqI=; b=UCMCF/mq2BED10uVqmJwJmuGPlmsr/j0FJ168n6sLsGiYfPkohLwR7yk RNW93qrxOSBgohnlFFoifBnPwvu9KntsF8l5yC2MiF7nYgSb4QBl5Wd0b xdiegaTMaFAiIT0DGFdFES6BL1nh/usA0IiXTpMvaqKMMyIKnxLof8mhf A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DRAAB8GJtZ/4kNJK1bAxkBAQEBAQEBAQEBAQcBAQEBAYNaZIEVB4NwihuQFoFulh6CEiELhRsCGoN2PxgBAgEBAQEBAQFrKIUYAQEBAQIBAQEhEToLBQkCAgEIDgIIAgImAgICGQwLFRACBAENBRuKDggQrzyCJotdAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBBoIdggKGVoRzFwomgkyCQh8FoE8ClECSXpYfAR84gQp3FUmHGnaJUoEPAQEB
X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208";a="283651014"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2017 17:33:34 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7LHXYeJ025000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 17:33:34 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 21 Aug 2017 13:33:33 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 21 Aug 2017 13:33:33 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Norm Strahle <nstrahle@juniper.net>
CC: "Aseem Choudhary (asechoud)" <asechoud@cisco.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, Ing-Wher Chen <Ing-Wher_Chen@jabil.com>
Thread-Topic: [yang-doctors] question regarding conditional/optional statements
Thread-Index: AdMWuspFVk5k9TDdRCeshA4HU2pVBgAfV2wAAAZRrAAAAQt5gAAUPP0AAAGZewAAJZZHAACgCPQA///ARQA=
Date: Mon, 21 Aug 2017 17:33:33 +0000
Message-ID: <D5C09135.C2737%acee@cisco.com>
References: <BN1PR0201MB0833B05FB5307BDEF2E8E3F5C3820@BN1PR0201MB0833.namprd02.prod.outlook.com> <20170817050647.apfeuvfhfw23ws6n@elstar.local> <BCE95ECB-360D-46E0-B062-371931C0F46A@tail-f.com> <20170817083739.u4vfbtkm34vf5utw@elstar.local> <DC062E7E-7422-4037-82E4-52B17422B33E@juniper.net> <CABCOCHQJOBXrYLntdg_7iL3wqy9Fkcd10f0ArwPJUNKo9dZAVQ@mail.gmail.com> <DM2PR0501MB15024D3A6AA8F654C1C7B418CF800@DM2PR0501MB1502.namprd05.prod.outlook.com> <20170821172128.ftogpej4jifxbt7m@elstar.local>
In-Reply-To: <20170821172128.ftogpej4jifxbt7m@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BC023794F635EB468C589E86E1A23A89@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/7BMS6q6bveUSa0yznXT3QToY7CI>
Subject: Re: [yang-doctors] question regarding conditional/optional statements
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Aug 2017 17:33:38 -0000


On 8/21/17, 1:21 PM, "yang-doctors on behalf of Juergen Schoenwaelder"
<yang-doctors-bounces@ietf.org on behalf of
j.schoenwaelder@jacobs-university.de> wrote:

>On Fri, Aug 18, 2017 at 12:59:10PM +0000, Norm Strahle wrote:
>> Hey folks, Appreciate all the feedback.  We discussed yesterday among
>>diffserv-ietf modelers yesterday and had a couple comments:
>> 
>> 
>> ·       We liked explicit statements (deviations, features, flag-bits)
>>rather than implicit – i.e. option 5 – of vendors leaving unsupported
>>leaves out of containers
>> 
>> ·       We think if-features or the “bit” flag mechanism are better
>>than deviations, as it at least allows clients to anticipate up front
>>that some items may not be supported.
>
>A decent implementation will expect deviations, deviations are always
>possible. I think there is a circular argument here, which boils down
>to "we do not want to use deviations because we do not want to process
>deviations".
> 
>> ·       One advantage of using the “bit” flag mechanism – i.e. option 2
>>- over features is that this allows a vendor to specify per-interface
>>what is supported.  What features a vendor supports for diffserv is very
>>hardware dependent and may vary from interface to interface within a
>>single device. A device may have multiple types and generations of line
>>cards, and thus, the types of stats supported will be different. The
>>bit-flag mechanism allows a device to reflect that to the client
>>explicitly.
>>
>
>As long as we talk about non-mandatory counters, simply not reporting
>counters that do not exist seems to be the most simple solution.

This is exactly what we are doing in many Routing YANG models.


> If you want to tell clients upfront that a counter will never exist, use
>the deviation mechanism. This is why we have it.

I would think a client could ascertain that a counter is not supported if
it is not returned.

Thanks,
Acee 



>
>/js
>
>-- 
>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/>
>
>_______________________________________________
>yang-doctors mailing list
>yang-doctors@ietf.org
>https://www.ietf.org/mailman/listinfo/yang-doctors

v2.23.0 | Report a Bug | By Email