Roman,
Thanks for the review, responses in line.
On 19-Jan-22 15:14, Roman Danyliw via Datatracker wrote:
...
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
** Section 3.1 and 3.2.
(a) (Section 3.1) “… the secure bootstrap process itself may include
special-purpose ASAs that run in a constrained insecure mode.”,
(b) (Section 3.2) “ … the ACP formation process itself may include
special-purpose ASAs that run in a constrained insecure mode.”
What is meant by “special-purpose” (i.e., how is that different than an ASA
that isn’t special purpose) and what are the security properties of a
“constrained insecure mode”? Is this text saying that the secure bootstrapping
and ACP formation might not always be done securely?
No, the point is that they are secure *because* only a constrained subset
of
GRASP is available. It's badly phrased.
(b) reads like it could be DULL-GRAP (Section 2.5.2 of draft-ietf-anima-grasp)
but it isn’t clear.
Yes, both are DULL-GRASP use cases in fact and are properly described in
RFC8994 and RFC8995. We clearly need to make these two sentences much less
obscure, as I already replied to Éric. Or we could delete them, since they
are a distraction from the main argument.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
** Section 6. Would the ASA lifecycle presented here need to consider resale,
transfer or decommissioning of equipment on which the ASA runs? I’m
specifically thinking of the broader considerations discussed in BRSKI.
For
example, should there be primitives to purge the ASA configuration, key
materials, or logs?
That seems like a factor to be considered; maybe just an option during
"uninstall", which we don't describe in detail.
** Section 6.1. Is there any integrity and authenticity checking before the
ASA software is installed?
There certainly should be. We should add a note.
** Section 6.1.1.
The condition to validate in order to pass to next phase is to ensure
that [list of ASAs] are well installed on [list of Installation
Hosts].
What does it mean to be “well installed”?
Nothing. We'll delete "well".
** Section 6.1.1
A minimum set of primitives to
support the installation of ASAs could be: install(list of ASAs,
Installation_target_Infrastructure, ASA placement function), and
uninstall (list of ASAs).
Would an explicit primitive for checking if an ASA is already installed
be
needed – that is, how does one deal with an install() if the ASA is already
installed?
Certainly a complete system would have to deal with versioning. We didn't
intend to describe a complete system here (that would be a whole other draft
IMHO) so probably we should clarify early in the section that this is only an
outline.
** Section 6.2.
First, there is a difference between (1) having a
piece of code available to run on a host and (2) having an agent
based on this piece of code running inside the host.
I don’t follow the text for (1). (1) seems to be roughly the definition of the
previously described installation phase (Section 6.1). What is the difference
being suggested for this phase?
I see your confusion. The sentence you quote might actually be redundant,
and at the minimum it needs to be rephrased.
** -- Section 6.2.3.
The specification of such an
ASA Instance Mandate is beyond the scope of this document.
It caught my attention that the specification of “ASA Instance Mandate” was
explicitly called out as being out of scope for this document. No issue with
that. However, so many of the other terms are also out of scope. For example,
“Set of ASAs – Resources relations” and “Instantiation_target_parameters”
OK, we should clarify.
** Section 8.
If a newly received or calculated value for a parameter falls
out of bounds, the corresponding parameter should be either left
unchanged or restored to a safe value.
Is that safe value likely to be contextual to the environment in which the ASA
is deployed?
Very possibly. It really is use-case dependent. (E.G. the max RF power output
of a base station might depend on national regulations, so the default value
could not be a factory default.)
** Editorial
-- Section 6.1.1. Editorial. Why does “[Installation_target_Infrastructure]
have both hyphens and capitalizes “Infrastructure” while “[ASA of a give type”
and [ASA placement function] doesn’t have hyphens and only capitalized the
first word?
Will aim at consistency.
-- Section 6.1.1. Editorial. A forward reference or earlier definition
of
“decoupled mode” would have been helpful. It is defined in Section 6.2.
Ack
Thanks,
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
