Hi Michael,
> On Feb 20, 2020, at 1:34 PM, Michael Richardson <[email protected]> wrote:
>
>
> Alissa Cooper via Datatracker <[email protected]> wrote:
>> == Section 2 ==
>
>> "If this field is not present, then IID is derived from the layer-2
>> address of the sender as per SLAAC ({?RFC4662})."
>
>> RFC 8064 recommends that the default IID generation scheme for use with
>> SLAAC is not to use the layer-2 address, but to use the mechanism
>> specified in RFC 7217. Is there a reason this specification is making a
>> different recommendation?
>
> Yes.
> We have this conversation pretty much every single time that 802.15.4 is
> discussed.
I’m a human being and I forget things. Forgive me.
Alissa
>
> 1) 6lowpan compression depends upon the layer-3 address being derived from
> the layer-2 address so that the usless bytes are not transmitted every
> single time.
>
> 2) however, 802.15.4 beacons are always sent using the 64-bit EUI64 L2 source
> addresses. The device does not have to use IEEE OUI assigned addresses,
> but could use IEEE randomized MAC addresses if the firmware decides to do
> this.
>
> 3) 802.15.4 prefers to use assign 2-byte short addresses (and to derive the
> L3 address from that short-address).
> The recently approved 6tisch-minimal-security CoJP protocol includes
> assignment of 2-byte address using a central process. As such, during
> normal operation neither the L2 and L3 addresses have manufacturer
> specific OUI content.
>
> I believe that other documents have said this already, so I don't think there
> needs to be any further repeating. Let me know if you feel differently.
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>
>> == Section 1.3 ==
>
>> This sentence is not comprehensible:
>
>> "Although However, even in this case, a unicast RS may be transmitted
>> in response[RFC6775] reduces the amount of multicast necessary to do
>> address resolution via Neighbor Solicitation (NS) messages, it still
>> requires multicast of either RAs or RS."
>
>> == Section 2 ==
>
>> s/({?RFC4662})/[RFC4862]
>
> both already fixed.
>
>> == Section 4 ==
>
>> A network doesn't have privacy considerations. The draft might want to
>> discuss how this specification reveals information about network
>> topology, but that isn't a privacy consideration.
>
> I think that every single draft should have privacy considerations.
> If you have a LLN as part of your household automation, then being able to
> map the extent of the LLN reveals which parts of the building belong to you.
>
> If I had a house with many pieces (parking spot, storage in the basement,
> etc) and I had active nodes in those places, I would want to consider whether
> or not I want to use the same subnet (with backbone), or whether I'd want to
> split things up.
>
>> DODAGID needs to be expanded on first use and needs a citation to be
>> provided.
>
> DODAG was previously expanded. DODAG expands to DODAG-Identity.
> I will cite RFC6550 here.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | network architect [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
