Hi Erik, Thanks for the review. A few replies below...
On 02-Dec-20 19:01, Erik Kline via Datatracker wrote: > 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? 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 > > [ 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? 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 > numberspace? ...protects against this attack. We should probably tweak the wording. > * For register_objective(), but happens if overlap=False for an objective > 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 > (i.e. on the same node)? 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. > [ 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.) 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. > > * 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)? 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 > > [ 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/ > > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
