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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 04 August 2020 11:46 UTC

Return-Path: <mcr@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 77D143A0985 for <anima@ietfa.amsl.com>; Tue, 4 Aug 2020 04:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 A61IMB2dGFRv for <anima@ietfa.amsl.com>; Tue, 4 Aug 2020 04:46:17 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F6B3A0983 for <anima@ietf.org>; Tue, 4 Aug 2020 04:46:15 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [206.108.166.28]) by relay.sandelman.ca (Postfix) with ESMTPS id DDF651F47B for <anima@ietf.org>; Tue, 4 Aug 2020 11:46:12 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 02D391A02CB; Tue, 4 Aug 2020 07:46:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima\@ietf.org" <anima@ietf.org>
In-reply-to: <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com> <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de>
Comments: In-reply-to Toerless Eckert <tte@cs.fau.de> message dated "Thu, 30 Jul 2020 18:11:42 +0200."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 04 Aug 2020 07:46:03 -0400
Message-ID: <12431.1596541563@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/0AHHPwRejzr1bJ4Ob9KlELxjRKE>
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: Tue, 04 Aug 2020 11:46:21 -0000

Toerless Eckert <tte@cs.fau.de> wrote:
    > Maybe here is a good logic:

    > The short document would not need to be an Update as long as we do not
    > want to eliminate the old /est URLs.

okay, then let's not make the change at all, it's mostly cosmetic.

    > Aliasing should be easy enough.

Aliasing on the server sides (MASA, Registrar) is trivial.
But, the alias will have to remain for all time.

Aliasing on the client, which has to make a decision and possibly a discovery
is non-trivial.  This is why I want to do this *NOW*, or not at all.

In addition, it's clear that we need a registry here!

There are four questions:

1) do we really need to rename anything?
2) do we really need to Link Discovery for the HTTP version? (CoAP version
   already does it in ace-coaps-est)
3) is this a rename or an alias?
4) do we want to do this in (a) BRSKI base document, (b) short document, (c)
   BRSKI-AE document.


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.

3) I see an alias as a waste of time. It's either a rename, or don't do it.

4) If we want to do this, then do it in the base document.
   Yes, with *ALL* the delay risk that Brian Carpenter mention.

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