Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 February 2020 16:01 UTC

Return-Path: <mcr@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 ECE5A120876; Mon, 17 Feb 2020 08:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a2w1fBexiYHK; Mon, 17 Feb 2020 08:01:02 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A82120863; Mon, 17 Feb 2020 08:01:00 -0800 (PST)
Received: from dooku.sandelman.ca (client-141-23-178-142.wlan.tu-berlin.de [141.23.178.142]) by relay.sandelman.ca (Postfix) with ESMTPS id 6D5071F458; Mon, 17 Feb 2020 16:00:56 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id A77391A2BDC; Mon, 17 Feb 2020 17:00:55 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
cc: The IESG <iesg@ietf.org>, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org
In-reply-to: <158186951737.5793.11389386724613529653.idtracker@ietfa.amsl.com>
References: <158186951737.5793.11389386724613529653.idtracker@ietfa.amsl.com>
Comments: In-reply-to =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org> message dated "Sun, 16 Feb 2020 08:11:57 -0800."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 17 Feb 2020 17:00:55 +0100
Message-ID: <15200.1581955255@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/G8EWT5D_yHRcovWJIAWwvGH4NSg>
Subject: Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with 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: Mon, 17 Feb 2020 16:01:06 -0000

These changes are at:
      https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/0a806e63e65f2ef0fe2c4a5086b653d9fb0c3ff6
and will be in -13 to be posted in a few minutes.

Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
    > -- Abstract -- "announce the presence of the network" makes me
    > wonder... Do nodes announce the network ? or do nodes announced THEIR
    > presence in the network ? or do router nodes announce the network? or
    > am I too unfamiliar with TSCH ?

I have changed the Abstract to say "routers announce".
Noting that in a 6tisch world, most things are routers.

    > -- Section 1.2 -- Please expand "ASN" at first use. I guess that this
    > is not the usual AS Number ;-)

    > -- Section 1.3 -- Please add a reference for "broadcast aloha slot".

    > Isn't the word "IETF" in "defines a new IETF Information Element (IE)"
    > redundant in an IETF document ?

The name of the Registry is:
    https://www.iana.org/assignments/ieee-std-802.15.4-ietf-ie-subtype-ids/ieee-std-802.15.4-ietf-ie-subtype-ids.xhtml#ieee-std-802.15.4-ietf-ie-subtype-ids-1
    IEEE Std 802.15.4 IETF IE Subtype IDs

I expanded the IE.

    > -- Section 2 -- "that need addressing via unicast Router Solicitation
    > messages" is unclear to me... Is to do SLAAC ? or look for an actual
    > router?

Yes, the point is to avoid multicast RS/RAs.
If for reason, the announcing node is *not* a router, it should not set the R bit.
Otherwise, it will answer unicast RS.

    > Add a reference + acronym expansion to RPL at first use.

Done.

    > "This field provides the suffix (IID)" please expand interface ID and,
    > on my side, I do not like naming the IID as a suffix.

I will remove the word suffix, and just say "Interface ID"

    > -- Section 5 -- Reading and applying RFC 8126 (how to write IANA
    > considerations) would be beneficial.

okay, I'll review it again and fix this to the standard way.

    > == NITS ==

    > -- Abstract -- Suggest to expand TSCH at first use.

I'm always uncomfortable with expansions in the Abstract, but I'll do that.

    > -- Section 1.3 -- Unsure whether "reasons: First, there" should have a
    > capitalized "First".

I'll remove First :-)

    > There are also many acronyms that should be expanded at first use (I
    > stopped commenting about those).

okay, I'll check again and make sure.

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