Have still not gotten around to do a more thorough review.
The one top of mind thought is that the draft is not well selling
the purpose and benefit of GRASP to developers. Whether they want to
call their software ASA or not.
given enough time i'd probably like to propose text for that purpose, e.g.:
-> Grasp is meant to provide a simpler way to develop new "control plane"
protocols. Instead of building one-off TLV protocols
- Uses CBOR, so programming with appropriate tool chains should
be similarily easy as is development of web signaling via JSON
(e.g.: in javascript).
- GRASP itself is a very constraint set of common message header
definitions.
- If a new protocol only requires peer-to-peer communication between
nodes, it should be easy to use simple GRASP libraries linked to
the application.
- Typically, GRASP should be run on top of a security layer.
If the nodes that need to communicat with each other have for
example certificates to mutually authenticate each other, GRASP
would run on top of TLS/dTLS using those certificates for mutual
authentication.
-> If there is underlying infrastructure to suport these functions, GRASP
also support discovery mechanisms:
- Link-local discovery via link-local multicasted announce/query methods
This is easy to support whenever networks support link-local multicasting.
- network wide discovery via hop-by-hop flooding with loop prevention.
- One infrastructure supporting this is when GRASP is run across the ACP.
Something along these lines. However we can pimp it up ;-)
Cheers
Toerless
E.g.:
In-Reply-To: <[email protected]>
On Mon, Apr 23, 2018 at 11:50:35AM +1200, Brian E Carpenter wrote:
> 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
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
