Hi Diego, I’m skimming this document for the first time, and I have a few observations.
There is some confusing wording in Section 3.3 that might appear to be inconsistently both choosing length-first ordering (Section 4.2.3), which is a deprecated early variant of deterministic encoding, as well as CBOR’s core deterministic encoding (Section 4.2.1). Is there really interest in keeping Section 4.2.3 alive? The core deterministic encoding as defined by Section 4.2.1 is now widely deployed. As usual, note that besides the “canonicalization” offered by the representation format (xml, json, cbor) chosen, you may need to consider whether there is a need for deterministically choosing one of multiple available variants for representing YANG data in that format; I don’t think the three YANG data representations have been designed with deterministic representation already in mind. (All that “canonicalization" heartache can be avoided by keeping the signatures outside the YANG data, so there is no need to provide deterministic signature insertion/removal operations.) More editorial comments: * Please decide whether an example is in diagnostic notation or in CDDL, do not mix (Section 3.1). * Please do not use the term “bitstring” when you actually mean a byte string. Grüße, Carsten > On 18. Feb 2025, at 00:27, Diego R. Lopez <diego.r.lo...@telefonica.com> > wrote: > > Hi, > We have recently filed a project proposal for the IETF 122 Hackathon, > intended to demonstrate and further explore the proposal on YANG provenance > originally presented in OPSAWG, and introduced as well to NETMOD and NMOP > (https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/) > If you are interested, look for the project titled “On the Use of YANG > Provenance Signatures” at the hackathon wiki. > Be goode, > -- > “Esta vez no fallaremos, Doctor Infierno” > Dr Diego R. Lopez > Telefonica > https://www.linkedin.com/in/dr2lopez/ > e-mail: diego.r.lo...@telefonica.com > Mobile: +34 682 051 091 _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
