[netmod] Re: adoption call for draft-ietf-netmod-yang-anydata-validation (post factum)

[Andy Bierman <[e-mail]>]

On Tue, Apr 7, 2026 at 9:04 AM Rob Wilton (rwilton) <rwilton=
[e-mail]> wrote:

> Hi Ahmed, Kent, Thomas, WG,
>
> Sorry, but I don't know whether the WG should adopt this document yet.
>
> As per my previous email, my main problem is that I either don't
> understand how the solution works, or otherwise I believe that it is
> incomplete and I would like to understand what the precise scope/goal of
> this document is and to know that there is an outline of a viable technical
> solution.
>
> Alternatively, if this document is only intended to cover the anydata
> cases where anydata leaves are encoded from the root of the schema, then it
> becomes somewhat tautological in its meaning and intent.  In this case then
> I think that the document should only be informational, and we might want
> to think whether we really need to publish it at all.  E.g., could it just
> be a couple of paragraphs in another document?
>
> The crux of my issue is that I believe that this document assumes that
> YANG anydata nodes are always encoded from the root of the schema, but this
> isn't a requirement from RFC 7950 section 7.10.  The encoding is just from
> the point of the node that is being returned (and that node must be
> correctly namespaced), but you don't need to include all the parent
> elements going back to the root of a data tree.  I.e., in the general case
> you cannot assume that you can just validate an anydata node against the
> root of the schema.
>
> YANG Patch (RFC 8072) is perhaps a good example that uses anydata nodes in
> this relative-path way:
>
> My understanding of a YANG patch operation for an edit request, is that
> the "target" leaf gives the path to the data node that is being edited, and
> the value (which is any data) is encoded relative to that path rather than
> the root of the tree.
>
> Hence any tool that is trying to validate the anydata part of a yang-patch
> operation against the schema needs to know that the anydata is encoded
> relative to the target path, otherwise it will mistakenly fail.
>
> Hence a full solution here needs a generic way of specifying this
> additional path into the schema where the anydata needs to be validated
> against.  Certainly, I don't think that we want to be trying to constrain
> the use of anydata in the YANG language to only encode data from the root
> of the schema tree!
>
> Another example would be RFC 9144, here, if the examples are correct, then
> the output is encoded relative to the input RPC xpath-filter.  I.e., there
> isn't enough information in the RPC reply to validate the anydata node, you
> need to know the additional relative path context from the RPC input.
>
> Finally, the proposed encoding for Yang Push v2 is another example where
> the anydata isn't directly encoded from the root of the tree, but instead
> it is relative to the path specified in "target-prefix" concatenated with
> "updates/target-path".  I.e., like how push-change-updates are encoded in
> RFC 8641.
>
> Separately, in terms of validation, I think that this should take an
> arbitrary datastore to validate against, and maybe even the ability to pass
> in some instance data for that datastore that is being validated against
> (e.g., if the goal is to validate leaf refs, etc).  In the case of
> validating against operational, I think that this document should reference
> section 5.3 of RFC 8342.   We should also check whether there are any other
> constraints, e.g., for factory-default or the system datastore that have
> been more recently specified in drafts/RFCs.
>
>
I agree with your comments.  I have previously raised concerns about this
draft on the ML.
The validation for an anydata node is based on the normative text in the RFC
or YANG module that defines the anydata node.  It has been in use for 18
years already,
so not sure what problem needs to be solved here.


Kind regards,
> Rob
>
>
Andy


>
>
> *From: *Kent Watsen <[e-mail]>
> *Date: *Tuesday, 7 April 2026 at 02:41
> *To: *[e-mail] <[e-mail]>
> *Subject: *[netmod] adoption call for
> draft-ietf-netmod-yang-anydata-validation (post factum)
>
> [This is a strange adoption call, as already the document was approved as
> a WG document,  Nonetheless, it is a good thing to do an adoption call]
>
> This email begins a two-week *adoption* on:
>
> Validating anydata in YANG Library context
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-anydata-validation//00/
>
>         Yes, it is strange that the document title starts with
> "draft-ietf-".  Please do
>         not allow that designation to influence your adoption call reviews.
>
> No IPR was declared for this document:
> https://mailarchive.ietf.org/arch/msg/netmod/N-p2jnzvDmog8SU29riWTCzUaHE/
>
> Please take time to review this draft and post comments by Apr 20.  Both
> favorable comments and objections are welcomed.
>
> Kent  (and Lou)
>
> _______________________________________________
> netmod mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>