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

Michael Richardson <> Wed, 19 August 2020 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A79E23A0969 for <>; Wed, 19 Aug 2020 05:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QwXVPvlQEO-l for <>; Wed, 19 Aug 2020 05:53:52 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3D983A0975 for <>; Wed, 19 Aug 2020 05:53:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F6938A06; Wed, 19 Aug 2020 08:32:58 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id NbpniXYCDB3h; Wed, 19 Aug 2020 08:32:56 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id F2DE338A03; Wed, 19 Aug 2020 08:32:55 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 87F547B; Wed, 19 Aug 2020 08:53:47 -0400 (EDT)
From: Michael Richardson <>
To: "Fries\, Steffen" <>
cc: "anima\" <>
In-Reply-To: <>
References: <> <> <12431.1596541563@dooku> <> <11029.1596647559@localhost> <>
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, 19 Aug 2020 08:53:47 -0400
Message-ID: <6058.1597841627@localhost>
Archived-At: <>
Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Aug 2020 12:53:55 -0000

Fries, Steffen <> wrote:
    >> 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.

    > Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses
    > HTTP, there is no need for a specific enhancement. The discovery using
    > /.well-known will provide all available endpoints to the pledge, which
    > then can evaluate the response. From an application perspective I would
    > expect that the pledge may not support multiple enrollment approaches
    > and simply try whatever he supports. The domain registrar would be the
    > more capable component to support multiple options.

Can you explain to me why the discovery via /.well-known/brski is useful?
This is on the *REGISTRAR*.

In reading BRSKI-AE, I seem to be missing any place where the PUSH mechanism
is described.  In a PUSH use case, what protocol would the pledge expose to
the pledge-agent and/or commissioner?
As far as I can tell, in the PULL case, when CMP (or another mechanism) will
be used, there is still a voucher exchange first.  The Registrar can express
it's preference in the (parboiled) voucher-request from Registrar to MASA.

The MASA, if the pledge supports the desired enrollment protocol, could
include the hint.  In fact, the MASA could include an entire URL with
meta-data about the protocol to use.

This would jive very nicely with the brski-cloud mechanism!!!

    > For the constraint case (not contained in BRSKI), the discovery of
    > specific endpoints is more important to not overload the pledge.

I don't understand this at all.  What do you mean, overload the pledge?
Are you talking about network or code space or what?

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

    > As stated before, the value from my understanding is more clarity
    > (distinct naming) regarding the provided services/endpoints.

yes, but that's a cosmetic issue.
it appeals to humans, but it makes no technical difference.
Nevertheless, if we can do this quickly, then let's do it.
I've provided proposed text in the form of a diff, the ADs have agreed to a
process, the chairs , just need to run it.

I hope that your(Siemens) Thomas Werner will comment.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-