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

[Michael Richardson <[e-mail]>]

Fries, Steffen <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-