Re: [Teas] [netmod] Issue with path statements in RPC

Martin Björklund <mbj+ietf@4668.se> Mon, 10 August 2020 09:43 UTC

Return-Path: <mbj+ietf@4668.se>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3133B3A1472; Mon, 10 Aug 2020 02:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=vMSiZUBH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=elK1SmoA
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 X8ACVPbU4xYG; Mon, 10 Aug 2020 02:43:28 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC19E3A12FE; Mon, 10 Aug 2020 02:43:27 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4D3E15C00B8; Mon, 10 Aug 2020 05:43:27 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 10 Aug 2020 05:43:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= cKdLzcGpaYZrTNUCmjblOo8sh7oahzBFT3VdcE73V14=; b=vMSiZUBHIQI7v7Fs i8T6dSETuNJ0pcSxQOwoqz23pUflrpOjBSsPbuiXuDHEb6eLOQ+ReRrlhj0yowXh eG1HL9P9A6FLFyWwXcOfyI/bFbE3w8T6HbE5Jj4BUoeyf8vvXyx3qHWs3GHy76k0 92tvO6Q8QURs76JGYajgAnzwNvFf78AfAogfP+XzdmJtN3lx7jwmkwlLVew+QUkh s4goA5FXcPUV1j+QfCIw/qpNHekTsyLCTtCObW6kfc/H17KrNUdOQ/XCX5AknQcY kOzu+F6UAhc2OkFkF9AX9WIe4vNrmKg8/5MpOhwO7ExkcMsyz+++il9e80qyBswl bc1XVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=cKdLzcGpaYZrTNUCmjblOo8sh7oahzBFT3VdcE73V 14=; b=elK1SmoAXYeLLtvZPSvlHVhGMqrwC5fwRjXnKnvEAlWrvKMmkZ8t41h1w ZpkbaoWUkmI+aH5NSHP8dWgT3iC1plBm93+Z0NGxADN03cbcRTyZAdNFc0TWbwaX NvhrhnuyrvhqYvZRvImQarzX24JoP7ExJQNVNSIvMcnCG7xitag72S6aegMr3OBF T28aXspeiTBWxT6aO2XONrqCO1LJWwpWuL61B8TadkI/8pzI5KpSUlAu8ZPHq3sP g+ev9ePrKBtwZQBqCnWHrVQplzr74UPnGu8BOhgg4Sj3A1tsP+YkHc4/jzBhOzO1 ZQh4RekAxbccTqFP75+TFv3mTzu9Q==
X-ME-Sender: <xms:vhYxX3lfPHqeyqgTQwSD5jh4bce4w0Gqe88n6qDY6gPyOqCbWi5-Tg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkeekgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtleenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehgfelheffgedtfeffleffud egffduueeuveejjeduhfeltdevvdfgtdfffeejvdenucffohhmrghinhepihgvthhfrdho rhhgpdhgihhthhhusgdrtghomhdphhhurgifvghirdgtohhmnecukfhppeduheekrdduje egrdegrdeggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:vhYxX614_YJXloSz5CaD2CU3RD_FEcTVqLHjHME0SKdakgo8sGSDmA> <xmx:vhYxX9onNL07FB_Nb37e6rw76xXMZVVvvAZtouv6qO8pBVtijCvHiw> <xmx:vhYxX_k_3nhY6dQig2rDb3ru0p_d3euMnEqEbxX6s7f89Io45LI77Q> <xmx:vxYxXy-mSBl4_0jEzyXdXBBC_GE1qlz8Ursyf9AcOmfCp2r9PmkflQ>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id F40E230600B4; Mon, 10 Aug 2020 05:43:25 -0400 (EDT)
Date: Mon, 10 Aug 2020 11:43:24 +0200 (CEST)
Message-Id: <20200810.114324.1967866904848316834.id@4668.se>
To: ietfc@btconnect.com
Cc: Italo.Busi@huawei.com, teas@ietf.org, netmod@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <AM7PR07MB62482A5ECDECE168A9335545A0440@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <9c365f0d89ae4f9c9054eed5c4730d59@huawei.com> <20200810.112423.1011687310446809904.id@4668.se> <AM7PR07MB62482A5ECDECE168A9335545A0440@AM7PR07MB6248.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/o7UiUv06a9KOUITowQuMEsp7OJg>
X-Mailman-Approved-At: Mon, 10 Aug 2020 08:55:15 -0700
Subject: Re: [Teas] [netmod] Issue with path statements in RPC
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 09:43:30 -0000

tom petch <ietfc@btconnect.com> wrote:
> From: netmod <netmod-bounces@ietf.org> on behalf of Martin Björklund <mbj+ietf@4668.se>
> Sent: 10 August 2020 10:24
> 
> Italo Busi <Italo.Busi@huawei.com> wrote:
> > We have found some issues with RPC XPaths when developing the YANG
> > code for
> > https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
> >
> > As discussed during the TEAS WG session in IETF 108, this issue has
> > been raised on pyang github:
> > https://github.com/mbj4668/pyang/issues/662
> >
> > It was also suggested to check with Netmod WG what should be the
> > correct behavior according to RFC7950.
> >
> > The following code is accepted by pyang 1.75 but not by pyang 2.1:
> >
> >     type leafref {
> >       path "/te:tunnels-path-compute/te:input/"
> >          + "te:path-compute-info/"
> >         + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> >     }
> >
> > The following code instead is accepted by pyang 2.1 but not by pyang
> > 1.7.5:
> >
> >     type leafref {
> >       path "/te:tunnels-path-compute/"
> >          + "te:path-compute-info/"
> >         + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> >     }
> 
> The leafref path is an XPath expression, which operates on the data
> tree (instance data).  The "input" node is not present in the instance
> data / data tree.  See section 6.4.1 of RFC 7950.
> 
> So the latter path (as verfied by pyang 2.1) is correct.
> 
> <tp>
> Martin,
> 
> Thank you for the clarifications.  Just looking at the first issue, what gave me pause was section 9.9; the path statement is used to identify the referred leaf in the schema tree and 'input' is in the schema tree.  But I can see that 6.4.1 overrides that implication.

Hmm, yes that text can certainly be improved.  9.9.2 however refers to
6.4.1.


/martin



> 
> Tom Petch
> 
> 
> 
> > Moreover the following when statement, which is quite useful to
> > constraint which information is provided by the RPC output based on
> > some attributes in the RPC input, is accepted by pyang 1.7.5 but not
> > accepted by pyang 2.1;
> >
> >   augment "/te:tunnels-actions/te:output" {
> >     description
> >       "Augment Tunnels Action RPC input with path delete result";
> >
> >     container path-computed-delete-result {
> >       when "derived-from-or-self(../../te:input/te:action-info/"
> >          + "te:action, 'tunnel-action-path-compute-delete')";
> >       description "Path Delete RPC output";
> >       leaf-list path-compute-transaction-id {
> >         type string;
> >         description
> >           "The list of the transaction-id values of the
> >            transient states that have been successfully deleted";
> >       }
> >     }   // container path-computed-delete-result
> >   }   // path-delete rpc output
> >
> >
> > Could you please help us to understand what is the correct behavior?
> >
> > In case the correct behavior is the one of pyang 2.1, our
> > understanding is that it would not be possible to provide in YANG when
> > constraints for the data nodes in the RPC output depending on specific
> > values of the data nodes used in the RPC input. Therefore these
> > constraints should be specified as behavior and implemented in the
> > back-end.
> >
> > Is our understanding correct?
> 
> Yes, this is correct.  It is not possible to refer to the
> corresponding "input" instance data in the XPath expressions for the
> "output".
> 
> 
> /martin
> 
> 
> >
> > Thanks for your help
> >
> > Sergio and Italo (on behalf of co-authors/contributors)
> >
> > Italo Busi
> > Principal Optical Transport Network Research Engineer
> >
> > [cid:image001.jpg@01D5AC11.9575BB40]
> > ____________________________________________________________________
> >
> > Huawei Technologies Italia S.r.l.
> > Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090
> > Segrate (MI)
> > Tel: +39 345 4721946 - Mobile:
> > Italo.busi@huawei.com<mailto:Italo.busi@huawei.com>
> >
> > __________________________________________________________________________________
> > Huawei Technologies Italia S.r.l. is a company registered in Italy at
> > the Company Registration Office of Milan, with registered number
> > 04501190963 and equity capital €3,000,000 fully paid up, whose
> > registered office is in Milan, Via Lorenteggio 240, Tower A, 20147
> > Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by
> > Huawei Technologies Cooperatief U.A.
> > CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT10010000006521 -
> > Batteries and Accumulators Registry No. IT12050P00002839.
> > ________________________________________________________________________________________________________________________
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address
> > is listed above. Any use of the information contained herein in any
> > way (including, but not limited to, total or partial disclosure,
> > reproduction, or dissemination) by persons other than the intended
> > recipient(s) is prohibited. If you receive this e-mail in error,
> > please notify the sender by phone or email immediately and delete it!
> > Thank you.
> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection
> > Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs
> > you that the personal data contained in this email will be collected
> > and treated for the acquisition of information preliminary to the
> > conclusion of contracts, for the definition of the contractual
> > relationship, as well as for the fulfillment of legal requirements
> > related to civil, tax and accounting law or any other legal obligation
> > to which Huawei may be subject. Personal data will not be subject to
> > disclosure and spread unless otherwise required by law. Huawei will
> > take appropriate security measures to protect personal data against
> > loss, misuse disclosure or destruction of the information. Personal
> > Data held may be transferred to countries outside the European Union,
> > however Huawei Italia has put in place appropriate safeguards for the
> > transfer of personal data to third countries by adopting the standard
> > data protection clauses of the EU Commission. Personal Data are kept
> > for a period necessary for the fulfillment of contract obligations
> > unless otherwise required by law. You can exercise your rights under
> > Art. 15 and following of the GDPR (i.e. right of access,
> > rectification, erasure, restriction, portability, object) by
> > contacting Huawei at this email address:
> > dataprotection@huawei.com<mailto:dataprotection@huawei.com> or through
> > the following channel:
> > www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>st>. You
> > have also the right to lodge a complaint with the competent
> > supervisory authorities. If you need any further information or have
> > any queries on how Huawei process your personal data, please send an
> > email to our Data Protection Officer at
> > dpo@huawei.com<mailto:dpo@huawei.com>.The Data Controller is Huawei
> > Technologies Italia S.r.l. with registered office in Milan, Via
> > Lorenteggio 240 Tower A, 20147.
> >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod