Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
"Fries, Steffen" <steffen.fries@siemens.com> Mon, 03 August 2020 05:53 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 CBDB33A0B5F
for <anima@ietfa.amsl.com>; Sun, 2 Aug 2020 22:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5
tests=[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 u6lWdbYDd1b1 for <anima@ietfa.amsl.com>;
Sun, 2 Aug 2020 22:53:02 -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 E3C403A0B55
for <anima@ietf.org>; Sun, 2 Aug 2020 22:53:01 -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 316AE4681F5;
Mon, 3 Aug 2020 07:53:00 +0200 (CEST)
Received: from DEMCHDC89ZA.ad011.siemens.net (demchdc89za.ad011.siemens.net
[139.25.226.105])
by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id CD89A15DEB3C0;
Mon, 3 Aug 2020 07:52:58 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by
DEMCHDC89ZA.ad011.siemens.net (139.25.226.105) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1979.3; Mon, 3 Aug 2020 07:52:58 +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.1979.003;
Mon, 3 Aug 2020 07:52:58 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Toerless Eckert <tte@cs.fau.de>, Eliot Lear <lear@cisco.com>
CC: Michael Richardson <mcr@sandelman.ca>, "Brockhaus, Hendrik"
<hendrik.brockhaus@siemens.com>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AQHWZo79bAr72qfmUkWU2+63F1bKP6khuCNg
Content-Class:
Date: Mon, 3 Aug 2020 05:52:58 +0000
Message-ID: <3406efb08f9d41528d958e53b5ce9289@siemens.com>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com>
<2ABF0BD6-8084-46C4-8E96-4772582BDA01@cisco.com>
<20200730163211.GC62130@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200730163211.GC62130@faui48f.informatik.uni-erlangen.de>
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-03T05:52:57Z;
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=83a706e9-5b9f-47fe-a47b-e74dc017c883;
MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [139.21.146.184]
x-tm-snts-smtp: 0F55CE0AA3BE1A5E6CC32F91D90BE07E5E55809C9158776B8199E7F1326A2DA02000: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/G8Pq2KUlmcRo7qcTdlDrv0QCqXY>
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: Mon, 03 Aug 2020 05:53:04 -0000
> From: Toerless Eckert <tte@cs.fau.de> > Sent: Donnerstag, 30. Juli 2020 18:32 > Right. So the question is keep it in the document or put it into a separate > small one. The small one would allow other derivative work not to have to > have BRSKI-AE as a normative reference, which may be better if its got > nothing to do with BRSKI-AE. > > I guess we can delay the decision up to the point when we do see such other > derivative work coming up, and then decide whether to separate out the > new /brski naming from the doc. As long as there is no such additional doc, > we keep things in BRSKI-AE as they are right now. >From my perspective the endpoint naming is independent from BRSKI-AE and we basically came to the discussion based on the illustrative example for the discovery option in BRSKI-AE. So keeping it in BRSKI-AE and making it independent upon further need also works. We may reuse the text then for a separate document if necessary. I conclude that the WG is in favor of this way. Best regards Steffen > > Cheers > Toerless > > > Eliot > > > > > On 30 Jul 2020, at 17:46, Fries, Steffen <steffen.fries@siemens.com> > wrote: > > > > > > Hi, > > > > > > Based on the discussion of splitting up the voucher handling endpoint > naming issues from BRSKI-AE today, I just wanted to ensure I got the way > forward right. > > > From the Etherpad discussion I understood Michael that he would not be > too happy with having a BRSKI update right after BRSKI publication as RFC. I > think finalizing the discussion on the list was advised. > > > > > > What we discussed in the WG meeting was to have a separate short > document, basically defining a renaming or alternatively an alias for the > current endpoints, which allows to keep the current implementations as is. > > > Hence, the draft would relate to all of the endpoints defined in section 5 > of BRSKI for the domain registrar facing the pledge (and potentially also the > MASA), which are: > > > /.well-known/est/requestvoucher used by pledge to registrar but also > from registrar to MASA > > > /.well-known/est/voucher_status used by pledge to registrar > > > /.well-known/est/requestauditlog used by registrar to MASA > > > /.well-known/est/enrollstatus used by pledge to registrar > > > > > > From Toerless I understood that he would like to not change the current > draft as it is already in the final state and rather provide an update as > separate document. > > > From Michael I understood he would not be keen on having a fast update > for the BRSKI document. At least not for a renaming of the defined > endpoints. Also the IESG may view this as too fast. > > > Eliot stated that there are already implementations out there that utilize > the /est approach. So having aliases could be one way of dealing with it, but > this would double the endpoints at least for the four stated ones above. > > > > > > Both approaches have there merits. Having the endpoints distinct from > the beginning allows a clearer separation of the functionalities, for the > pledge and for server side handling. Specifically if we later on allow for > alternative enrollment protocols in BRSKI-AE and define the discovery > approach, it will lead to less confusion to align the naming with the > corresponding functionality. From that perspective, my gut feeling would be > that an integration into base BRSKI may be more appropriate. On the > contrary, it will slow down the process, but somebody stated that there are > examples that these changes have been also done in the past and could be > done fast. > > > > > > What do you suggest as way forward? > > > > > > Best regards > > > Steffen > > > > > > > > > -- > > > Steffen Fries > > > Siemens AG, Corporate Technology > > > mailto:steffen.fries@siemens.com > > > > > -- > --- > tte@cs.fau.de
- [Anima] Handling of endpoint path names (from BRS… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Eliot Lear
- Re: [Anima] Handling of endpoint path names (from… Toerless Eckert
- Re: [Anima] Handling of endpoint path names (from… Toerless Eckert
- Re: [Anima] Handling of endpoint path names (from… Brockhaus, Hendrik
- Re: [Anima] Handling of endpoint path names (from… Brian E Carpenter
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- [Anima] possible last minute changes to anima-boo… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] possible last minute changes to anima… Mark Nottingham
- Re: [Anima] possible last minute changes to anima… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Werner, Thomas
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Brian E Carpenter
- Re: [Anima] Handling of endpoint path names (from… Esko Dijk
- [Anima] constrained handling of endpoint path nam… Michael Richardson
- Re: [Anima] constrained handling of endpoint path… Esko Dijk
- Re: [Anima] constrained handling of endpoint path… Michael Richardson