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

["Fries, Steffen" <[e-mail]>]

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 <[e-mail]> On Behalf Of Reshad Rahman via
> Datatracker
> Sent: Sonntag, 15. August 2021 17:23
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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%2Fyangvalidator&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qZYcLcbndcMuCb77Zj
> sWzaXAhcLQTqYixESNNN4h%2BcA%3D&amp;reserved=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.2&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=kynl2GRBX1uCdL8hvU
> %2BZVqkHKdTMrp%2B4u5ZsYZWzcLE%3D&amp;reserved=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.4&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cnmkIb3STbSR5BHuwI
> GWxsj2lMYMs7AmlbMtF8euKhU%3D&amp;reserved=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.7&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yGzdefsWVH2Hh2%2
> B5IPJiCplkkQ82KQgsPpKLjOV%2BlrI%3D&amp;reserved=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%2F18&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883255
> 602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=a7GFxdMxFfZ65hYCa3
> dWR8VR7apcwUeTtudUppFFysw%3D&amp;reserved=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%2F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CCOwD%2Bah2tRbrw
> zENSiREVaiFV2wpZqwjosP5LFCi9E%3D&amp;reserved=0 and
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FOrJYk01en82VVG-
> Ncud1YWxCBtg%2F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wi%2BFqLKFxdK3WW
> 6NhRUSVnQoCaCxOLevXt1sBQZC%2Fm0%3D&amp;reserved=0
> 
> 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. 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bfd-yang-17%23section-
> 2.12&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=XmG%2BhJU5FW5CSd
> NS9uOW2EuC39F2qN9ExXJJDqVtyZc%3D&amp;reserved=0 is for BFD registries
> maintained by IANA
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc5880%23section-
> 8&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vfl2p3p64px3zjY1x1qu
> vESQWC28SCnGynAZXK1Xn7E%3D&amp;reserved=0).
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fmsg%2Fnetmod%2FdNGvcvckwuS_pBmkVg_Te8bedZs%2
> F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Gp3iK%2F%2B9PYogX
> gYM4Rd3mIRw9mJHMz4kDwg48ucymGE%3D&amp;reserved=0. For an
> example, see
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-
> 7.18.3&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=J0tpewRRp2%2Fcipztr
> aYPPC9%2FtagGQ3S879ehphxRPdY%3D&amp;reserved=0
> 
> 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. - Prefix
> "ivr" is used for ietf-voucher-request although RFC8995 has "vcr". While this is
> valid, I am curious why. - Please take a look at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23appendix-
> B&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oyAUYIKQZSQxxURiRc
> j0RTlM6kiupsa6PqRs0hb86jg%3D&amp;reserved=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:
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf
> .org%2Fwg%2Fanima%2F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7BDzJ4MjL%2BaCAAh
> v4A2PZLl2pB0b7WoNM19qAEGVICU%3D&amp;reserved=0>
>        WG List:  <mailto:[e-mail]>
>        Author:   Steffen Fries
>                  <mailto:[e-mail]>
>        Author:   Hendrik Brockhaus
>                  <mailto: [e-mail]>
>        Author:   Eliot Lear
>                  <mailto: [e-mail]>
>        Author:   Thomas Werner
>                  <mailto: [e-mail]>";
>      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 XXXX: 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 {
>              type binary;
>              description
>                "The agent-signed-data field contains a JOSE [RFC7515]
>                 object provided by the Registrar-Agent to the Pledge.
> 
>                 This artifact is signed by the Registrar-Agent
>                 and contains a copy of the pledge's serial-number.";
>            }
> 
>            leaf agent-provided-proximity-registrar-cert {
>              type binary;
>              description
>                "An X.509 v3 certificate structure, as specified by
>                 RFC 5280, Section 4, encoded using the ASN.1
>                 distinguished encoding rules (DER), as specified
>                 in ITU X.690.
>                 The first certificate in the registrar TLS server
>                 certificate_list sequence (the end-entity TLS
>                 certificate; see RFC 8446) presented by the
>                 registrar to the registrar-agent and provided to
>                 the pledge.
>                 This MUST be populated in a pledge's voucher-request
>                 when an agent-proximity assertion is requested.";
>              reference
>                "ITU X.690: Information Technology - ASN.1 encoding
>                 rules: Specification of Basic Encoding Rules (BER),
>                 Canonical Encoding Rules (CER) and Distinguished
>                 Encoding Rules (DER)
>                 RFC 5280: Internet X.509 Public Key Infrastructure
>                 Certificate and Certificate Revocation List (CRL)
>                 Profile
>                 RFC 8446: The Transport Layer Security (TLS)
>                 Protocol Version 1.3";
>            }
> 
>            leaf agent-sign-cert {
>              type binary;
>              description
>                "An X.509 v3 certificate structure, as specified by
>                 RFC 5280, Section 4, encoded using the ASN.1
>                 distinguished encoding rules (DER), as specified
>                 in ITU X.690.
>                 This certificate can be used by the pledge,
>                 the registrar, and the MASA to verify the signature
>                 of agent-signed-data. It is an optional component
>                 for the pledge-voucher request.
>                 This MUST be populated in a registrar's
>                 voucher-request when an agent-proximity assertion
>                 is requested.";
>              reference
>                "ITU X.690: Information Technology - ASN.1 encoding
>                 rules: Specification of Basic Encoding Rules (BER),
>                 Canonical Encoding Rules (CER) and Distinguished
>                 Encoding Rules (DER)
>                 RFC 5280: Internet X.509 Public Key Infrastructure
>                 Certificate and Certificate Revocation List (CRL)
>                 Profile";
>            }
>          }
>        }
>      }
>    }
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fanima&amp;data=04%7C01%7Ccef9763c-149c-
> 4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BBO%2FhGYnqAUtGF
> 3Jc5KBxe53v3jF%2BpyWdukQSAmp9x8%3D&amp;reserved=0