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