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

[Michael Richardson <[e-mail]>]

Fries, Steffen <[e-mail]> wrote:
    >> -----Original Message-----
    >> From: Michael Richardson <[e-mail]>
    >> Sent: Freitag, 28. August 2020 20:32
    >> > Maybe I phrased it wrong. The intention is not to make the pledge more
    >> > complex. The goal should be to keep the pledge simple and enhance the
    >> > registrar to handle also other situations like unavailability of
    >> > certain connections. The registrar should be the more capable
    >> > component. The discovery was intended in situations, in which the
    >> > registrar supports multipole options, but not all may be mandatory
    >> > supported. In this case the discovery would help. Otherwise the pledge
    >> > may do trial and error.
    >>
    >> While I appreciate the idea of having the pledge fail faster, and go onto to
    >> the next possible registrar, I think that the pledge should support one and
    >> only one mechanism, and it's up to the registrars to keep up.

    > Yes, this keeps the pledge simple, but would require the registrar to
    > implement the other options mandatorily.

*A* Registrar has to implement the right options.
There could be more than one system with the same CA behind them.
I way prefer to just let the pledge implement one thing.

Maybe that will cause significant bifurcation in the BRSKI-capable thing
market, but I suspect that most registrars will implement it all.

    >> If we are doing proper ACP ANIMA, then we can include the enrollment
    >> options for the Registrar into the GRASP DULL announcement, and this can
    >> inform the pledge's decision as to which Registrar to pick.

    > This would also be an option for a  discovery, but I have to dig deeper into GRASP.

okay.

    >> I don't yet understand how the voucher-request is done in async BRSKI.

    > I realize more an more that a pure "request-object" without considering
    > the transport is probably too abstract. Implementing requires also the
    > transport.

Yes, okay, I thought that this was in scope for this document.
Or, when I agreed to adopt, I thought that.

I have quite a few ideas on how to do this: we really ran through them all
during BRSKI/6tisch-zero-touch/SZTP and we settled on a compromise.

    >> I thought that was what we were doing.. I have many ideas about this.

    > Yes, voucher-request and also certification-request would be collected
    > by the pledge-agent. Good to hear you have ideas here, as we need to
    > define the approach more precisely.

    >> > Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge would
    >> > be queried by the pledge-agent for certain objects. It was intended to
    >>
    >> But, how is it queried?

    > The pledge essentially must be able to listen for the request. In
    > industrial environments the embedded device is most often in a server
    > role waiting for requests. This would have to be leveraged also for the
    > PUSH interaction.

Cool.
I can also see BT and NFC being used for the push.

    >> Well, I thought that the furnace in the basement where there is no
    >> connectivity was a really good use case.
    >> The furnace installer has a smartphone or dedicated comissioning
    >device.

    > This was one of the point I concluded form the last meeting. The trust
    > assumptions about the pledge and pledge-agent interaction is one of the
    > points to be discussed further.

Good.

    >> As for HTTP: I would tend to suggest that we should use CoAP.
    >> This works over WIFI as well as other technologies, and convergence here
    >> would be good.

    > Which may bring it closer to the constraint voucher than BRSKI. I was
    > looking for the latter, hence HTTP as proposal. But this is open for
    > discussion.

:-)

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-