Dear Jeroen, Thanks a lot for the feedback and also for the implementation. That's much appreciated.
Since I am currently performing end to end integration testing in context of https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration, the next iteration of what we did at IETF 125 (https://datatracker.ietf.org/meeting/125/materials/slides-125-nmop-sessa-3-an-architecture-for-yang-push-to-message-broker-integration-00) I am also looking forward to test the YANG feature coverage xYang as well and feedback. Regarding your comments, see inline my feedback. Best wishes Thomas From: Jeroen van Bemmel <[email protected]> Sent: Tuesday, April 21, 2026 3:04 AM To: [email protected] Subject: [netmod] Re: WGLC on yang-anydata-validation-00 Be aware: This is an external email. Hi all, As an implementer of the xYang library, I'd like to share some feedback before WGLC closes. I implemented the draft as an optional extension in xYang (Python): https://github.com/exergy-connect/xYang/blob/main/examples/anydata_validation_usage.py There is also an online interactive Javascript version: https://exergy-connect.github.io/xYang/anydata_validation/ The approach is conceptually straightforward and easy to implement. I support the goal of enabling validation for anydata. However, I'm concerned that the draft relies on assumptions about sender behavior and schema availability that may not hold across all deployments. Sender assumptions and encoding The draft appears to assume that anydata content is produced by a YANG-aware sender and encoded according to RFC 7951. In practice, anydata is also used as a schema-agnostic container for payloads produced outside of a YANG context. TG> That is correct. Even in YANG-native systems, encoding is often context-dependent, and producers may not consistently emit fully module-qualified names. Treating RFC 7951-style encoding as a prerequisite introduces an implicit requirement on the sender that may not align with existing deployments. TG> Fair point. Schema availability The definition of anydata in RFC 7950 allows for content whose model is not known at design time, and RFC 7951 indicates that it may not be known at runtime. In such cases, requiring module-qualified encoding is not realistic. As a result, the draft appears to apply primarily to deployments where schema context is available and the sender is YANG-aware. TG> James brought up with https://mailarchive.ietf.org/arch/msg/netmod/kIHYCAAH0GoJWKaPh-gKnv6Vd5g/ that it is desirable to signal with an identityref and updated section 7.10 of RFC 7950. As a co-author I agree that this could be useful, however I am unsure wherever this document is the right place to do so. I would like to hear your and also others from the mailing list wherever there is interest to do that and perhaps even further proposals how this should be addressed best. Alternative: receiver-side binding In many cases, the receiver already has sufficient context to interpret anydata. For example, in RFC 8641 Figure 9: * datastore-contents can be interpreted based on the subscription context * value in yang-patch/edit can be interpreted based on the target This suggests a receiver-side schema binding model, rather than requiring YANG-specific encoding from the sender. TG> Exactly! This has been described here https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-11#section-4.7 and needs to be expanded to describe yang-patch/edit case as well as discussed in https://mailarchive.ietf.org/arch/msg/netmod/FBd3sXdzB4DpCLkUYSmL1VJhgCg/ Scope clarification At a minimum, the draft should be explicit about its scope and assumptions. For example, how should implementations behave when: * JSON is received without module names, or * a module cannot be resolved locally? Absent such clarification, there is a risk that the draft is interpreted as a general solution for anydata, while in practice it applies only to a subset of deployments. TG> Fully agree and we will take that as input for the next document version. Best regards, Jeroen van Bemmel / xYang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
