Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-08

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 22 January 2020 22:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9F7391200BA; Wed, 22 Jan 2020 14:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 c1c5bMLeASgi; Wed, 22 Jan 2020 14:16:48 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6A0120091; Wed, 22 Jan 2020 14:16:47 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EB7613897E; Wed, 22 Jan 2020 17:16:13 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8AD74C69; Wed, 22 Jan 2020 17:16:46 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>
cc: ops-dir@ietf.org, last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org
In-Reply-To: <157961235471.28933.16198137615082431630@ietfa.amsl.com>
References: <157961235471.28933.16198137615082431630@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 22 Jan 2020 17:16:46 -0500
Message-ID: <11553.1579731406@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/OXi31_Tq1cvjLhK_PhNqsE4vOxo>
Subject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-08
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, 22 Jan 2020 22:16:51 -0000

Qin Wu via Datatracker <noreply@ietf.org> wrote:
    > Minor issue: 1.  Abstract Is small details about 6TiSCH join and
    > enrollment information? If yes, why not document it explicitly?

The WG decided against trying to detail every possible use of these
containers.  The ones that are aimed at enrollment are clearly labelled.

The other ones were asked for by researchers who recognized that they needed
additional information to make decisions; but how those containers will be
used is still in the research space.

    > Also it
    > will be great to clarify in the abstract why 6TiSCH join and enrollment
    > information needs to be carried? For which purpose?
    
    > 2 Section 1, 1st
    > paragraph s/slot designated a broadcast slot/slot designated as a
    > broadcast slot 3.Section 1.2 2nd paragraph s/annouce/announce

thank you, will be in -09.
    
    > 4. Section 1.2, last paragraph is slot/s slot per second? Please make
    > clear about this.

that paragraph already rewritten.
    
    > 5.Section 3, 2nd paragraph s/Beagon/Beacon 6.Section

Thank you.

    > 4 Should the last paragraph be moved after the first sentence and
    > before the second sentence in the first paragraph?

I don't understand your suggestion here.

    > How DODAGID is
    > related to network ID? Should you add DODAGID as a new abbreviation or
    > term? When Dogagid is hashed, how interloper can use the network ID to
    > map out the extend of mesh network? What do you mean by the extend of
    > the mesh network? s/ provides some cover the addresses used within the
    > network/ provides some cover for the addresses used within the network.

The extent of a network is how much geography it covers.
An attacker can currently see the extent of a network by observing the PANID
of all transmissions, which is not part of the encrypted section in 802.15.4.
But, a network could use multiple PANIDs.  The included NetworkID will be the
same across multiple PANIDs, allowing the map of related networks to be made.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [