Hello Mališa :
the JRC, which may be co-located on the JP or another device.
This was assuming a special case of a pledge that is one hop away from the
6LBR, where 6LBR is co-located with the JP.
I removed "which may be co-located on the JP or another device" to avoid
confusion and added the following two sentences at the end of the Join Process
Overview section:
"
As other nodes in the network, the 6LBR node plays the role of the JP.
The 6LBR may in addition be co-located with the JRC.
"
[PT>] WFM : )
• 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.
The join *process*, as described in the draft, is specific to TSCH because of
the EB assumption. The join *protocol*, however, is not and applies to 15.4 at
large, as well as it could easily be applied to other IoT technos with a
registration of additional configuration parameters.
I rephrased "It deeply duty cycles" to "It follows the provided schedule"
I also added the following paragraph in the introduction:
"
The 6TiSCH Join Protocol defined in this document is generic and can be used
as-is in modes of IEEE 802.15.4 other than TSCH, that 6TiSCH is based on.
The 6TiSCH Join Protocol may as well be used in other (low-power) networking
technologies where efficiency in terms of communication overhead and code
footprint is important.
In such a case, it may be necessary to register configuration parameters
specific to the technology in question, through the IANA process.
The overall join process described in {{join-process-overview}} and the
configuration of the stack is, however, specific to 6TiSCH.
"
[PT>] Cool! The more we can indicate what is 6TiSCH specific the better; I
really think your work should be considered across the board.
• 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.
I added the following sentence in the terminology section:
"
The term "6LBR", as used throughout the document, also denotes the function of
the "DODAG root" defined in {{RFC6550}}, assuming the two entities are
co-located, as recommended by {{I-D.ietf-6tisch-architecture}}.
"
I guess this should be enforced by the architecture draft?
[PT>] it is mentioned; question to ROLL related to the unaware leaves draft is
whether we make it the rule. I think that was the intention in 6LoWPAN anyway.
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?
See if the sentence above takes care of this.
[PT>] WFM
• 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.
I guess this sentence belongs to the 6P document where SF requirements are
listed. Can we move it there at this point?
[PT>] Question to Xavi. From my perspective, 6P is way too advanced in IESG to
add text that would discuss AF behavior. At least we’d need a rereview by the
TSV area.
• 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".
I am not happy to add this many bytes to the request..
How about we do "jrc.arpa" ?
[PT>] To be validated with the arpa registry but I agree shorter is better.
• 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}}”
Rewrote the paragraph on key_index to:
"
* key_index: The identifier of the key, encoded as a CBOR unsigned integer.
This parameter MUST be included.
The parameter uniquely identifies the key and is used to retrieve the key for
incoming traffic.
In case of {{IEEE802.15.4-2015}}, the decoded CBOR unsigned integer value sets
the "secKeyIndex" parameter that is signaled in all outgoing and incoming
frames secured with this key.
If the decoded CBOR unsigned integer value is larger than the maximum
link-layer key identifier, which is 255 in {{IEEE802.15.4-2015}}), the key is
considered invalid.
Additionally, in case of {{IEEE802.15.4-2015}}, the value of 0 is considered
invalid.
In case the key is considered invalid, the implementation MUST discard the key
and attempt to decode the next key in the array.
"
[PT>] WFM
• About the lease ASN, how is the JRC aware of the current ASN?
Good catch, this has an implied assumption on JRC being co-located with 6LBR.
One option is to return this as seconds from the moment Join Response is
received by the pledge. The pledge would then need to convert it to ASN. Makes
sense?
[PT>] Yes; The 6LBR could convert a sense of global time into ASN back and
forth. There must be enough buffer to make sure the message reaches the pledge
before application ASN has come. I wonder if it could also be that the JRC
indicates a relative time offset that the 6LBR could convert?
• 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.
Removed date from the 15.4 reference and updated the title to the one in 2015
version. Now using IEEE Std 802.15.4 when referring to the IEEE 802.15.4
without a reference.
[PT>] You may want 2 references, one dated 2015 for the key-size discussion
about and one undated for the general discussion.
All in all, this is an excellent and very clear document, congratulation.
Do you expect 06 to be ready for WGLC?
Yes, I am working on it!
The repo commit of these changes is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/498ec7f8907d42679392df9bd681130439659b27
Waiting for your response on .arpa name and the lease time before resolving
that.
[PT>] there you go then
Take care,
Pascal
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
