Subject: [Anima] Erik Kline's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 22:01:34 -0800

Erik Kline has entered the following ballot position for
draft-ietf-anima-grasp-api-08: 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-api/

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

[[ questions ]]

[ section 2.3.2.4 ]

* It looks like the URI may contain an IP address or FQDN as well as a
  port number?  If so, is there a validation requirement about the presence
  or value of the port field in the ASA_locator in relation to the port
  number in the URI?

[ section 2.3.3. ]

* For deregister_asa(), if the ASA name is redundant, does that mean that
  a call like deregister_asa(asa_nonce=valid_nonce, name="") should succeed?

  I suppose one ASA can deregister other ASAs by cycling through the 32-bit
  numberspace?

* For register_objective(), but happens if overlap=False for an objective
  already registered with overlap=True?  And what about the inverse?

  I guess, what is the trust model of multiple ASAs sharing a GRASP core
  (i.e. on the same node)?

[ section 2.3.4 ]

* For objectives that other ASAs on the same node might be trying to
  discover(), is the cache kept separate per-ASA or shared?

  If shared, it seems like the TTL<minTTL entries should be ignored and not
  deleted, maybe? (I haven't read any text describing cache implementation
  requirements or guidance yet.)

* For asynchronous mechanisms, is the callback (if used) called multiple
  times, as locators are discovered or are they accumulated until the timeout
  is reached and returned in one callback invocation?

  If the former, is there one final callback with, if necessary, an empty list
  to indicate the timeout was reached (as a convenience)?

[[ nits ]]

[ abstract ]

* "adapted to the support for" -> "adapted to add support for", perhaps

[ section 2.3.2.4 ]

* Perhaps replace "ifi...probably no use to a normal ASA" with something like
  "probably only of use to an ASA on a node with multiple active interfaces"?

[ section 2.3.6 ]

* s/caches all flooded objectives that it receive/... that it receives/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Dec 2020 14:02:26 +1300

Hi Erik,

Thanks for the review. A few replies below...

> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/

Short answer: no. As noted in the text, ASAs "are presumed to provide correct
locators". Longer answer: the usage of both FQDNs and URIs as locators is
specified in GRASP for completeness, but we've never worked out the details.
In particular, you will notice that there is no transport type for HTTP
defined. The underlying text in the GRASP spec is at:
https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.9.5

>   a call like deregister_asa(asa_nonce=valid_nonce, name="") should succeed?

Good question. [Pause to look at code.] I see that I coded it to fail
if the name doesn't match, which protects against mistakes, but also...
 
>   I suppose one ASA can deregister other ASAs by cycling through the 32-bit

...protects against this attack. We should probably tweak the wording.
 
>   already registered with overlap=True?  And what about the inverse?

Good question. I think the correct answer should be that all registrations
should be the same for a given objective; nothing else makes sense to me.

>   I guess, what is the trust model of multiple ASAs sharing a GRASP core

Part of the general trust model: if a node can join the ACP it is trusted,
so all ASAs in that node are trusted. As noted elsewhere, ASA authorization
is left for future work.

>   requirements or guidance yet.)

That's arguable. If one ASA decides it needs a fresh discovery, all other
ASAs will benefit. Flushing the cache won't affect sessions already under
way.

>   to indicate the timeout was reached (as a convenience)?

Hmm. I think that depends very much on the exact callback system in use,
and there seems to be quite a choice. 

> [[ nits ]]

Noted, thanks.

   Brian