Subject: [Anima] draft-ietf-anima-grasp-api discussion

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Apr 2018 11:50:35 +1200

A few comments on the issues raised at IETF 101:

>    2c. GRASP Application Program Interface (API) - 10min
>       9:55 - 10:05, by Bing Liu, draft-ietf-anima-grasp-api
> [Sheng Jiang] Why "current API lacks support explicit locators for an objective
>    " is an issue? It's straightforward to just expose it. And let the ASAs 
>    decide whether to use it.
> [Bing] We're not very sure whether it is good to open such detailed thing to 
>    ASAs by the GRASP module.

I think it is straightforward. In fact, I already added it to the Python
code, as an optional parameter for the register_obj() call. I found a
use for it in one variant of my demo implementation of BRSKI discovery.

So do people think the API description should include this?
 
> [Sheng] Error codes between API and GRASP module and error codes inside the 
>    GRASP are different. If it is the latter, it should be in GRASP document.
> [Bing] It's inside the GRASP, but it is mostly regarding to ASAs.
>    (Errata: it is actually in the API not in GRASP messages.)

Right. But it's still an open question whether most of the
return codes should be standardised or implementation-dependent.

The first four IMHO definitely need to be standard:

ok = 0       #"Call succeeded"
declined = 1 #"Declined"
noReply = 2  #"No reply"
unspec = 3   #"Unspecified error"

> [Toerless Eckert] The main issue to me would be that the functionality 
>    expressed over grasp is meant to be application information, so the trouble 
>    is to establish cross application standards. I try to do that in the DNS-SD 
>    draft which is trying to say okay whatever application you are if you're 
>    trying to signal a service then here is a standard for that and I think 
>    that's the type of functional document not an API document.

Correct, it's almost an API on top of the API ;-)

    Brian