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

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 13:56:36 -0400

stfries <[email-masked]> wrote:
    > New assertion type for the voucher necessary for
    > agent-proximity. Likely to enhance the enum in the YANG module for the
    > voucher in [RFC
    > 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3)

Kent, how do we do add a new enum?
Does the grouping help us at all?
We need to do this for both voucher and voucher-request.

    >  enum agent-proximity { description "Indicates that the voucher has

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Jun 2021 22:44:31 +0000

Hi Michael,

> We need to do this for both voucher and voucher-request.

Firstly, because it took me quite some time to put this message in context, for everyone else, here’s a link to GitHub Issue #18: https://github.com/anima-wg/anima-brski-async-enroll/issues/18 <https://github.com/anima-wg/anima-brski-async-enroll/issues/18>.

I’m unsure what it is trying to be accomplished but, generally, either an “augment” and a module-revision can be used to add an enum.

K.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Jun 2021 16:01:43 -0700

On Wed, Jun 16, 2021 at 3:45 PM Kent Watsen <[email-masked]> wrote:

> Firstly, because it took me quite some time to put this message in
> context, for everyone else, here’s a link to GitHub Issue #18:
> https://github.com/anima-wg/anima-brski-async-enroll/issues/18.
>
> I’m unsure what it is trying to be accomplished but, generally, either an
> “augment” and a module-revision can be used to add an enum.
>
>

An enumeration type is hard-wired.
No enums can be added via augmentation.
You have to "deviate replace" the type-stmt to add an enum externally,
or you have to update the module and add the enum inline.

I

> K.
Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 17 Jun 2021 06:21:59 +0000

Hi Kent
New assertion type for the voucher necessary for
agent-proximity. Likely to enhance the enum in the YANG module for the
voucher in [RFC
8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8366%23section-5.3&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C8f0def833074455274eb08d931185e52%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637594803581468513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=rzMb4kIf2KFodqTPQn0t%2FPR4Qa36swMHP5vpc90w5VI%3D&reserved=0>)

Firstly, because it took me quite some time to put this message in context, for everyone else, here’s a link to GitHub Issue #18: https://github.com/anima-wg/anima-brski-async-enroll/issues/18<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fanima-brski-async-enroll%2Fissues%2F18&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7C8f0def833074455274eb08d931185e52%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637594803581478469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=B1c%2FG9IS2Umv7K%2FpB%2BKKZWvyhB1Bq0bLRX%2FrIRsSZTc%3D&reserved=0>.

[stf] Thank you for the hint. In one of the use cases of BRSKI-AE a registrar-agent acting on behalf of the registrar is used to facilitate the communication between pledge and registrar. In this case the MASA should assert “agent-proximity” instead of “proximity” to show, that there was no direct connection between the pledge and the registrar. Also, as the pledge does not verify a signature of the registrar, this assertion is weaker than “proximity” but stronger than “logged”. To achieve this we intended to enhance the current enum with the new assertion type.

Best regards
Steffen

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 17 Jun 2021 15:05:32 +0000

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 [email-masked]<mailto:[email-masked]> On Behalf Of Andy Bierman
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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Jun 2021 08:18:51 -0700

> 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 [email-masked] *On Behalf Of *Andy Bierman
> 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

> 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

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 17 Jun 2021 16:12:49 +0000

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.

Best regards
Steffen

From: Andy Bierman <[email-masked]>
Sent: Donnerstag, 17. Juni 2021 17:19

>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>

Best regards
Steffen

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Jun 2021 09:42:17 -0700

On Thu, Jun 17, 2021 at 9:12 AM Fries, Steffen <[email-masked]>
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.

Andy

> *From:* Andy Bierman <[email-masked]>
> *Sent:* Donnerstag, 17. Juni 2021 17:19
>
>
>
>
> 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://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>
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jun 2021 16:09:49 -0400

Kent, my appologies for not putting enough context with my email.
Andy, thanks for the clarification.

As I understand, in order to add a new assertion to RFC8366's leaf
"assertion", we have to revise RFC8366.

Question: was it a mistake to make this an assertion, if we wanted to
be able extend it?
Can we do this via IANA registry in some way instead?

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Jun 2021 20:47:21 +0000

> On Jun 18, 2021, at 4:09 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

In hindsight, a more extensible solution would’ve been to define "leaf assertion” using “type identityref” instead of “type enumeration”, as then external modules could define additional “identity” statements.  As Andy points out, the only way new enums can be added is via a module revision.

An IANA registry cannot be used to extend RFC 8366 now…if that were desired, it would have had to be defined by RFC 8366.  A revision of RFC 8366 could define such behavior, but then would might wonder why not use the revision to instead flip "leaf assertion” to “type identityref”.

FWIW, "leaf assertion” is not used by SZTP (RFC 8572).

K.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jun 2021 18:23:10 -0400

Kent Watsen <[email-masked]> wrote:
    > An IANA registry cannot be used to extend RFC 8366 now…if that were
    > desired, it would have had to be defined by RFC 8366.  A revision of
    > RFC 8366 could define such behavior, but then would might wonder why
    > not use the revision to instead flip "leaf assertion” to “type
    > identityref”.

Yes, okay, so if we have to revise 8366, then this sounds like something we
should do.