[Anima] Mirja Kühlewind's No Objection on draft-ietf-anima-bootstrapping-keyinfra-22: (with COMMENT)

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

Mirja Kühlewind has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: 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-bootstrapping-keyinfra/



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

I agree with Alissa's discuss that the conclusion of section 10(.3) should be
to recommend a manual configuration mode. Also with respect to section 10.2: if
ownership is "enforced" by the manufacturer, there should also probably be a
way for the buyer to check if ownership was transferred by the saler during the
re-sale process.

Two other small comments on more load related points:

1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid head of
queue
   problems wherein an attacker running a fake proxy or registrar could
   perform protocol actions intentionally slowly.  The pledge SHOULD
   continue to listen to for additional GRASP M_FLOOD messages during
   the connection attempts."
One minor comment: Maybe also say explicitly, while running in parallel, one
should not send all initial messages at exactly the same time but pace  them
out (e.g. one every 3 secs) to avoid network overload when initial connectivity
is very constraint.

2) sec 4.3: " It must
   be sufficiently low that the aggregate amount of periodic M_FLOODs
   from all EST servers causes negligible traffic across the ACP."
I know this is a little bit a blurry requirement but I would still like to see
a MUST here. Or maybe give an upper bound for the maximum frequency, e.g. MUST
NOT send more than once per minute...? Not sure it there is a reasonable value
here.