[netmod] Re: Feedback on "YANG Libraries Feature Comparison" (IETF 126) — from the yangkit author

[Kent Watsen <[e-mail]>]

Regarding "validating anydata payload against an associated schema context", I don't understand how this is possible, as there is no standard published for doing such a thing, and therefore there can be no expectation on tooling to support it.

Please recall that the "yang-anydata-validation" document was accidentally adopted before, but currently stands in the DEAD state.  See this mail archive message <https://mailarchive.ietf.org/arch/msg/netmod/ZT4qiwO_Qn6A1vPbJ7M56flrrkE/> and the document's Datatracker state <https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-anydata-validation/>.

Kent


> On Jul 24, 2026, at 2:53 PM, chong feng <[e-mail]> wrote:
> 
> Hi Vivek,
> 
> Thank you for the detailed clarification. The discussion is useful because it also highlights some challenges in defining fair and meaningful evaluation criteria for YANG libraries.
> 
> Regarding the points you clarified:
> 
> Anydata validation
> 
> I agree that the test results depend heavily on the definition of "validation support".
> 
> From my understanding of RFC 7950, anydata represents an unknown set of nodes that can be modeled with YANG. Therefore, the semantic correctness of an anydata payload can only be verified when the corresponding schema context is available.
> 
> Without a schema context, an implementation can only preserve and manipulate the payload as opaque data. It cannot determine whether the payload is a valid instance of a YANG modeled data tree.
> 
> Therefore, I suggest that "anydata validation support" should distinguish at least two different capabilities:
> 
> preserving/manipulating anydata payload without schema knowledge;
> 
> validating anydata payload against an associated schema context.
> 
> Otherwise, an implementation that correctly follows the RFC semantics may be considered only "partially supported" simply because it cannot validate information that is not available.
> 
> XPath / data extraction
> 
> Thanks for providing the detailed test scenarios.
> 
> The behavior of XPath evaluation on a container node returning null is something I need to check in the yangkit implementation.
> 
> If the XPath expression is a valid YANG data tree path, then returning null for an existing container node may indicate an implementation issue rather than a capability limitation.
> 
> However, the test should also clearly distinguish between:
> 
> YANG XPath evaluation defined by RFC 7950;
> 
> schema tree path operations;
> 
> convenience APIs for extracting values.
> 
> These are different concepts and should not be mixed in a capability comparison.
> 
> Updating existing data nodes
> 
> I would like to clarify that the two-stage update and validation model in yangkit is intentional.
> 
> Separating modification from validation is a common design choice for configuration systems.
> 
> If every data modification operation automatically triggers validation, it introduces several problems:
> 
> unnecessary validation overhead when multiple nodes are modified together;
> 
> inability to temporarily represent an intermediate state during a transaction;
> 
> difficulty implementing atomic update workflows.
> 
> For example, a configuration change may require modifying several related nodes before the complete data tree becomes valid. The expected workflow is:
> 
> modify multiple nodes;
> 
> validate the final state once.
> 
> Therefore, I suggest that the evaluation criteria should consider whether an implementation supports a complete update-and-validation workflow, rather than assuming validation must happen immediately after each modification.
> 
> Schema comparison
> 
> I agree that schema comparison is an important capability for YANG users.
> 
> However, I think there is a distinction between a library capability and an application/tool capability.
> 
> yangkit is designed as a fundamental YANG processing library. Tools such as yang-comparator are built on top of yangkit and use its schema tree APIs to implement higher-level functions.
> 
> Whether schema comparison should be included in the core library capability evaluation is ultimately an architectural choice. Different libraries may intentionally provide different levels of abstraction.
> 
> My concern is that mixing core library functions with ecosystem tools may make comparisons less objective.
> 
> Overall, I appreciate your work on comparing different YANG libraries. However, I believe the community would benefit from defining a more precise capability taxonomy and a shared test specification, for example separating:
> 
> RFC semantic compliance;
> 
> core library APIs;
> 
> extension tools built on top of libraries;
> 
> application workflows.
> 
> This would make future comparisons more meaningful and avoid penalizing different but valid architectural choices.
> 
> Best regards,
> 
> Frank
> 
> 
> Vivekananda Boudia <[e-mail] <mailto:[e-mail]>> 于 2026年7月24日周五 下午7:37写道：
>> Hi Frank,
>> 
>> Thank you very much for your detailed and constructive feedback.
>> I fully agree that a shared,open set of test cases and evaluation criteria for YANG libraries would be valuable for the community, especially as YANG continues to grow with an increasing number of features.
>> I would like to clarify how we performed the tests and why some capabilities were rated as partially supported or implementable.
>> 1. Anydata validation — “Partially Supported”
>> 
>> We evaluated three scenarios:
>> Primitive value
>> We provided a primitive value, such as a string or number, as the content of an anydata node.
>> Based on our understanding of RFC 7950, Section 7.10, and RFC 7951, Section 5.5, an anydata node should contain data that can be modeled with YANG.
>> We therefore expected a validation error for a primitive value.
>> 
>> This scenario was the reason for the “Partially Supported” rating.
>> Object without an associated schema
>> Yangkit returned an “Unknown element” error. We considered this an expected and valid behavior.
>> Object with an associated schema
>> Yangkit successfully validated the anydata content against the provided schema. We also considered this the expected behavior.
>> References:
>> https://datatracker.ietf.org/doc/html/rfc7950#section-7.10
>> https://datatracker.ietf.org/doc/html/rfc7951#section-5.5
>> 2. XPath / data extraction — “Partially Supported”
>> 
>> For data-tree XPath evaluation, we used:
>> import org.yangcentral.yangkit.xpath.impl.YangXPathImpl;
>> 
>> YangXPathImpl xpath =
>>     new YangXPathImpl("/xt:top-container/xt:child-container/xt:value1");
>> Our observations were:
>> Retrieving a leaf worked as expected.
>> Retrieving a container returned null, which we did not expect.
>> Traversing a structure and retrieving a leaf worked as expected.
>> Traversing inside an anydata node did not work, which we considered expected based on the RFC semantics.
>> The “Partially Supported” rating was therefore specifically related to our inability to retrieve a container through YangXPathImpl.
>> For subtree validation against the schema tree, we used a different mechanism:
>> import org.yangcentral.yangkit.common.api.AbsolutePath;
>> 
>> AbsolutePath absolutePath = new AbsolutePath();
>> absolutePath.addStep(
>>     new XPathStep(new QName("urn:example", "root"))
>> );
>> absolutePath.addStep(
>>     new XPathStep(new QName("urn:example", "content"))
>> );
>> 3. Add new schema node — “Not Supported” Supported
>> 
>> I tested the SchemaNodeContainer.addSchemaNodeChild() approach you mentioned, and it works.
>> I updated the result during the NETMOD presentation and changed the capability to Supported.
>> 4. Update existing data node — “Not Supported” Partially Supported
>> 
>> We confirm that an existing leaf value can be updated using the LeafData.setValue() API.
>> Therefore, the capability to update an existing data node value is supported.
>> 
>> However, we also observed that modifying a value may temporarily introduce an invalid value, since validation is not automatically triggered when the document is modified.
>> An explicit validation operation is therefore required after the update. In our tests, validate() did not appear to perform the expected type validation, while methods such as getValue() could trigger some checks.
>> There may be a more appropriate API usage pattern that we did not identify for performing a complete update-and-validation workflow.
>> 5. Schema comparison — “Implementable”
>> 
>> We did identify yang-comparator and agree that it demonstrates that semantic schema comparison can be implemented using yangkit.
>> However, the objective of our comparison was to evaluate capabilities directly exposed by each library rather than by separate tools built on top of them.
>> For this reason, we classified the feature as Implementable rather than directly supported by the core library.
>> The remaining difference mainly concerns producing results in a format aligned with draft-ietf-netmod-yang-schema-comparison.
>> 
>> Thank you again for your clarifications. Our intention is not to judge the design choices made by the different libraries, but to document the behavior observed through a common set of scenarios.
>> Your feedback helps us make the evaluation more precise and better explain the criteria behind each result.
>> 
>> Best regards,
>> Vivek
>> 
>> From: "chong feng" <[e-mail] <mailto:[e-mail]>>
>> To: "Vivekananda Boudia" <[e-mail] <mailto:[e-mail]>>, "Pierre Francois" <[e-mail] <mailto:[e-mail]>>, "Maxence Younsi" <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Sent: Tuesday, July 21, 2026 10:47:36 AM
>> Subject: Feedback on "YANG Libraries Feature Comparison" (IETF 126) — from the yangkit author
>> 
>> Hi Vivekananda, Pierre, and Maxence,
>> 
>> Thank you for the "YANG Libraries Feature Comparison" presentation at IETF 126 NETMOD. As the author and maintainer of yangkit, I'm delighted to see this kind of systematic, cross-implementation comparison — it is exactly the type of work that benefits the entire YANG ecosystem.
>> 
>> I'd like to offer some clarifications on a few of the yangkit evaluation results, and more broadly, to suggest that the community could benefit from developing a shared set of test criteria together.
>> 
>> 1. Anydata Validation — rated "Partially Supported"
>> 
>>  <https://github.com/yang-central/yangkit/blob/claude/yangkit-feature-support-analysis-9izbbp/IETF126-email-draft.md#1-anydata-validation--rated-partially-supported>
>> As the original proposer of the anydata statement during the YANG 1.1 revision (the proposal was accepted into RFC 7950), I'd like to clarify its intended semantics.
>> 
>> RFC 7950 Section 7.10 distinguishes anydata from anyxml: anydata represents "an unknown set of nodes that can be modeled with YANG," meaning its content must conform to some YANG model — we just don't know which one at compile time. Yangkit requires an explicit schema context (via AnydataValidationOptions) before validating anydata payload, which directly reflects this semantics.
>> 
>> There is an important distinction between "preserving anydata payload as opaque data" and "validating anydata payload against a schema." Both are useful capabilities, but they serve different purposes. It would be valuable for the community to discuss and agree on what "anydata validation support" should mean in the context of a feature comparison.
>> 
>> The same applies to the "Anydata inside structures" rating.
>> 
>> 2. XPath / Data Extraction — rated "Partially Supported"
>> 
>>  <https://github.com/yang-central/yangkit/blob/claude/yangkit-feature-support-analysis-9izbbp/IETF126-email-draft.md#2-xpath--data-extraction--rated-partially-supported>
>> Yangkit implements a complete XPath 1.0 engine (based on Jaxen) with all YANG-specific extension functions defined in RFC 7950: current(), deref(), derived-from(), derived-from-or-self(), enum-value(), re-match(), and bit-is-set().
>> 
>> In RFC 7950, XPath is used for when, must, leafref path, and instance-identifier — all of which evaluate over the data tree. YANG XPath paths are data node paths that skip schema-only constructs like choice and case, making them fundamentally different from schema paths.
>> 
>> It's also worth noting that RFC 7950 defines anydata as an opaque, indivisible node in the data tree — it has no addressable child nodes. XPath path steps cannot enter anydata internals regardless of implementation; this is inherent to the data model defined by the specification.
>> 
>> I'd be interested to understand which specific test scenarios yangkit did not pass, so we can determine whether the gap is in RFC-mandated functionality or in capabilities beyond the specification scope.
>> 
>> 3. Add New Schema Node — rated "Not Supported"
>> 
>>  <https://github.com/yang-central/yangkit/blob/claude/yangkit-feature-support-analysis-9izbbp/IETF126-email-draft.md#3-add-new-schema-node--rated-not-supported>
>> yangkit-model supports dynamically adding, removing, and modifying schema nodes via APIs such as SchemaNodeContainer.addSchemaNodeChild() — this is a design-time capability for model editing and compilation.
>> 
>> For data validation (yangkit-data), the schema is treated as immutable, which is a deliberate design choice: data validation requires a stable reference point. If a new schema is needed at runtime, the approach is to re-run model parsing and build a new schema context.
>> 
>> These are two distinct capabilities — model editing and data validation — and it may be useful to evaluate them separately.
>> 
>> 4. Update Existing Data Node — rated "Not Supported"
>> 
>>  <https://github.com/yang-central/yangkit/blob/claude/yangkit-feature-support-analysis-9izbbp/IETF126-email-draft.md#4-update-existing-data-node--rated-not-supported>
>> Yangkit supports updating data node values through the LeafData.setValue() API. After modification, calling validate() re-validates the data tree. This decoupled design enables efficient batch updates — multiple nodes can be modified without triggering validation on each intermediate (potentially invalid) state, with a single validation pass after all changes are complete.
>> 
>> I noticed the slides annotate this item with "can easily be changed in code source," which suggests the capability is recognized. I'd be happy to provide more guidance on the intended API usage patterns if that would be helpful.
>> 
>> 5. Schema Comparison — rated "Implementable"
>> 
>>  <https://github.com/yang-central/yangkit/blob/claude/yangkit-feature-support-analysis-9izbbp/IETF126-email-draft.md#5-schema-comparison--rated-implementable>
>> yang-comparator (https://github.com/yang-central/yang-comparator) is a tool built on yangkit that performs semantic-level schema tree comparison. It compiles two versions of YANG modules into their respective schema trees and performs structural diff at the schema level — node additions/deletions/modifications, type changes, constraint changes, and so on.
>> 
>> While its output format may not yet fully align with draft-ietf-netmod-yang-schema-comparison, the core schema comparison capability is implemented and has been used in production. I'd welcome discussion on what output format or criteria the comparison should use.
>> 
>> 
>> 
>> I want to emphasize that this feedback is meant to be constructive, and I think your work points to something the community needs: a shared, open set of test cases and evaluation criteria for YANG libraries. Different libraries make different design choices, and having an agreed-upon test specification would make comparisons fairer and more useful for everyone.
>> 
>> Best regards, Frank
>> 
> _______________________________________________
> netmod mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]