Hi Pascal,
See responses inline.
Mališa
On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> 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 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.
"
>
>
>
>
> · 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?
>
done
>
>
> · 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.
"
>
> · 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?
> 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.
>
>
> · 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.
>
Deleted the sentence you cited.
> · 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?
> · 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" ?
· 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.
"
>
>
> · 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?
> · Some acronyms like AEAD could be spelled out on first use
>
Done
· 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.
> 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.
Mališa
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
