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. 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
