Re: [6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 February 2020 16:18 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 9939512083E; Mon, 17 Feb 2020 08:18:16 -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 WoniLn2S6aU1; Mon, 17 Feb 2020 08:18:12 -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 4C8EB12007C; Mon, 17 Feb 2020 08:18:11 -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 A7E181F458; Mon, 17 Feb 2020 16:18:09 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 363611A2BDC; Mon, 17 Feb 2020 17:18:09 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>
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: <158187587385.5858.4196333441268190800.idtracker@ietfa.amsl.com>
References: <158187587385.5858.4196333441268190800.idtracker@ietfa.amsl.com>
Comments: In-reply-to Roman Danyliw via Datatracker <noreply@ietf.org> message dated "Sun, 16 Feb 2020 09:57:53 -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:18:09 +0100
Message-ID: <15950.1581956289@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/vi0qlE0EiJ0AklL_VuZqHvcwg9Q>
Subject: Re: [6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (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: Mon, 17 Feb 2020 16:18:17 -0000

specific edits are here:
      https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/d88a0a980fda85fcc82c4cac84954cb2c7b00c59

and posted as -13 just now.

Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
    > ** Section 2.  Rank Priority and Pan Priority.  Can you please clarify
    > whether a higher or lower number indicated an increased priority:

Done with edits for Eric.

    > -- Rank priority says “Lower values are better” -- What does “better”
    > mean?  Is a lower number more or less willing this 6LR is to serve as
    > the RPL parent?

    > -- Pan priority doesn’t include guidance on whether a higher or lower
    > number indicate increased priority.

Clarified text to say:
          Lower values indicate more willing, and higher values indicate less willing.

in a number of places.  Please see changes at:
   https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/0a806e63e65f2ef0fe2c4a5086b653d9fb0c3ff6

    > ** Section 2.  network id.  Can you please clarify the computation of
    > the default value using SHA-256.

I have changed the text to say:
  : In a 6tisch network, where RPL {{RFC6550}} is used as the mesh routing protocol, the
  network ID can be constructed from a truncated SHA256 hash of the prefix (/64) of the
  network.  This will be done by the RPL DODAG root and communicated by the RPL
  Configuration Option payloads, so it is not calculated more than once.
  That is just a suggestion for a default algorithm: it may be set in any
  convenience way that results in a non-identifing value.

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > ** Section 2.  Rank Priority.  This is a local value to be determined
    > in other work.  It might be calculated from RPL rank, and it may
    > include some modifications based upon current number of children, or
    > number of neighbor cache entries available.

    > -- what’s a local value?  What’s the other work?

    > -- the follow on sentence of “It might be … “ doesn’t seem decisive in
    > the guidance.  Would it be cleaner to say, that the computation of this
    > value is out of scope of this document.

I have removed the word "local", by expanding it:

  This value is calculated by each 6LR according to algorithms specific to the
  routing metrics used by the RPL ({?RFC6550}).  
  The exact process is a subject of significant research work.  
  It will typically be calculated from the RPL rank, and it may include some modifications
  based upon current number of children, or number of neighbor cache entries
  available.  
  This value MUST be ignored by pledges, it is to help enrolled devices only to
  compare different connection points.


    > ** Editorial

    > -- Please review Yoav Nir’s SECDIR feedback

already did that, and Yoav has confirmed he is happy.

    > -- Abstract.  Per “Nodes in the TSCH network typically frequently
    > transmit …”, likely only “typically” or “frequently” is needed.

Both have been removed.

    > -- Typo.  s/the the/the/g
    
thank you.

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