Hi Gioele, for a transaction the RFC states 6P Request, 6P Response, and 6P Confirmation messages for a given transaction MUST share the same Version, SFID, and SeqNum values.
The case when the response uses a different seqnum can only happen if the issuer of the response power cycles. In this case, section 3.4.6.1 and 3.4.6.2 detail the procedure to follow. Basically, the transaction should be aborted. And the SF should take action to solve the inconsistency.. regards X Missatge de Gioele Carignani <gioelecarign...@gmail.com> del dia dv., 30 d’ag. 2019 a les 17:29: > Hi all, > I was looking into RFC 8480, and I would like to know how RESPONSE > messages with an inconsistent SeqNum (for example the SeqNum that would be > used for the next transaction) are treated. > > Under the assumption that this RESPONSE messages does not match any > REQUEST, will this message simply be ignored or is a CLEAR transaction > started? > Thank you > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajos...@uoc.edu <usu...@uoc.edu> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
