Re: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

[Andy Bierman <[e-mail]>]

On Thu, Jun 17, 2021 at 9:12 AM Fries, Steffen <[e-mail]>
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 <[e-mail]>
> *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 [e-mail] *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
>
>
>