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

[Michael Richardson <[e-mail]>]

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

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