TL;DR> we can not use augment to get the behaviour that we want of being to
extend existing YANG modules with new attributes. We have to revise
8366 each time we want extend things. This email details the work to
make that occur.[email protected] wrote: > Title : A Voucher Artifact for Bootstrapping Protocols > Authors : Kent Watsen > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-01 * I have revised the ietf-voucher YANG module to use sx:structure (RFC8971) rather than YANG-DATA (RFC8040). I seem to have missed doing this for voucher-request, which I'll fix in the next revision. * I have worked on pyang so that it will produce SID values for the sx:structure extension. The pull request is at: https://github.com/mbj4668/pyang/pull/839 As I suspected, it was about five lines of changes. I have some test cases for pyang for this, but I'm struggling to get pyang's "make test" to finish period. * It seems that the assignment of SID values between YANG-DATA and sx:structure is consistent, which is really good. * As discussed at some of the design team meetings, and I think at IETF115, I have merged into the rfc8366bis the ietf-voucher-request content from RFC8995. * yes, there seem to be duplicate SID values for ietf-voucher-request, and I'll sort that out, now that I notice I didn't update it to sx:structure. That will be -02. * I will merge in the changes to ietf-voucher and ietf-voucher-request from draft-ietf-anima-constrained-voucher. At which point, the document title will *really really* be wrong, since it won't even contain the voucher, just constrained-BRSKI. But, we fixed the title awhile ago. I propose to do this in -03, so one can see a clear progression of changes. * I will merge in the changes from PRM in -04. * Since we have to revise rfc8366bis whenever we want to extend or amend the YANG module, there seems to be no point in having the iana-voucher-assertion-type submodule. I propose to remove that, and just leave it all as a flat enumeration. * I don't think we can attempt to get to Internet Standard with this document. There will be, I think, too many changes which have not gone through interoperability tests. Perhaps in two years, this could occur via IESG Action. * The document will need a significant re-edit, and I would ask everyone to please read it with the view to: what should we omit, or just reference RFC8366, and what do we need to revise given the additional pieces that are being merged in. One thought is that we change our mind about making this a Obsoletes, and go back to making this document an Updates:, but I am still stting on the fence for this. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
