"Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> writes:
> Hi all, > > This immediately made me worried about all such xxx-ref constructs in YANG > that I've seen in a few modules. > > But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343 > I see that this error is avoided because interface-ref is fully qualified > right ? > RFC 8407, sec 4.2: o The local module prefix SHOULD be used instead of no prefix in all path expressions. This is particularly important for typedefs that are intended to be used in other modules. Lada > typedef interface-ref { > type leafref { > path "/if:interfaces/if:interface/if:name"; > } > description > "This type is used by data models that need to reference > interfaces."; > } > > Jason > > From: netmod <[email protected]> On Behalf Of Jernej Tuljak > Sent: Wednesday, February 9, 2022 3:47 AM > To: Fengchong (frank) <[email protected]>; > [email protected] > Subject: Re: [netmod] question about unprefixed path in leafref > > > On 08/02/2022 03:40, Fengchong (frank) wrote: > Hi all, > > In RFC7950 sec6.4.1 says: > > > o Names without a namespace prefix belong to the same namespace as > > the identifier of the current node. Inside a grouping, that > > namespace is affected by where the grouping is used (see > > Section > 7.13<https://datatracker.ietf.org/doc/html/rfc7950#section-7.13>). Inside a > typedef, that namespace is affected by > > where the typedef is referenced. If a typedef is defined and > > referenced within a grouping, the namespace is affected by where > > the grouping is used (see Section > 7.13<https://datatracker.ietf.org/doc/html/rfc7950#section-7.13>). > > But in module openconfig-aft-network-instance: > > augment "/oc-ni:network-instances/oc-ni:network-instance/" + > "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" { > > description > "Add leaves that require referencing of a network instance to the > operational state parameters of a next-hop within the AFT for IPv4 > unicast."; > > uses aft-nexthop-ni-state; > } > > grouping aft-nexthop-ni-state { > description > "Operational state parameters relating to a next-hop which reference a > network instance."; > > leaf network-instance { > type oc-ni:network-instance-ref; > description > "The network-instance within which the next-hop should be resolved. > When this leaf is unspecified, the next-hop is resolved within > the local instance."; > } > } > > The typedef network-instance-ref is defined in module > openconfig-network-instance: > > typedef network-instance-ref { > type leafref { > path "/network-instances/network-instance/config/name"; > } > description > "A re-usable type that can be referenced within other > modules that references a network instance."; > } > > The leafref’s path is a unprefixed path. > > So, according RFC7950, the typedef network-instance-ref is referenced in leaf > network-instance, and the leaf is inside grouping aft-nexthop-ni-state, and > this grouping is used in augment > "/oc-ni:network-instances/oc-ni:network-instance/" + > "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" > So the path "/network-instances/network-instance/config/name" ‘s namespace is > module openconfig-aft-network-instance’s namespace. But in fact, there is no > node called network-instances with namespace: > http://openconfig.net/yang/aft/ni. > > Is it incorrect? > > I try to use pyang to compile it, and no error is reported. > > These modules are written in YANG 1.0, therefore RFC6020 applies, not > RFC7950. This was one of the cases where RFC6020 was unclear, hence new text > you quote from RFC7950. If you change openconfig-network-instance to YANG > 1.1, pyang should report an error for that "path" when the "typedef" gets > used in openconfig-aft-network-instance. > > Jernej > > > > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > 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! > > > > > _______________________________________________ > > netmod mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
