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

Alissa Cooper via Datatracker <noreply@ietf.org> Wed, 19 February 2020 21:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3266412022D; Wed, 19 Feb 2020 13:18:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, pthubert@cisco.com, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <158214708113.17592.6654776663880425456.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 13:18:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/MpY4NwObdCyGe0aATl7JCvzq4F8>
Subject: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 21:18:01 -0000

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.