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
