Re: [Anima] GRASP objective details for registrar

Toerless Eckert <> Mon, 25 September 2017 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC8B0134576; Mon, 25 Sep 2017 12:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 686aImt6D2sN; Mon, 25 Sep 2017 12:36:51 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C7BA134587; Mon, 25 Sep 2017 12:36:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 96E2B58C4E9; Mon, 25 Sep 2017 21:36:44 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 78554B0CCC2; Mon, 25 Sep 2017 21:36:44 +0200 (CEST)
Date: Mon, 25 Sep 2017 21:36:44 +0200
From: Toerless Eckert <>
To: Brian E Carpenter <>,
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Anima] GRASP objective details for registrar
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Sep 2017 19:36:54 -0000

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.

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.)


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 )