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 )
>
>
import grasp
err, anonce = grasp.register_asa("test") #register as an asa
obj = grasp.objective("AN_registrar") #create an objective
obj.synch = True
obj.value = {"std": {"grasp-sender-ttl": 10, "service": {"name": "toe",
"priority": 3, "weight": 5}}}
err = grasp.register_obj(anonce, obj) #register the objective
tobj = grasp.tagged_objective(obj,None) #tag the objective (lazy: set a null
locator)
err = grasp.flood(anonce, None, tobj) #flood the tagged objective
_MainThread 3636 Assembled Python message [9, 863884159,
b'fd6345ebdc1500000000000000000001', 0, [[['AN_registrar', 5, 6, {'std':
{'grasp-sender-ttl': 10, 'service': {'name': 'toe', 'weight': 5, 'priority':
3}}}], []]]]
_MainThread 3636 Assembled CBOR message:
b'85091a337dd37f50fd6345ebdc1500000000000000000001008182846c414e5f7265676973747261720506a163737464a27067726173702d73656e6465722d74746c0a6773657276696365a3646e616d6563746f656677656967687405687072696f726974790380'
_mclisten 3424 Received multicast
b'85091a337dd37f50fd6345ebdc1500000000000000000001008182846c414e5f7265676973747261720506a163737464a27067726173702d73656e6465722d74746c0a6773657276696365a3646e616d6563746f656677656967687405687072696f726974790380'
from fe80::c0da:ac17:5f6d:8e76 port 51865 interface 11
_mclisten 3424 Multicast: CBOR->Python: [9, 863884159,
b'fd6345ebdc1500000000000000000001', 0, [[['AN_registrar', 5, 6, {'std':
{'grasp-sender-ttl': 10, 'service': {'name': 'toe', 'weight': 5, 'priority':
3}}}], []]]]
_mclisten 3424 Initiator: fd63:45eb:dc15::1
_mclisten 3424 Listening for LL multicasts
_mchandler 5520 Multicast handler got something
[IPv6Address('fe80::c0da:ac17:5f6d:8e76'), 51865, 11, [9, 863884159,
b'fd6345ebdc1500000000000000000001', 0, [[['AN_registrar', 5, 6, {'std':
{'grasp-sender-ttl': 10, 'service': {'name': 'toe', 'weight': 5, 'priority':
3}}}], []]]]]
_mchandler 5520 Got Flood message
dump_all()
<SNIP>
Flood cache contents:
--------------------
AN_registrar count: 6 value: {'std': {'grasp-sender-ttl': 10, 'service':
{'name': 'toe', 'weight': 5, 'priority': 3}}} source: None 6 7017 0_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
