Re: [Anima] GRASP objective details for registrar

[Toerless Eckert <[e-mail]>]

On Sun, Sep 24, 2017 at 09:05:29AM +1300, Brian E Carpenter wrote:
> > What's the CBOR/CDDL tool you're using, i'll try it myelf first
> > before yelling for help ;-)
>
> It's a Ruby tool called simply 'cddl'
>
> Install Ruby and then install the gem called cddl.
> http://www.rubygemsearch.org/rubygems/cddl

Thanks! [ Cabo: Would be great if the output of cddl generate would
show barewords as strings and not as hexadecimal... ]

> I would argue that in many cases of simple objectives this would be a mistake.
> It's a conceptual and practical complication for the ASA writer, unless a
> map (and probably JSON) is already "native" for the problem at hand.
															    > I am absolutely not against maps for cases where they are the natural
> solution. But if the objective happens to be a simple value, why?

Sure. My high level question is how CBOR in IETF can and will establish
a larger framework of pre-defined/reused data types so that app developer
using GRASP (or other protocols with CBOR) could easier reuse existing
data-types when composing new information models. I remember the initial
discussion about how to indicate IPv6 addresses etc. pp.

My simple starting point idea within GRASP is to allow a structure
in which we can start defining such standardized data-types and
reuse them. They would not be at all mandatory, but offered as an
option to objective developers.

The two simple ways to do this is to use a map where the key 'std:' has
a sub-map with standardized keys using standardized value structures.

So, for M_FLOOD of services, which is what we need for ACP and BRSKI,
the standardized parameters i am interested in are:

-> ability to indicate sender-ttl
-> Ability to express service in an RFC2782/RFC6335 compatible
   fashion so that:
   a) We do not have to come up with a registry of our own, but just
      register the services names according to RFC6335
   b) We can perform service selection also compatible with
      RFC2782 if desired (prio/weight).

Appended the fixed syntax that i would want to propose as the structure for
mflood objective values - in a followup draft. In ACP i will just
use the definitions without assuming those will establish a standard
registry - that way we can make the choice whether we like the
idea of this becoming a standard registry for future work.

(oh: and if/when the low-bitrate folks start to complain about
 keys as barewords not being efficient, we can always add 
 a numerical registration based map option.)

Cheers
    Toerless

objective-value  = mflood-ovalue

; objective-value in M_FLOOD:
mflood-ovalue   /= { 1*parameter }

; Standardized parameter:
parameter      //= ( std: { 1*std-param } )

; Any non-standardized objective-value elements can be
; added by objectives in two ways:
; a) add to parameters (any map/tlv where the type is not 'std').
; This allows to have both std-param and objective specific params
; together
; parameter    //= ...
; b) choose a different value for mflood-ovalue, eg:
; string or list. Then you can not use std-param
; mflood-ovalue   /= ...

; value of ttl field of flood-message as set by sender.
; Upon receipt, (sender-ttl - ttl) is the distance of
; the receiver from the sender.
std-param      //= ( grasp-sender-ttl: 1..255 )

; DNS-SD compatible service supported by objective.
; service-name must be registered according to RFC6335
; an would therefore also useable in RFC2782 (DNS-SD)
; Do not register protocol/port numbers for new services
; unless there is a good reason. When using GRASP/ACP,
; protocol/port can be dynamically discovered.

std-param      //= ( service: service )
service          =  { service-name , *service-param }
; Same syntax, guidelines as service name in rfc2782
service-name     = ( name: tstr )
service-param    = selection-param
; Same semantic as rfc2782. Default = 0
selection-param //= ( priority: 0..65535 )
selection-param //= ( weight:   0..65535 )