Michael Richardson wrote:
> > Besides this, we see further use cases, in which the connection to the
> PKI is
> > not always available. This may be the case if the connection to the CA
> is only
> > temporary available or not directly available. Here, the approach would
> require
Fries, Steffen wrote:
> Besides this, we see further use cases, in which the connection to the
PKI is
> not always available. This may be the case if the connection to the CA is
only
> temporary available or not directly available. Here, the approach would
require
> a rather
On 2018-12-03 06:44, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Indeed not. My suggestion creates no new protocol and doesn't change
> anything
> > for the registrar, proxy, and pledge. It recycles the registrar-MASA
> protocol
> > as the registrar-OASA protocol.
Brian E Carpenter wrote:
> Indeed not. My suggestion creates no new protocol and doesn't change
anything
> for the registrar, proxy, and pledge. It recycles the registrar-MASA
protocol
> as the registrar-OASA protocol. And presumably it also recycles the
registrar-MASA
>
Brian E Carpenter wrote:
> OK, thanks. I'm interested in another scenario too: one where the
> operator will not accept using a connection to the open Internet and
> therefore will not accept any real-time access to any MASA. As I've
> said for several years, this is a highly
On 2018-11-29 00:26, Fries, Steffen wrote:
> Hi Brian,
>>> [stf] Agreed. Although I’m not sure if store and forward could be solely a
>>> functionality of the domain registrar and not necessarily a
>> new component.
>>> Getting back to my original question, do you see the asynchronous handling
On 2018-11-28 02:11, Eliot Lear wrote:
> Hi Steffen
>
>> On 27 Nov 2018, at 11:49, Fries, Steffen 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
On 2018-11-28 00:49, Fries, Steffen wrote:
> Hi Eliot
...
>>> OK, thanks. I'm interested in another scenario too: one where the operator
>>> will not accept using a connection to the open Internet and therefore will
>>> not accept any real-time access to any MASA. As I've said for several
>>>
Hi Eliot,
On 2018-11-27 23:04, Eliot Lear wrote:
>
>
>> OK, thanks. I'm interested in another scenario too: one where the operator
>> will not accept using a connection to the open Internet and therefore will
>> not accept any real-time access to any MASA. As I've said for several years,
>>
Hi Eliot
On 27 Nov 2018, at 11:49, Fries, Steffen
mailto: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
Hi Steffen
> On 27 Nov 2018, at 11:49, Fries, Steffen 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
Hi Eliot
OK, thanks. I'm interested in another scenario too: one where the operator will
not accept using a connection to the open Internet and therefore will not
accept any real-time access to any MASA. As I've said for several years, this
is a highly likely scenario in some types of network
> OK, thanks. I'm interested in another scenario too: one where the operator
> will not accept using a connection to the open Internet and therefore will
> not accept any real-time access to any MASA. As I've said for several years,
> this is a highly likely scenario in some types of network
Hi Brian
-Original Message-
From: Brian E Carpenter
Sent: Sonntag, 25. November 2018 20:22
To: Eliot Lear ; Fries, Steffen (CT RDA ITS)
Cc: anima@ietf.org
Subject: Re: [Anima] BRSKI support for asynchronous processing
On 2018-11-26 02:09, Eliot Lear wrote:
> Hi Stef
Hi Eliot
I assumed it to be collocates with the RA and that the CA is separate.
Ok, well there we have it ;-)
I should have been more specific. I was referring to the EST request. The
BRSKI request regarding the voucher is assumed to a proxy residing inside the
plant. I assumed a strong
On 2018-11-26 02:09, Eliot Lear wrote:
> Hi Steffen
>
>
>> On 23 Nov 2018, at 20:27, Fries, Steffen wrote:
>>
>> Hi Eliot
>>
We are currently in the process of discussing different scenarios and
approaches for the onboarding of (IoT) devices in plants, substations, or
Hi Steffen
> On 23 Nov 2018, at 20:27, Fries, Steffen wrote:
>
> Hi Eliot
>
>>> We are currently in the process of discussing different scenarios and
>>> approaches for the onboarding of (IoT) devices in plants, substations, or
>>> cloud-based services. The current BRSKI document provides
Hi Eliot
We are currently in the process of discussing different scenarios and
approaches for the onboarding of (IoT) devices in plants, substations, or
cloud-based services. The current BRSKI document provides here a good approach
to address the case in which a pledge has an online connection
Hi Steffen
> On 23 Nov 2018, at 17:53, Fries, Steffen wrote:
>
> Hi everyone,
>
> We are currently in the process of discussing different scenarios and
> approaches for the onboarding of (IoT) devices in plants, substations, or
> cloud-based services. The current BRSKI document provides here
Hi everyone,
We are currently in the process of discussing different scenarios and
approaches for the onboarding of (IoT) devices in plants, substations, or
cloud-based services. The current BRSKI document provides here a good approach
to address the case in which a pledge has an online
20 matches
Mail list logo
