Dear authors; As part of shepherding the draft for publication, please find review comments below:
Very well written draft altogether! A few things still: Section 4.2: " The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchange with the JP, as per Section 5.5.1 of [RFC6775]<https://tools.ietf.org/html/rfc6775#section-5..5.1>. " This reference is outdated. I suggest referring to section 5.6. of [RFC8505]. Section 6: Again a ref to RFC 6775. In a general manner please use RFC 8505. "The JRC can be co-located on the 6LBR. In this special case, the IPv6 address of the JRC can be omitted from the Join Response message for space optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs [RFC6550<https://tools.ietf.org/html/rfc6550>] to its IPv6 address. The pledge learns the address of the JRC once joined and upon the reception of the first RPL DIO message, and uses it to operate as a JP." Note that the expectation is that the 6LBR is the RPL root as suggested in the 6TiSCH architecture. When they are not the same box I expect the all the text about 6LBR throughout this doc is really about the RPL root. This should be indicated somewhere. Section 6.1: There are a number of SHOULD there, but no explanation of what happens if the SHOULD is not respected. Maybe a sentence that says that the SHOULDs are about protecting the network against the threats discussed in the section and that failing to follow the recommendation may create congestion and more sensitivity to attacks? Otherwise all good for me! Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
