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