BRSKI with Pledge in Responder Mode (BRSKI-PRM)
draft-ietf-anima-brski-prm-23

Hi Authors, thanks for submitting -23 of the draft. However, I believe Gorry provided additional comments w.r.t. -22, that I do not see reflected in this version. Are you planning to submit another version?

[Ballot comment]
Thank you for preparing this document, and the update in rev-19/20, and the additional text describing the relation to TLS 1.3.

1. There appears to be some slight format problem with the bullets I saw listed in my rendering:
  “such as: * Avoid
  logging personally identifiable information unless unavoidable. *
  Anonymize or pseudonymize data where possible.” (resolved).

2. I did not understand the list of three security considerations at the start of section 12. At least, it would be very helpful to explain these in sufficient detail to understand each, and also helpful to understand the implications for users of each. Some words to clarify would be very helpful.

3. Please could you add text to explain “no transport layer security between Registrar-Agent and pledge..” e.g., please explain: Is this something that users ought to add to a design? how? why? is it a desirable property? Why? ... or is this intended to be explained more in the next subsections? ... Especially since 7.1 speaks of optional use of TLS.

4. Please update the text to clarify what is intended by: “Pledges MAY support both initiator and responder mode.” ... (resolved - made "may").

5. Please consider updating the text:
    “503 Service Unavailable: if a simple retry of the Registrar-Agent
      request might lead to a successful response; this error response
      SHOULD include the Retry-After response header field with an
      appropriate value”
- Why is this not a MUST, if there is a reason, please explain the alternative to the SHOULD and when this is a suitable response.

[Ballot comment]
Thanks for addressing my previous DISCUSS.

Please see https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ for more details on handling ballot positions. These comments are offered purely to improve the document, and their incorporation is at the discretion of the authors and the responsible AD.

=====================

In 5.1, can the contents of the slide be extracted and placed as a figure in the document, or is there a reason we need to deep-link into an old presentation?

Section 7.3 appears in neither of the tables in 6.2/6.3; upon further reading, I see that's because the endpoint is already defined in RFC8995. However, as the behavior is modified in this document I suggest noting the existence of behavior changes in 6.3, even if it's not a new endpoint. It helps make Section 6 a more complete roadmap of the forthcoming section.

The third paragraph of 6.3.1 seems unclear. Perhaps reword this?

Check your usage of the terms "HTTP(S)", "HTTPS", and "HTTP-over-TLS". I assume that the first two are intended to differentiate when TLS is optional and when it's required, but the latter two seem duplicative of each other.

Some of the 2119 language in 7.x is unneeded; a few examples:
- "MUST begin" could simply be "begins". The Agent is acting in its own time when it wants to begin the process.
- "SHALL trigger" could simply be "triggers", and so on.
- "MASA ... MUST support the same formats" is simply a statement of a correct deployment, not a protocol conformance issue. If the MASA doesn't support the format, the agent will get the 415 status code described below.

The requirements on the formats of the messages are appropriate 2119 targets, however, as is the Pledge's response when a trigger message is received.

Given the multiple ways that processing caCerts could fail, it might be worth permitting some optional error detail in 7.7.2 for the Registrar-Agent to log and/or debug.

Appendix A.2 defines the culinary term "parboiled" and references its use in RFC 8995. It appears that while 8995 uses it in the filename of one example, it does not use the term to define any portion of the protocol, nor does this document. If its use is widespread among implementers and it is useful/necessary to know, elevate it to a Section 2 definition and use it as appropriate throughout the document. Otherwise, it seems like the term could be dropped entirely without loss of clarity.

Nits:

- Section 4 has several extraneous commas.
- Expand "incl." in 5.1
- Consider expanding/defining CMS on first use or in Terminology, including a reference directly to RFC 5652
- Section 7.6, inconsistent capitalization of R/registrar and "to optimize [this process]"?
- Section 7.7, extra comma after "only be done"
- Section 11 has bullet points that render as in-line asterisks

[Ballot discuss]
Thank you for preparing this document, and the update in rev-19/20, I'd appreciate more clarity in the text:

1. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY" rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC 9325, which asserts that TLS 1.3 is in widespread use.

(see the related DISCUSS from Mike Bishop)

[Ballot comment]
(updated ballot for -20)
Thank you to Paul Kyzivat for the GENART review.

Thank you for addressing my DISCUSS feedback.

(Comments on -18)

** Section 4.

  *  The use of authenticated self-contained objects addresses both,
      the TLS challenges and the technology stack challenge.

What are “technology stack challenges”?

** Section 6.1
  Alternatively, the registrar EE
  certificate MAY be provided via configuration or a repository

What is a “repository” and how is that difference than “configuration”?

** Section 6.1
  Further, the Registrar-Agent SHOULD have synchronized time.

What is the impact of not having synchronized time?

** Section 6.1.2
  Note that this goes against the naming recommendation of [RFC6763].
  The _brski-pledge._tcp service, however, targets machine-to-machine
  discovery.

What in RFC6763 suggests a scope that would exclude “machine-to-machine discovery” to provide justification for not following its recommendation?

** Section 6.1.2
  For Ethernet,
  it is provided by simply connecting the network cable.

Isn’t this an oversimplification?  What if it there is local policy which manages the behavior of the interface?  What about provisioning that might need to occur on a switch?

** Section 6.1.2
  How to gain network
  connectivity is out of scope of this document.

If this is the case, why is there discussion of WiFi, Ethernet, references to [I-D.richardson-emu-eap-onboarding], and 6LoWPAN.

** Section 6.3
  Overall, this may have
  operational implications when the registrar is part of a scalable
  framework as described in Section 1.3.1 of
  [I-D.richardson-anima-registrar-considerations].

If these operational implications are important, why are they an informative reference in an unadopted I-D?

** Section 6.3.1
  This may be supported by a specific naming in the SAN (subject
  alternative name) component of the Registrar-Agent EE certificate,
  which allows the domain registrar to explicitly detect already in the
  TLS session establishment that the connecting client is a Registrar-
  Agent.

What is the standardized approach for this naming scheme to enable interoperability?  Is this out of scope?

** Section 7.1.1.1.1
  The serial-number member SHALL contain the product-serial-number of
  the pledge with which the Registrar-Agent assumes to communicate as
  string. 

Is this the same serial number as emitted in in mDNS in Section 6.1.2?

** Section 7.1.1.1.2.  are there any MTI “alg”s to support to ensure interoperability?

** Section 7.3
  The registrar SHOULD verify the TLS client authentication of the
  Registrar-Agent, in particular if the TLS session is used to obtain
  the Registrar-Agent EE certificate (see Section 6.3).

Why wouldn’t the client authentication be verified?  When is this acceptable to do?

** Section 9
  Besides the above, also consider the existing documents on
  operational modes for
  *  BRSKI registrars in
      [I-D.richardson-anima-registrar-considerations]

  *  BRSKI MASA in [I-D.richardson-anima-masa-considerations]

What does it mean to “consider” these documents?  Are they relevant operational considerations?

[Ballot comment]
Version -20 addresses all my comments, hence my new No Objection ballot.

# Below is for easy archiving (feel free to ignore)

Thank you for the work put into this document (even using nice SVG graphics!), I am afraid that my review was rather superficial (lack of time due to last week AI pref interim), but I trust the responsible AD. It is also interesting to see how the scope has increased in the 10 years of ANIMA (while staying in the charter) from always-on big routers network to IoT.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Matthias Kovatsch for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to David Lawrence, the DNS directorate reviewer, please consider this dns-dir review:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/reviewrequest/21545/ (thanks Steffen for your reply)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (archived)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 6.1.2

It appears that there is no restriction on 'product-serial-number' in this section and for mDNS a label has a strict syntax, i.e., if the serial number is always composed of only digits or A-2 or '-', then all is good, but if there is a dot, then all is bad or if the serial number if longer than 255 characters... Can this syntax check be added ?

`Note that the service name definition is not fully inline with the naming recommendation of [RFC6763]. However, the definition allows to discover specific instances of a pledge.` the readers and implementers will appreciate some explanations for the deviation and how to minimize the impact.

## COMMENTS (archived)

### Section 4

Please expand `BTLE` (usually written BLE I think). And section 7 uses a different acronym in `Bluetooth Low Energy (BLE), or Near Field Communication (NFC)`

`over other technologies like BTLE or NFC, which may not support TLS protected communication` but the 6LO WG has defined IP over these media, i.e., COAP could be used. Suggest adding text why 6LO WG technologies cannot be used.

`The use of authenticated self-contained objects addresses both, the TLS challenges` for sure mTLS offers authentication, but it also offers confidentiality and that is not the case for `authenticated self-contained objects`. Or did I miss something obvious ?

### Section 5

About the title s/5. Solution Architecture/5. Architecture/

### Section 5.1

I was about to DISCUSS this point as I find *very unusual* to refer to another PDF document rather than having a SVG/ASCII ART diagram in the I-D... `An abstract overview of the BRSKI-PRM protocol can be found on slide 8 of [BRSKI-PRM-abstract].`

In which figure ? `Note that the Join Proxy is not shown in the figure` ? I guess it is about figure 1, but let's be precise.

Figure 1, what does `drop ship` means on this figure ?

### Section 6.1.2

I noted that authors of the related draft-ietf-anima-brski-discovery also tried to interact with the DNSSD WG, see https://mailarchive.ietf.org/arch/msg/dnssd/rWqgj_c_ZRT6CTGi7gby1r5FdLQ/ which is good of course. Thanks.

### Section 10.2

While I noted that the datatrack IANA note says OK, please add the exact URI for the IANA registry as I was unable to find it in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-pledge if this was the intended registry then s/IANA has registered the following service name*s*/IANA is requested to register the following service name/


## NITS (non-blocking / cosmetic)

### Section 7.2.2.2 (and other places)

You may want to use 2025 rather than 2022 ;-)

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-anima-brski-prm-19
CC @evyncke

Thank you for the work put into this document (even using nice SVG graphics!), I am afraid that my review was rather superficial (lack of time due to last week AI pref interim), but I trust the responsible AD. It is also interesting to see how the scope has increased in the 10 years of ANIMA (while staying in the charter) from always-on big routers network to IoT.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Matthias Kovatsch for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to David Lawrence, the DNS directorate reviewer, please consider this dns-dir review:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/reviewrequest/21545/ (thanks Steffen for your reply)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 6.1.2

It appears that there is no restriction on 'product-serial-number' in this section and for mDNS a label has a strict syntax, i.e., if the serial number is always composed of only digits or A-2 or '-', then all is good, but if there is a dot, then all is bad or if the serial number if longer than 255 characters... Can this syntax check be added ?

`Note that the service name definition is not fully inline with the naming recommendation of [RFC6763]. However, the definition allows to discover specific instances of a pledge.` the readers and implementers will appreciate some explanations for the deviation and how to minimize the impact.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 4

Please expand `BTLE` (usually written BLE I think). And section 7 uses a different acronym in `Bluetooth Low Energy (BLE), or Near Field Communication (NFC)`

`over other technologies like BTLE or NFC, which may not support TLS protected communication` but the 6LO WG has defined IP over these media, i.e., COAP could be used. Suggest adding text why 6LO WG technologies cannot be used.

`The use of authenticated self-contained objects addresses both, the TLS challenges` for sure mTLS offers authentication, but it also offers confidentiality and that is not the case for `authenticated self-contained objects`. Or did I miss something obvious ?

### Section 5

About the title s/5. Solution Architecture/5. Architecture/

### Section 5.1

I was about to DISCUSS this point as I find *very unusual* to refer to another PDF document rather than having a SVG/ASCII ART diagram in the I-D... `An abstract overview of the BRSKI-PRM protocol can be found on slide 8 of [BRSKI-PRM-abstract].`

In which figure ? `Note that the Join Proxy is not shown in the figure` ? I guess it is about figure 1, but let's be precise.

Figure 1, what does `drop ship` means on this figure ?

### Section 6.1.2

I noted that authors of the related draft-ietf-anima-brski-discovery also tried to interact with the DNSSD WG, see https://mailarchive.ietf.org/arch/msg/dnssd/rWqgj_c_ZRT6CTGi7gby1r5FdLQ/ which is good of course. Thanks.

### Section 10.2

While I noted that the datatrack IANA note says OK, please add the exact URI for the IANA registry as I was unable to find it in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-pledge if this was the intended registry then s/IANA has registered the following service name*s*/IANA is requested to register the following service name/


## NITS (non-blocking / cosmetic)

### Section 7.2.2.2 (and other places)

You may want to use 2025 rather than 2022 ;-)

[Ballot discuss]
Thank you for preparing this document, and the updaye in rev-19, I have remaining questions where I'd appreciate more clarity in the text:

1. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY" rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC 9325, which asserts that TLS 1.3 is in widespread use. (see related DISCUSS from Mike Bishop).

2. I could not understand the protocol action of the “MUST” requirement below (i.e. what does “available” mean for a RFC2119 requirement?:
    “if the certificate chain
      is not included in the x5c Header Parameter, it MUST be available
      at the domain registrar for verification”
Please consider changing this text, for instance text like the following could be helpful:
“if the certificate chain is not available at the domain registrar for verification, ... MUST ... be done“.

[Ballot comment]

1. There appears to be some slight format problem with the bullets I saw listed in my rendering:
  “such as: * Avoid
  logging personally identifiable information unless unavoidable. *
  Anonymize or pseudonymize data where possible.” (resolved).

2. I did not understand the list of three security considerations at the start of section 12. At least, it would be very helpful to explain these in sufficient detail to understand each, and also helpful to understand the implications for users of each. Some words to clarify would be very helpful.

3. Please could you add text to explain “no transport layer security between Registrar-Agent and pledge..” e.g., please explain: Is this something that users ought to add to a design? how? why? is it a desirable property? Why? ... or is this intended to be explained more in the next subsections? ... Especially since 7.1 speaks of optional use of TLS.

4. Please update the text to clarify what is intended by: “Pledges MAY support both initiator and responder mode.” ... (resolved - made "may").

5. Please consider updating the text:
    “503 Service Unavailable: if a simple retry of the Registrar-Agent
      request might lead to a successful response; this error response
      SHOULD include the Retry-After response header field with an
      appropriate value”
- Why is this not a MUST, if there is a reason, please explain the alternative to the SHOULD and when this is a suitable response.

[Ballot comment]
Hi Steffen, Thomas, Eliot, and Michael,

Thank you for the productive discussion and for addressing almost all my points raised in [1]. The companion discussion [2] triggered by [1] is also instructive.

(1) As indicated in the thread, I trust Mahesh will do the right thing with the following (used-to-be DISCUSS point):

# Cluster with 8366bis

CURRENT:

  The JSON PVR Data MUST contain the following fields of the “ietf-
  voucher-request” YANG module as defined in
  [I-D.ietf-anima-rfc8366bis];

I think this spec should be clustered with 8366bis. There are several structures that used in this document and which depend on what is defined in 8366bis. Changes to the bis will have implications on this one.

(2) Here are some few comments found when checking 18/19 diff:

* nit

OLD: building automation use case mentioned in (Section 3.1.1)

NEW: building automation use case mentioned in Section 3.1.1

* Smells like a normative reference. Please change as follows:

OLD: if it does not support a more general discovery as defined in [I-D.ietf-anima-brski-discovery]

NEW: if it does not support a more general discovery such as defined in [I-D.ietf-anima-brski-discovery]

* nit

OLD: limiting for a requests to avoid susceptibility of the pledge

NEW: limiting for requests to avoid susceptibility of the pledge

* nit (many occurrences)

OLD: Algorithms supported for JWS signatures MUST support

NEW: Algorithms used for JWS signatures MUST support

* Extra references, really?

CURRENT:

  Requirements to the utilized credentials authenticating and artifact
  signatures on the registrar as outlined in Section 6.3 may have
  operational implications when the registrar is part of a scalable
  framework as described in Section 1.3.1 of
  [I-D.richardson-anima-registrar-considerations].

  Besides the above, also consider the existing documents on
  operational modes for

  *  BRSKI registrars in
      [I-D.richardson-anima-registrar-considerations]

  *  BRSKI MASA in [I-D.richardson-anima-masa-considerations]

I-D.richardson-anima-registrar-considerations cited in "Besides the above," was cited in the sentence right above ;-)

Please update.

* Commentary not intended initially to make it into the text:

CURRENT:
  Documents that define exclusively modules following the extension in
  [RFC8971] are not required to include the security template in
  Section 3.7.1.  Likewise, following the template is not required for
  modules that define YANG extensions such as [RFC7952].

I provided this text to motivate what you can safely remove the old paragraph. But, if you want to include it, then some tweaking is needed (Section 3.7.1 ref is broken in the context of this draft + we don't use 7952 here), I suggest:

NEW:
  Documents that define exclusively modules following the extension in
  [RFC8971] are not required to include the YANG security template per
  the guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].

Many thanks again for editing such a well-written document.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/anima/qHRppN_6T3KBdsjOksxu8bw4byI/

[2] https://mailarchive.ietf.org/arch/msg/anima/8HLrJ_PLjIbf11gZjMTuXkC2Z9g/

[Ballot comment]
Hi Steffen, Thomas, Eliot, and Michael,

Thank you for the productive discussion and for addressing almost all my points raised in [1]. The companion discussion [2] triggered by [1] is also instructive.

(1) As indicated in the thread, I trust Mahesh will do the right thing with the following (used-to-be DISCUSS point):

# Cluster with 8366bis

CURRENT:

  The JSON PVR Data MUST contain the following fields of the “ietf-
  voucher-request” YANG module as defined in
  [I-D.ietf-anima-rfc8366bis];

I think this spec should be clustered with 8366bis. There are several structures that used in this document and which depend on what is defined in 8366bis. Changes to the bis will have implications on this one.

(2) Here are some few comments found when checking 18/19 diff:

* nit

OLD: building automation use case mentioned in (Section 3.1.1)

NEW: building automation use case mentioned in Section 3.1.1

* Smells like a normative reference. Please change as follows:

OLD: if it does not support a more general discovery as defined in [I-D.ietf-anima-brski-discovery]

NEW: OLD: if it does not support a more general discovery such as defined in [I-D.ietf-anima-brski-discovery]

* nit

OLD: limiting for a requests to avoid susceptibility of the pledge

NEW: limiting for requests to avoid susceptibility of the pledge

* nit (many occurrences)

OLD: Algorithms supported for JWS signatures MUST support

NEW: Algorithms used for JWS signatures MUST support

* Extra references, really?

CURRENT:

  Requirements to the utilized credentials authenticating and artifact
  signatures on the registrar as outlined in Section 6.3 may have
  operational implications when the registrar is part of a scalable
  framework as described in Section 1.3.1 of
  [I-D.richardson-anima-registrar-considerations].

  Besides the above, also consider the existing documents on
  operational modes for

  *  BRSKI registrars in
      [I-D.richardson-anima-registrar-considerations]

  *  BRSKI MASA in [I-D.richardson-anima-masa-considerations]

I-D.richardson-anima-registrar-considerations cited in "Besides the above," was cited in the sentence right above ;-)

Please update.

* Commentary not intended initially to make it into the text:

CURRENT:
  Documents that define exclusively modules following the extension in
  [RFC8971] are not required to include the security template in
  Section 3.7.1.  Likewise, following the template is not required for
  modules that define YANG extensions such as [RFC7952].

I provided this text to motivate what you can safely remove the old paragraph. But, if you want to include it, then some tweaking is needed (Section 3.7.1 ref is broken in the context of this draft + we don't use 7952 here), I suggest:

CURRENT:
  Documents that define exclusively modules following the extension in
  [RFC8971] are not required to include the YANG security template per
  the guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].

Many thanks again for editing such a well-written document.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/anima/qHRppN_6T3KBdsjOksxu8bw4byI/

[2] https://mailarchive.ietf.org/arch/msg/anima/8HLrJ_PLjIbf11gZjMTuXkC2Z9g/

[Ballot discuss]
Thanks for a clear and well-structured document. Two points that I hope are easily addressed, and then I'll update my ballot to No Objection:

RFC 8995 predates draft-ietf-uta-require-tls13, obviously, since the latter is also with the IESG now. This document only restates 8995's TLS requirements on the registrar and the MASA, so those don't have to change here. However, in Section 7.3, should the REQUIRED/SHOULD alignment of TLS versions be swapped at least for the Registrar-Agent to match the new guidance? For new protocols, TLS 1.3 ought to be the requirement; TLS 1.2 is permitted. (Non-blocking: Consider whether to make corresponding requirements on the registrar and MASA when BRSKI-PRM is being used. However, without updating 8995, this would effectively make both versions mandatory for servers supporting both BRSKI and BRSKI-PRM.)

Can you give me a quick overview of the thinking between when you use the HTTP status codes 401 vs. 403? This document seems to use both 401 and 403 for various forms of failed authentication. In general, 401 means "I don't know who you are" and 403 means "I know who you are, and you don't get to do that." I don't see any language around the WWW-Authenticate response field RFC 9110 requires in a 401 response, for example. There may be BRSKI legacy here as well, but I'd like to understand a little better first. Given that you're passing around self-authenticating objects, there are multiple levels of authentication going on here that make it tricky.

[Ballot comment]
Please see https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ for more details on handling ballot positions. These comments are offered purely to improve the document, and their incorporation is at the discretion of the authors and the responsible AD.

=====================

In 5.1, can the contents of the slide be extracted and placed as a figure in the document, or is there a reason we need to deep-link into an old presentation?

Section 7.3 appears in neither of the tables in 6.2/6.3; upon further reading, I see that's because the endpoint is already defined in RFC8995. However, as the behavior is modified in this document I suggest noting the existence of behavior changes in 6.3, even if it's not a new endpoint. It helps make Section 6 a more complete roadmap of the forthcoming section.

The third paragraph of 6.3.1 seems unclear. Perhaps reword this?

Check your usage of the terms "HTTP(S)", "HTTPS", and "HTTP-over-TLS". I assume that the first two are intended to differentiate when TLS is optional and when it's required, but the latter two seem duplicative of each other.

Some of the 2119 language in 7.x is unneeded; a few examples:
- "MUST begin" could simply be "begins". The Agent is acting in its own time when it wants to begin the process.
- "SHALL trigger" could simply be "triggers", and so on.
- "MASA ... MUST support the same formats" is simply a statement of a correct deployment, not a protocol conformance issue. If the MASA doesn't support the format, the agent will get the 415 status code described below.

The requirements on the formats of the messages are appropriate 2119 targets, however, as is the Pledge's response when a trigger message is received.

Given the multiple ways that processing caCerts could fail, it might be worth permitting some optional error detail in 7.7.2 for the Registrar-Agent to log and/or debug.

Appendix A.2 defines the culinary term "parboiled" and references its use in RFC 8995. It appears that while 8995 uses it in the filename of one example, it does not use the term to define any portion of the protocol, nor does this document. If its use is widespread among implementers and it is useful/necessary to know, elevate it to a Section 2 definition and use it as appropriate throughout the document. Otherwise, it seems like the term could be dropped entirely without loss of clarity.

Nits:

- Section 4 has several extraneous commas.
- Expand "incl." in 5.1
- Consider expanding/defining CMS on first use or in Terminology, including a reference directly to RFC 5652
- Section 7.6, inconsistent capitalization of R/registrar and "to optimize [this process]"?
- Section 7.7, extra comma after "only be done"
- Section 11 has bullet points that render as in-line asterisks

[Ballot discuss]
** Section  6.1.2
  In the absence of a more general discovery as defined in
  [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use

The way this sentence is constructed makes [I-D.ietf-anima-brski-discovery] a normative reference.  Put more generally, it reads “If then MUST be used”.  To know that applies, one needs to fully understand .  I don't think that is the intent.

** Section 7.6.2.1
  *  reason: contains a human-readable message; SHOULD NOT provide
      information beneficial to an attacker

Per the requirement in Section 4.2 of RFC2277 that the “Protocols that transfer text MUST provide for carrying information about the language of that text”, what is the recommended approach here?

Same question for pvs-details in reason-context and pbs-details in reason-context (

** Section 7.6.2.1
  *  reason: contains a human-readable message; SHOULD NOT provide
      information beneficial to an attacker

...
  *  reason-context: contains a JSON object that provides additional
      information specific to a failure; in contrast to Section 5.7 of
      [RFC8995], MUST be provided; SHOULD NOT provide information
      beneficial to an attacker

When is it acceptable to provide information beneficial to the attacker?

[Ballot comment]
Thank you to Paul Kyzivat for the GENART review.

** Section 4.

  *  The use of authenticated self-contained objects addresses both,
      the TLS challenges and the technology stack challenge.

What are “technology stack challenges”?

** Section 6.1
  Alternatively, the registrar EE
  certificate MAY be provided via configuration or a repository

What is a “repository” and how is that difference than “configuration”?

** Section 6.1
  Further, the Registrar-Agent SHOULD have synchronized time.

What is the impact of not having synchronized time?

** Section 6.1.2
  Note that this goes against the naming recommendation of [RFC6763].
  The _brski-pledge._tcp service, however, targets machine-to-machine
  discovery.

What in RFC6763 suggests a scope that would exclude “machine-to-machine discovery” to provide justification for not following its recommendation?

** Section 6.1.2
  For Ethernet,
  it is provided by simply connecting the network cable.

Isn’t this an oversimplification?  What if it there is local policy which manages the behavior of the interface?  What about provisioning that might need to occur on a switch?

** Section 6.1.2
  How to gain network
  connectivity is out of scope of this document.

If this is the case, why is there discussion of WiFi, Ethernet, references to [I-D.richardson-emu-eap-onboarding], and 6LoWPAN.

** Section 6.3
  Overall, this may have
  operational implications when the registrar is part of a scalable
  framework as described in Section 1.3.1 of
  [I-D.richardson-anima-registrar-considerations].

If these operational implications are important, why are they an informative reference in an unadopted I-D?

** Section 6.3.1
  This may be supported by a specific naming in the SAN (subject
  alternative name) component of the Registrar-Agent EE certificate,
  which allows the domain registrar to explicitly detect already in the
  TLS session establishment that the connecting client is a Registrar-
  Agent.

What is the standardized approach for this naming scheme to enable interoperability?  Is this out of scope?

** Section 7.1.1.1.1
  The serial-number member SHALL contain the product-serial-number of
  the pledge with which the Registrar-Agent assumes to communicate as
  string. 

Is this the same serial number as emitted in in mDNS in Section 6.1.2?

** Section 7.1.1.1.2.  are there any MTI “alg”s to support to ensure interoperability?

** Section 7.3
  The registrar SHOULD verify the TLS client authentication of the
  Registrar-Agent, in particular if the TLS session is used to obtain
  the Registrar-Agent EE certificate (see Section 6.3).

Why wouldn’t the client authentication be verified?  When is this acceptable to do?

** Section 9
  Besides the above, also consider the existing documents on
  operational modes for
  *  BRSKI registrars in
      [I-D.richardson-anima-registrar-considerations]

  *  BRSKI MASA in [I-D.richardson-anima-masa-considerations]

What does it mean to “consider” these documents?  Are they relevant operational considerations?

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-anima-brski-prm-18
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### RFC 3339 or RFC 9557?

```
1500   The created-on member SHALL contain the current date and time at tPVR
1501   creation as standard date/time string as defined in Section 5.6 of
1502   [RFC3339].
```

See https://datatracker.ietf.org/doc/html/rfc9557#inconsistent


### Attacker controlled time?

```
1580   *  created-on: SHALL contain the current date and time at PVR
1581       creation as standard date/time string as defined in Section 5.6 of
1582       [RFC3339]; if the pledge does not have synchronized time, it SHALL
1583       use the created-on value from the JSON Agent-Signed Data received
1584       with the tPVR artifact and SHOULD advance that value based on its
1585       local clock to reflect the PVR creation time
```

Is there any risk of this section interacting with the provisional status?

See https://datatracker.ietf.org/doc/html/rfc8995#section-5.1-6


### nonce

```
1587   *  nonce: SHALL contain a cryptographically strong pseudo-random
1588       number
```

Do you mean a single number? or do you mean a sequence of byte of some length derived from some PRNG?

Consider language like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-17#section-9.3

### "created-on" vs "iat"

```
1826   {
1827     "alg": "ES256",
1828     "x5c": [
1829       "base64encodedvalue==",
1830       "base64encodedvalue=="
1831     ],
1832     "crit": ["created-on"],
1833     "created-on": "2022-09-13T00:00:02.000Z"
1834   }
```

Per https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 it is possible to replicate claims in headers.

I wonder why the existing `iat` claim is not sufficient for this use case, aside from being an integer.
It also seems like an integer based creation time would be easier and safer to use.

### application/pkcs7-mime

```
2407   A successful interaction with the Key Infrastructure will result in a
2408   pledge EE certificate signed by the domain owner (e.g., LDevID
2409   certificate).  The registrar MUST reply to the Registrar-Agent with
2410   the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the
2411   body of an HTTP 200 OK response.  In the response header, the
2412   Content-Type field MUST be set to application/pkcs7-mime.
```

https://datatracker.ietf.org/doc/html/rfc2311#section-3.2

I don't think you want the optional "smime-type" parameter, but you might want to comment on envelopedData vs signedData here.

### application/voucher-jws+json vs application/jose+json

```
2662   defined in Section 7.3.6.  In the request header, the Content-Type
2663   field MUST be set to application/voucher-jws+json as defined in
2664   [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to
2665   application/jose+json.
```

I found myself wondering which objects use `application/voucher-jws+json`  and which use `application/jose+json`.
A simple table might help explain this once upfront.
Are there cases where `application/jose+json` is used for encryption?


### reason-context

```
2771   *  reason-context: contains a JSON object that provides additional
2772       information specific to a failure; in contrast to Section 5.7 of
2773       [RFC8995], MUST be provided; SHOULD NOT provide information
2774       beneficial to an attacker
```

Consider giving this more structure, like: https://datatracker.ietf.org/doc/html/rfc7807#section-3

Also, seems potentially conflicting definitions exist:

```
3474       "reason-context": { * $$arbitrary-map }
```

Yet there are map keys defined with very specific semantics, consider gathering them in a table.


## Nits

### Consider clarifying not base64url-encoded

```
2567   format.  For JSON syntax, the octet-based certificates MUST be
2568   base64-encoded.  It SHALL contain one or more domain CA (root or
2569   issuing) certificates.
```

Since this is a common point of confusion, and you are using base64url nearby.
You might highlight this once for both `x5c` and `x5bag`.

### Registrar Endpoints

```
1071   +================+=========================+========================+
1072   | Endpoint      | Operation              | Exchange and Artifacts |
1073   +================+=========================+========================+
1074   | requestenroll  | Supply PER              | Section 7.4            |
1075   |                | to Registrar            |                        |
1076   +----------------+-------------------------+------------------------+
1077   | wrappedcacerts | Obtain CA              | Section 7.5            |
1078   |                | Certificates            |                        |
1079   +----------------+-------------------------+------------------------+

1081     Table 2: Additional Well-Known Endpoints on a BRSKI-PRM Registrar
```

Some `-` / `_` could improve readability of these... later in the document I see `voucher_status` and `enrollstatus`...

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-anima-brski-prm-18
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### RFC 3339 or RFC 9557?

```
1500   The created-on member SHALL contain the current date and time at tPVR
1501   creation as standard date/time string as defined in Section 5.6 of
1502   [RFC3339].
```

See https://datatracker.ietf.org/doc/html/rfc9557#inconsistent


### Attacker controlled time?

```
1580   *  created-on: SHALL contain the current date and time at PVR
1581       creation as standard date/time string as defined in Section 5.6 of
1582       [RFC3339]; if the pledge does not have synchronized time, it SHALL
1583       use the created-on value from the JSON Agent-Signed Data received
1584       with the tPVR artifact and SHOULD advance that value based on its
1585       local clock to reflect the PVR creation time
```

Is there any risk of this section interacting with the provisional status?

See https://datatracker.ietf.org/doc/html/rfc8995#section-5.1-6


### nonce

```
1587   *  nonce: SHALL contain a cryptographically strong pseudo-random
1588       number
```

Do you mean a single number? or do you mean a sequence of byte of some length derived from some PRNG?

Consider language like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-17#section-9.3

### "created-on" vs "iat"

```
1826   {
1827     "alg": "ES256",
1828     "x5c": [
1829       "base64encodedvalue==",
1830       "base64encodedvalue=="
1831     ],
1832     "crit": ["created-on"],
1833     "created-on": "2022-09-13T00:00:02.000Z"
1834   }
```

Per https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 it is possible to replicate claims in headers.

I wonder why the existing `iat` claim is not sufficient for this use case, aside from being an integer.
It also seems like an integer based creation time would be easier and safer to use.

### application/pkcs7-mime

```
2407   A successful interaction with the Key Infrastructure will result in a
2408   pledge EE certificate signed by the domain owner (e.g., LDevID
2409   certificate).  The registrar MUST reply to the Registrar-Agent with
2410   the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the
2411   body of an HTTP 200 OK response.  In the response header, the
2412   Content-Type field MUST be set to application/pkcs7-mime.
```

https://datatracker.ietf.org/doc/html/rfc2311#section-3.2

I don't think you want the optional "smime-type" parameter, but you might want to comment on envelopedData vs signedData here.

### application/voucher-jws+json vs application/jose+json

```
2662   defined in Section 7.3.6.  In the request header, the Content-Type
2663   field MUST be set to application/voucher-jws+json as defined in
2664   [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to
2665   application/jose+json.
```

I found myself wondering which objects use `application/voucher-jws+json`  and which use `application/jose+json`.
A simple table might help explain this once upfront.
Are there cases where `application/jose+json` is used for encryption?


### reason-context

```
2771   *  reason-context: contains a JSON object that provides additional
2772       information specific to a failure; in contrast to Section 5.7 of
2773       [RFC8995], MUST be provided; SHOULD NOT provide information
2774       beneficial to an attacker
```

Consider giving this more structure, like: https://datatracker.ietf.org/doc/html/rfc7807#section-3

Also, seems potentially conflicting definitions exist:

```
3474       "reason-context": { * $$arbitrary-map }
```

Yet there are map keys defined with very specific semantics, consider gathering them in a table.


## Nits

### Consider clarifying not base64url-encoded

```
2567   format.  For JSON syntax, the octet-based certificates MUST be
2568   base64-encoded.  It SHALL contain one or more domain CA (root or
2569   issuing) certificates.
```

Since this is a common point of confusion, and you are using base64url nearby.
You might highlight this once for both `x5c` and `x5bag`.

### Registrar Endpoints

```
1071   +================+=========================+========================+
1072   | Endpoint      | Operation              | Exchange and Artifacts |
1073   +================+=========================+========================+
1074   | requestenroll  | Supply PER              | Section 7.4            |
1075   |                | to Registrar            |                        |
1076   +----------------+-------------------------+------------------------+
1077   | wrappedcacerts | Obtain CA              | Section 7.5            |
1078   |                | Certificates            |                        |
1079   +----------------+-------------------------+------------------------+

1081     Table 2: Additional Well-Known Endpoints on a BRSKI-PRM Registrar
```

Some `-` / `_` could improve readability of these... later the in the document I see  `voucher_status` and `enrollstatus`...

[Ballot comment]
Section 7.3, para 2:  Pick one:  either 'mutual authentication' or 'client authentication'.  If you pick 'mutual authentication', then in sentence 2, it could be 'mTLS uses....' [one should do a global search, there are a bunch of 'client authentication' instances throughout the draft]

Section 7.3, para 3:  Is this suggesting that the registrar only needs to verify the Registrar-Agent's connection if it doesn't already have the Registrar-Agent's EE certificate?  seems odd....and possibly insecure.

Section 12.1:  Is there a resource exhaustion DOS attack on the Pledge?

Section 6.1 and 12.3:  Doesn't frequent rekey of the Registrar-Agent lead to synchronization issues with the Registrar?  How is this mitigated?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-prm-18

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt

# for your convenience, please find some non-blocking COMMENTS

# My review is rather generic and high level, it is not my area of expertise. If my comments refer to items obvious when familiar with the technology, then feel free to ignore.

# comments
# ========

14 Abstract

GV> Would this abstract be a viable alternative?

"
This document defines the BRSKI-PRM (Pledge in Responder Mode) variant of the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. BRSKI-PRM supports the secure enrollment of devices, referred to as pledges, into a domain where direct communication with the registrar is not possible. Instead, the pledges interact with a proxy entity that relays authenticated and authorized enrollment requests to the registrar. This approach accommodates deployment scenarios where network constraints, operational considerations, or topological factors prevent direct pledge-to-registrar communication. The protocol extensions defined in this document maintain the security and trust properties of BRSKI while enabling broader applicability in constrained or segmented environments.
"

183   Security information about the customer domain, specifically the
184   customer domain certificate, are exchanged and authenticated
185   utilizing signed data objects, the voucher artifacts as defined in
186   [RFC8995].

GV> original text reads odd. Revised textblob:

"
Security information pertaining to the customer domain, specifically, the customer domain certificate, is exchanged and authenticated through the use of signed data objects, namely the voucher artifacts, as defined in [RFC8995].
"



3789 10.2.  Service Name and Transport Protocol Port Number Registry
3790
3791   IANA has registered the following service names:
3792
3793   *Service Name:* brski-pledge
3794   *Transport Protocol(s):* tcp
3795   *Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org)
3796   *Contact:* IETF Chair chair@ietf.org (mailto:chair@ietf.org)
3797   *Description:* The Bootstrapping Remote Secure Key Infrastructure
3798   Pledge
3799   *Reference:* [THISRFC]

GV> Does this need to be the iesg and the chair to be as assignee and contact? At first glance this looks unusual. This seems to have happened in v18 of the draft.

Gunter Van de Velde
RTG Area Director

[Ballot discuss]
Thank you for preparing this document. I have the following four questions where I'd appreciate more clarity in the text:

1. The text says: “SHOULD NOT provide information beneficial to an attacker”.
I don’t understand the RFC 2119 SHOULD recommendation. To me, the current text does not say what actually has to be done, or what ought not to be done (e.g. citing some suitable RFCs to help clarify what is needed). Also I do wonder whether this be a “MUST”? (i.e., under what conditions is it considered good to provide information to benefit an attacker?). Could this just be wisdom - e.g.”needs to avoid”, rather than a protocol requirement?

2. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY" rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC 9325, which asserts that TLS 1.3 is in widespread use.

3. I could not understand the protocol action of the “MUST” requirement below (i.e. what does “available” mean for a RFC2119 requirement?:
    “if the certificate chain
      is not included in the x5c Header Parameter, it MUST be available
      at the domain registrar for verification”
Please consider changing this text, for instance text like the following could be helpful:
“if the certificate chain is available at the domain registrar for verification, it MAY be omitted from the x5c Header Parameter“.

4. Please update the text to explain/clarify:
  “The registrar MAY consider ignoring any but the newest PER
  artifact from the same pledge in case the registrar has at any point
  in time more than one pending PER from the pledge?"
I don't understand the requirement from the text, please explain: For example, could this  perhaps be a RFC2119 requirememnt: "MAY ignore" .. and then add text to describe when this is allowed (or not).

[Ballot comment]

1. There appears to be some slight format problem with the bullets I saw listed in my rendering:
  “such as: * Avoid
  logging personally identifiable information unless unavoidable. *
  Anonymize or pseudonymize data where possible.”

2. I did not understand the list of three security considerations at the start of section 12. At least, it would be very helpful to explain these in sufficient detail to understand each, and also helpful to understand the implications for users of each. Some words to clarify would be very helpful.

3. Please could you add text to explain “no transport layer security between Registrar-Agent and pledge..” e.g., please explain: Is this something that users ought to add to a design? how? why? is it a desirable property? Why? ... or is this intended to be explained more in the next subsections? ... Especially since 7.1 speaks of optional use of TLS.

4. Please update the text to clarify what is intended by: “Pledges MAY support both initiator and responder mode.” Is this MAY intended to permit *both* of the modes, or *either* of the modes, or something else?

5. Please consider updating the text:
    “503 Service Unavailable: if a simple retry of the Registrar-Agent
      request might lead to a successful response; this error response
      SHOULD include the Retry-After response header field with an
      appropriate value”
- Why is this not a MUST, if there is a reason, please explain the alternative and when this is a suitable response.

[Ballot discuss]
Hi Steffen, Thomas, Eliot, and Michael,

Many thanks for editing such a well-written document. Enjoyed reading it, although some repetition here and there but that can be easily fixed.

Special thanks for the well thought management/logging/operational considerations.

Thanks to Ran Chen for the opsdir review.

I have some few DISCUSS/COMMENT points. I will send you offline a set of minor/edits.

# DISCUSS

# Unconditional MUST

CURRENT:
  The pledge MUST respond to all requests regardless of the
  Host header field provided by the client (i.e., ignore it). 

I don’t think that is safe.

I’m afraid this needs some scoping; as there are other legitimate conditions where the pledge doe snot have to reply.

# Compliance with HTTP BCP (RFC9205)

CURRENT:
  If the pledge is unable to create the PVR, it SHOULD respond with an
  HTTP error status code to the Registrar-Agent.  The following client
  error status codes SHOULD be used:

The use of normative language is IMO not compliant with the guidance in RFC9205, about error handling.

There are several similar constructs in the document.

# Cluster with 8366bis

CURRENT:

  The JSON PVR Data MUST contain the following fields of the “ietf-
  voucher-request” YANG module as defined in
  [I-D.ietf-anima-rfc8366bis];

I think this spec should be clustered with 8366bis. There are several structure that used in this document and which depends on what is defined in 8366bis. Changes to the bis will have implications on this one.

With that in mind, I tend to suggest holding approval of this specification till we finalize the bis spec.

# Requires TLS1.3

CURRENT:
  As already stated in [RFC8995], the use of TLS 1.3 (or newer) is
  encouraged.  TLS 1.2 or newer is REQUIRED on the Registrar-Agent
  side.  TLS 1.3 (or newer) SHOULD be available on the registrar, but
  TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be available on the
  MASA, but TLS 1.2 MAY be used.

Please update to take into to reflect draft-ietf-uta-require-tls13.

[Ballot comment]
# Consider having a reference figure early in the document with the various entities.

# Be consistent through the document about how you expand as both forms are used: Xccc Xccc Xcc (XXX) or XXX (Xccc Xccc Xcc).

# Entities are functional one: There might be multiple servers, RAs, pledges, etc. Consider fixing this through the document. For example:


OLD:
  EST in turn
  relies for the authentication and authorization of the certification
  request on the credentials used by the underlying TLS between the EST
  client and the EST server.

NEW:
  EST in turn
  relies for the authentication and authorization of the certification
  request on the credentials used by the underlying TLS between the EST
  client and an EST server.
 

OLD: BRSKI addresses scenarios in which the pledge initiates the
NEW: BRSKI addresses scenarios in which a pledge initiates the

OLD:
  *  introduces the Registrar-Agent as new component to facilitate the
      communication between the pledge and the domain registrar. 

NEW:
  *  introduces the Registrar-Agent as new component to facilitate the
      communication between the pledge and a domain registrar. 


OLD: is cryptographically bound to the end entity (EE) certificate.
NEW: is cryptographically bound to an end entity (EE) certificate.

Etc.

# Consider providing an example of non-IP

CURRENT:
  *  also enables the usage of alternative transports, both IP-based
      and non-IP,

# Capability management:

CURRENT
  There may be pledges that can support both modes, initiator and
  responder mode.  In these cases, BRSKI-PRM can be combined with BRSKI
  as defined in [RFC8995] or BRSKI-AE [I-D.ietf-anima-brski-ae] to
  allow for more bootstrapping flexibility.

Do we need to expose these capabilities to a management system? How this can be managed/controlled?

# Not a definition

CURRENT:
  CSR:  Certificate Signing Request.

This is not a definition. May be point to the RFC you cited in the doc.

# Resource vs. Endpoint

CURRENT:
  endpoint:  Term equivalent to resource in HTTP [RFC9110] and CoAP
      [RFC7252].  Endpoints are accessible via Well-Known URIs
      [RFC8615].

For the CoAP mention, this may be confusing as CoAP has also the concept of “Endpoint”, which is not identical to resource.

# Lack of reference

CURRENT:
mTLS:  mutual Transport Layer Security.

# Unfortunate acronym

PoP: Unfortunate as this one is widely used for Point of Presence. No need to change anything, though.

# Consistency

OLD: Registrar_Agent
NEW: Registrar-Agent

# Mysterious

CURRENT: Requirements Discussion and Mapping to Solution-Elements

What does Solution-Elements mean?

# Thanks!

CURRENT:
  An abstract overview of the BRSKI-PRM protocol can be found on slide
  8 of [BRSKI-PRM-abstract].

That figure is helpful. I didn’t checked though that all the steps are still valid in the latest version of the spec. I trust you have done that check.

# Outsource Key Infrastructure   

This is currently drawn within the customer domain. Can this be outsourced/external to the customer domain?

# HTTP(S)

CURRENT: the pledge and the Registrar-Agent is assumed to be HTTP(S) 

In which case the non-secure mode is allowed?

# Group OPS considerations in one single section

Consider moving the following to the OPS cons section:

CURRENT:
  The benefits of BRSKI-PRM can be achieved even without the
  operational complexity of stand-alone Registrar-Agents by integrating
  the necessary functionality of the Registrar-Agent as a module into
  the domain registrar as shown in Figure 3 so that it can support the
  BRSKI-PRM communications to the pledge.

And

CURRENT
  Overall, this may have
  operational implications when the registrar is part of a scalable
  framework as described in Section 1.3.1 of
  [I-D.richardson-anima-registrar-considerations].

# Need concrete behavior

CURRENT: Further, the Registrar-Agent SHOULD have synchronized time.

Should we provide more concrete behavior here?

# Non-discovery

CURRENT:
  6.1.1.  Discovery of the Registrar

This is more about non-discovery :-)

Consider changing to “Explicit Configuration of Registrars”

# hostname and intermittent connectivity

CURRENT:
  While the Registrar-Agent requires the IP address of the domain
  registrar to initiate a TLS session, a separate discovery of the
  registrar is likely not needed and a configuration of the domain
  registrar IP address or hostname is assumed. 

How to reconcile this with the intermittent connectivity condition mentioned early in the document, including with a name resolution service which may not be reachable?

BTW, multiple IP addresses may be available. Consider updating to:

NEW:
  While the Registrar-Agent requires an IP address of the domain
  registrar to initiate a TLS session, a separate discovery of the
  registrar is likely not needed and a configuration of the domain
  registrar IP address or hostname is assumed. 

# Configurable knobs

CURRENT:
  In the absence of a more general discovery as defined in
  [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use

Do we need to have a control parameter here to instruct the behavior of the RA?

The same applies for the following:

CURRENT:
  A nonceless voucher MAY be accepted as in [RFC8995] if allowed by the
  pledge implementation of the manufacturer.


# Expired I-Ds

CURRENT: e.g., as proposed in [I-D.richardson-emu-eap-onboarding]. 

I suggest to remove citations of expired individual I-Ds.

# “MUST …unless” constructs should be “SHOULD …unless”

OLD:
  To enable interaction as responder with the Registrar-Agent, pledges
  in responder mode MUST act as servers and MUST provide the endpoints
  defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
  path, except for the OPTIONAL endpoint "qps".  The endpoints are
  defined with short names to also accommodate for resource-constrained
  devices.

NEW:
  To enable interaction as responder with a Registrar-Agent, pledges
  in responder mode MUST act as servers and SHOULD provide the endpoints
  defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
  path, except for the OPTIONAL endpoint "qps".  The endpoints are
  defined with short names to also accommodate for resource-constrained
  devices.

(also s/the/a)

# Redundant language (many occurrences in the text)

OLD: Optionally, TLS MAY be used to provide transport security
NEW: TLS MAY be used to provide transport security

# TTL

CURRENT:
  Note that the pledge provisionally accepts the registrar EE
  certificate contained in the tPVR until it receives the voucher (see
  Section 5.4).

Shouldn’t that be TTLed as well for better security control?

# Inappropriate use of normative language

CURRENT:
  The following assumes that a Registrar-Agent MAY need to query the
  overall status of a pledge. 

This is an assumption, s/MAY/may

# Rate-limit log actions

CURRENT:
  The registrar SHOULD log certain events to provide an audit trail for
  the onboarding of pledges into its domain. 

In order to protect the registrar from overload attacks, consider adding a rate-limit guard for logging the same event.

# Missing IANA action

CURRENT: IANA has registered the following service names

Please ad an action for IANA to update that entry. Thanks.

# You are allowed to not use the template!

CURRENT:
  The use of YANG to define data structures via the [RFC8971]
  "structure" statement, is relatively new and distinct from the common
  use of YANG to define an API accessed by network management protocols
  such as NETCONF [RFC6241] and RESTCONF [RFC8040].  For this reason,
  these guidelines do not follow the template described by Section 3.7
  of [RFC8407] (Security Considerations).

You can delete this text. 8407bis have the required provisions for you :-)

  Documents that define exclusively modules following the extension in
  [RFC8791] are not required to include the security template in
  Section 3.7.1.  Likewise, following the template is not required for
  modules that define YANG extensions such as [RFC7952].

Hope this helps.

Cheers,
Med

Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: David Lawrence. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-anima-brski-prm-17. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the BRSKI Well-Known URIs registry on the Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters registry page located at:

https://www.iana.org/assignments/brski-parameters/

eight, new URIs are to be registered as follows:

Path Segment Description Reference
requestenroll Supply PER to registrar [ RFC-to-be ]
wrappedcacert Obtain wrapped CA certificates [ RFC-to-be ]
tpvr Trigger Pledge Voucher-Request [ RFC-to-be ]
tper Trigger Pledge Enroll-Request [ RFC-to-be ]
svr Supply voucher to pledge [ RFC-to-be ]
scac Supply CA certificates to pledge [ RFC-to-be ]
ser Supply Enroll-Response to pledge [ RFC-to-be ]
qps Query pledge status [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, we will register the following service name at https://www.iana.org/assignments/service-names-port-numbers:

Service Name: brski-pledge
Transport Protocol(s): tcp
Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org
Description: The Bootstrapping Remote Secure Key Infrastructure Pledge
Reference: [ RFC-to-be ]

NOTE: Per RFC 6335, Section 8.1.1, for assignments done through RFCs published via the "IETF Document Stream" (RFC 4844), the contact will be the IETF Chair . Please update this in the document.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2025-01-30):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-brski-prm@ietf.org, ietf@kovatsch.net, mjethanandani@gmail.com, tte@cs.fau.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BRSKI with Pledge in Responder Mode (BRSKI-PRM)) to Proposed Standard


The IESG has received a request from the Autonomic Networking Integrated
Model and Approach WG (anima) to consider the following document: - 'BRSKI
with Pledge in Responder Mode (BRSKI-PRM)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines enhancements to Bootstrapping a Remote Secure
  Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
  domains featuring no or only limited connectivity between a pledge
  and the domain registrar.  It specifically changes the interaction
  model from a pledge-initiated mode, as used in BRSKI, to a pledge-
  responding mode, where the pledge is in server role.  For this, BRSKI
  with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints
  for the Domain Registrar and pledge, and a new component, the
  Registrar-Agent, which facilitates the communication between pledge
  and registrar during the bootstrapping phase.  To establish the trust
  relation between pledge and registrar, BRSKI-PRM relies on object
  security rather than transport security.  The approach defined here
  is agnostic to the enrollment protocol that connects the domain
  registrar to the Key Infrastructure (e.g., domain CA).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This template version is dated 4 July 2022.*

The shepherd review was conducted on draft-ietf-anima-brski-prm-14.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement among the active WG participants, in particular the
design team. There are others being silent, but no opponents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open-source implementation by the Munich University of Applied
Sciences. The code is available at https://github.com/hm-edu/open-brski under
MIT license (the repo may move for organizational reasons, but a forwarder
was requested).

- Rust for MASA, Registrar, and Pledge; Dart for Registrar-Agent

There are two company inner source implementations of BRSKI-PRM by Siemens,
developed by different persons and cross-tested for correctness and
interoperability.

- Java for MASA, Registrar, and (unconstrained) Pledge
- C for Pledge

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is only off-the-shelf use of other technologies, so that a review is
not necessary.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

All YANG definitions were moved to ietf-anima-rfc8366bis, hence YANGDOCTORS
early reviews on Datatracker should be updated or removed.

IOTDIR and SECDIR early reviews are recommended to follow up with a new review
after the major improvements of the document structure.

IANA review for the BRSKI .well-known Registry additions and the DNS Service
Name registration is missing.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is contained.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The CDDL definitions were reviewed by Carsten Bormann and checked with
cddl-gen.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed to address real-world (industrial) use cases of BRSKI
that require a workflow different from the one defined in RFC8995.

The document has been correctly designed and is now clearly written.

It is ready, but part of and aligned with the RFC8366bis cluster.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

They were checked and discussed for the following areas:
- ART
- SEC
- TSV
The topics from the following areas are considered not applicable:
- INT
- OPS
- RTG

One issue was identified by the shepherd:
TSV "Using _tcp and _udp in SRV DNS records"

The document provides a basic discovery mechanism following the approach of
BRSKI [RFC8995] and registers the service name "brski-pledge" for _tcp.
Since the document defines a transport-agnostic protocol, with HTTP(S) just as
default transport, it should be clarified who shall register "brski-pledge"
for _udp.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested status is "Standard Track", which is correctly documented in the
document header and the Datatracker attribute is "Proposed Standard".
This is appropriate as the document defines a new protocol, which must be
interoperable.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors recently confirmed e-mail that they are not aware of any IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.
There are 4 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-14.txt

== There is 1 instance of lines with non-ascii characters in the document.
Umlaut in lastname within Acknowledgements -- appears to be allowed.

== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
  document.
This appears to be the example for "_brski-pledge._tcp.local".
The idnits tool seems to be lacking support for DNS-SD constructs.

-- Found something which looks like a code comment -- if you have code
  sections in the document, please surround them with '' and
  '' lines.
Unclear if this still holds for HTML RFCs with language-annotated Markdown
listings. I assume this to be addressed in the RFC Editor pass together with
'THISRFC'.

Note that the HTML version of the idnits tool does not render "",
so it was only noticed now through the datatracker link to the text version.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references were checked with [16] in mind.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

- I-D.draft-ietf-anima-rfc8366bis
- I-D.draft-ietf-anima-jws-voucher
- I-D.ietf-netconf-sztp-csr

The first two are planned as cluster together with other 8366bis work such as
I-D.ietf-anima-constrained-voucher.
The last, I-D.ietf-netconf-sztp-csr, needs coordination at AD level.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The registrations are consistent with the body of the document.
The existing "BRSKI Well-Known URIs" IANA Registry is clearly referenced.
The DNS Service Name registration is assumed to be checked in the IESG review.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/


# Document Shepherd Write-Up for Group Documents

*This template version is dated 4 July 2022.*

The shepherd review was conducted on draft-ietf-anima-brski-prm-14.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement among the active WG participants, in particular the
design team. There are others being silent, but no opponents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open-source implementation by the Munich University of Applied
Sciences. The code is available at https://github.com/hm-edu/open-brski under
MIT license (the repo may move for organizational reasons, but a forwarder
was requested).

- Rust for MASA, Registrar, and Pledge; Dart for Registrar-Agent

There are two company inner source implementations of BRSKI-PRM by Siemens,
developed by different persons and cross-tested for correctness and
interoperability.

- Java for MASA, Registrar, and (unconstrained) Pledge
- C for Pledge

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is only off-the-shelf use of other technologies, so that a review is
not necessary.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

All YANG definitions were moved to ietf-anima-rfc8366bis, hence YANGDOCTORS
early reviews on Datatracker should be updated or removed.

IOTDIR and SECDIR early reviews are recommended to follow up with a new review
after the major improvements of the document structure.

IANA review for the BRSKI .well-known Registry additions and the DNS Service
Name registration is missing.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is contained.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The CDDL definitions were reviewed by Carsten Bormann and checked with
cddl-gen.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed to address real-world (industrial) use cases of BRSKI
that require a workflow different from the one defined in RFC8995.

The document has been correctly designed and is now clearly written.

It is ready, but part of and aligned with the RFC8366bis cluster.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

They were checked and discussed for the following areas:
- ART
- SEC
- TSV
The topics from the following areas are considered not applicable:
- INT
- OPS
- RTG

One issue was identified by the shepherd:
TSV "Using _tcp and _udp in SRV DNS records"

The document provides a basic discovery mechanism following the approach of
BRSKI [RFC8995] and registers the service name "brski-pledge" for _tcp.
Since the document defines a transport-agnostic protocol, with HTTP(S) just as
default transport, it should be clarified who shall register "brski-pledge"
for _udp.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested status is "Standard Track", which is correctly documented in the
document header and the Datatracker attribute is "Proposed Standard".
This is appropriate as the document defines a new protocol, which must be
interoperable.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors recently confirmed e-mail that they are not aware of any IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.
There are 4 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-14.txt

== There is 1 instance of lines with non-ascii characters in the document.
Umlaut in lastname within Acknowledgements -- appears to be allowed.

== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
  document.
This appears to be the example for "_brski-pledge._tcp.local".
The idnits tool seems to be lacking support for DNS-SD constructs.

-- Found something which looks like a code comment -- if you have code
  sections in the document, please surround them with '' and
  '' lines.
Unclear if this still holds for HTML RFCs with language-annotated Markdown
listings. I assume this to be addressed in the RFC Editor pass together with
'THISRFC'.

Note that the HTML version of the idnits tool does not render "",
so it was only noticed now through the datatracker link to the text version.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references were checked with [16] in mind.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

- I-D.draft-ietf-anima-rfc8366bis
- I-D.draft-ietf-anima-jws-voucher
- I-D.ietf-netconf-sztp-csr

The first two are planned as cluster together with other 8366bis work such as
I-D.ietf-anima-constrained-voucher.
The last, I-D.ietf-netconf-sztp-csr, needs coordination at AD level.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The registrations are consistent with the body of the document.
The existing "BRSKI Well-Known URIs" IANA Registry is clearly referenced.
The DNS Service Name registration is assumed to be checked in the IESG review.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/


# Document Shepherd Write-Up for Group Documents

*This template version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement among the active WG participants, in particular the
design team. There are others being silent, but no opponents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open-source implementation by the Munich University of Applied
Sciences. The code is available at https://github.com/hm-edu/open-brski under
MIT license (the repo may move for organizational reasons, but a forwarder
was requested).

- Rust for MASA, Registrar, and Pledge; Dart for Registrar-Agent

There are two company inner source implementations of BRSKI-PRM by Siemens,
developed by different persons and cross-tested for correctness and
interoperability.

- Java for MASA, Registrar, and (unconstrained) Pledge
- C for Pledge

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is only off-the-shelf use of other technologies, so that a review is
not necessary.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

All YANG definitions were moved to ietf-anima-rfc8366bis, hence YANGDOCTORS
early reviews on Datatracker should be updated or removed.

IOTDIR and SECDIR early reviews are recommended to follow up with a new review
after the major improvements of the document structure.

IANA review for the BRSKI .well-known Registry additions and the DNS Service
Name registration is missing.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is contained.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The CDDL definitions were reviewed by Carsten Bormann and checked with
cddl-gen.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is needed to address real-world (industrial) use cases of BRSKI
that require a workflow different from the one defined in RFC8995.

The document has been correctly designed and is now clearly written.

It is ready, but part of and aligned with the RFC8366bis cluster.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

They were checked and discussed for the following areas:
- ART
- SEC
- TSV
The topics from the following areas are considered not applicable:
- INT
- OPS
- RTG

One issue was identified by the shepherd:
TSV "Using _tcp and _udp in SRV DNS records"

The document provides a basic discovery mechanism following the approach of
BRSKI [RFC8995] and registers the service name "brski-pledge" for _tcp.
Since the document defines a transport-agnostic protocol, with HTTP(S) just as
default transport, it should be clarified who shall register "brski-pledge"
for _udp.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested status is "Standard Track", which is correctly documented in the
document header and the Datatracker attribute is "Proposed Standard".
This is appropriate as the document defines a new protocol, which must be
interoperable.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors recently confirmed e-mail that they are not aware of any IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.
There are 4 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-14.txt

== There is 1 instance of lines with non-ascii characters in the document.
Umlaut in lastname within Acknowledgements -- appears to be allowed.

== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
  document.
This appears to be the example for "_brski-pledge._tcp.local".
The idnits tool seems to be lacking support for DNS-SD constructs.

-- Found something which looks like a code comment -- if you have code
  sections in the document, please surround them with '' and
  '' lines.
Unclear if this still holds for HTML RFCs with language-annotated Markdown
listings. I assume this to be addressed in the RFC Editor pass together with
'THISRFC'.

Note that the HTML version of the idnits tool does not render "",
so it was only noticed now through the datatracker link to the text version.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, all references were checked with [16] in mind.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

- I-D.draft-ietf-anima-rfc8366bis
- I-D.draft-ietf-anima-jws-voucher
- I-D.ietf-netconf-sztp-csr

The first two are planned as cluster together with other 8366bis work such as
I-D.ietf-anima-constrained-voucher.
The last, I-D.ietf-netconf-sztp-csr, needs coordination at AD level.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The registrations are consistent with the body of the document.
The existing "BRSKI Well-Known URIs" IANA Registry is clearly referenced.
The DNS Service Name registration is assumed to be checked in the IESG review.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/


BRSKI PRM was split out from draft-ietf-anima-brski-async-enroll-03 because the scope of the document became too large.
draft-ietf-anima-brski-async-enroll-04 only contains the solution for one use-case, BRSKI-PRM now the solution for the other use-case.