On Thu, Jun 17, 2021 at 9:12 AM Fries, Steffen <[email protected]> wrote:
> Hi Andy, > > > > Thanks for the reference. I have to dive into that a little deeper. Based > on your previous comment, it would be possible to use the “deviate replace” > to and replace the existing enum in the voucher definition by an enhanced > enum definition in our document. If I understood this right, it is probably > the easiest way. > > > Deviations are not allowed in IETF modules. You probably need to update the module that has the leaf with the enumeration type. > Best regards > > Steffen > > > Andy > *From:* Andy Bierman <[email protected]> > *Sent:* Donnerstag, 17. Juni 2021 17:19 > > > > > 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 [email protected] *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 > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8366%23page-11&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7Cccdb6da524d24947105d08d931a33d66%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595399442930701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8VRqAnhX6Ug7JfUYJYi6VPDmwnXcFg3oa1B9GcMDf7g%3D&reserved=0>) > 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 > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.20.3&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7Cccdb6da524d24947105d08d931a33d66%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595399442930701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eytq7Vf%2BXgcEIa8TfsAozmJ9sKINN6a%2FHgdLrKvJNX8%3D&reserved=0> > > > > > > >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 > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
