Hi,
I'm replying to this message thread since the content of this message
closely relates to what Kristian was asking back then, which seems more
convenient compared to starting another thread.
I've noticed that the YANG modules defined by RFC 9132 [1] do not appear
to comply with RFC 8791. There are several cases where leafref "path"
statements in those modules reference configuration/state data nodes
from within "sx:structure" definitions:
- ietf-dots-signal-channel@2021-09-02 at line 221 (enclosed in a
grouping that gets used within an "sx:structure" at line 585)
- ietf-dots-signal-channel@2021-09-02 at line 232 (enclosed in a
grouping that gets used within an "sx:structure" at line 585)
- ietf-dots-signal-control@2021-09-02 at line 88 (within
"sx:structure-augment" targeting the same "sx:structure" as above)
In all cases, the expression's target is "/data-channel:dots-data",
which does not exist in the conceptual document that is used as the
context for those path-stmt definitions. There is only one possible
document element for an arbitrary "sx:structure" instance document,
which in this case is "/dots-signal:dots-signal". This means there can
never be an absolute "path" statement not starting with
"/dots-signal:dots-signal" defined within this specific "sx:structure".
In addition to the text I had already quoted in my previous reply, these
modules do not appear to be in line with the following text from RFC 8791:
The XPath document element is the extension statement itself,
such that the child nodes of the document element are
represented by the data-def-stmt substatements within this
extension. This conceptual document is the context 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
Most likely at least one errata needs to be reported for RFC 9132, but
I'd like more eyes on this to confirm.
[1] - https://datatracker.ietf.org/doc/rfc9132/
Jernej
On 09/04/2025 12:57, Jernej Tuljak wrote:
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://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]
To unsubscribe send an email [email protected]
_______________________________________________
netmod mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
