Simon,

Your suggestions make sense to me.

Others?

Thomas

On Mon, Jun 22, 2015 at 5:16 PM, Simon Duquennoy <[email protected]> wrote:

> That was an important fix, thanks, but now we seem to have an new
> inconsistency. In 6.2,
> "Join Priority of any node MUST be equivalent to the result of the
> function DAGRank(rank)"
> implies the DAG root has a rank of 1. However, IEEE802.15.4e-2012
> stipulates that the PAN coordinator's join priority is 0 (section
> 5.2.4.13). This means that the PAN coordinator cannot be DAG root -- surely
> not what we want.
>
> My suggestion is to define Join Priority as "DAGRank(rank)-1".
>
> Two more comments on section 6.2:
> * This statement is currently inconsistent with having JP = DAGRank(rank):
> "The Join Priority of the DAG root is zero, i.e., EBs sent from the DAG
> root are sent with Join Priority equal to 0."
> * The whole paragraph reads like there are possibly several time sources
> (so far so good). However, this sentence implies there is only one: "If
> connectivity to the time source neighbor is lost, a new time source
> neighbor MUST be chosen among the neighbors in the routing parent set."
>
> Thanks,
> Simon
>
>
> On Mon, Jun 1, 2015 at 11:19 PM, Thomas Watteyne <
> [email protected]> wrote:
>
>> Yup, good catch!
>>
>> On Sun, May 24, 2015 at 10:08 PM, Xavier Vilajosana <
>> [email protected]> wrote:
>>
>>> Dear Nicola,
>>>
>>> thanks for your comment! I reviewed both rfc6550 and rfc6552 and you are
>>> right.
>>>
>>> I corrected the draft as follows:
>>>
>>>
>>>   +-------+
>>>     |   0   | R(0) = 0
>>>     |       | DAGRank(R(0)) = 0
>>>     +-------+
>>>         |
>>>         |
>>>     +-------+
>>>     |   1   | R(1)=R(0)+683=683
>>>     |       | DAGRank(R(1)) = 2
>>>     +-------+
>>> ...
>>>
>>> substituted by this
>>>
>>>   +-------+
>>>     |   0   | R(minHopRankIncrease) = 256
>>>     |       | DAGRank(R(0)) = 1
>>>     +-------+
>>>         |
>>>         |
>>>     +-------+
>>>     |   1   | R(1)=R(0)+683 = 939
>>>     |       | DAGRank(R(1)) = 3
>>>     +-------+
>>> ...
>>>
>>> thanks you very much!
>>> regards,
>>> Xavi
>>>
>>> 2015-05-22 19:43 GMT+02:00 Nicola Accettura <[email protected]>:
>>>
>>>> Hi Xavi, Kris, all,
>>>>
>>>> reading RFC 6550, I find:
>>>>
>>>>
>>>>    1. page 70:
>>>>
>>>>    A DODAG root MUST advertise a Rank of ROOT_RANK.
>>>>
>>>>    2. page 112:
>>>>
>>>>    ROOT_RANK: This is the Rank for a DODAG root.  ROOT_RANK has a value
>>>>             of MinHopRankIncrease (as advertised by the DODAG root), such
>>>>             that DAGRank(ROOT_RANK) is 1.
>>>>
>>>>
>>>> So that the example in section 9.1.2 of draft-ietf-6tisch-minimal-06
>>>> seems not compliant with RFC 6550 (unless node 0 is a virtual DODAG root).
>>>>
>>>> Am I missing something?
>>>>
>>>> Sincerely,
>>>> Nicola
>>>>
>>>> _______________________________________________
>>>> 6tisch mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to