[Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 30 September 2017 01:03 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B3D51134317; Fri, 29 Sep 2017 18:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MjTyMZU-WSf5; Fri, 29 Sep 2017 18:03:07 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CC81342FF; Fri, 29 Sep 2017 18:03:07 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id d187so582054pfg.11; Fri, 29 Sep 2017 18:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/vP7K6abK5upi/51uZvzrCIWIzXtdFuzhv9L9RBZg6I=; b=FXuwp8VIvIRV33AOE+skxzo1ECn1TnfWTE/cm81Gw8RbR7x7kBI5xrYG4DS5fSkhuE v69/DUEDkRzdQrBFkodmC2TEV8V2xXDEFh/se7YQPDi4w0zLLFd7Y00KUsUGR8Lq3Ph7 3ObjL1t2n4NQElDvJNT/Hhsz3BiolvoDaSzJf9QpYM2KcS8Vbp4iV4U4p3wKXqViieHu bV/4EAczVfDNV3CwEUZ0xvsLXYHy2Hg4qOPgusMSfGC7n5sELuwz1vCTe6NA6Kv1enHr vnZvV2YVDta8KnVqQpP4uA4kyk09TjNsxALDx5gaRSpcUtRwauysM+DO7LhZyJe618Bk fbPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/vP7K6abK5upi/51uZvzrCIWIzXtdFuzhv9L9RBZg6I=; b=c2913T1KE5zzVpgnNVtRa9NppiTI4N+ZJq/+8uGjdd4MuVO9gAmOcwvT/dRknm97F4 h69aUmSa/u3g5XOKHHR5L1W4Xcuotq+txS17JkWS4cMAnGzb9IlUaMjIbHtwJL3NLt3y fKBNNgANQwplMBM0QWlAsoWmpyQVzfLrUYC8mR13cTqjCNS2+147SMk4VRQ9JiMFM14r jkDnhTtQYX/bgL+DlMrPFxTiyUBNU97tFNj1bH6VZdYjxfSZLjLS/JdxHskxSKqB50bq qygre+D/BJUcKFkltgyT2zgbW6ilUFzSDpHhrXUKtXJ7f5LE77luBBAUryzjv2AeI45V l8yw==
X-Gm-Message-State: AHPjjUgWx/+nVCItIdyV/uHMNLaF/jshKfWpx9isbQQwYPUIJ1g86J1w 14PoHblYqCApHpGuittOLjuqcg==
X-Google-Smtp-Source: AOwi7QCSIhyvdk2LCPLh4gddMXNPQcQpVEgNjleAEog0v/75/hQGYIe4AsQYB6jUN4XXZse7R3T5CA==
X-Received: by with SMTP id i15mr9396535pfi.257.1506733386282; Fri, 29 Sep 2017 18:03:06 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 65sm7881748pgh.31.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 18:03:05 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca> <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de> <19014.1506705896@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <d7495a4d-380b-7b9a-e2ba-561952f747d7@gmail.com>
Date: Sat, 30 Sep 2017 14:03:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19014.1506705896@obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/PAFui30cRqYb_oiwlqwQeJrPEwI>
Subject: [Anima] Some questions to the WG: [I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]
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: Sat, 30 Sep 2017 01:03:09 -0000

On 30/09/2017 06:24, Michael Richardson wrote:
> Toerless Eckert <tte@cs.fau.de> wrote:
>     > On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
>     brian> Toerless explained elsewhere why he thinks the duplication is
>     brian> needed.
>     >>
>     >> I read that after my email.
>     >> I simply can't agree.
>     > I don't think i was suggesting duplication. I was suggesting for
>     > one document to define an extensibel objective and the other draft to
>     > extend it.
> Objectives are so easy to define and require so little IANA coordination that
> I don't see why we would want to extend it without also updating the BRSKI
> document.
> So to be clear: this is overly general, and I am opposed to this.

So there are several separate questions here.

1. I understood Toerless to be arguing that the registrar may need to be
contacted again some considerable time after the bootstrap (i.e. join)
action, specifically for what he called EST-renew.

Is that agreed?

2. If yes, would that need a new discovery action?

I assume the answer is yes, since we want to be reasonably
stateless and not assume that we can cache the registrar's address
and port indefinitely.

3. If so, do we want to re-use the same objective (AN_join_registrar
for the sake of argument)? Or would we prefer this to be a distinct

(I don't think the question would be different in a DNS-SD regime:
one service or two?)

4. In any case, do we want to make this objective or objectives
highly extensible (which basically means using CBOR maps instead
of simple CBOR arrays)? This has the usual pros and cons:
highly extensible = more complex parsing.

There's no doubt this can be done; I've already checked that even
my prototype GRASP code can carry quite complex CBOR structures
transparently. But it does assume that the recipient ASA can
reliably parse them, which is a reasonably complex requirement
for AN infrastructure components.

I don't have preconceived answers to questions 1, 3 and 4. What
do people think?

Toerless also wrote:

> The extensibel notation i was suggesting would also result in the
> definition of a brski-enrol service name that would be useable outside
> of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

I didn't quite get that. Although we currently require that GRASP
runs over an ACP, there is nothing magic about that. I don't see that
BRSKI actually depends on the ACP either; both would surely run over
bare metal if we told them to (and the Security ADs weren't watching).