Last Call Review of draft-ietf-anima-brski-cloud-11
review-ietf-anima-brski-cloud-11-rtgdir-lc-white-2024-11-03-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-anima-brski-cloud-11
Reviewer: Russ White
Review Date: 1 November 2024
Intended Status: Standards Track

Summary:

This document is basically ready for publication but has nits that 
should be considered prior to publication.

Comments:

This document is readable; some suggestions towards improving 
readability are included in the nets section below. The diagrams and 
attendant explanations are very helpful in understanding how the 
described process works.

One specific question asked about this document:

==
>From a routing perspective, the only question would be if there are any 
considerations to be had either between the device and the Owner 
Registrar or between the Owner Registrar and Cloud Registrar. A simple 
answer could be there is nothing to be considered, or that the DHCP 
request that bootstraps the device has all that is needed. If that is 
the case, as you seem to be suggesting, that is all that is needed.
==

If DHCP is used for bootstrapping, it should provide enough information 
to fulfill the expectations required in this draft.

Major Issues:

No major issues found.

Minor Issues:

The Pledge does not know who its owner will be when manufactured. 
Instead, in BRSKI it is assumed that the network to which the Pledge 
connects belongs to the owner of the Pledge and therefore 
network-supported discovery mechanisms can resolve generic, non-owner 
specific names to the owners Registrar.

Is this a new attack surface? Does this need to be mentioned in the 
security considerations section?

Nits:

==
In BRSKI, the Pledge performs enrolment ...
enrollment

==
There is no local domain Registrar ...
"Because" or "Since" there is no local domain Registrar ...

==
... it can return a voucher that pins the actual Owner Registrar.
I'm not certain about the use of "pins" here (?) ... maybe "describes" 
or "redirects to" or something similar? "Pins" doesn't seem to be used 
in a lot of other places in the document.

==
The Pledge must have an IP address that is able to make DNS queries...
"The Pledge must have an IP address so it is able to make DNS queries... 
"

==
...SHOULD consider all 4xx and 5xx errros...
"errors"

==
...out-of-scope of this document. (section 3.2.1)
"out of the scope of this document"

==
Section 3.3.1

The Pledge MUST never visit a location that it has already been to, in 
order to avoid any kind of cycle

and then

The exception is that a 401 Unauthorized code SHOULD cause the Pledge to 
retry a number of times over a period of a few hours.

Readers might find this a little confusing. It might be better to 
restate the first sentence something like:

"The Pledge MUST NOT revisit a prior location to avoid permanent 
bootstrap cycles. Pledeges MAY, however, visit the current location 
multiple times (as in the case of a 401 Unauthorized Code response, 
overload responses, etc.). "

I also wonder about the case of simpler timeouts, overload indications, 
etc.--I tried to include these here, but I'm not certain the language is 
correct.

==
Secion 4.2

I think this would be easier to read if each step were in a separate 
paragraph.

==
Section 6

Does this need to be included (since it is essentially empty)?