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

Alissa Cooper <alissa@cooperw.in> Wed, 18 March 2020 19:07 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA83A1A74; Wed, 18 Mar 2020 12:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=XAbFQjM9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dzNmeBsV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpvSDoLym7Md; Wed, 18 Mar 2020 12:07:47 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A5F3A1A70; Wed, 18 Mar 2020 12:07:29 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 14D535C02BB; Wed, 18 Mar 2020 15:07:28 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 18 Mar 2020 15:07:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V s5Ais0xJs8klfzrjpfi/J4+b37zjuJmulr6Ar2NYfs=; b=XAbFQjM9yuCSvkHp+ a7yZ5nAyF8d90qr51DF1+ef9smqi32uZFrmeNwOlW0s1taKz8/1lUYx3nXU3bJf6 XrcK97L/QtEoj+QDu2QbuE79riLB3nxZoSSFDszpBrc7hNceTFsb/6jh6mGk7WH6 OjEMqHlSw6Cm1kylGM99F5DHkgLfbdtGf2H1YaUxPIpG+hrR+4akPBXN7i+2R6FH gK0dCft17gFJlfxD0i1vhktEXZp0jTm+geCMhxpNjLo7a3KvOHXaXRXKvRVjt654 dsXcTeV/3H0bcwGNavFmA9O4GJy1QU1waxTsscQkFAHreCDuX0D4azKQhj7t7l7C gdsvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Vs5Ais0xJs8klfzrjpfi/J4+b37zjuJmulr6Ar2NY fs=; b=dzNmeBsVMbvPWKE9TMhIaU67qPc54y2tl+6y5asGf773k25LicztmWslj B6Pb865FVLx8+pgMzA959unoFaa0TdkQRO2MOYVSxaNKh6jfnWFIgX6cZANlizd2 Lic5hkRk+1heeFgnfLuS1PVwApyUAnv8mU8JUPIjQLOyIlh74KpJG6uFsC2xsgIY 1mtJLcDW2cj9LiZ5tnTIC7N7Skpc0XlJPixiZZjeX4Q8/w7lWdmMzbzeB0L+Sf8R OHHmfPwemu3M3fLiAULFZDRy+fg/gFBK/6Oqlr0N3vhSbvFDQHQiX826HZqn4LaP ycHdgNFfBDSNSMSkwLGRofUpkEWDg==
X-ME-Sender: <xms:b3FyXry7b5sc-i734O0pfCbZ6f3OVihB9pbyoSxPpW8SGWLVWtinQQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrges tghoohhpvghrfidrihhnqeenucffohhmrghinhepshgrnhguvghlmhgrnhdrtggrnecukf hppedutdekrdehuddruddtuddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:b3FyXgHnOw3WH_33aWX5y3ThLS_phv9h-iK0g3f-I80DGSurnasZ1g> <xmx:b3FyXpjGoQ_aUAVwuLm1JKf3qQhq3r0gJw-s7Txa-eeu1BZ_5fO22Q> <xmx:b3FyXjqIDRFfdzjdqoyu-riosDhRZY_TMQFoNPrL-V8BLBopUh-dRQ> <xmx:cHFyXtI7sAd6dchLGZT-8Wtc9P0KsmGecQCHbd3CkXvaEJN-mv1sUg>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 1BB733061856; Wed, 18 Mar 2020 15:07:27 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <1950.1582223681@dooku>
Date: Wed, 18 Mar 2020 15:07:26 -0400
Cc: IESG <iesg@ietf.org>, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <990A5466-7E56-4729-8D4C-31EB5A7FA798@cooperw.in>
References: <158214708113.17592.6654776663880425456.idtracker@ietfa.amsl.com> <1950.1582223681@dooku>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/YXD1Cf7YAy8AkO_cdmreYtGZGcU>
Subject: Re: [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
Precedence: list
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, 18 Mar 2020 19:07:55 -0000

Hi Michael,

> On Feb 20, 2020, at 1:34 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Alissa Cooper via Datatracker <noreply@ietf.org> 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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>