Re: [netmod] Issue with path statements in RPC
tom petch wrote:
> From: netmod on behalf of Martin Björklund
>
> Sent: 10 August 2020 10:24
>
> Italo Busi 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.
>
>
> 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.b...@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. IT1001006521 -
> > Batteries and Accumulators Registry No. IT12050P2839.
> >
> > 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
Re: [netmod] Issue with path statements in RPC
From: netmod on behalf of Martin Björklund
Sent: 10 August 2020 10:24
Italo Busi 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.
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.
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.b...@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. IT1001006521 -
> Batteries and Accumulators Registry No. IT12050P2839.
>
> 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
Re: [netmod] Issue with path statements in RPC
Italo Busi 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.
> 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.b...@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. IT1001006521 -
> Batteries and Accumulators Registry No. IT12050P2839.
>
> 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
