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

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 06 August 2020 07:51 UTC

Return-Path: <steffen.fries@siemens.com>
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 099593A0FFD for <anima@ietfa.amsl.com>; Thu, 6 Aug 2020 00:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 It1_p9sYCV89 for <anima@ietfa.amsl.com>; Thu, 6 Aug 2020 00:51:54 -0700 (PDT)
Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6953A0F3A for <anima@ietf.org>; Thu, 6 Aug 2020 00:51:54 -0700 (PDT)
Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id CE9E94680BF; Thu, 6 Aug 2020 09:51:52 +0200 (CEST)
Received: from DEMCHDC89XA.ad011.siemens.net (demchdc89xa.ad011.siemens.net [139.25.226.103]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id D1BEA15ECAB38; Thu, 6 Aug 2020 09:51:51 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by DEMCHDC89XA.ad011.siemens.net (139.25.226.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 6 Aug 2020 09:51:51 +0200
Received: from DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) by DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) with mapi id 15.01.2044.004; Thu, 6 Aug 2020 09:51:51 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AdZmfbkJ/iBKc9n1QAWzDvrnlpnz3///+0AAgAeRb4D//879sIACHpmA//7t5iA=
Content-Class:
Date: Thu, 6 Aug 2020 07:51:51 +0000
Message-ID: <eee14f13f5cf4183bf69e999c5fcea04@siemens.com>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com> <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de> <12431.1596541563@dooku> <2c4323c817134845ae7c36b41fd239c1@siemens.com> <11029.1596647559@localhost>
In-Reply-To: <11029.1596647559@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-06T07:51:49Z; 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=17ba410b-a9a4-44ee-b063-5680293001fa; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [139.21.146.185]
x-tm-snts-smtp: 877D19404309F23CE4A44B2DF0FDD148C0359AA0E90150C1935697C3C4F5C5432000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/rOIASs1HaFE-ti50QXAoILg4stU>
Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 06 Aug 2020 07:51:56 -0000

> From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
> Fries, Steffen <steffen.fries@siemens.com> wrote:
>     >> 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?
> 
> I frankly don't see the point of the discovery at all.
> 
> I understand the use case with CoAP, where one wants to be able to multicast a
> request to /.well-known/core to find out which devices support a particular
> service.
> HTTP does not have the same thing, so I don't see the point of agility in the end
> points if they are all in /.well-known anyway.
Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses HTTP, there is no need for a specific enhancement. The discovery using /.well-known will provide all available endpoints to the pledge, which then can evaluate the response. From an application perspective I would expect that the pledge may not support multiple enrollment approaches and simply try whatever he supports. The domain registrar would be the more capable component to support multiple options. 
For the constraint case (not contained in BRSKI), the discovery of specific endpoints is more important to not overload the pledge.   
Based on that, I would propose to update the example in section 5.3 of BRSKI-AE to list only /.well-know instead of the currently stated /.well-know/brski. 

> 
>     >> 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.
> 
> If there is value in renaming, then lets do it RIGHT NOW.
> I DO NOT WANT to confuse the market by having an RFC come out, followed by
> another one 'correcting' it six months later.
> I CAN NOT live with that situation.
As stated before, the value from my understanding is more clarity (distinct naming) regarding the provided services/endpoints.

> 
>     >> 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.
> 
> Do we agree that this rename is cosmetic?
> It appeals to humans, computer code does not care in any way.
> If the WG can tolerate the process risk, then it shouldn't be a problem.
> If we can agree by the end of the week to do this, then the changes could be
> approved in less than a week, if the ADs agree that this does not require a new
> IETF LC.
As this is essentially a name change and does not change the functionality of BRSKI I would assume that there is no need for an new IETF LC, which would slow down publication. With that assumption in mind, I would be in favor. 

Best regards
Steffen
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -=
> IPv6 IoT consulting =-