Mališa Vučinić <[email protected]> wrote: >> (I can write text next week on this) >>
> Yes, this is all fine with me. If you could provide a PR on the latest
> minimal-security-06 branch, that would be great!
I will work on that on Wednesday, when I've 8hr on a train.
> I generalized the rekeying text so that it falls under the processing
rules
> of the CBOR Link-Layer Key parameter. The first join of a pledge just
> becomes a special case but there is a distinction between the 6LBR and
> non-6LBR nodes. I don't see how the JRC that is not colocated with the
6LBR
> can trigger the sending of a link-layer frame secured with the new
> keys...
In such a situation, there will need to be an additional control protocol,
which might be proprietary or future work, but in any case, I think it's okay
if we clearly mark it as out-of-scope.
>> I'm fine with that, but in that case, we need to tell such a pledge how
to
>> find a Join Proxy and/or the actual JRC. At present, we use the 15..4
>> specific Enhanced Beacon. There a bunch of options:
>> 1) DHCPv6
>> 2) GRASP
>> 3) mDNS (DNS-SD)
>> 4) RA option
> In the current text somewhere in the one-touch section, there is simply a
> requirement that 6LBR needs to be provisioned with the IPv6 address of the
> JRC. Then, it can contact it over CoAP/IPv6 directly using global
> addressing. I still need to do some changes to CoAP message mapping to
> cover this case clearly, but I don't think another protocol is necessary.
> Of course, the current text does not preclude the use of another protocol
> for that purpose.
Good, so we can just mark it as out-of-scope.
I think that this is okay.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
