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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 05 August 2020 17:12 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 A96043A0DDD for <anima@ietfa.amsl.com>; Wed, 5 Aug 2020 10:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wHpawZmdUDMZ for <anima@ietfa.amsl.com>; Wed, 5 Aug 2020 10:12:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECF63A0DCE for <anima@ietf.org>; Wed, 5 Aug 2020 10:12:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 021EC38993; Wed, 5 Aug 2020 12:52:10 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X18ZNbYiHgPn; Wed, 5 Aug 2020 12:52:00 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B2DB638991; Wed, 5 Aug 2020 12:52:00 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A567C114; Wed, 5 Aug 2020 13:12:39 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Fries\, Steffen" <steffen.fries@siemens.com>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <2c4323c817134845ae7c36b41fd239c1@siemens.com>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com> <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de> <12431.1596541563@dooku> <2c4323c817134845ae7c36b41fd239c1@siemens.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 05 Aug 2020 13:12:39 -0400
Message-ID: <11029.1596647559@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/BLQMSsV7Cgw5yEiL5wTY1Fjc7A0>
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: Wed, 05 Aug 2020 17:12:52 -0000

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.

    >> 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.

    >> 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.

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