Subject: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 13:18:01 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

== 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?

----------------------------------------------------------------------
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]

== 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.

DODAGID needs to be expanded on first use and needs a citation to be provided.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 19:34:41 +0100

> "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.

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.

    > s/({?RFC4662})/[RFC4862]

both already fixed.

    > 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

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-