On Thursday, August 19, 2021, 04:43:33 PM EDT, Michael Richardson <[email protected]> wrote: On 2021-08-15 11:22 a.m., Reshad Rahman via Datatracker wrote: > It was correctly pointed out that the enumeration for "leaf assertion" in > RFC8366 can not be augmented. If my understanding is correct, there is a > suggestion to do a IANA-maintained module for the assertion and republish a > new > YANG module revision when a new assertion is added. However, I don't believe > the "assertion values" are actually IANA-maintained.
The RFC8366bis would create the IANA Registry. <RR> If you want a central location for these values, then doing IANA maintained values is the way to go. But I am not familiar with the details of the process, so I don't know of the extra cost, if any, of doing it that way. e..g I assume when a new value is needed in the future, we'll need a bis of 8366bis on top of the new document which uses that value?Adding Rob to shed some light on this. >So I don't think that > doing a IANA-maintained module is good in this case (disclaimer: I won't > pretend to be an expert on IANA-maintained modules). As comparision point, the > IANA BFD module at > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-17#section-2.12 is > for BFD registries maintained by IANA > (https://datatracker.ietf.org/doc/html/rfc5880#section-8). Thank you, I did need another example. > Since 8366bis is being worked on, can the enum be changed to an identity? That > way, when a new assertion is needed, a new identity is added. Identities would > also enable to support "multiple inheritance" as was asked here: > https://mailarchive.ietf.org/arch/msg/netmod/dNGvcvckwuS_pBmkVg_Te8bedZs/. For > an example, see https://datatracker.ietf.org/doc/html/rfc7950#section-7.18.3 I don't know if I can use an identity. <RR> I believe you can use an identity. But if you want a central location for all 'values', identity is not the way to go. If you're ok with having the uses distributed in various documents, identity will work.RFC6020 section 6.2, I think?<RR> No that's identifiers. I'm not sure that I understand the 7950 example.<RR> Does this help: https://datatracker.ietf.org/doc/html/rfc7950#section-7.18As opposed to having enum E with e.g. values E1 and E2, you have an identity I (no "base") and then new identities I1 and I2 with I as base. For example: identity path-type { description "Base identity for BFD path type. The path type indicates the type of path on which BFD is running."; } identity path-ip-sh { base path-type; description "BFD on IP single hop."; reference "RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)."; } identity path-ip-mh { base path-type; description "BFD on IP multihop paths."; reference "RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths."; } > Other comments: > - rc:yang-data (RFC8040) is used. While this seems to be fine, if the > voucher-request-async-artifact template needs to be extended in the future, my > understanding is that it is not possible with yang-data. However, you could > use Uhm, but we use rc:yang-data in RFC8366, and we extend it in RFC8995 to make voucher-request. And we take that, and we extend it in anima-constrained-voucher. So I'm confused. Is that we are doing this a bug?<RR> No. When 8366 was written, afaik the work on structure had just started. So it made sense that you used yang-data. > "structure" and (eventually) "augment-structure" from RFC8791 for this. - I have read 8791 now. It seems fine. I don't see why we would or wouldn't do RFC8366bis as a structure. I would appreciate a deeper understanding of what it does better.<RR> structure allows for extensions and doesn't need to be at top-level (which is the case for yang-data). Maybe you don't need those 2 enhancements. BTW: we plan to rename all of our extensions (still in ID stage) to be ietf-voucher-foo, rather than ietf-foo-voucher, and I wondered if there was any reason why this was a bad idea. It seems like a good idea from a collection/sorting point of view for the humans involved.<RR> Sounds good.
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
