[Anima] Mirja Kühlewind's No Objection on draft-ietf-anima-autonomic-control-plane-13: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-13: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) I would like to see a slightly stronger statement here in section 6.1.3:
"The M_FLOOD message MUST be sent periodically.  The default SHOULD be
   60 seconds, the value SHOULD be operator configurable."
Maybe the following instead:
"The M_FLOOD message MUST be sent periodically.  The default MUST be
   60 seconds, the value SHOULD be operator configurable but SHOULD be
   not smaller than 60 seconds."
Or even a MUST for the minimum value is that acceptable for the desired use cases.

2) Also in section 6.5, I would like to seem some rate limiting/pacing:
"An ACP node may choose to attempt initiate the different feasible ACP
   secure channel protocols it supports according to its local policies
   sequentially or in parallel,..."

3) Sec 6.7.3: How are baseline ACP and constrained ACP nodes defined?

4) sec 6.10.6:
"With the current allocations, only 2 more schemes are
   possible, so the last addressing scheme should consider to be
   extensible in itself (e.g.: by reserving bits from it for further
   extensions."
Maybe use a normative MUST here:
"With the current allocations, only 2 more schemes are
   possible, so the last addressing scheme MUST be
   extensible in itself (e.g.: by reserving bits from it for further
   extensions."

5) I guess section 10 could be moved to the appendix.