Hi,
One quick comment on the draft.
> An example of discovery message using GRASP would be the following
> (in this example, the fog monitoring controller is identified by
> its IPv6 address: 2001:DB8::::::):
>
> [M_DISCOVERY, 13948745, h'20010db81
On 27-Jul-21 14:32, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > In other words, the method of bulk transfer described in
> > draft-ietf-anima-grasp-distribution at Section 4.3 "Bulk Information
> > Transfer" could be improved by first negotiating a larger message size
>
Brian E Carpenter wrote:
> In other words, the method of bulk transfer described in
> draft-ietf-anima-grasp-distribution at Section 4.3 "Bulk Information
> Transfer" could be improved by first negotiating a larger message size
> than the default 2048 bytes. That might improve eff
The following errata report has been submitted for RFC8995,
"Bootstrapping Remote Secure Key Infrastructure (BRSKI)".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6649
--
Type: Technical
Rep
The following errata report has been submitted for RFC8995,
"Bootstrapping Remote Secure Key Infrastructure (BRSKI)".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6648
--
Type: Technical
Rep
Esko Dijk wrote:
> If the EKU is present, it will restrict the allowed usage purposes of
> the certificate to only those items listed in the EKU. So, if a client
> needs to use such certificate for DTLS/TLS, it needs to add
> id-kp-clientAuth.
> And if a server needs to use su
In the hackathon work a Registrar implementor noticed an x5bag on the
BRSKI-EST link (Pledge->Registrar)
I think that the DTLS Client Certificate (and chain) is always better.
But, I guess we should say something about why the Registrar should prefer to
use that instead.
So pledge can put stuff
Toerless Eckert wrote:
> Which gets us back to the case you mention, which is one and the same
vendor
> (shudder) reusing serial numbers.
> a) Are we aware of any actual instance of this ?
Yes... the bigger the org, the less anyone has any idea what's going on
globally.
And then a
Hi Brian,
Thanks for the information, I will consider and note it in the '-04' version.
BR/Xun
-Original Message-
From: Anima On Behalf Of Brian E Carpenter
Sent: Tuesday, 27 July 2021 00:29
To: Anima WG
Subject: [Anima] Bulk transfer in draft-ietf-anima-grasp-distribution-03
Recently
Thanks, Max,
Michael: i don't remember an example from you where serial number would
be re-assigned. Can you remind me ? Oherwise maybe alk about it on thursday..
Thanks!
Toerless
On Mon, Jul 26, 2021 at 10:22:02PM +, Max Pritikin (pritikin) wrote:
>
> I shared my understanding of why t
Recently I rediscovered something that we included in RFC 8990:
"2.8.3. Message Size
GRASP nodes MUST be able to receive unicast messages of at least
GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages longer
than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly allo
I shared my understanding of why the field exists and the language in existing
docs supporting that understanding. As an optimist I hoped that manufacturers
wouldn’t re-use serial numbers, although MCR followed up with examples, so I
focussed on a rosy future where anima concepts are well estab
Thanks, Max
My point was that reuse of serial number by e..: a MASA service supporting
multiple vendors is not a sufficient example why you would need this field.
The way i understand it, you would also need to assume that the two
devices with the same serial number have the same trust anchor agai
Dear WGs
For those of you here on the list who are new to ANIMA and
would be interested in an overview and status report of ANIMA,
i will be giving those this week because of us finishing
ouur charer round 1 work before this IETF:
First and last session of the week:
Monday session 1 in SACM WG
14 matches
Mail list logo
