Yacht,
Let me chime in a little bit. Responses below.
Regards,
Diego
El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka <yasuyuki.tan...@inria.fr>
escribió:
> Hi Xavi,
>
> > What is the issue you see with this?
>
> At least, there is an inconsistency in RFC8480. Here is another example:
>
> https://tools.ietf.org/html/rfc8480#section-3.2.2
>
> rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a
> given
> rfc8480> transaction MUST share the same Version, SFID, and SeqNum
> values.
>
> Such an inconsistency could bring confusion and/or an interoperability
> issue.
>
> According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a
> special
> meaning which is "I've lost all the states completely (due to
> power-cycle)",
> although this is another case we will receive such a response as shown in
> Figure 32... Honestly, I'm not sure how valuable it is to know the peer has
> performed power-cycle, by the way.
>
As far as I can remember, it is important to know that the peer has
forgotten all the states and has lost his schedule, so all the allocated
cells with that neighbour are currently not valid anymore and should be
wiped from the local schedule.
> So, if setting 0 to SeqNum of a response is a right thing, I would add some
> text to the SeqNum definition in Section 3.2.2, to tell there is an
> exception.
>
> Best,
> Yatch
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
