Re: [Anima] GRASP objective details for registrar

[Brian E Carpenter <[e-mail]>]

Here's confirmation that your CDDL generates a valid objective-value.
In the attached, you will find 8 Python statements and the resulting
output from a GRASP instance talking to itself.

If there's consensus to go this way I can update my demo code
for the BRSKI actors accordingly. But we need some WG discussion
about that, and I need to learn a bit about using maps in Python :-).

Regards
   Brian

On 26/09/2017 08:36, Toerless Eckert wrote:
> 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 )
> 
>