Re: [yang-doctors] when statement of an optional leaf? Does it make an optional leaf?

"Jean Quilbeuf -X (jquilbeu - LIANEO at Cisco)" <jquilbeu@cisco.com> Tue, 17 March 2020 18:19 UTC

Return-Path: <jquilbeu@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 020F93A0A03 for <yang-doctors@ietfa.amsl.com>; Tue, 17 Mar 2020 11:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.59
X-Spam-Level:
X-Spam-Status: No, score=-9.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=i1lOK+xC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ag4CPGeu
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 FvabDayRGeRP for <yang-doctors@ietfa.amsl.com>; Tue, 17 Mar 2020 11:19:09 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175923A09FE for <yang-doctors@ietf.org>; Tue, 17 Mar 2020 11:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9586; q=dns/txt; s=iport; t=1584469149; x=1585678749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JK92Vm7oZVt4PKwNSwT+rF5vZhsdjcQoRMkXYXnHcwM=; b=i1lOK+xCQXF+0E0ba2eclLG2lruwuyDugDS1O3rGP9Zm70boRL+RwC04 blcr3QOHGXwSsKPKopnUtyjfmYWinf6G2ccmZsj3xaXA75BRZ751Ed5P0 2I+Dichedo6CNJUf06LoClHO962MY4AUbPoU9sv4XMv+YrE42Otx+XcwA Y=;
IronPort-PHdr: 9a23:VQCg1hHhPaGrDzDSwAyV7J1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+efzzci0+FslffFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CxAAA0FHFe/4cNJK1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKoQWg0UDinSCX5gYgUKBEANUCQEBAQwBARgLCgIEAQGEQwIXgX0kOBMCAwEBCwEBBQEBAQIBBQRthVYMhWMBAQEBAwEBEBEEDQwBASwLAQsEAgEGAhEEAQEDAhEVAgICJQsVCAgCBAENBQgagwWCSgMuAQ6SA5BnAoE5iGJ1fzOCfwEBBYFDQYMsGIIMAwaBDiqMLhqCAIFYgk0+gmQBAQIBAYEaST2CUjKCCiKQcYYbmTcKHoIeh1aPPZtGhGiKHokCklwCBAIEBQIOAQEFgWkigVhwFTuCbFAYDY4dDBcVgzuFFIVBdAKBJ4suLYE1XwEB
X-IronPort-AV: E=Sophos;i="5.70,565,1574121600"; d="scan'208";a="457436014"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2020 18:19:07 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 02HIJ7it028848 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Mar 2020 18:19:08 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Mar 2020 13:19:07 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Mar 2020 13:19:06 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Mar 2020 14:19:06 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yx6olA6r7JIZOeqC6ronzNSfQcQDtUnULpPIlaKf1ON84Z3soUnuCurHNPNyKAj5Pqzn81HWSbvgKcm4wBHCRp6f9CC93m1P9iJMW2gRFyfJstTxg8Cc1H2ILsTEfuvXnFFD8r6pG5GCyb8vmiwYUewy9JxmeWwLLrR00gy72K/wELt/1p0VUUMmep9mOxU/zvGedfP5F1M6hd9XteGUe/9XqcSYdXyk65UpaULZFgwjhEyKio79LE5GjAkbuqp939nZf4adjFlF25FZpcxmnc45WHo/mSA8ErYJOUy3yxRJwhURdIKuTSPP320egbwV5AonITWlpvoEXMtweCKTQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JK92Vm7oZVt4PKwNSwT+rF5vZhsdjcQoRMkXYXnHcwM=; b=BP8K0tClxbEjUmXjJxg7W+cg0JTuX7hFbKDcbhTXq79V65Quu1RoiAmmv4V0w7ah0eCFgz45c/KuY5jra46xKGgKZ+JbCgy5dr04JGhQUatt6j1LV3c8CAEBSQHT2N0aNxutwje5NmtrAx0knXENDDbyEGMZ+8dpLIDLp+gIlntJumb7pn6Lq7HY4YrAOmP+EVNWUa+n2A65W2KpNgpR/zxHzbfJgPbRK7h5WEParuZb5pyh8QLpiTR5hy5GDz8wG/7H8mKwsLBO/xXmjPc5na79jMaaGznPbjsdoUOm1k1QC87QZAwXOMkLS39xmsEd1XNY8dNJivFUN4Kb0aw/mg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JK92Vm7oZVt4PKwNSwT+rF5vZhsdjcQoRMkXYXnHcwM=; b=Ag4CPGeuLbj0zB9DqAYqxtw/IzMU0AnyYq08YpsisUNvNBivbkFnzX9uPh+xi++dATzlvzVGdHcJ/Tmsxs0/DQ0zQ0itN5q32hxVqnCLybGAY/PJ3t6LUCRyC/lGWDk1h22P4FWAGHQy0F4lLm5XoTaaTCogvtAEyJbnjDGjbPk=
Received: from BN7PR11MB2609.namprd11.prod.outlook.com (2603:10b6:406:b1::26) by BN7PR11MB2660.namprd11.prod.outlook.com (2603:10b6:406:b2::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.21; Tue, 17 Mar 2020 18:19:05 +0000
Received: from BN7PR11MB2609.namprd11.prod.outlook.com ([fe80::bccd:3886:13be:fb8]) by BN7PR11MB2609.namprd11.prod.outlook.com ([fe80::bccd:3886:13be:fb8%7]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020 18:19:05 +0000
From: "Jean Quilbeuf -X (jquilbeu - LIANEO at Cisco)" <jquilbeu@cisco.com>
To: "Benoit Claise (bclaise)" <bclaise@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org>, YANG Doctors <yang-doctors@ietf.org>
CC: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Thread-Topic: [yang-doctors] when statement of an optional leaf? Does it make an optional leaf?
Thread-Index: AQHV/G0tB++LGbRm4EuHMPrV/4nfDqhNCROAgAAMDACAAAC0EA==
Date: Tue, 17 Mar 2020 18:19:05 +0000
Message-ID: <BN7PR11MB260950B33CFC2147056C5C4BD9F60@BN7PR11MB2609.namprd11.prod.outlook.com>
References: <50f02dc5-850d-90c5-9cad-48a062fe686c@cisco.com> <87imj2opwc.fsf@nic.cz> <c5f81ba6-31df-2114-9568-32c941d117de@cisco.com>
In-Reply-To: <c5f81ba6-31df-2114-9568-32c941d117de@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jquilbeu@cisco.com;
x-originating-ip: [2001:420:c0c0:1007::273]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc835ec1-ecd9-4b88-2d92-08d7ca9fad7c
x-ms-traffictypediagnostic: BN7PR11MB2660:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN7PR11MB266026BB74D137A2C2408A04D9F60@BN7PR11MB2660.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(199004)(6506007)(53546011)(316002)(7696005)(5660300002)(110136005)(107886003)(4326008)(71200400001)(52536014)(186003)(966005)(478600001)(66556008)(64756008)(66476007)(66574012)(86362001)(66446008)(8676002)(9686003)(55016002)(81166006)(76116006)(66946007)(81156014)(8936002)(33656002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2660; H:BN7PR11MB2609.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1URobam9lOk9SUr6tv6g174eqwZppE0E1y2X8NIbTlYJMg0wv18tS5/nR6tigTvShT1h9MZLu9eWeXOeSHw1Sab1AiAIDT1KWWyJJxxCOQCAmICSwvPne84om1tg1TY4/VAMuZlgZINzTsqPN70ez7TOHIE4ERGRgPRRWGuDhAdi7Sy3HIGCaK9fwGQVV/eJC7fstu4WE4hRwFNnDELElVLFTNf8MWVMXvcx6R9Q/HOrMKBxyc3WGr4rCiqf+cSUdgXoxrgaZ5S7Pn+C6TB5qOs2FbBUxdInRKudGUR/5jzqHzQ7lQNpIETl2v/JA1Rvx0JQRvcUm/XX6vIG9i2qtJRNSlXYyvE2CRQY0kT+LK40qf4gP7uB+14UHcWAXRttdDrie5Fhikvk+zxtKsH4qQMn1ovWjpsPZ2P5470eJsor9+1eGarhCvAmysAG8/usxvnq7yWX+BFR0hMT3QsTem3trkKMS3rEccTV59sNOzZNeR+QSqVzTAGbDSEI68G3SraW44jNMJyhL0rMYMUzkQ==
x-ms-exchange-antispam-messagedata: bvnMLbdZ2dJuMVI5n3CYlrfOHhuQKv0NWG7Lq734OjUurQO3FLnQlqyGaf4dGRpyhwJ6gnFuaQ5/qiYCXf8SJm3TwLXQWo1+8+xiMhzQCrfN7Oz79pVLV3x5lnEX/vLRbAkXuuOmCA5VyxbgPpa7Ent6GS4DwrlsNn7zHiry8pI=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dc835ec1-ecd9-4b88-2d92-08d7ca9fad7c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 18:19:05.3692 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZwqghUX9QMl3xoVbcD42ODOKOd7L4iWlTGcJdAQAC0KDCh2XHTPlla6Go9XiJVGWGxIlzaqR695yvcjcuGawtQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2660
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/yDxv1gRJDlVWnQTqU0r97nHeoPo>
Subject: Re: [yang-doctors] when statement of an optional leaf? Does it make an optional leaf?
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 17 Mar 2020 18:19:18 -0000

Hi Benoît, all,
To clarify:
by "it works" I meant that instances that do not specify a "maintenance-contact" nor a "under-maintenance" (which then default to false) become valid for ConfD after the modification. Did not try pyang !

Best,
Jean



-----Original Message-----
From: Benoit Claise <bclaise@cisco.com> 
Sent: Tuesday, March 17, 2020 7:08 PM
To: Ladislav Lhotka <lhotka@nic.cz>; Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org>; YANG Doctors <yang-doctors@ietf.org>
Cc: Eric Vyncke (evyncke) <evyncke@cisco.com>; Jean Quilbeuf -X (jquilbeu - LIANEO at Cisco) <jquilbeu@cisco.com>
Subject: Re: [yang-doctors] when statement of an optional leaf? Does it make an optional leaf?

Hi Lada,

Thanks for the XPath correction.
When I apply this change, I still see the maintenance-contact as mandatory.

$ pyang -f tree ietf-service-assurance.yang
module: ietf-service-assurance
   +--ro assurance-graph-version?       yang:counter32
   +--ro assurance-graph-last-change?   yang:date-and-time
   +--rw subservices
      +--rw subservice* [type id]
         +--rw type                                identityref
         +--rw id                                  string
         +--ro last-change? yang:date-and-time
         +--ro label?                              string
         +--rw under-maintenance?                  boolean
         +--rw maintenance-contact                 string

I guess the validation is not clever enough to combine "mandatory true" 
and Xpath (when "../under-maintenance='true'") from maintenance-contact with the optional under-maintenance leaf ... to conclude that maintenance-contact is actually optional.

Regards, Benoit
> Hi Benoit,
>
> "maintenance-contact" may remain mandatory - due to its default value, "under-maintenace" is always present, as far as XPath evaluation is concerned.
>
> But because of this, your when expression probably doesn't have the 
> effect that you expect: it will always be true. I think it needs to be 
> changed to
>
>      when "../under-maintenance = 'true'";
>
> Lada
>
> Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org> writes:
>
>> YANG doctors,
>>
>> $ pyang -f tree  ietf-service-assurance.yang
>> module: ietf-service-assurance
>>     +--ro assurance-graph-version?       yang:counter32
>>     +--ro assurance-graph-last-change?   yang:date-and-time
>>     +--rw subservices
>>        +--rw subservice* [type id]
>>           +--rw type                                identityref
>>           +--rw id                                  string
>>           +--ro last-change?                        yang:date-and-time
>>           +--ro label?                              string
>>           +--rw under-maintenance?                  boolean
>>           +--rw maintenance-contact string <===============================
>>           +--rw (parameter)?
>>           |  +--:(service-instance-parameter)
>>           |     +--rw service-instance-parameter
>>           |        +--rw service?         string
>>           |        +--rw instance-name?   string
>>           +--ro health-score?                       uint8
>>           +--rw symptoms
>>           |  +--ro symptom* [start-date-time id]
>>           |     +--ro id                     string
>>           |     +--ro health-score-weight?   uint8
>>           |     +--ro label?                 string
>>           |     +--ro start-date-time        yang:date-and-time
>>           |     +--ro stop-date-time?        yang:date-and-time
>>           +--rw dependencies
>>              +--rw dependency* [type id]
>>                 +--rw type               -> /subservices/subservice/type
>>                 +--rw id                 -> 
>> /subservices/subservice[type=current()/../type]/id
>>                 +--rw dependency-type?   identityref
>>
>> The YANG modules comes from
>> https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assuranc
>> e-yang/
>> Have a look at
>> https://raw.githubusercontent.com/YangModels/yang/ecb622b214e59c5f631
>> 2e915d4d65823a6485852/experimental/ietf-extracted-YANG-modules/ietf-s
>> ervice-assurance@2020-01-13.yang
>>
>> The leafs in question:
>>
>>             leaf under-maintenance {
>>               type boolean;
>>               default false;
>>               description
>>                 "An optional flag indicating whether this particular subservice is under
>>                 maintenance. Under this circumstance, the subservice symptoms and the
>>                 symptoms of its dependencies in the assurance graph should not be taken
>>                 into account. Instead, the subservice should send a 'Under Maintenance'
>>                 single symptom.
>>
>>                 The operator changing the under-maintenance value must set the
>>                 maintenance-contact variable.
>>
>>                 When the subservice is not under maintenance any longer, the
>>                 under-maintenance flag must return to its default value and
>>                 the under-maintenance-owner variable deleted.";
>>             }
>>             leaf maintenance-contact {
>>      when "../under-maintenance";
>>               type string;
>>               mandatory true;
>>               description
>>                 "A string used to model an administratively assigned name of the
>>                 resource that changed the under-maintenance value to 'true.
>>
>>                 It is suggested that this name contain one or more of the following:
>>                 IP address, management station name, network manager's name, location,
>>                 or phone number. In some cases the agent itself will be the owner of
>>                 an entry. In these cases, this string shall be set to a string
>>                 starting with 'monitor'.";
>>             }
>>
>> In case of a leaf (maintenance-contact) with a when statement 
>> pointing to an optional leaf (under-maintenance), should the leaf
>> (maintenance-contact) be marked as optional in the tree output?
>>
>> Regards, Benoit
>> _______________________________________________
>> yang-doctors mailing list
>> yang-doctors@ietf.org
>> https://www.ietf.org/mailman/listinfo/yang-doctors