From: netmod <[email protected]> on behalf of Ladislav Lhotka <[email protected]> Sent: 10 February 2022 15:58
"Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> writes: > 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. <tp> I cannot recall which I-D triggered it but this point was hammered home, at least to me, some time back, a year or two perhaps, and I have looked out for it ever since. It was probably a TEAS I-D that gave different results with different validators. Tom Petch 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
