specific edits are here:
https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/d88a0a980fda85fcc82c4cac84954cb2c7b00c59
and posted as -13 just now.
Roman Danyliw via Datatracker <nore...@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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
