Roman Danyliw has entered the following ballot position for
draft-ietf-anima-asa-guidelines-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/



----------------------------------------------------------------------
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?

(b) reads like it could be DULL-GRAP (Section 2.5.2 of draft-ietf-anima-grasp)
but it isn’t clear.


----------------------------------------------------------------------
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?

** Section 6.1.  Is there any integrity and authenticity checking before the
ASA software is installed?

** 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”?

** 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?

** 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?

** -- 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”

** 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?

** 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?

-- 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.



_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to