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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Sun, 16 Feb 2020 09:57:53 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-12: 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.  Rank Priority and Pan Priority.  Can you please clarify whether
a higher or lower number indicated an increased priority:

-- 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.

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

The text initially says that network id is a “variable length field, up to 16
bytes in size”.  Later it says that “the network ID can be constructed from a
SHA256 hash of the prefix (/64) of the network.  That is just a suggestion for
a default value.”  However, a SHA256 hash has a 256 bit output which can’t fit
into a 16 byte field size.  Is there a truncation?

----------------------------------------------------------------------
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.

** Editorial

-- Please review Yoav Nir’s SECDIR feedback

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

-- Typo.  s/the the/the/g

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Feb 2020 17:18:09 +0100

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

and posted as -13 just now.

Roman Danyliw via Datatracker <[email-masked]> 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.

    > ** 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.

    > -- 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.

    > -- 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 24 Feb 2020 19:11:56 +0000

Hi Michael!

Response inline ...

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: Monday, February 17, 2020 11:18 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-enrollment-
> enhanced-beacon-12: (with DISCUSS and COMMENT)
> 
> 
> specific edits are here:
>       https://bitbucket.org/6tisch/6tisch-join-enhanced-
> beacon/commits/d88a0a980fda85fcc82c4cac84954cb2c7b00c59
> 
>    https://bitbucket.org/6tisch/6tisch-join-enhanced-
> beacon/commits/0a806e63e65f2ef0fe2c4a5086b653d9fb0c3ff6

Thanks.  These clarifications address my concerns.

>   convenience way that results in a non-identifing value.

Understood.  However, to clarify, is there guidance on how this truncation should be applied (i.e., which bits are supposed to be used? )?

>     > transmit …”, likely only “typically” or “frequently” is needed.

Thanks for all of these changes.

Regards,
Roman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 18:23:59 -0500

> Understood.  However, to clarify, is there guidance on how this
    > truncation should be applied (i.e., which bits are supposed to be used?
    > )?

The calculation is
a) a suggestion on how the control plane should initialize itself by default.
b) done once in the 6LBR, so any truncation is acceptable.

I.e. it doesn't matter how it's done.

Communicating the NetworkID down the RPL DODAG is ROLL WG work, which has not
proceeded in pace with this work.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 28 Feb 2020 14:09:00 +0000

Hi Richard!

> From: iesg <[email-masked]> On Behalf Of Michael Richardson
> Sent: Monday, February 24, 2020 6:24 PM
> Cc: [email-masked]; [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
>     >> 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
> Communicating the NetworkID down the RPL DODAG is ROLL WG work,
> which has not proceeded in pace with this work.

Understood.  Thanks for the changes in -13/-14. Do you think it will be obvious to the reader/audience that any truncation is acceptable (which was more my point, not clearly articulated)?  

Thanks.  I'll clear my position.

Roman