Reading the 8366bis Pull Request for voucher extendibility, https://github.com/anima-wg/voucher/pull/79 , a few questions came up.
I wonder what extendibility problem we really want to solve in scope of 8366bis. The proposed method doesn’t work for IETF wanting to add new attributes (+ SIDs) inside the existing “voucher” YANG module. To keep the scope of this work in check, we may want to focus only on easy extendibility of the voucher by assigning new attributes (with accompanying SIDs) inside this module. Any such extension that is added will probably need to increase the revision of the YANG module, right? Do we also need a registry at IANA to list the extension elements? Does the document that adds the extension need to say “updates 8366bis” ? Once we have this extension method clearly defined, we can easily create a follow-up document that for example adds vendor-specific attributes to the voucher. Or adds attributes imported from other YANG modules. (Which is what the PR currently defines: which could go into a follow-up document.) Or do I make some thinking error here? One practical question on the proposed extension mechanism in the PR: Assume a JSON voucher, with strings for the keys. For an extension using the “ietf-tcp” module, the key name would be something like “extension:ietf-tcp” and the value would be an object with further keys/values. When doing YANG validation of the voucher, the validator encounters the key name “extension:ietf-tcp” – how would that pass a YANG validation? Since the name “extension:ietf-tcp” is not defined in scope of the “voucher” YANG module. Is it still valid per the “voucher” YANG model / does it need to be? I’m somewhat worried that taking too much scope in 8366bis will delay this work, also delaying others (e.g. cBRSKI) in the process. Esko
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
