Diego, Thanks for the presentation of the yang-provenance work today. I read through the document now after your presentation. I find it quite interesting, and have a couple of questions and comments.
First of all, I would have expected this sort of "meta" information to be mapped to attributes in XML or JSON (as described by existing RFCs). For CBOR I have to admit I don't know what is said about attributes. But I guess mapping this to (config false) leafs that are tactically augmented in by server implementors should work too, and may even have some benefits. Rather than specifying a typedef, I would suggest that you create a grouping (with a single leaf). This has the added benefit that you can ensure the name of the leaf is the same every time (which reinforces the idea that only one such leaf is possible on every level in the tree) and that nobody will miss modeling this leaf as config false, even if it appeared in a config true context. You have some examples that place the platform-provenance leaf first in lists. I would strongly recommend against this, even in examples, since (in XML) the list keys MUST go first in the instance data. A rather common server implementor beginner's mistake is to forget this, and I don't think we'd want to muddle the waters more with examples of this kind. I'd suggest placing the platform-provenance leaf after the list key(s), or maybe last. How would a validating client know which leafs are provenance-signatures? Should it go by leaf name (trying to validate any container/list that has a leaf called "provenance-signature" in any namespace? Should it examine the leaf type? Marking by YANG extension...? In section 4, the need for canonicalization is mentioned, and algorithm described. The algo for XML is really only about reordering and sometimes moving or excluding XML attributes. I'm not saying canonicalization isn't needed, but I don't see exactly what purpose you have in mind for doing this is. If all we are after is to verify that a particular string (XML, JSON or whatever) has not been tampered with, I guess canonicalization would not really be needed? If it indeed is needed, is the light algorithm referenced enough to achieve your intended purpose? I mean, the payload is not canonicalized when it comes to whitespace, ordering of elements and many other aspects. Will your purpose still be fulfilled? Best Regards, /jan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
