Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Fries, Steffen]

Hi Reshad,

A while ago you did the early YANGDOCTORS review of BRSKI-AE. You identified 
some issues to be addressed. Meanwhile we have split the draft to better focus 
on distinct functionality. The result is BRSKI-AE 
(https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/) and BRSKI-PRM 
(https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/).
After the split all YANG related module definitions were moved into BRSKI-PRM, 
as there was no further need in BRSKI-AE to define own YANG modules. 
RSKI-PRM meanwhile had a YANGDOCTORS early review which resulted in "Ready with 
Nits"

What I wanted to ask is if there is any possibility to update the YANGDOCTORS 
early review for BRSKI-AE to "not applicable" or similar to avoid the 
impression it defines a YANG module in the first place and that it needs 
further work based on the review results? 
We are currently in the preparation of WGLC. Hence the question.

Best regards
Steffen

> -Original Message-
> From: Anima  On Behalf Of Reshad Rahman via
> Datatracker
> Sent: Sonntag, 15. August 2021 17:23
> To: yang-doct...@ietf.org
> Cc: draft-ietf-anima-brski-async-enroll@ietf.org; anima@ietf.org
> Subject: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-
> enroll-03
> 
> Reviewer: Reshad Rahman
> Review result: Not Ready
> 
> Major comments on this document:
> - The YANG module has errors. Please validate it first e.g. by using
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyangvalid
> ator.com%2Fyangvalidatordata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qZYcLcbndcMuCb77Zj
> sWzaXAhcLQTqYixESNNN4h%2BcA%3Dreserved=0 or local tools. Also if
> you follow guidelines @
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.2data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kynl2GRBX1uCdL8hvU
> %2BZVqkHKdTMrp%2B4u5ZsYZWzcLE%3Dreserved=0, you will see errors
> present, if any, on datatracker. See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing 
> extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. - Include a tree diagram as per
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.4data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cnmkIb3STbSR5BHuwI
> GWxsj2lMYMs7AmlbMtF8euKhU%3Dreserved=0 - For the security
> considerations, please add information as requested in
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section-
> 3.7data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yGzdefsWVH2Hh2%2
> B5IPJiCplkkQ82KQgsPpKLjOV%2BlrI%3Dreserved=0
> 
> New assertion-type:
> This is regarding issue #18, i.e.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-async-
> enroll%2Fissues%2F18data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a7GFxdMxFfZ65hYCa3
> dWR8VR7apcwUeTtudUppFFysw%3Dreserved=0, the need for 8366bis
> etc. Email threads:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FOm6QOZL-
> bupgEblNLDL3S0PnaPY%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CCOwD%2Bah2tRbrw
> zENSiREVaiFV2wpZqwjosP5LFCi9E%3Dreserved=0 and
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FOrJYk01en82VVG-
> 

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Reshad Rahman]

 On Thursday, August 19, 2021, 04:43:33 PM EDT, Michael Richardson 
 wrote:
 
 
 On 2021-08-15 11:22 a.m., Reshad Rahman via Datatracker wrote:
> It was correctly pointed out that the enumeration for "leaf assertion" in
> RFC8366 can not be augmented. If my understanding is correct, there is a
> suggestion to do a IANA-maintained module for the assertion and republish a 
> new
> YANG module revision when a new assertion is added. However, I don't believe
> the "assertion values" are actually IANA-maintained. 

The RFC8366bis would create the IANA Registry.

 If you want a central location for these values, then doing IANA 
maintained values is the way to go. But I am not familiar with the details of 
the process, so I don't know of the extra cost, if any, of doing it that way. 
e..g I assume when a new value is needed in the future, we'll need a bis of 
8366bis on top of the new document which uses that value?Adding Rob to shed 
some light on this.
 >So I don't think that
> doing a IANA-maintained module is good in this case (disclaimer: I won't
> pretend to be an expert on IANA-maintained modules). As comparision point, the
> IANA BFD module at
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-17#section-2.12 is
> for BFD registries maintained by IANA
> (https://datatracker.ietf.org/doc/html/rfc5880#section-8).

Thank you, I did need another example.

> Since 8366bis is being worked on, can the enum be changed to an identity? That
> way, when a new assertion is needed, a new identity is added. Identities would
> also enable to support "multiple inheritance" as was asked here:
> https://mailarchive.ietf.org/arch/msg/netmod/dNGvcvckwuS_pBmkVg_Te8bedZs/. For
> an example, see https://datatracker.ietf.org/doc/html/rfc7950#section-7.18.3

I don't know if I can use an identity.
 I believe you can use an identity. But if you want a central location for 
all 'values', identity is not the way to go. If you're ok with having the uses 
distributed in various documents, identity will work.RFC6020 section 6.2, I 
think? No that's identifiers. 
I'm not sure that I understand the 7950 example. Does this help: 
https://datatracker.ietf.org/doc/html/rfc7950#section-7.18As opposed to having 
enum E with e.g. values E1 and E2, you have an identity I (no "base") and then 
new identities I1 and I2 with I as base. For example:  identity path-type {
description
  "Base identity for BFD path type. The path type indicates
   the type of path on which BFD is running.";
  }
  identity path-ip-sh {
base path-type;
description "BFD on IP single hop.";
reference
  "RFC 5881: Bidirectional Forwarding Detection (BFD)
   for IPv4 and IPv6 (Single Hop).";
  }
  identity path-ip-mh {
base path-type;
description "BFD on IP multihop paths.";
reference
  "RFC 5883: Bidirectional Forwarding Detection (BFD) for
   Multihop Paths.";
  }

> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the
> voucher-request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could 
> use

Uhm, but we use rc:yang-data in RFC8366, and we extend it in RFC8995 to 
make voucher-request.  And we take that, and we extend it in 
anima-constrained-voucher.

So I'm confused.
Is that we are doing this a bug? No. When 8366 was written, afaik the work 
on structure had just started. So it made sense that you used yang-data.

> "structure" and (eventually) "augment-structure" from RFC8791 for this. -

I have read 8791 now.
It seems fine.  I don't see why we would or wouldn't do RFC8366bis as a 
structure.  I would appreciate a deeper understanding of what it does 
better. structure allows for extensions and doesn't need to be at top-level 
(which is the case for yang-data). Maybe you don't need those 2 enhancements.

BTW: we plan to rename all of our extensions (still in ID stage) to be 
ietf-voucher-foo, rather than ietf-foo-voucher, and I wondered if there 
was any reason why this was a bad idea.  It seems like a good idea from 
a collection/sorting point of view for the humans involved. Sounds good.

  ___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Michael Richardson]

On 2021-08-15 11:22 a.m., Reshad Rahman via Datatracker wrote:

It was correctly pointed out that the enumeration for "leaf assertion" in
RFC8366 can not be augmented. If my understanding is correct, there is a
suggestion to do a IANA-maintained module for the assertion and republish a new
YANG module revision when a new assertion is added. However, I don't believe
the "assertion values" are actually IANA-maintained. 


The RFC8366bis would create the IANA Registry.

>So I don't think that

doing a IANA-maintained module is good in this case (disclaimer: I won't
pretend to be an expert on IANA-maintained modules). As comparision point, the
IANA BFD module at
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-17#section-2.12 is
for BFD registries maintained by IANA
(https://datatracker.ietf.org/doc/html/rfc5880#section-8).


Thank you, I did need another example.


Since 8366bis is being worked on, can the enum be changed to an identity? That
way, when a new assertion is needed, a new identity is added. Identities would
also enable to support "multiple inheritance" as was asked here:
https://mailarchive.ietf.org/arch/msg/netmod/dNGvcvckwuS_pBmkVg_Te8bedZs/. For
an example, see https://datatracker.ietf.org/doc/html/rfc7950#section-7.18.3


I don't know if I can use an identity.
RFC6020 section 6.2, I think?
I'm not sure that I understand the 7950 example.


Other comments:
- rc:yang-data (RFC8040) is used. While this seems to be fine, if the
voucher-request-async-artifact template needs to be extended in the future, my
understanding is that it is not possible with yang-data. However, you could use


Uhm, but we use rc:yang-data in RFC8366, and we extend it in RFC8995 to 
make voucher-request.  And we take that, and we extend it in 
anima-constrained-voucher.


So I'm confused.
Is that we are doing this a bug?


"structure" and (eventually) "augment-structure" from RFC8791 for this. -


I have read 8791 now.
It seems fine.  I don't see why we would or wouldn't do RFC8366bis as a 
structure.  I would appreciate a deeper understanding of what it does 
better.


BTW: we plan to rename all of our extensions (still in ID stage) to be 
ietf-voucher-foo, rather than ietf-foo-voucher, and I wondered if there 
was any reason why this was a bad idea.   It seems like a good idea from 
a collection/sorting point of view for the humans involved.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Fries, Steffen]

Hi Reshad,

From: Reshad Rahman 
Sent: Mittwoch, 18. August 2021 23:08

>reshad> Other comments: - rc:yang-data (RFC8040) is used. While this
>reshad> seems to be fine, if the voucher- request-async-artifact template
>reshad> needs to be extended in the future, my understanding is that it
>reshad> is not possible with yang-data. However, you could use
>reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
>reshad> this.
>
> I am probably the guilty party that wrote the YANG.
> I guess I missed your email (seeing Steffen's reply only), and I'll go back 
> to the
> list to find it to understand.
 And I didn't receive Michael's response to Steffen. Not in my Junk folder 
either.
[stf] Michael also just received my response to your email. ANIMA WG was in cc 
so I’m not sure what happened.


I saw that the constraint voucher follows the same approach.
 Where is the constraint voucher defined?
[stf] https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

> We do want to mix and match the various extensions.
> It is not clear to me how to do that.
Maybe related to this, would it be better to augment the voucher than as 
requested by Reshad or the voucher-request as we currently do it. I also had a 
look into the constraint voucher as there are also enhancements defined. So I 
guess I should go with the augmented voucher?
 I didn't see a voucher-request node but I'm probably looking for the wrong 
thing.
[stf] You answered this already with your hint in the previous email. We cant 
augment the yang-data is what I understood as it does not allow augmentation.


Best regards
Steffen

>> We will discuss this point. Currently there is no explicit need for
>> enhancements.
>
>reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 
> has
>reshad> "vcr". While this is valid, I am curious why.
>
> I didn't think the prefix had relevance outside of the module, but I don't 
> know a
> lot here.
 It doesn't. It's just usually people use the same prefix as defined in the 
module. No big deal if you want to use a different one, I was just curious why.

Regards,
Reshad.

I meanwhile changed it to vcr. If it has no relevance outside the module, it 
should not be a problem

Regards
Steffen

>
> --
> ]  Never tell me the odds!| ipv6 mesh networks [
> ]  Michael Richardson, Sandelman Software Works|IoT architect  [
> ]m...@sandelman.ca  http://www.sandelman.ca/ 
> 
>|  ruby on rails[

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Reshad Rahman]

 Hi all,
On Wednesday, August 18, 2021, 07:46:31 AM EDT, Fries, Steffen 
 wrote:  
 
 Hi Michael, 

> -Original Message-
> From: Michael Richardson 
> Sent: Mittwoch, 18. August 2021 13:27
> 
>    reshad> Other comments: - rc:yang-data (RFC8040) is used. While this
>    reshad> seems to be fine, if the voucher- request-async-artifact template
>    reshad> needs to be extended in the future, my understanding is that it
>    reshad> is not possible with yang-data. However, you could use
>    reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
>    reshad> this.
> 
> I am probably the guilty party that wrote the YANG.
> I guess I missed your email (seeing Steffen's reply only), and I'll go back 
> to the
> list to find it to understand.
 And I didn't receive Michael's response to Steffen. Not in my Junk folder 
either.
I saw that the constraint voucher follows the same approach.
 Where is the constraint voucher defined?
> We do want to mix and match the various extensions.
> It is not clear to me how to do that.
Maybe related to this, would it be better to augment the voucher than as 
requested by Reshad or the voucher-request as we currently do it. I also had a 
look into the constraint voucher as there are also enhancements defined. So I 
guess I should go with the augmented voucher?
 I didn't see a voucher-request node but I'm probably looking for the wrong 
thing.
>    > We will discuss this point. Currently there is no explicit need for
>    > enhancements.
> 
>    reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 
>has
>    reshad> "vcr". While this is valid, I am curious why.
> 
> I didn't think the prefix had relevance outside of the module, but I don't 
> know a
> lot here.
 It doesn't. It's just usually people use the same prefix as defined in the 
module. No big deal if you want to use a different one, I was just curious why.
Regards,Reshad.
I meanwhile changed it to vcr. If it has no relevance outside the module, it 
should not be a problem

Regards
Steffen 

> 
> --
> ]              Never tell me the odds!                | ipv6 mesh networks [
> ]  Michael Richardson, Sandelman Software Works        |    IoT architect  [
> ]    m...@sandelman.ca  http://www.sandelman.ca/       |  ruby on rails    [

  ___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Reshad Rahman]

 Hi Steffen,

On Wednesday, August 18, 2021, 04:44:01 AM EDT, Fries, Steffen 
 wrote:  
 
 Hi Reshad,

Thank you for the review. I will address the points in the next update of the 
draft. 
I took over the proposed changes you made and will provide the tree diagram and 
the enhancement to the security considerations as suggested. In the ANIMA 
design team we will discuss the recommendations for RFC 8366bis 
I have some remarks to the other comments:

> See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing 
> extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. 
I'm not sure about the last statement, as we would like to enhance the existing 
voucher-request definition from RFC 8995 in BRSKI-AE. Does this comment means 
we cannot augment the voucher-request as it already augments the voucher and 
therefore have to use the voucher  and only describe the leafs added?
 The document currently has the following   uses 
ivr:voucher-request-grouping {
 augment "voucher-request" {
There is no node "voucher-request" in voucher-request-grouping in RFC8995 
(unless I missed it). So I assumed it's the "voucher" node which is intended to 
be augmented. Disclaimer: I don't fully understand the intent here.
If it is the voucher-request-artifact  from RFC8995 which is to be augmented, I 
believe that can't be done because yang-data doesn't allow for augments. // 
Top-level statement
 rc:yang-data voucher-request-artifact {
   uses voucher-request-grouping;
 }
> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the voucher-
> request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could 
> use
> "structure" and (eventually) "augment-structure" from RFC8791 for this. 
We will discuss this point. Currently there is no explicit need for 
enhancements.
 My understanding is that people are being encouraged to use "structure" 
instead of "yang-data", but I'll fer this to the AD (Rob).
>- Prefix
> "ivr" is used for ietf-voucher-request although RFC8995 has "vcr". While this 
> is
> valid, I am curious why. 
Changed to match the definition in RFC 8995. Also changed for the "uses" 
statement in the grouping.
 Ack.
Regards,Reshad.
Best regards
Steffen



- Please take a look at
> Error during processing.
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23appendix-
> Bdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oyAUYIKQZSQxxURiRc
> j0RTlM6kiupsa6PqRs0hb86jg%3Dreserved=0 for a module remplate.
> e.g. data definition statements usualy go after grouping definitions.
> 
> Valid YANG module:
> 
>    module ietf-async-voucher-request {
>      yang-version 1.1;
> 
>      namespace
>        "urn:ietf:params:xml:ns:yang:ietf-async-voucher-request";
>      prefix "constrained";
> 
>      import ietf-restconf {
>        prefix rc;
>        description
>          "This import statement is only present to access
>          the yang-data extension defined in RFC 8040.";
>        reference "RFC 8040: RESTCONF Protocol";
>      }
> 
>      import ietf-voucher-request {
>        prefix ivr;
>        description
>          "This module defines the format for a voucher request,
>              which is produced by a pledge as part of the RFC8995
>              onboarding process.";
>        reference
>          "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
>      }
> 
>      organization
>      "IETF ANIMA Working Group";
> 
>      contact
>      "WG Web:
>  .org%2Fwg%2Fanima%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7BDzJ4MjL%2BaCAAh
> v4A2PZLl2pB0b7WoNM19qAEGVICU%3Dreserved=0>
>        WG List:  
>        Author:  Steffen Fries
>                  
>        Author:  Hendrik Brockhaus
>                  
>        Author:  Eliot Lear
>                  
>        Author:  Thomas Werner
>                  ";
>      description
>      "This module defines an extension of the RFC8995 voucher
>        request to permit a registrar-agent to convey the adjacency
>        relationship from the registrar-agent to the registrar.
> 
>        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
>        'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
>        and 'OPTIONAL' in the module text are to be interpreted as
>        described in RFC 

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Fries, Steffen]

Hi Michael, 

> -Original Message-
> From: Michael Richardson 
> Sent: Mittwoch, 18. August 2021 13:27
> 
> reshad> Other comments: - rc:yang-data (RFC8040) is used. While this
> reshad> seems to be fine, if the voucher- request-async-artifact template
> reshad> needs to be extended in the future, my understanding is that it
> reshad> is not possible with yang-data. However, you could use
> reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
> reshad> this.
> 
> I am probably the guilty party that wrote the YANG.
> I guess I missed your email (seeing Steffen's reply only), and I'll go back 
> to the
> list to find it to understand.
I saw that the constraint voucher follows the same approach.

> We do want to mix and match the various extensions.
> It is not clear to me how to do that.
Maybe related to this, would it be better to augment the voucher than as 
requested by Reshad or the voucher-request as we currently do it. I also had a 
look into the constraint voucher as there are also enhancements defined. So I 
guess I should go with the augmented voucher?


> > We will discuss this point. Currently there is no explicit need for
> > enhancements.
> 
> reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 
> has
> reshad> "vcr". While this is valid, I am curious why.
> 
> I didn't think the prefix had relevance outside of the module, but I don't 
> know a
> lot here.
I meanwhile changed it to vcr. If it has no relevance outside the module, it 
should not be a problem

Regards
Steffen 

> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Michael Richardson]

reshad> Other comments: - rc:yang-data (RFC8040) is used. While this
reshad> seems to be fine, if the voucher- request-async-artifact template
reshad> needs to be extended in the future, my understanding is that it
reshad> is not possible with yang-data. However, you could use
reshad> "structure" and (eventually) "augment-structure" from RFC8791 for
reshad> this.

I am probably the guilty party that wrote the YANG.
I guess I missed your email (seeing Steffen's reply only), and I'll go back
to the list to find it to understand.

We do want to mix and match the various extensions.
It is not clear to me how to do that.

> We will discuss this point. Currently there is no explicit need for
> enhancements.

reshad> - Prefix "ivr" is used for ietf-voucher-request although RFC8995 has
reshad> "vcr". While this is valid, I am curious why.

I didn't think the prefix had relevance outside of the module, but I don't
know a lot here.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Fries, Steffen]

Hi Reshad,

Thank you for the review. I will address the points in the next update of the 
draft. 
I took over the proposed changes you made and will provide the tree diagram and 
the enhancement to the security considerations as suggested. In the ANIMA 
design team we will discuss the recommendations for RFC 8366bis 
I have some remarks to the other comments:

> See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing 
> extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. 
I'm not sure about the last statement, as we would like to enhance the existing 
voucher-request definition from RFC 8995 in BRSKI-AE. Does this comment means 
we cannot augment the voucher-request as it already augments the voucher and 
therefore have to use the voucher  and only describe the leafs added?

> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the voucher-
> request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could 
> use
> "structure" and (eventually) "augment-structure" from RFC8791 for this. 
We will discuss this point. Currently there is no explicit need for 
enhancements.

>- Prefix
> "ivr" is used for ietf-voucher-request although RFC8995 has "vcr". While this 
> is
> valid, I am curious why. 
Changed to match the definition in RFC 8995. Also changed for the "uses" 
statement in the grouping.

Best regards
Steffen



- Please take a look at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23appendix-
> Bdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oyAUYIKQZSQxxURiRc
> j0RTlM6kiupsa6PqRs0hb86jg%3Dreserved=0 for a module remplate.
> e.g. data definition statements usualy go after grouping definitions.
> 
> Valid YANG module:
> 
>module ietf-async-voucher-request {
>  yang-version 1.1;
> 
>  namespace
>"urn:ietf:params:xml:ns:yang:ietf-async-voucher-request";
>  prefix "constrained";
> 
>  import ietf-restconf {
>prefix rc;
>description
>  "This import statement is only present to access
>   the yang-data extension defined in RFC 8040.";
>reference "RFC 8040: RESTCONF Protocol";
>  }
> 
>  import ietf-voucher-request {
>prefix ivr;
>description
>  "This module defines the format for a voucher request,
>  which is produced by a pledge as part of the RFC8995
>  onboarding process.";
>reference
>  "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
>  }
> 
>  organization
>   "IETF ANIMA Working Group";
> 
>  contact
>   "WG Web:
>  .org%2Fwg%2Fanima%2Fdata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7BDzJ4MjL%2BaCAAh
> v4A2PZLl2pB0b7WoNM19qAEGVICU%3Dreserved=0>
>WG List:  
>Author:   Steffen Fries
>  
>Author:   Hendrik Brockhaus
>  
>Author:   Eliot Lear
>  
>Author:   Thomas Werner
>  ";
>  description
>   "This module defines an extension of the RFC8995 voucher
>request to permit a registrar-agent to convey the adjacency
>relationship from the registrar-agent to the registrar.
> 
>The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
>'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
>and 'OPTIONAL' in the module text are to be interpreted as
>described in RFC 2119.";
>  revision 2021-08-13 {
>description
> "Initial version";
>reference
> "RFC : Voucher Request for Asynchronous Enrollment";
>  }
>  rc:yang-data voucher-request-async-artifact {
>// YANG data template for a voucher.
>uses voucher-request-async-grouping;
>  }
>  // Grouping defined for future usage
>  grouping voucher-request-async-grouping {
>description
>  "Grouping to allow reuse/extensions in future work.";
>uses ivr:voucher-request-grouping {
> 
>  augment voucher {
>description "Base the constrained voucher-request upon the
>  regular one";
>leaf agent-signed-data