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.
>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.
RFC6020 section 6.2, I think?
I'm not sure that I understand the 7950 example.
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?
"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.
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.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
