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
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.
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.
*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.
*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.
*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.
Best regards,
Jeroen van Bemmel / xYang
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
