Early Review of draft-ietf-opsawg-yang-provenance-05
review-ietf-opsawg-yang-provenance-05-yangdoctors-early-lindblad-2026-05-31-00

This is my (much belated, sorry) YANG Doctor review of yang-provenance-05.

I find the document and YANG modules easy to read, and the authors' intent
laudable. There are a few places where additional clarification might be good,
and a few other where details could be improved (see below). This specification
is clearly implementable (I know it has been). However, I am worried about the
interoperability of this effort, and therefore its utility as a standard.

Let me explain. Section 1.1 has a few examples of intended deployment scenarios
are listed. The first one is:

   *  Device Configuration Integrity: Digital signatures may be applied
      to device configuration elements to ensure that specific
      configuration fragments originate from an authorized source (e.g.,
      controller, automation system) and have not been altered in
      transit.  This is useful for zero-touch provisioning and secure
      configuration distribution in programmable networks.

The device may indeed match the provenance signature in the incoming
configuration payload of a configuration operation against the incoming string.
The device may indeed send send signed configuration data back to the
controller so that the controller can verify that the string has not been
tampered with. If the controller chooses to store the received string in a
file, anyone can indeed verify that the string has not been tampered with.

As long as we verify strings, it works. But devices and controllers typically
do not use strings or flat files as backend storage. They use YANG Datastores.
And this is where the interoperability breaks down.

There is a good amount of talk about canonicalization in the document. That is
indeed crucial in order to attain some interoperability. Instead of defining
some proprietary mechanism, the document refers to existing canonicalization
mechanisms for XML, JSON and CBOR. Very good to reuse rather than reinvent, but
the references here go to the transport layer encoding canonicalization.

It's a lot about removing leading and trailing spaces, replacing XML namespace
tags with their full names, and using the most compact CBOR type that supports
the value. That's all great, but entirely misses the necessary (for
interoperability) YANG level canonicalization.

Take this server with three modules as an example:

module server {
  container aaa {
    leaf bbb { ... }
    leaf provenance { type iyangprov:provenance-signature; }
  }
}
module ext1 {
  augment /server:aaa {
    leaf ccc { ... }
  }
}
module ext2 {
  augment /server:aaa {
    leaf ddd { ... }
  }
}

One server implementation may serialize the YANG Datastore as
<aaa>
  <bbb>...</bbb>
  <provenance>...<provenance>
  <ccc>...</ccc>
  <ddd>...</ddd>
</aaa>

While another one, equally valid server implementation might instead use:
<aaa>
  <ddd>...</ddd>
  <ccc>...</ccc>
  <bbb>...</bbb>
  <provenance>...<provenance>
</aaa>

If the first implementation is a device, and the second a controller sending a
configuration change request to the device, then comparing signatures based on
canonicalization on the XML (or JSON, CBOR) level is not going to work as a way
to see if the configurations are "the same".

The undefined order between augments is but one of many canonicalization cases
that are undefined in YANG. Element ordering in general is mostly undefined.
Attribute ordering. Deviations. Choice of namespace tags in values. To name a
few.

If this document was about a mechanism to provide and verify the provenance of
XML, JSON and CBOR data, we have it. But if the aim is to do the same for YANG
data, as the abstract states, we are missing an important and difficult layer
here.

Similar problems arise for the Telemetry and Monitoring Data use case: As soon
as we leave the strings behind and store the data in a YANG Datastore, we have
the same problems here.

The third example use case, Network-Wide Service Orchestration, including
service chaining, suffers from this even more.

A couple of details:

Section 3.2 states that "it is RECOMMENDED to at least issue an error warning."
The meaning of the last couple of words is unclear.

Section 4.2.1 and 4.3 speak about the leaf order. "The provenance leaf is
inserted before the contents leaf." In my judgement, this document probably
cannot dictate/have opinions about the ordering of leafs in a Datastore, as
that would conflict with 7950. As far as I can understand, this added
requirement is probably not important anyway, so maybe removing this text would
be an easy solution?

Best Regards,
/Jan