Bootstrapping Remote Secure Key Infrastructure (BRSKI) Cloud Registrar
draft-ietf-anima-brski-cloud-19

[Ballot comment]
[Edit on 4 Sep:  Thanks for addressing my discuss.  I appreciate the all the hard work.]


Thanks to Mike Ounsworth for their (multiple) secdir reviews.

Section 4.2, step 6:  What/where is this:  {pledge-certificate-identity-considerations} ?

Section 8.4:  What/where is this: {bootstrap-via-cloud-registrar-and-owner-est-service} ?

[Ballot comment]
Thanks for addressing my previous blocking DISCUSS issue (I told you that it was trivial to fix).

Alas, I have noticed that some of my original non-blocking COMMENTS below are not addressed in -17 (notably having references *only* to DHCPv4 rather than DHCPv6).


## COMMENTS (non-blocking)

### Missing privacy / operational considerations ?

As the Cloud and Owner are different organisation, I was expected to read some privacy considerations:
- the Cloud Registrar will see the addresses (i.e., location) and devices count per Owner
- the Owner relies on the Cloud Registrar availability, i.e., it is a single point of failure (the draft discusses briefly about bankruptcy but this could be censorship as well)

### Nice use of SVG

Thanks for using SVG graphics, so much more readable :-)

### Section 1.1

The OEM definition is not really the usual one, but this is OK I guess in this I-D even if the word 'created' looks weird in this context (why not 'manufactured').

Missing "owner", does it mean the guy buying the phone (or...) or the company operating it ? It is really an ambiguous and overloaded term.

The word 'domain' is also under-specified as it can means several things.

### Section 1.2

s/target use cases/use cases/ ?

More important, as we are in 2025, why using DHCPv4 and no DHCPv6 ? One author is even a RFC 8415 author... Please update the draft with DHCPv6 reference. It is informational use of DHCPv4 as an example, therefore this point is sadly not DISCUSS worthy.

Add an informative reference to `LDevID`.

### Section 2

Please expand `MASA` and provide a reference.

### Section 2.1

Please add "Pledge operator" to the terminology as it is a little unclear.

It is not enough to state `The Pledge must have an IP address so that it is able to make DNS queries` suggest "The Pledge must have an IP address and be capable to reach a recursive DNS server".

### Section 2.2

Suggest expanding `CSR` at first use.

Should a reference be added to `IDevID` ?

### Section 3

I find the flow of steps then ventilate by use case somehow difficult to read. Probably too late to change but a flow by use case then steps would have been easier to read.

### Section 3.1.1

`which are typically` or "which MUST be" ?

## NITS (non-blocking / cosmetic)

### Section 3.1.2

s/link local IPv6 address/link-local IPv6 address/

### Section 3.2

Add a reference to RFC 7231 for "Retry-After".

### Section 3.2.3

Like in section 1.2, we are still in 2025, so how does the proposed solution compare to DHCPv6 ?

### Section 3.3.1

Should there be a bound to the number of redirects ?

### Section 4.2

Is it a little unclear whether global/routable IP addresses are included in `It MAY also be a local address that includes an IP address literal including both IPv4 [RFC1918] and IPv6 Unique Local Addresses [RFC4193]. `.

### Section 8.1

Isn't it a little scary/unsafe if a pledge upgrades its firmware (potentially in a non secure way) and its trust anchors ?

The following summat from Michael pretty much sums it up:

Eric Vyncke (evyncke)  wrote:
    > Any idea when a revised I-D will be submitted (with the PR addressing
    > my DISCUSS point) ? I would love to clear my blocking DISCUSS ;-)

I think that we have changes for the three DISCUSSes, but authors are on
vacation, and so we don't yet have consensus among us.
I'm also unclear if Deb is happy yet.

I see a bunch of COMMENTS from Med,  which I will double check about, since I
don't recall reading them in email.

[Ballot comment]
I support the DISCUSS positions of Mike Bishop and Deb Cooley.

I am also somewhat skeptical of this method of bootstrapping a device. It requires a continuous infrastructure dependency on the Cloud Regstrar, VARs, subVARs and company. What I personally experience for deploying various internet devices that phone home, is that they offer a phone app with bluetooth and/or the device can go into a wifi hotspot mode for the phone to connect to for configuration/provisioning (and firmware updates)

[Ballot discuss]
In the security considerations section, please state what the consequences are for the issues listed.  For example:
  ---  Section 8.1, para 1:  So what?  Is there an issue with a Pledge connecting to the Internet before being enrolled?  [hint:  yes, there is]

  ---  Section 8.1, para 2:  While a Pledge should check for firmware updates, validation and transfer of those updates needs to happen in a secure fashion - usually this means source integrity (did the f/w come from the correct place), firmware integrity (is the f/w load the same?), and possibly confidentiality.  A sentence to make this more obvious would be good.

  ---    Section 8.2:  While reading this long section, I see a recommendation near the bottom.  Perhaps reorganizing this section so the recommendation is closer to the top.  The goal here is to reduce security issues due to compromised trust anchors (i.e. keep the list small).  The second goal is to reduce the issues with requiring an update to the trust store list (properly validating the service).
    ----  One comment in particular, in para 2, while it might be easier, using one of the WebPKI trust stores will result in many trust anchors that are not applicable.

  ---  Section 8.3:  What are the consequences of accepting a redirect when validation fails?

[Ballot comment]
Thanks to Mike Ounsworth for their (multiple) secdir reviews.

Section 4.2, step 6:  What/where is this:  {pledge-certificate-identity-considerations} ?

Section 8.4:  What/where is this: {bootstrap-via-cloud-registrar-and-owner-est-service} ?

[Ballot comment]
Thank you for the work put into this document.

I support the DISCUSS provided by Mike Bishop.

It would really be super-helpful to expand MASA and EST when first used, it was not good to have to research to check exactly what these were intended to expand to! (Presumably: Manufacturer Authorized Signing Authority, Enrollment over Secure Transport).

[Ballot discuss]
I previously reviewed draft -11 of this document for the HTTP Directorate; see https://mailarchive.ietf.org/arch/msg/httpbisa/Ny1EanWGyy4IyItpYxHDW8sImiw/. Most of those comments do not appear to have been addressed, so I reiterate them here.

# Updates metadata

The draft says it updates RFC 8995, but this is not mentioned in the Abstract.

# HTTP Reference

The draft makes several references to HTTP status codes and headers, but does not have a reference to RFC9110 to define these.

# Redirect handling

In Section 3.3, a 307 status code is used to indicate that the client should
make a fresh POST with a new payload to the URI indicated in the Location
header. The use of 307 as opposed to other 3XX status codes is understandable
because the client is intended to make a new POST rather than changing to GET
(as would be implied by e.g. a 303). However, generation of a new payload for
the new request differs from HTTP redirect handling as described in Section
15.4 of RFC 9110, which says that the same request should be sent to the new
URI modulo certain transformations described there. A response type or Link
relation might be a more appropriate means of communicating this.

Similarly, Section 3.3 does not describe the handling for other 3XX responses
that a server might legitimately return. For example, it doesn't seem
impossible that a server would send a 303 with the location of the requested
voucher. This specification should describe generic 3XX handling, unless that
is already covered sufficiently in other RFCs.

[Ballot comment]
- In Section 3.1.1, the document references
"brski-registrar.manufacturer.example.com" as an example Registrar URI which is
given in RFC 8995, Appendix B. A bare hostname is not a URI; RFC 8995 appears
to assume that the URI will have a scheme of "https" and paths of specific
resources as described in the protocol. (Similarly, RFC 7030 requires the
client to have "sufficient information to form the EST server URI", which can
be as little as a bare hostname.) This document attempts to bridge that gap by
saying that the client SHOULD be provided a full URI and including typical
values for scheme and path. I think this is a good approach, perhaps using
similar language to RFC 7030 to describe constructing the URI from provided and
typical components.

- In Section 3.2, protocol-specific meanings are attributed to particular
status codes in the HTTP response. One of these present in RFC 8995 (404 to
mean Validation Failed) seems particularly odd, given that vanilla HTTP would
interpret that as the voucher request endpoint not existing, rather than the
Pledge's identity not being known to the server. This specification doesn't
appear to make the situation any worse, but reviewing Section 4.6 of RFC 9205
may still be useful.


===NITS FOLLOW===
- 2. "Sections Section 7.2 and 8.3."

[Ballot discuss]

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

Thank you for the work put into this document.

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

Special thanks to Sheng Jiang for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status and *uses the old template*.

Thanks also to the DNS & IoT directorates reviewers: Qin Wu (and I have seen the replies) and Tim Wicinski.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Abstract

As this I-D updates RFC 8995, the abstract must mention this update (with a one line describing the update if possibe).

NB: it is also flagged by the id-nits tool.

[Ballot comment]

## COMMENTS (non-blocking)

### Missing privacy / operational considerations ?

As the Cloud and Owner are different organisation, I was expected to read some privacy considerations:
- the Cloud Registrar will see the addresses (i.e., location) and devices count per Owner
- the Owner relies on the Cloud Registrar availability, i.e., it is a single point of failure (the draft discusses briefly about bankruptcy but this could be censorship as well)

### Nice use of SVG

Thanks for using SVG graphics, so much more readable :-)

### Section 1.1

The OEM definition is not really the usual one, but this is OK I guess in this I-D even if the word 'created' looks weird in this context (why not 'manufactured').

Missing "owner", does it mean the guy buying the phone (or...) or the company operating it ? It is really an ambiguous and overloaded term.

The word 'domain' is also under-specified as it can means several things.

### Section 1.2

s/target use cases/use cases/ ?

More important, as we are in 2025, why using DHCPv4 and no DHCPv6 ? One author is even a RFC 8415 author... Please update the draft with DHCPv6 reference. It is informational use of DHCPv4 as an example, therefore this point is sadly not DISCUSS worthy.

Add an informative reference to `LDevID`.

### Section 2

Please expand `MASA` and provide a reference.

### Section 2.1

Please add "Pledge operator" to the terminology as it is a little unclear.

It is not enough to state `The Pledge must have an IP address so that it is able to make DNS queries` suggest "The Pledge must have an IP address and be capable to reach a recursive DNS server".

### Section 2.2

Suggest expanding `CSR` at first use.

Should a reference be added to `IDevID` ?

### Section 3

I find the flow of steps then ventilate by use case somehow difficult to read. Probably too late to change but a flow by use case then steps would have been easier to read.

### Section 3.1.1

`which are typically` or "which MUST be" ?

## NITS (non-blocking / cosmetic)

### Section 3.1.2

s/link local IPv6 address/link-local IPv6 address/

### Section 3.2

Add a reference to RFC 7231 for "Retry-After".

### Section 3.2.3

Like in section 1.2, we are still in 2025, so how does the proposed solution compare to DHCPv6 ?

### Section 3.3.1

Should there be a bound to the number of redirects ?

### Section 4.2

Is it a little unclear whether global/routable IP addresses are included in `It MAY also be a local address that includes an IP address literal including both IPv4 [RFC1918] and IPv6 Unique Local Addresses [RFC4193]. `.

### Section 8.1

Isn't it a little scary/unsafe if a pledge upgrades its firmware (potentially in a non secure way) and its trust anchors ?

[Ballot comment]
Hi Owen, Rifaat, and Michael,

Thank you for the effort put into this specification.

Also, thanks to Tim Wicinski for the DNSDIR review and to the authors for engaging and proposing changes.

# Overall

The document is well-written with a clear applicability scope. The description is repetitive in some places (e.g., all the details about “SIP phones” is repeated several times, redundant text in 1.2.1, etc.); some less words would be appropriate to help readers better focus on the core specification.

Please find below more detailed comments. Major comments are marked with (*).

# Operationalizing the solution (*)

The approach requires some coordination and provisioning that involve several entities. The document includes some useful discussion but those are really scattered in the document. I suggest to group these matters under a new “Operational Considerations” section. That section can include, e.g., required out of band configuration, discovery consideration, scalability discussion, service stability requirements and migration considerations, current Sections 5 and 7 as subsections.

# Inappropriate use of normative language  (*)

Several uses of the normative language in the document are not justified. Also, many of those are redundant with other statements in the document. For example:

(1) Introduction
  This work is in support of [BRSKI], Section 2.7, which describes how
  a Pledge MAY contact a well-known URI of a Cloud Registrar if a local
            ^^
  Registrar cannot be discovered or if the Pledge's target use cases do
  not include a local Registrar.

  …
  This document updates [BRSKI] by clarifying operations that are left
  out of scope in [BRSKI].  Two modes of operation are specified in
  this document.  The Cloud Registrar MAY redirect the Pledge to the^
                                      ^^^^
  owner's Registrar, or the Cloud Registrar MAY issue a voucher to the
                                            ^^^
  Pledge that includes the domain of the owner's Enrollment over Secure
  Transport [RFC7030] (EST) server.

(2) Section 2
  It is also possible that the Cloud Registrar MAY redirect the Pledge
                                                ^^^^
  to another Cloud Registrar operated by a VAR, with that VAR's Cloud
  Registrar then redirecting the Pledge to the Owner Registrar.  This
  scenario is discussed further in Sections Section 7.2 and 8.3.

(3) Section 3.1.1
  BRSKI defines how a Pledge MAY contact a well-known URI of a Cloud

I suggest s/MAY/may at least in these excerpts and similar ones.

# Internal inconsistency (*)

CURRENT:
  … and MUST
  NOT send the CSR Attributes request to the Cloud Registrar, because
  the Cloud Registrar does not have authority to issue a certificate
  for the customer domain.  (The Cloud Registrar is not a full EST
  server) If a Pledge sends a CSR Attributes request to the Cloud
  Registrar, then the Cloud Registrar MUST reply with 404 response
  code.

There is a conflict between the first MUST NOT and “if … sends”.

# Compliancy with BCP 56  (*)

There are several statements in the document that are not consistent with this reco:

  Applications using HTTP MUST NOT re-specify the semantics of HTTP
  status codes, even if it is only by copying their definition.  It is
  NOT RECOMMENDED they require specific reason phrases to be used; the
  reason phrase has no function in HTTP, is not guaranteed to be
  preserved by implementations, and is not carried at all in the HTTP/2
  [HTTP/2] message format.

Examples of such statements are

  Registrar, then the Cloud Registrar MUST reply with 404 response
  code.

Or

  The Cloud Registrar MUST determine Pledge ownership.  Prior to
  ownership determination, the Registrar checks the request for
  correctness and if it is unwilling or unable to handle the request,
  it MUST return a suitable 4xx or 5xx error response to the Pledge as

Or

  If the request is correct and the Registrar is able to handle it, but
  unable to determine ownership at that time, then it MUST return a 401

and similar statements in the document. Please check and revise accordingly. Typically, s/MUST return/returns

# Deviation vs. RFC8366bis  (*)

The document says:

(Section 2.3)
  [RFC8366bis] contains the two needed voucher extensions: "est-domain"
  and "additional-configuration" which are needed when a client is
  redirected to a local EST server.

(Section 3.2.3)
  The voucher MAY include the new "additional-configuration" field.
  ..
  The exact Pledge and Registrar behavior for handling and specifying
  the "additional-configuration" field is outside the scope of this
  document.

## However, there is no “additional-configuration” in draft-ietf-anima-rfc8366bis. Do we meant “additional-configuration-url”? If so, please update accordingly

## BTW, s/extensions/parameters as “extensions” have a special meaning in YANG.

# Need for a concrete recommendation (*)

CURRENT:
  In order to avoid permanent bootstrap cycles, the Pledge MUST NOT
  revisit a prior location. 

How this is actually implemented? How the behavior is controlled? Should previous attempts be cached, time-outed? If so, what is the depth of cached failures?

# Incomplete behavior (*)

Section 3.1.1 has the following

CURRENT:
  The Pledge SHOULD be provided with the entire URI of the Cloud
  Registrar, including the protocol and path components, which are
  typically "https://" and "/.well-known/brski", respectively.

But, what is supposed to do if incomplete URI is provided?

# Please find below some additional minor comments

## Expand BRSKI in the title.

## Abstract

### Help the device

CURRENT:
  Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how
  to onboard a device securely into an operator-maintained
  infrastructure.  It assumes that there is local network
  infrastructure for the device to discover and help the device. 

I don’t parse what is meant by “help the device”.

## New device

CURRENT:
  This document defines how to contact a well-known Cloud Registrar,
  and two ways in which the new device may be redirected towards the
  operator-maintained infrastructure. 

The concept of “new” is not clear at this stage. Do we consider a device new when it contacts the registrar for the first time or do we also consider cases where a device first connect to a given network?

## Introduction

### Nits

OLD:
  Bootstrapping Remote Secure Key Infrastructures [BRSKI] BRSKI
                                                          ^^^^^^
  specifies automated and secure provisioning of nodes (which are
                                                        ^^^^^^^^^^
  called Pledges) with cryptographic keying material (trust anchors and

NEW:
  Bootstrapping Remote Secure Key Infrastructures [BRSKI] (BRSKI)
  specifies automated and secure provisioning of nodes
  (called Pledges) with cryptographic keying material (trust anchors and

### Phone, a bit outdates and does not reflect actual uses

I suggest to use User Agent (UA), rather than “phone” in this part (and similar ones)

OLD:
  This kind of non-network onboarding is sometimes called "Application
  Onboarding", as the purpose is typically to deploy a credential that
  will be used by the device in its intended use.  For instance, a SIP
  [RFC3261] phone might have a client certificate to be used with a SIP
  proxy.

NEW:
  This kind of non-network onboarding is sometimes called "Application
  Onboarding", as the purpose is typically to deploy a credential that
  will be used by the device in its intended use.  For instance, a SIP
  [RFC3261] user agent (UA) might have a client certificate to be used with a SIP
  proxy.

## Terminology

The document says:

  This document uses the terms Pledge, Registrar, MASA, and Voucher
  from [BRSKI] and [RFC8366bis].

But provides a copy/past of some other entries (e.g., Manufacturer). Any reason that entry is copy/pasted here rather than listing it similar to other BRSKI terms?

## Applicability

This text is lost in the “target Use Cases”. I suggest to move this to a dedicated subsection or to the introduction.

CURRENT:
  A network with an operator that is able to
  provision these options would also be able to use BRSKI without
  changes.  Such a network has no need for the mechanisms described in
  this document!

## Typical, really?

CURRENT:
  A typical example is a VoIP phone manufacturer provides telephones to
  a local system integration company (a VAR). 

This may be “typical” in the past, but I don’t think this is “typical” nowadays.

## Missing LDevID reference

CURRENT:
  When the employee plugs in the device and turns it on,
  the device will be provisioned with a LDevID and configuration that
  connections the phone with the Enterprises' VoIP PBX. 

Consider adding a pointer to 802.1AR?


## “cloud” in Section 1.2.2

OLD:
  The voucher
  issued by the cloud includes domain information for the owner's EST
  service that the Pledge should use for certificate enrollment.

NEW:
  The voucher
  issued by the Cloud Registrar includes domain information for the owner's EST
  service that the Pledge should use for certificate enrollment.

## Architecture

### Cloud Registrars

The text seems to assume that there is one single Cloud Registrar instance, while this shouldn’t. I suggest to make this change (and also through the doc):

OLD:
  In both use cases, the Pledge connects to the Cloud Registrar during
  bootstrap.

NEW:
  In both use cases, the Pledge connects to a Cloud Registrar during
  bootstrap.

### Additional information

CURRENT:
  When
  returning a voucher, additional bootstrapping information is embedded
  in the voucher. 

Can we cite examples of additional information?

Absent such example, not sure that sentence adds value.

### IP address and reachability

CURRENT:
  prior to connecting to the Cloud Registrar.  The Pledge must have an
  IP address so that it is able to make DNS queries, and be able to
  send requests to the Cloud Registrar. 

The first “must” does not guarantee that DNS queries can be successfully placed.

For example, a device can only have a link local address, but that does not help communicating more than one hop further.

### Internal setup

CURRENT:
  For many telephony applications, this is typically going to be a
  wired connection.  For wireless use cases, existing Wi-Fi onboarding
  mechanisms such as [WPS] can be used.

Do we really need to have this?

## Section 3.3.1

s/will a follow/will follow

## Section 4.2

* s/In step 3, the the Cloud Registrar/In step 3, the Cloud Registrar
* s/ authenticate/authenticate


## Section 7.1: nit

OLD:
  When the Pledge attempts to connect to any Cloud Registrar, an
  incorrect connection will be detected because the Pledge will be
  unable to verify the TLS connection to its Cloud Registrar via DNS-ID
  check Section 6.3 of [RFC9525]. 

NEW:
  When the Pledge attempts to connect to any Cloud Registrar, an
  incorrect connection will be detected because the Pledge will be
  unable to verify the TLS connection to its Cloud Registrar via DNS-ID
  check (Section 6.3 of [RFC9525]). 

Cheers,
Med

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

# 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-cloud-16.txt

# nice writeup and well written. Thanks for the great work

# Detailed Review
# ===============

163 1.1.  Terminology

GV> Many goodies in this section. I see "Owner Domain" and "Owner registrar" but no definition of "Owner" or "Owner delegate" 

Many thanks for this document,
Gunter Van de Velde,
Routing AD

Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Tim Wicinski. 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-cloud-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-02-28):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-brski-cloud@ietf.org, mjethanandani@gmail.com, shengjiang@bupt.edu.cn
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BRSKI Cloud Registrar) 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
Cloud Registrar'
  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-02-28. 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


  Bootstrapping Remote Secure Key Infrastructures defines how to
  onboard a device securely into an operator-maintained infrastructure.
  It assumes that there is local network infrastructure for the device
  to discover and help the device.  This document extends the new
  device behavior so that if no local infrastructure is available, such
  as in a home or remote office, the device can use a well-defined
  "call-home" mechanism to find the operator-maintained infrastructure.

  This document defines how to contact a well-known Cloud Registrar,
  and two ways in which the new device may be redirected towards the
  operator-maintained infrastructure.  The Cloud Registrar enables
  discovery of the operator-maintained infrastructure, and may enable
  establishment of trust with operator-maintained infrastructure that
  does not support BRSKI mechanisms.




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



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

Hi Authors,

I was doing one final check before sending the document forward. It would be nice to address these remaining comments.

This document updates RFC8995 but does not seem to include explanatory text
about this in the abstract.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Duplicate normative references to: rfc7030.

Document references draft-ietf-lamps-rfc7030-csrattrs-15, but -16 is the latest
available revision.

Section 3, paragraph 1
> ledge MUST be manufactured with pre-loaded trust anchors that are used to ve
>                                ^^^^^^^^^^
This word is normally spelled as one.

"References", paragraph 3
> c-editor.org/rfc/rfc9525>. [WPS] WiFi Alliance, "Wi-Fi Protected Setup (WPS)
>                                  ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Request for Last Call review by IOTDIR Completed: On the Right Track. Reviewer: Qin Wu. Sent review to list. Submission of review completed at an earlier date.

Three of the four *DIR reviews have provided very useful comments that should be addressed, and a revised I-D produced before the document can be sent forward. The one review from IOTDIR is still pending.

This document was AD reviewed by Robert Wilton before he stepped down. The authors agreed to update the document to address the AD comments. And thus the state of Revised I-D needed.

Document Writeup, template from IESG area on ietf.org, dated August 10, 2017.

draft-ietf-anima-brski-cloud-08 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track.  Based on the existing BRSKI infrastructure. This document
  defines a new BRSKI-enabled device behaviour: if no local infrastructure is
  available, the device can use a well defined "call-home" mechanism to find
  the operator maintained BRSKI infrastructure. This document defines a 
  mechanism how the new device can contact a well-known Cloud Registrar, and 
  two ways in which the new device may be redirected towards the operator 
  maintained infrastructure.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document defines a new BRSKI-enabled device behaviour with the existing
  BRSKI infrastructure: if no local infrastructure is available, the device 
  can use a well defined "call-home" mechanism to find the operator maintained 
  BRSKI infrastructure. Tis document defines a mechanism how the new device
  can contact a well-known Cloud Registrar, and two ways in which the new 
  device may be redirected towards the operator maintained infrastructure.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-friel-anima-brski-cloud prior to its adoption.
  There was unanimous support for it in favor of adoption and none against),
  so this document was adopted in May, 2021. It is a follow-up document
  of RFC8995 "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", which
  published May 2021. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant long document development period (20
  months for individual document period, 31 month for WG document period). It
  is partly because of global COVID-19 and slow process of its prior dependent
  document and parallel brother documents.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by ANIMA WG participants, which
  did receive comments to help improving the document. So far, there is no
  existing implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Robert Wilton is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once (and had other minor comments from time
  to time) and feed back my comments to the authors
 
  The issues raised in my reviews were promptly addressed by authors in the
  current version along with the comments from other ANIMA WG members. 
  This document current -08 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, O. Friel, R. Shekh-Yusef and Michael C. Richardson have
  confirmed in writing that they are not aware of any IPR, and that any and
  all appropriate IPR disclosures required for full conformance with the
  provisions of BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise 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. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  Yes. draft-ietf-lamps-rfc7030-csrattrs
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  No. This document makes no IANA requests.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  No, this document does not request any such checks.

Document Writeup, template from IESG area on ietf.org, dated August 10, 2017.

draft-ietf-anima-brski-cloud-08 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Standards Track.  Based on the existing BRSKI infrastructure. This document
  defines a new BRSKI-enabled device behaviour: if no local infrastructure is
  available, the device can use a well defined "call-home" mechanism to find
  the operator maintained BRSKI infrastructure. This document defines a 
  mechanism how the new device can contact a well-known Cloud Registrar, and 
  two ways in which the new device may be redirected towards the operator 
  maintained infrastructure.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document defines a new BRSKI-enabled device behaviour with the existing
  BRSKI infrastructure: if no local infrastructure is available, the device 
  can use a well defined "call-home" mechanism to find the operator maintained 
  BRSKI infrastructure. Tis document defines a mechanism how the new device
  can contact a well-known Cloud Registrar, and two ways in which the new 
  device may be redirected towards the operator maintained infrastructure.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-friel-anima-brski-cloud prior to its adoption.
  There was unanimous support for it in favor of adoption and none against),
  so this document was adopted in May, 2021. It is a follow-up document
  of RFC8995 "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", which
  published May 2021. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant long document development period (20
  months for individual document period, 31 month for WG document period). It
  is partly because of global COVID-19 and slow process of its prior dependent
  document and parallel brother documents.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  This document went through multiple reviews by ANIMA WG participants, which
  did receive comments to help improving the document. So far, there is no
  existing implementations.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Robert Wilton is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I reviewed this document thorough once (and had other minor comments from time
  to time) and feed back my comments to the authors
 
  The issues raised in my reviews were promptly addressed by authors in the
  current version along with the comments from other ANIMA WG members. 
  This document current -08 version is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, O. Friel, R. Shekh-Yusef and Michael C. Richardson have
  confirmed in writing that they are not aware of any IPR, and that any and
  all appropriate IPR disclosures required for full conformance with the
  provisions of BCP 78 and BCP 79 have already been filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise 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. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  Yes. draft-ietf-lamps-rfc7030-csrattrs
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  No. This document does not update any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  No. This document makes no IANA requests.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  No, this document does not request any such checks.

This document was put into WGLC Nov 2022, but state change in data tracker was missed,
authors think all issues raised in Jul 2023, waiting for ok. from last issue raiser (Esko).