Hi Michael! Response inline ...
> -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Monday, February 17, 2020 11:18 AM > To: Roman Danyliw <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected] > 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 <[email protected]> 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
