Thanks for this review, Pascal. I went quickly through your comments and I should be able to fix all of this for -06. My goal is to have -06 ready for WGLC.
On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) < [email protected]> wrote: > Hello Mališa > > > > As you are getting ready to publish a next rev, please find simple > comments on 05 that you may want to act upon in 06. > > > > · As mentioned earlier in the draft, the most probable > collocation for the JRC would be the 6LBR, and probably not a JP deep in > the network. > > Why did you point on the JP in the below? > > > > the JRC, which may be co-located on the JP or another device. > > > > > > · This sentence is too complex : > > > > 4. In case of successful processing of the request, the pledge > > receives a join response from JRC (via the JP) that sets up one > > or more link-layer keys used to authenticate and encrypt > > subsequent transmissions to peers, and a short link-layer address > > for the pledge. > > > > Who sets up what is unclear. Could you make it 2 sentences? > > > > · I see what you mean there > > > > It deeply duty cycles its radio, switching the radio on when the provided > schedule indicates slots which the pledge may use for the join process. > > > > But this seems to make the process very specific to TSCH when it could > easily apply to IEEE Std. 802.15.4 at large. It is my reading that for the > most part the protocol is not dependent of TSCH and that it could easily > have larger applicability. Is there a way to word it as “in the case of > TSCH, …” ? also suggestion to reword “It deeply duty cycles” to follows > the indicated schedule or something. > > > > · On paper the 6LoWPAN concept of 6LBR (a central registrar, > though the 6LoWPAN definition indicates a border router function) is not > necessarily the same guy as the RPL root, though it makes full sense that > they are – and the 6TiSCH architecture recommends that they be. Maybe we > could enforce that they are in another spec. > > > > 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}} to its IPv6 address. The pledge learns the address of the JRC > once joined and upon the reception of a first RPL DIO message, and uses it > to operate as a JP. > > > > I’d add a sentence at the beginning of the spec that the text makes the > assumption that the 6LBR is the RPL root per the architecture and that in > case they are separate, you really mean the RPL root? > > > > · We should not say the following: > > > > When the JRC is not co-located with the 6LBR, then the code point provides > a clear indication to the 6LBR that this is join response traffic. > > > > This seems to indicate that the traffic class may only be applied to join > response. In the future, we may apply that behavior to other traffic. > That’s linked to the point of having a class. > > > > · This could be listed as a dependency or an expectation, or just > be declared out of scope: > > > > Companion SF documents SHOULD specify how traffic with code point AF42 is > handled with respect to cell allocation. > > > > I’m not too happy with a SHOULD directed to an unnamed future spec as > opposed to an implementer. Unsure how the IESG will react to that. > > > > > > · The URI host of the request may point on something more specific > to any jrc as opposed to other nodes: > > > > The Uri-Host option is set to "6tisch.arpa". This is an anycast type > of identifier of the JRC that is resolved to its IPv6 address by the JP > > > > Suggestion: "default-jrc.6tisch.arpa". > > · The text below is not future proof > > > > If the decoded CBOR unsigned integer value is larger than 255 (length > defined by {{IEEE802.15.4-2015}}) > > > > I’d rather say larger than the “max MAC-Layer security key size, which is > 255 with {{IEEE802.15.4-2015}}” > > > > · About the lease ASN, how is the JRC aware of the current ASN? > > > > · Some acronyms like AEAD could be spelled out on first use > > > > · I think we were told to use a form like “IEEE Std. 802.15.4” to > refer to the IEEE standards. Note that one should avoid dating the IEEE > spec references unless there is a quote or a pointer that is specific to a > particular year. > > > > > > All in all, this is an excellent and very clear document, congratulation. > > > > Do you expect 06 to be ready for WGLC? > > > > Take care, > > > > Pascal > > > > > > > > > > > > > > > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
