Mališa Vučinić writes:
> Thanks Tero for the proposal. Is the current "key_usage" registry enough to
> fully configure the security tables for the non-index modes?
I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e.,
multicast/broadcast keys which are owned by somebody. In the
Dear all
Confirming the adoption of
https://datatracker.ietf.org/doc/draft-richardson-6tisch-roll-enrollment-priority/
.
Michael, please publish the exact copy as draft-ietf * 00, indicating that this
is a replacement to your original draft.
Many thanks!
The chairs
Please find the minutes of the WG meeting at
https://datatracker.ietf.org/meeting/102/materials/minutes-102-6tisch.
--
Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley
The 6TISCH WG has placed draft-richardson-6tisch-roll-enrollment-priority in
state Adopted by a WG (entered by Pascal Thubert)
The document is available at
https://datatracker.ietf.org/doc/draft-richardson-6tisch-roll-enrollment-priority/
Comment:
Confirmed at IETF 102
Thanks Jim for working on this! When you have time, please drop us a line
with the proposed solution.
Mališa
On Wed, Jul 18, 2018 at 2:13 PM Jim Schaad wrote:
> I think that I have a solution that could be implemented at the cost of
> one additional round trip the first time the JRC wants to
I think the Link_Layer_Key can very easily changed to send any kind of
keys that are supported by 802.15.4.
If it is updated as follows:
Link_Layer_Key = (
key_index : uint,
? key_usage : uint / nint,
key_value : bstr,
? key_source :
I think that I have a solution that could be implemented at the cost of one
additional round trip the first time the JRC wants to update the endpoint.
Jim
From: Mališa Vučinić
Sent: Tuesday, July 17, 2018 1:22 PM
To: Jim Schaad
Cc: 6tisch@ietf.org
Subject: Re: Review
On Tue, Jul 17, 2018 at 10:25 PM Tero Kivinen wrote:
> If JRC restarts and looses track who is in the network, then it cannot
> send updaes, as it does not know who is in the network. I.e., in that
> case all nodes need to rejoin.
>
How do we detect that JRC restarted at 6LBR if JRC is in the
On Wed, Jul 18, 2018 at 2:36 AM Tengfei Chang
wrote:
> Hi Malisa and Tero,
>
> Thanks for answering my question! It is clear to me!
>
> I don't fully understand. Do you mean in which case would a node send
>> another Join Request, if it has already completed the join process sometime
>> before
(snip)
On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen wrote:
>
> I would like at least some text in the security considerations section
> warning about the common wrong ways of generating PSK. The IoT vendors
> are quite often care more about the time to market than the security,
> thus do use
10 matches
Mail list logo
