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.
