On Thu, Jun 17, 2021 at 8:05 AM Fries, Steffen <steffen.fr...@siemens.com> wrote:
> 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: > > > I am not really following this specific issue. I was just pointing out that YANG enumeration types cannot be augmented. It is the wrong terminology, since only schema nodes can be augmented. > *>From:* Anima 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? > > > https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3 > >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 > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
