Re: [netmod] Query about usage of local-name() in YANG XPATH expressions

2016-03-28 Thread Andy Bierman
Hi,

I added a new issue in github about open vs. closed systems

https://github.com/netmod-wg/rfc6087bis/issues/32

Andy


On Mon, Mar 28, 2016 at 12:59 PM, William Ivory <wiv...@brocade.com> wrote:

> Hi Andy,
>
>
>
> Thanks.  So if we have a tightly controlled set of YANG files, and
> restrict usage to a specific use case where we have a set of nodes across
> multiple modules with the same name, we should be fine.
>
>
>
> William
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* 28 March 2016 20:51
> *To:* William Ivory <wiv...@brocade.com>
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] Query about usage of local-name() in YANG XPATH
> expressions
>
>
>
> Hi,
>
>
>
> This was raised as a concern by Lada (see netmod WG email arourd July 2014)
>
>
>
> The issue is that the expression breaks module containment and will match
>
> depending on what other YANG modules are known to the YANG compiler.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Sat, Mar 26, 2016 at 3:08 AM, William Ivory <wiv...@brocade.com> wrote:
>
> Hi,
>
>
>
> From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is
> noted about the use of the XPATH local-name() function:
>
>
>
>The 'local-name' function SHOULD NOT be used to reference local names
>
>outside of the YANG module defining the must or when expression
>
>containing the 'local-name' function.  Example of a local-name
>
>function that should not be used:
>
>
>
>   /*[local-name()='foo']
>
>
>
> However, no explanation is given as to why this is a bad idea.  We have a
> specific use case where local-name() would appear to allow us to massively
> simplify some rather cumbersome must expressions, but I wanted to check I’m
> not missing some ‘gotcha’ here.  Is it simply that relying on a common node
> name across multiple modules is generally a bad design as it ties the
> modules together, or is there more to it?  If so, then in our case this is
> a reasonable restriction.
>
>
>
> Thanks,
>
>
>
> William
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8=VZGB2NkaE9--68moPlgZM_ag1CgKvjJqSwwZ2iw1gio=7Ju95XbNKdlg4tPZG9ahSeMHUT_lqGFPtiZxcXevTxw=>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] Query about usage of local-name() in YANG XPATH expressions

2016-03-28 Thread William Ivory
Hi Andy,

Thanks.  So if we have a tightly controlled set of YANG files, and restrict 
usage to a specific use case where we have a set of nodes across multiple 
modules with the same name, we should be fine.

William

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: 28 March 2016 20:51
To: William Ivory <wiv...@brocade.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Query about usage of local-name() in YANG XPATH 
expressions

Hi,

This was raised as a concern by Lada (see netmod WG email arourd July 2014)

The issue is that the expression breaks module containment and will match
depending on what other YANG modules are known to the YANG compiler.


Andy



On Sat, Mar 26, 2016 at 3:08 AM, William Ivory 
<wiv...@brocade.com<mailto:wiv...@brocade.com>> wrote:
Hi,

From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is noted 
about the use of the XPATH local-name() function:

   The 'local-name' function SHOULD NOT be used to reference local names
   outside of the YANG module defining the must or when expression
   containing the 'local-name' function.  Example of a local-name
   function that should not be used:

  /*[local-name()='foo']

However, no explanation is given as to why this is a bad idea.  We have a 
specific use case where local-name() would appear to allow us to massively 
simplify some rather cumbersome must expressions, but I wanted to check I’m not 
missing some ‘gotcha’ here.  Is it simply that relying on a common node name 
across multiple modules is generally a bad design as it ties the modules 
together, or is there more to it?  If so, then in our case this is a reasonable 
restriction.

Thanks,

William


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8=VZGB2NkaE9--68moPlgZM_ag1CgKvjJqSwwZ2iw1gio=7Ju95XbNKdlg4tPZG9ahSeMHUT_lqGFPtiZxcXevTxw=>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] Query about usage of local-name() in YANG XPATH expressions

2016-03-28 Thread Andy Bierman
Hi,

This was raised as a concern by Lada (see netmod WG email arourd July 2014)

The issue is that the expression breaks module containment and will match
depending on what other YANG modules are known to the YANG compiler.


Andy



On Sat, Mar 26, 2016 at 3:08 AM, William Ivory  wrote:

> Hi,
>
> From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is
> noted about the use of the XPATH local-name() function:
>
>The 'local-name' function SHOULD NOT be used to reference local names
>outside of the YANG module defining the must or when expression
>containing the 'local-name' function.  Example of a local-name
>function that should not be used:
>
>   /*[local-name()='foo']
>
> However, no explanation is given as to why this is a bad idea.  We have a
> specific use case where local-name() would appear to allow us to massively
> simplify some rather cumbersome must expressions, but I wanted to check I’m
> not missing some ‘gotcha’ here.  Is it simply that relying on a common node
> name across multiple modules is generally a bad design as it ties the
> modules together, or is there more to it?  If so, then in our case this is
> a reasonable restriction.
>
> Thanks,
>
> William
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod