Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

"Fries, Steffen" <> Tue, 04 August 2020 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C31893A0D63 for <>; Tue, 4 Aug 2020 10:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zPtqquKX_hfc for <>; Tue, 4 Aug 2020 10:08:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E9CB3A0D92 for <>; Tue, 4 Aug 2020 10:08:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id A25824F0011; Tue, 4 Aug 2020 19:08:05 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 9DD3915E71F84; Tue, 4 Aug 2020 19:08:05 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Tue, 4 Aug 2020 19:08:05 +0200
Received: from ([]) by ([]) with mapi id 15.01.2044.004; Tue, 4 Aug 2020 19:08:05 +0200
From: "Fries, Steffen" <>
To: Michael Richardson <>, "" <>
Thread-Topic: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AdZmfbkJ/iBKc9n1QAWzDvrnlpnz3///+0AAgAeRb4D//879sA==
Date: Tue, 4 Aug 2020 17:08:05 +0000
Message-ID: <>
References: <> <> <12431.1596541563@dooku>
In-Reply-To: <12431.1596541563@dooku>
Accept-Language: en-US, de-DE
Content-Language: en-US
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-04T17:08:03Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=118e283d-3063-4102-8f75-4d5e3c90d02c; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: []
x-tm-snts-smtp: 83B59AE5170443E7824F6551259F89EDFFA98F12EF9C858A689035CA65BD7DE22000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Aug 2020 17:08:17 -0000

Hi Michael,

Thank you for your view on the discussion and the proposals. 
> Aliasing on the server sides (MASA, Registrar) is trivial.
> But, the alias will have to remain for all time.
Yes, that was the burden connected. 

> Aliasing on the client, which has to make a decision and possibly a discovery is
> non-trivial.  This is why I want to do this *NOW*, or not at all.

> In addition, it's clear that we need a registry here!
> There are four questions:
> 1) do we really need to rename anything?
> 2) do we really need to Link Discovery for the HTTP version? (CoAP version
>    already does it in ace-coaps-est)
> 3) is this a rename or an alias?
> 4) do we want to do this in (a) BRSKI base document, (b) short document, (c)
>    BRSKI-AE document.
> My answers:
> 1) No, I don't want to rename anything.  Let BRSKI-AE establish a new registry.
> 2) I don't want to Link Discovery, and I think it's harmful if BRSKI-AE
>    proposes this rather than it being in the base document.
Just to be sure I understand it right, the discovery of enrollment endpoints would still be part of BRSKI-AE? 
So what we added in section 5.3 of the latest BRSKI-AE is still necessary to my understanding?

> 3) I see an alias as a waste of time. It's either a rename, or don't do it.
Renaming would be the much clearer way forward in the light of multiple (different) enrollment endpoints supported at the registrar and the connected processing as discussed.

> 4) If we want to do this, then do it in the base document.
>    Yes, with *ALL* the delay risk that Brian Carpenter mention.
My take from the discussion so far regarding that point was rather reluctance regarding changes in the base document due to the connected delay, but as you stated, it would be the clean way. 

Best regards

> --
> Michael Richardson <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-