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