On 2018-11-28 02:11, Eliot Lear wrote:
> Hi Steffen
>
>> On 27 Nov 2018, at 11:49, Fries, Steffen <steffen.fr...@siemens.com> wrote:
>>
>> Getting back to my original question, do you see the asynchronous handling
>> of pledge enrolment as part of the current charter of the working group?
>
> I don’t know (I'll leave the to the chairs). Assuming yes:
>
>> If yes, would you rather expect to see EST enhanced to handle asynchronous
>> support or would it be better to allow for alternative enrolment protocol
>> support on the domain registrar featuring the handling of self-contained
>> objects? As the domain registrar is likely to be not a constraint device as
>> a pledge, this choice could technically be provided, while the pledge has
>> the freedom to choose, which enrolment to use.
>
> If the domain registrar is not there, that’s an easy one, right? Device just
> has to retry until the registrar is present (assuming it’s trying to
> onboard). Do you have requirements for more than that?
>
> If the domain registrar is there and the CA is not there, there are seemingly
> two choices:
> Store and forward from the registrar; or
> Reject the request until the CA is present
In the autonomic network ("professionally managed") scenario, I
would think of it more as a pre-fetch: somebody has pre-fetched
a nonceless voucher when the pledge was added to inventory, so
there's no need to connect to the MASA in real time.
In an on-demand situation, you're correct that it would be a
store-and-forward mechanism with a wait state. But that's
not ANIMA.
Brian
>
> If we add a 3rd approach of forwarding to some intermediary component, then
> *it* has to store and forward. In any case, the registrar needs to return a
> status to the pledge, saying, “Thanks for checking in… check back with me in
> X minutes” (where X might be some value that can back off based on load.
> Another alternative would be to refer to some 3rd player.
>
> To implement the store and forward, the registrar just needs a queue, but the
> pledge needs to remember the request (and any associated nonce). And I think
> that works out because any such behaviour would demand a few new EST RESTful
> endpoints.
>
> Eliot
>
>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
