Fries, Steffen <[email protected]> wrote: >> -----Original Message----- >> From: Michael Richardson <[email protected]> >> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
