Hi Michael,
You can use augment-structure to extend a yang structure.
-----邮件原件-----
发件人: netmod [mailto:[email protected]] 代表 Michael Richardson
发送时间: 2023年1月12日 2:18
收件人: [email protected]; [email protected]
抄送: [email protected]
主题: [netmod] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt
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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
