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

[Roman Danyliw <[e-mail]>]

Hi Michael!

Response inline ...

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Monday, February 17, 2020 11:18 AM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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
> 
> and posted as -13 just now.
> 
> Roman Danyliw via Datatracker <[e-mail]> 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

Thanks.  These clarifications address my concerns.

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

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

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

Thanks for all of these changes.

Regards,
Roman