Toerless Eckert wrote:
> Could as well simply be a function which buffers flood-messages over a
> period of e.g.: 60 seconds and coalesces them together, so it's
> transparent to the originators (loose coupling).
> So, now i have a single flood-message with multiple objectives,
Toerless Eckert wrote:
> On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote:
>>
>> Brian E Carpenter wrote: > I need to
>> understand epochs a bit better. I wonder whether an epoch > boundary
>> should define when session-id repetition becomes OK (even if >
On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > I need to understand epochs a bit better. I wonder whether an epoch
> > boundary should define when session-id repetition becomes OK (even if
> > highly improbable). There's a
On Wed, Aug 24, 2022 at 04:57:21PM -0400, Michael Richardson wrote:
> > What I don’t understand is why the signature then needs to be encoded
> > as part of the objective. Why can’t I sign a combination of objectives
> > that are only valid as that combination?
>
> I think it could
Brian E Carpenter wrote:
> I need to understand epochs a bit better. I wonder whether an epoch
> boundary should define when session-id repetition becomes OK (even if
> highly improbable). There's a practical argument for that: a good
> implementation will cache obsolete
On 25-Aug-22 08:57, Michael Richardson wrote:
Carsten Bormann wrote:
> That is getting closer to my question “what does it mean for
> (something) to be signed”?
> Apparently, this is a statement from an initiator, valid within the
> session-id, optionally scoped to the
Carsten Bormann wrote:
> That is getting closer to my question “what does it mean for
> (something) to be signed”?
> Apparently, this is a statement from an initiator, valid within the
> session-id, optionally scoped to the locator option, and expressed in
> the objective.
The use case that led me to start some of this discussion was that of
using Information Centric Networking in emergency situations.
A key observation that many have made is that backup/emergency systems need
constant maintenance and testing, and if they aren't used regularly then they
tend to
On 2022-08-24, at 19:20, Toerless Eckert wrote:
>
> data-to-be-signed = [session-id, initiator, ?locator-option, objective ]
That is getting closer to my question “what does it mean for (something) to be
signed”?
Apparently, this is a statement from an initiator, valid within the
All for it, if we agree on the challenges with it (which i think are "easily"
solved).
My use-case is signing of objectives in flood-messages doing service
announcements,
e.g.: with my DNS-SD compatible approach (or any other approach).
1) We want the flooded message to be protected against
>If that's the case, we are on the wrong track. Should we be discussing
>signing GRASP objectives, rather than messages?
Agreed. We can work on a mechanism that can sign objectives first. Later,
if there were use cases that signed objectives were not sufficient, we can
define a flood message.
Brian E Carpenter wrote:
> On 23-Aug-22 21:56, Toerless Eckert wrote:
>> Agreed. My opininion is that the mandatory-to-verify is not at the
>> level of the flood-message, but at the objective definition level.
> If that's the case, we are on the wrong track. Should we be
On 23-Aug-22 21:56, Toerless Eckert wrote:
Agreed. My opininion is that the mandatory-to-verify is not at the
level of the flood-message, but at the objective definition level.
If that's the case, we are on the wrong track. Should we be discussing
signing GRASP objectives, rather than
13 matches
Mail list logo
