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

"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Thu, 30 July 2020 17:14 UTC

Return-Path: <hendrik.brockhaus@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 920E43A0F25 for <anima@ietfa.amsl.com>; Thu, 30 Jul 2020 10:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com
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 ASkJOGYLVPC8 for <anima@ietfa.amsl.com>; Thu, 30 Jul 2020 10:14:13 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B25B3A0EC3 for <anima@ietf.org>; Thu, 30 Jul 2020 10:14:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sfpm+ibCrjbBu9wsEbMzZKdQeZIgHXXx9oZl7IusoXUnI5CYdUiTeNSkyQ5LztihlPvMoj77Ao3R0TB1PbWb4UYHLeB5erxrbuMlBOCpZz08zRMFPnf5WZLp3OL5lK73t9rbJoPYts0StXj5aZqrfEKcagghCNJRmaPkovxB+vlmjYDFPzt/ZIMa+F29/ObbT2VZnRkahL+/AlBm9B0FvBteOKX7xQLor+HXfyGX3V5AX7W/0nlOySwim60l+mpMr5NmBgFOHcd26mvBFKVSdSptY1kVJDwBXA8T1EzsfAnixXTawdyoISswEVjkSIdKZlNHndGwIZGn0Kec0vsR4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Znyg4gOkenD03iZSbVPtIqbIVEMKksv4eGkZxTL3WXg=; b=IoM64d/Fcji6/UltRtfMZd77MxuqioaQcOPngrly3cuW82qNr6bXDRh/DDQFFBRSDGJ4x04/N6ZeNJbJjxrThv+mqPWcMWCnhVNtyBbyqqO/V31qbgxNoWFiAF9R41Q2EB6sr+xMYZkxyvjgu8+oashcmuodmJtJ7fDQRnk6CYaN/3aJj2oKiyNsJFN47OGveWZT/KP9rPy9TwD9zD4LooFfwM92GN4VfBuLaSgTtN1ORHHBRij7+uF1p6xTIW+lzq+WO/aVulHWYXiOliaoUY/XVxxfW7ppgePIioLZM1wwa1rcvRJwyk3bvd5HZgzszhJfN+sJsQJJILTeAVBbuQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Znyg4gOkenD03iZSbVPtIqbIVEMKksv4eGkZxTL3WXg=; b=c4aKzIalHxpK9BMIL9r7+ELM9jL4Dc6wugboCJJW9zPIoIXKUWAk7Gl5Ph59HpRwgP+yhXHeZTtb26NwkWI6kJRz3kP2oIfkYMDFnHiEjZLiSui13LnWxZ+e+/DA5n7ObZmR5Za/Qgx5N+vR/TFWLKLLKrCMUXpha4hKoT0sr/0=
Received: from DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:112::10) by DB8PR10MB3130.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:f9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Thu, 30 Jul 2020 17:14:07 +0000
Received: from DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.COM ([fe80::4155:d977:e100:6be8]) by DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.COM ([fe80::4155:d977:e100:6be8%2]) with mapi id 15.20.3239.018; Thu, 30 Jul 2020 17:14:07 +0000
From: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "steffen.fries@siemens.com" <steffen.fries@siemens.com>, Michael Richardson <mcr@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>, Eliot Lear <lear@cisco.com>
Thread-Topic: Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AQHWZo79rZ1/3jVW+kuZRNM0r6HX+akgWvpA
Content-Class:
Date: Thu, 30 Jul 2020 17:14:07 +0000
Message-ID: <DB8PR10MB31628CAD0634A031B19C3AD6FE710@DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.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: de-DE, en-US
Content-Language: de-DE
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-07-30T17:14:06Z; 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=03300553-8f21-45eb-830a-aa358ef1af00; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [195.145.170.189]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7bb3e57e-c763-4a70-161b-08d834abf7f4
x-ms-traffictypediagnostic: DB8PR10MB3130:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB8PR10MB313055386D653F6D5D4FFB30FE710@DB8PR10MB3130.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6qCOeybvEekwl4OwUPk3UwgGT/MPytDT7scH7ukvvxvHFc9NeUKldfKRR1cUtptmsiAGSxrKiSvBwQcoLdHLiadujhmlknIZ67ENLRmyVEb+IVqrrm0MCXypBn1Hw866YTC3VyOUHbbHWaD1gE5Ds0dGGql06JViUyx8fepjtdLCxgmvIipq0HimC3Oymh7hTdDktBasJM9VvBz7gYOj1TY84OFvPhfdFlKSkDKnKd57OLr+ekvpbEF2F6gVOToWYOP9NYsKgW+85TQWXfm6634XqGj/pTqwJhrVB5XyJkp8UpxsmUoYNU5K7YdZVRKvgbdJASpebvVxDH3iHTP4gXoWp6azY7rL/20RwJRTNvsuVNGOwzorkXLYufbBtdba
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(346002)(396003)(136003)(376002)(83380400001)(4326008)(66574015)(7696005)(8936002)(316002)(9686003)(52536014)(71200400001)(86362001)(55016002)(6506007)(53546011)(54906003)(5660300002)(26005)(66446008)(33656002)(76116006)(478600001)(6916009)(8676002)(2906002)(186003)(66946007)(66556008)(64756008)(66476007)(166863002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 20x+S7gZvKYcpKtlCueb5oF7FKWqpnN+yT5HPY6XIyy/pt/x8U5ItV9QQOedddCFyyYvDYq0U+04rMuKFB5O3pW5XZNqW32s/dFfJqnN0f7ZkztVRgbpmZcm4EQCSMsnHnBwgqgyBIwWAaT6wzx3PGCVDbmELS4zbUJP/FC17vTa/z+fls/i/4328c2hxhUrd+F5hzOj1dip1gvR5AURi0vE1IN9iIliWWdxwg53nLoZiHQ/ZuP+9Oj9c9A168cTzKa6Dqc+kBA1sTIB9RlaNg07D9ftitpAp48MHoqDcUQaVD1ATtl1d9usdv57xpcs8SFTvt4SXjgR3oJTB5/RPJWJ+R7Mc35ebiOLZOwyFUIBjYo/FxIAu0DxuY0MU2Mj1MCM+JHB0IHwkK/BYImO3XyYQF9Zc8qi7117ZU9yam4rcKB3zbn6iApajkMgwTdbDUYIdk0n2qMPXA+ozkyHwZ5LLcZY5uLm/xdCwEOVgPPLFexG220bkRtNUzaILIiLs50qMLvJAoBBhRYYsbHY0QhQJVy8Zo5ar+ouhgBYwuQhs6boXrAgY9pGtxeZyWBpm+PGFsMtRefKFIYbgpSWfCfj66b0Z/Nji1sz+GYVAjJcz7bPzmCLJwriIeABBU1x3fDPbYDNBmkm90cwHexGbQ==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB8PR10MB3162.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7bb3e57e-c763-4a70-161b-08d834abf7f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 17:14:07.6079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fzD/R3XJMqijCViPoYv8KQt51pvUtaJ/yVq894Ufv9+l2FmsI0924XjMJMHGRNGrc1SPUtIhFzLBPGEZDUUzrNkETvl5xCyhnYaGokKoMg0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR10MB3130
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/moE_l_YHt2QO6Lt58pNlM-InSME>
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, 30 Jul 2020 17:14:17 -0000

Toerless

I have one question to better make up my mind.
How long do you thing would the change to the BRSKI document delay the approval process? 
Finally this change is quite easy to explain. And from my point of view, doing this change to BRSKI before approval, would be, from a standardization point of view, the clearest solution.

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Toerless Eckert <tte@cs.fau.de>
> Gesendet: Donnerstag, 30. Juli 2020 18:32
> An: Eliot Lear <lear@cisco.com>
> Cc: Fries, Steffen (CT RDA CST) <steffen.fries@siemens.com>om>; Michael
> Richardson <mcr@sandelman.ca>ca>; Brockhaus, Hendrik (CT RDA CST SEA-DE)
> <hendrik.brockhaus@siemens.com>om>; anima@ietf.org
> Betreff: Re: Handling of endpoint path names (from BRSKI-AE discussion today)
> 
> On Thu, Jul 30, 2020 at 06:06:09PM +0200, Eliot Lear wrote:
> > Steffen
> >
> > I enjoyed today???s discussion.  My suggestion is a short document that does
> not CHANGE endpoints but simply creates new ones that have the same
> functionality as the old ones.  That doesn???t require an ???Updates??? header,
> and based on that I think you might even keep these in the same document.
> Would people be ok with that?
> 
> 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.
> 
> 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