[Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-anima-grasp-12: 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-grasp/



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

Substantive:

-3.5.2.1: "Messages MUST be authenticated and encryption MUST be
   implemented."
Should the latter be "... MUST be used"? It seems odd for authentication
to be MUST use, but crypto to only be MTI.

-3.5.4.3: "An exponential backoff SHOULD be used for subsequent
   repetitions, to limit the load during busy periods."
Why not MUST? Also, is there a retry limit?  (Comment applies to the
other sections that mention retries with exponential backoff)

-3.5.6.2: "To ensure that flooding does not result in a loop, the
originator of
   the Flood Synchronization message MUST set the loop count in the
   objectives to a suitable value "
I assume this is true for discovery and negotiation as well? I don't
think it was mentioned in those sections (although I think I saw a
related mention in the message format sections.)

- 3.10.5: "SHOULD NOT be used in
   unmanaged networks such as home networks."
Why not MUST?

-5, Privacy and Confidentiality: Did people consider IP Addresses and
other potentially persistent identifiers as impacting privacy?

-7, Grasp Message and Options table: Why "Standards Action"? Would you
expect some harm to be done if this were only Spec Required?

Editorial:

- Is section 2 expected to be useful to implementers once this is
published as an RFC? Unless there's a reason otherwise, I would suggest
moving this to an appendix, or even removing it entirely. As it is, you
have to wade through an unusual amount of front material before you get
to the meat of the protocol.

- Along the lines of the previous comment, I found the organization a bit
hard to follow. I didn't find actual protocol details until around page
21. Procedures are split (and sometimes repeated) between the procedure
sections and the message format sections. I think that will make this
more difficult and error prone than necessary for implementors to read
and reference.  I fear readers will read one section and think they
understand the procedures, and miss a requirement in the other.

- 3.5.2.2: First bullet:
Please consider a "MUST NOT construction. "MUST only" can be ambiguous.
It would be helpful to explain why the loop count must not be more than
one. I can infer that from the later sections on relays, but it was not
obvious when reading this section. And unless I missed something, there's
no text that puts the two ideas together.

- 3.5.4.5: This section seems redundant to the similar sections under
negotiation . Since those sections have more information, would it make
sense to consolidate them there?