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

Benoit Claise <bclaise@cisco.com> Tue, 17 March 2020 18:08 UTC

Return-Path: <bclaise@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 DF9E53A09DF for <yang-doctors@ietfa.amsl.com>; Tue, 17 Mar 2020 11:08:13 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 99DKvecIF9Gj for <yang-doctors@ietfa.amsl.com>; Tue, 17 Mar 2020 11:08:07 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E77C3A09DB for <yang-doctors@ietf.org>; Tue, 17 Mar 2020 11:08:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6273; q=dns/txt; s=iport; t=1584468487; x=1585678087; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vdBtx8/u8qkdjVlyztq6zjKrsBlVLvaIxzBQNHr9m6I=; b=S/XCKV4A3rCEd8aVQ4i1XVeD3Xpdr80a4Smm4580URadVduU1aIIrSNv KIFLad4vu+gFYiKFyxOA+Yq624SPwVpl6JZ8OY4fJlvyK2VCvwP0sWeAQ wGXycBcxH7kSet1/QynTMdeF709ThV/dw/vcOK7U6QfDECeMrhwbfRlEg s=;
X-IronPort-AV: E=Sophos;i="5.70,565,1574121600"; d="scan'208";a="24437497"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2020 18:08:00 +0000
Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) (authenticated bits=0) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPSA id 02HI7wv0030653 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2020 18:08:00 GMT
To: Ladislav Lhotka <lhotka@nic.cz>, Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org>, YANG Doctors <yang-doctors@ietf.org>
Cc: Eric Vyncke <evyncke@cisco.com>, "Jean Quilbeuf -X (jquilbeu - LIANEO at Cisco)" <jquilbeu@cisco.com>
References: <50f02dc5-850d-90c5-9cad-48a062fe686c@cisco.com> <87imj2opwc.fsf@nic.cz>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <c5f81ba6-31df-2114-9568-32c941d117de@cisco.com>
Date: Tue, 17 Mar 2020 19:07:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <87imj2opwc.fsf@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Authenticated-User: bclaise
X-Outbound-SMTP-Client: 10.55.221.38, ams-bclaise-nitro5.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/mDCIozo5cTwmstaI96v4_47XcK8>
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:08:15 -0000

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-assurance-yang/
>> Have a look at
>> https://raw.githubusercontent.com/YangModels/yang/ecb622b214e59c5f6312e915d4d65823a6485852/experimental/ietf-extracted-YANG-modules/ietf-service-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