Re: [Anima] GRASP objective details for registrar

Toerless Eckert <tte@cs.fau.de> Mon, 25 September 2017 19:36 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B0134576; Mon, 25 Sep 2017 12:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 686aImt6D2sN; Mon, 25 Sep 2017 12:36:51 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7BA134587; Mon, 25 Sep 2017 12:36:49 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 96E2B58C4E9; Mon, 25 Sep 2017 21:36:44 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (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 <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, cabo@tzi.org
Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
Message-ID: <20170925193644.GA9705@faui40p.informatik.uni-erlangen.de>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <b392cf90-ffcf-d053-0a01-31b510277077@gmail.com> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> <f81e352b-a6af-adce-d60f-aef7c55748c2@gmail.com> <20170923065956.GC32014@faui40p.informatik.uni-erlangen.de> <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3ad2ebe1-c975-d115-4f26-2fe792f02779@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/_t3U-gwvjK25YruPmL2CZdgh8is>
Subject: Re: [Anima] GRASP objective details for registrar
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=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.
> 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 )