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)?
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
