Dear Malisa, see my comments inline
Missatge de Mališa Vučinić <[email protected]> del dia dt., 17 de jul. 2018 a les 17:57: > Hi Xavi, > > Many thanks for sending this review. See my responses inline. > > Mališa > > On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen < > [email protected]> wrote: > >> Hi, >> >> I reviewed the ”Minimal Security Framework for 6TiSCH” document. >> >> Here some comments that have not been mentioned by others. >> >> 1) I miss some section describing how errors are handled at the cbor >> level. This is what if the received Configuration option is wrong, e.g >> there is an element in the map with an unsupported value. >> Or even what if the Join Request contains a wrong role number?. Would be >> good to mention what are the actions taken by the JRC upon receiving a Join >> Request with an incorrect CBOR element. Also from the >> pledge point of view, what if the Join Response contains an unsupported >> parameter. I guess the same will apply for Update Request, from the 6N >> point of view. >> > > This makes perfect sense. We focused on error handling in case security > errors are detected on the OSCORE layer, and somehow neglected the > parameter semantics. > > My proposal is to add a new CBOR parameter to CoJP objects, e.g. > "error_code" carrying an array of errors codes that were detected. > > With that, we'd need to make a table of most common errors on the CoJP > level. > > Does that make sense? > This makes sense. Maybe a concern is the length of the message which should be kept small. Maybe we can discuss different options such a single error byte (e.g., supporting 255 error codes) a bitmap or the proposed array of errors. > > >> >> 2) The JRC is the origin of Parameter Update Requests which may contain >> for example rekeying material or a new short address. The draft needs to >> describe what happens if the destination 6N is not reachable. >> I understand that there will be a timeout and possibly will retry later >> or do not try anymore (this has to be stated). >> What if the node is no more in the network? when the JRC will stop >> sending the short address updates? When it will remove that node from its >> "database"? >> > > I discuss this also during the meeting tomorrow. What you propose is > indeed something that an implementor must consider but I am not sure if we > want to specify any particular behavior in the draft, since this seems to > be more of a policy. > > I can add explicit text discussing this issue, but leaving it up to the > implementation of the JRC to decide how transmission errors of CoAP CON > message, that is Parameter Update Request, should be handled. What do you > think? > > I think that identifying the issue is important so implementers can take it into account. > > >> >> kind regards >> Xavi >> -- >> Dr. Xavier Vilajosana >> Wireless Networks Lab >> >> *Internet Interdisciplinary Institute (IN3)Professor* >> (+34) 646 633 681 <+34%20646%2063%2036%2081> >> [email protected] <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
