Thank you for your clarification!
________________________________
From: Jernej Tuljak <[email protected]>
Sent: Wednesday, April 9, 2025 12:57 PM
To: Kristian Sallberg (krisallb) <[email protected]>; [email protected]
<[email protected]>
Subject: Re: [netmod] RFC8791: Leafref in sx:augment-structure referencing node
outside the sx:structure
Hi,
that "path" statement should be reported as an error due to the following text
in RFC 8791:
The XPath document element is the augmented extension
statement itself, such that the child nodes of the document
element are represented by the data-def-stmt substatements
within the augmented 'structure' statement.
The context node of the 'augment-structure' statement is
derived in the same way as the 'augment' statement, as defined
in Section 6.4.1 of [RFC7950]. This conceptual node is
considered the context node for the following YANG statements:
- must-stmt
- when-stmt
- path-stmt
- min-elements-stmt
- max-elements-stmt
- mandatory-stmt
- unique-stmt
- ordered-by
- instance-identifier data type
While RFC 7950 allows multiple (document) root node children in its repurposed
XPath model [1], it is clear (enough) that there can only ever be one such
child in the case of each "sx:structure"/"sx:augment-structure". The term
"document element" refers to this child and is defined in [XPATH]. Though this
could have been stated in clearer terms within RFC text. RFC 8791 does not list
[XPATH] as a normative reference, it is only listed as such in RFC 7950 (a
normative reference of RFC 8791).
If XPath expressions used within "sx:structure"/"sx:augment-structure"
definitions would be able to target data nodes in configuration and operational
state, RFC 8791 would need to state this explicitly somehow with something like
the following, which for example applies to "notification" definitions in RFC
7950:
o If the XPath expression is defined in a substatement to a
"notification" statement, the accessible tree is the notification
instance, all state data in the server, and the running
configuration datastore. If the notification is defined on the
top level in a module, then the root node has the node
representing the notification being defined and all top-level data
nodes in all modules as children. Otherwise, the root node has
all top-level data nodes in all modules as children.
There is no such text. This would also not be in line with the intent of
"sx:structure", as described in Section 1 of RFC 8791 [2], which among other
things says this:
There is no assumption that a YANG data structure can only be used as a
top-level abstraction, and it may also be nested within some other data
structure.
[1] https://datatracker.ietf.org/doc/html/rfc7950#section-6.4
[XPATH] https://www.w3.org/TR/1999/REC-xpath-19991116/#root-node
[2] https://datatracker.ietf.org/doc/html/rfc8791#name-introduction
Jernej
On 04/04/2025 09:03, Kristian Sallberg (krisallb) wrote:
Looking for guidance regarding this case. I interpret RFC8791 as it allows (or
at least does not explicitly forbid) the YANG embedded in this github issue.
What's your take?
https://github.com/CESNET/libyang/issues/2375
[https://opengraph.githubassets.com/9fc8c3621cfb4570f5d79a591c3c91247fb0a519facb24449c3daba662cb21e9/CESNET/libyang/issues/2375]<https://github.com/CESNET/libyang/issues/2375>
yanglint can't find absolute path leafref target when defined within
sx:augment-structure · Issue #2375 ·
CESNET/libyang<https://github.com/CESNET/libyang/issues/2375>
Reproducible with: yanglint 3.7.8 This YANG should be valid AFAICT but yanglint
can't find the leafref's target: module example { yang-version 1.1; namespace
"ex:ample"; prefix example; import ietf...
github.com
Best regards,
Kristian
_______________________________________________
netmod mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
