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

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 30 July 2020 15:46 UTC

Return-Path: <steffen.fries@siemens.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 780B53A0AC3 for <anima@ietfa.amsl.com>; Thu, 30 Jul 2020 08:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 160FDYY2Wc3R for <anima@ietfa.amsl.com>; Thu, 30 Jul 2020 08:46:12 -0700 (PDT)
Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA9A3A0ABD for <anima@ietf.org>; Thu, 30 Jul 2020 08:46:12 -0700 (PDT)
Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de []) by gw-eagle2.siemens.com (Postfix) with ESMTPS id 87677468014; Thu, 30 Jul 2020 17:46:10 +0200 (CEST)
Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net []) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 49B141511CF94; Thu, 30 Jul 2020 17:46:10 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net ( by DEMCHDC8A2A.ad011.siemens.net ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 30 Jul 2020 17:46:09 +0200
Received: from DEMCHDC8A1A.ad011.siemens.net ([]) by DEMCHDC8A1A.ad011.siemens.net ([]) with mapi id 15.01.1979.003; Thu, 30 Jul 2020 17:46:09 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr@sandelman.ca>, Eliot Lear <lear@cisco.com>, "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, Toerless Eckert <tte@cs.fau.de>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AdZmfbkJ/iBKc9n1QAWzDvrnlpnz3w==
Date: Thu, 30 Jul 2020 15:46:09 +0000
Message-ID: <3f2d1790efb44ac39405a23dc592dd89@siemens.com>
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-07-30T15:46:05Z; 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=c15637ac-96a8-4787-9bee-3af6edd47582; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: []
x-tm-snts-smtp: 2F45A1E04F9BF1E72A9A25D370AE0347B26E90E6C1A8EF7548BAF4B339DB226E2000: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/jjusQdqzS3G4WbczolCxF0_YmQQ>
Subject: [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, 30 Jul 2020 15:46:15 -0000


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 Fries
Siemens AG, Corporate Technology