Hi Andy, Thank you for pointing out that it will not be possible to have a straight forward enhancement of the enum. I have some questions to the points you raised:
>From: Anima anima-boun...@ietf.org<mailto:anima-boun...@ietf.org> On Behalf Of >Andy Bierman >An enumeration type is hard-wired. Hardwired in terms of a fixed definition of values for the enum in RFC 8366? >No enums can be added via augmentation. That means just the definition of an additional enum value is not enough. >You have to "deviate replace" the type-stmt to add an enum externally, As I’m not too deep in YANG, could you provide more information on this part? Would this be an approach to (just) redefine the type enumeration in the leaf “assertion” (https://datatracker.ietf.org/doc/html/rfc8366#page-11) and adding the new assertion type “agent-proximity”? Would this require to keep all enums already defined in RFC 8366 or could we just use the ones necessary in BRSKI-AE? >or you have to update the module and add the enum inline. Does this result in an update of the module “ietf-voucher” or to define a new module, which imports and augments the voucher by adding the new enum? Best regards Steffen
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
