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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
