Subject: [6tisch] new (unpublished) version of terminology draft - please review

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 9 Jan 2015 10:18:49 +0000

Dear 6TiSCH,

based on the latest discussion we had about security-related terms, I have updated, together with Thomas and Pascal, the terminology draft.

The new version of the draft (still unpublished)  is available at: https://bitbucket.org/6tisch/draft-ietf-6tisch-terminology/src/master/ draft-ietf-6tisch-terminology-03.txt

Could you please have a look, and let us know if there is anything to be fixed/modified, before publishing it?

@Rene: can you please check if your concerns about security-related terms have been properly addressed?

Thank you!

Maria Rita, Thomas and Pascal

---

From: Rene Struik <[email-masked]>
Date: Fri, 09 Jan 2015 11:00:15 -0500

Hi Maria:

I still see lots of terms that do not fit in there and that I indicated 
in my review email to you, Pascal and Thomas on this yesterday (copied 
below - email Thu Jan 8, 2015, 7:14pm EST).

Best regards, Rene

On 1/9/2015 5:18 AM, Maria Rita PALATTELLA wrote:
>
> Dear 6TiSCH,
>
> based on the latest discussion we had about security-related terms, I 
> have updated, together with Thomas and Pascal, the terminology draft.
>
> The new version of the draft (*still unpublished*)  is available at: 
> https://bitbucket.org/6tisch/draft-ietf-6tisch-terminology/src/master/ 
> draft-ietf-6tisch-terminology-03.txt
>
> @_Rene_: can you please check if your concerns about security-related 
> terms have been properly addressed?
>
> Thank you!
>
-------- Forwarded Message --------
Subject: 	Re: preview draft-ietf-6tisch-terminology-03: thoughts?
Date: 	Thu, 08 Jan 2015 19:14:25 -0500
From: 	Rene Struik <[email-masked]>
To: 	Thomas Watteyne <[email-masked]>
CC: 	Pascal Thubert <[email-masked]>, Maria Rita Palattella 
<[email-masked]>

Hi Thomas:

Slightly later than expected, but here are my comments:

I would simply refer to 802.15.4e-2012 and, e.g., CoAP, for precise 
terms borrowed from there, rather than trying to define those again. 
Some examples below.
a1) Blacklist: these are the frequencies not occurring in the 
macHoppingSequenceList array (see 5.1.1.5.3).
a2) ASN: already defined in 5.1.1.5.2. This being said, this term is not 
well defined, since ultimately it is set (I presume) by the PAN 
coordinator (whether or not this represents Big Bang time for the 
network or not). It is certainly not "arbitrary". Some ambiguity also 
remains since the ASN number in the enhanced beacon (5.2.4.13) is not 
necessarily the same as the one maintained by the PAN coordinator. This 
essentially is all sloppiness in 802.15.4e specs.
a3) Coap. Why mention that coap runs over UDP here?
a4) EB: too much detail. This is all included in the 802.15.4e-2012 
spec, so I would be more succinct here. BTW - the term "mote" (in 
beaconing mote) is not really defined (this may be a relic of past 
versions of the draft). As a final note: the notion that the join 
priority indicates the path length between beaconing device and PAN 
coordinator is really flawed: the entire topology may have changed along 
the way; moreover, it is predicated on tree-like network build-up 
notions (which seems to preclude random provisioning as relevant to, 
e.g., building control people). {We discussed this during the 6TiSCH 
security call this Tue, Jan 6, 2015. See also my RoLL mailing list 
message http://www.ietf.org/mail-archive/web/roll/current/msg09039.html
a5) IE: information elements are not just in the header, these can also 
be in the payload. Some details as to availability hereof with 6tisch is 
not a given (nothing in 5.2.4 of 802.15.4e-2012 provides for allocation 
to SDOs).
a6) Per-peer L2 key: this is called link key in 802.15.4. No need for 
yet another term here. Besides, it is very well possible that keys are 
shared accross different layers (so L2 notion may be misplaced).

Some other non-security comments:
b1) Channel distribution/usage matrix. The term "RPL parent" is 
unnecessary, so can (and should) be dropped. Editorial: "such matrix" 
should read "such a matrix".
b2) With chunks, the term "interference domain" is not defined. 
Shouldn't this be added to the terminology definition list? Not sure 
what "well-distributed in time and frequency means". The entire notion 
of pre-programming chunks according to some policy needs more 
explanation (e.g., which external entity, what bootstrap, etc., can 
re-programming take place, etc.?).
b3) Chunk ownership appropriation vs. ditto delegation: this suggests 
that external entity cannot be a neighbor (?). What is peer-to-peer 
interaction (e.g., does this include one-flow/unidirectional as well?).
b4) NME: this entity may also cooperate with "server" entity roles 
involved with the join protocol.

Security-related:
c1) Premature notions: some terms should be omitted, since these seem to 
point at technology solution directions that have not been nailed down 
or lack any precision (and, hence, seem meaningless at this stage). This 
includes the terms (all to be removed for now) DevID, DTLS, IDevID, 
"production network" (in JN), LDevID, PANA, unique join key.
c2) The term JCE is vaguely defined. With the join protocol, there is a 
"server" element that may assist in (a) authentication of joining device 
or neighbor node (loosely speaking: "join assistant"); (b) authorization 
of the device to the neighbor node and vice-versa; (c) configuring the 
device and obtaining configuration info from that device (e.g., 
statistics). These roles may be in different devices (since different 
roles can be mapped to the same device, one role to multiple devices 
[e.g., if one has more than one "server" element], etc. Moreover, part 
of the configuration info to be passed to the device may be network-wide 
key (in 802.15.4-speak: KeyID=0x01), etc. These can all be distributed 
(although simple networks may implement these all in the same device, 
depending on policy).
-- JCE: role of entity that may assist in several aspects of the join 
protocol, such as authentication, authorization, configuration.
-- JN: no need to define (any  node will at some moment be joining). 
Even having just an acronym here is "acronymitis".
-- JA: one-hop neighbor of a joining node that may facilitate it to 
become meaningful part of the network (e.g., by serving as a local 
connectivity point to the remainder of the network).
-- 
c3) KMP (useless term and "acronymitis" example). Remove.
c4) SA (kind of useless at this point in time). Remove.

Other comments:
d1) Not sure whether some of the terms related to neighbor discovery are 
relevant to 6tisch. See my email as of September 11, 2014 on this topic: 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02489.html

[snip]

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 13 Jan 2015 15:26:35 +0000

Thanks Rene for your detailed review.
Please find inline my comments.

@all: As agreed on the last 6TiSCH call, please review the terminology draft by 16/1/2015.
Being a WG document, your feedbacks are very welcome.
Thank you!
Maria Rita

-------- Forwarded Message --------
Subject:

Re: preview draft-ietf-6tisch-terminology-03: thoughts?

Date:

Thu, 08 Jan 2015 19:14:25 -0500

From:

Rene Struik <[email-masked]><mailto:[email-masked]>

To:

Thomas Watteyne <[email-masked]><mailto:[email-masked]>

CC:

Pascal Thubert <[email-masked]><mailto:[email-masked]>, Maria Rita Palattella <[email-masked]><mailto:[email-masked]>

Hi Thomas:

I would simply refer to 802.15.4e-2012 and, e.g., CoAP, for precise terms borrowed from there, rather than trying to define those again. Some examples below.
[MR] I personally would keep IEEE802.15.4e-2012 related terms. 6TiSCH builds on top of TSCH, and I guess not everyone that wants to get started with 6TiSCH will read the whole standard before.
While reading 6TiSCH drafts, it will be easier to find out terms in the terminology draft, rather than in the standard.
I would suggest to have definitions as close as possible to those in the standard. what do you think?

a1) Blacklist: these are the frequencies not occurring in the macHoppingSequenceList array (see 5.1.1.5.3).
[MR] In terminology draft - Blacklist:  Set of frequencies which should not be used for communication.
The current definition conveys the message. those in the std may be more precise, but for someone not familiar with 15.4e spec (and thus, macHoppingSequenceList) will not be easy to understand.

a2) ASN: already defined in 5.1.1.5.2. This being said, this term is not well defined, since ultimately it is set (I presume) by the PAN coordinator (whether or not this represents Big Bang time for the network or not). It is certainly not "arbitrary". Some ambiguity also remains since the ASN number in the enhanced beacon (5.2.4.13) is not necessarily the same as the one maintained by the PAN coordinator. This essentially is all sloppiness in 802.15.4e specs.
[MR] in the current version we refer to 15.4e for more details. if you think it is not well define there, do you have any suggestion how to improve the definition?
I am afraid main other concepts should be clarified about network formation.

a3) Coap. Why mention that coap runs over UDP here?
[MR] I do agree we can drop this term and its definition.

a4) EB: too much detail. This is all included in the 802.15.4e-2012 spec, so I would be more succinct here. BTW - the term "mote" (in beaconing mote) is not really defined (this may be a relic of past versions of the draft). As a final note: the notion that the join priority indicates the path length between beaconing device and PAN coordinator is really flawed: the entire topology may have changed along the way; moreover, it is predicated on tree-like network build-up notions (which seems to preclude random provisioning as relevant to, e.g., building control people). {We discussed this during the 6TiSCH security call this Tue, Jan 6, 2015. See also my RoLL mailing list message http://www.ietf.org/mail-archive/web/roll/current/msg09039.html

[MR] In terminology draft  - EB:    Enhanced Beacon frame used by a node to announce the  presence of the network.  It contains information about the timeslot length, the current ASN value, the slotframes and timeslots the beaconing mote is listening  on, and a 1-byte join priority (i.e., number of hops  separating the node sending the EB, and the PAN  coordinator).

We have mainly listed all the info carried by the EB. but we can cut it short. what about:

[NEW] EB:    Enhanced Beacon frame used by a node to announce the  presence of the network.  It contains useful information that allows a new node to synchronize and join the network [IEEE802.15.4e]

Sure MOTE should be NODE.

a5) IE: information elements are not just in the header, these can also be in the payload. Some details as to availability hereof with 6tisch is not a given (nothing in 5.2.4 of 802.15.4e-2012 provides for allocation to SDOs).

a6) Per-peer L2 key: this is called link key in 802.15.4. No need for yet another term here. Besides, it is very well possible that keys are shared accross different layers (so L2 notion may be misplaced).
[MR] then, what about using link key as defined in the std?

Some other non-security comments:
b1) Channel distribution/usage matrix. The term "RPL parent" is unnecessary, so can (and should) be dropped. Editorial: "such matrix" should read "such a matrix".
[MR]  agreed. will fix.

b2) With chunks, the term "interference domain" is not defined. Shouldn't this be added to the terminology definition list? Not sure what "well-distributed in time and frequency means". The entire notion of pre-programming chunks according to some policy needs more explanation (e.g., which external entity, what bootstrap, etc., can re-programming take place, etc.?).
[MR] May be we should cut some details from the chunk definition. For instance we could remove last details:
They can be pre-programmed, or can be computed by an external entity at the network bootstrap.
More detailed information should be given in a specific draft dedicated to chunks.
@Pascal: what do you think?

b3) Chunk ownership appropriation vs. ditto delegation: this suggests that external entity cannot be a neighbor (?). What is peer-to-peer interaction (e.g., does this include one-flow/unidirectional as well?).
[MR] I am just wondering if we should keep the appropriation and delegation terms. or shall we drop them for now?
As per b2) more details should be given in a chunk-related draft, and not in the terminology draft.
what do others think?
@Pascal: what do you think?

b4) NME: this entity may also cooperate with "server" entity roles involved with the join protocol.

Security-related:
c1) Premature notions: some terms should be omitted, since these seem to point at technology solution directions that have not been nailed down or lack any precision (and, hence, seem meaningless at this stage). This includes the terms (all to be removed for now) DevID, DTLS, IDevID, "production network" (in JN), LDevID, PANA, unique join key.
[MR] what does the 6TiSCH security team think about?

c2) The term JCE is vaguely defined. With the join protocol, there is a "server" element that may assist in (a) authentication of joining device or neighbor node (loosely speaking: "join assistant"); (b) authorization of the device to the neighbor node and vice-versa; (c) configuring the device and obtaining configuration info from that device (e.g., statistics). These roles may be in different devices (since different roles can be mapped to the same device, one role to multiple devices [e.g., if one has more than one "server" element], etc. Moreover, part of the configuration info to be passed to the device may be network-wide key (in 802.15.4-speak: KeyID=0x01), etc. These can all be distributed (although simple networks may implement these all in the same device, depending on policy).
-- JCE: role of entity that may assist in several aspects of the join protocol, such as authentication, authorization, configuration.
-- JN: no need to define (any  node will at some moment be joining). Even having just an acronym here is "acronymitis".
-- JA: one-hop neighbor of a joining node that may facilitate it to become meaningful part of the network (e.g., by serving as a local connectivity point to the remainder of the network).
[MR] so, shall we keep only JCE and JA as per your suggestion? what does the 6TiSCH security team think about?

[MR]  agreed

[MR] agreed

Other comments:
d1) Not sure whether some of the terms related to neighbor discovery are relevant to 6tisch. See my email as of September 11, 2014 on this topic: http://www.ietf.org/mail-archive/web/6tisch/current/msg02489.html
[MR] which ones would you like to delete?

[snip]

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

From: Rene Struik [mailto:[email-masked]]
Sent: Friday, January 09, 2015 5:00 PM
To: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] new (unpublished) version of terminology draft - please review

Hi Maria:

I still see lots of terms that do not fit in there and that I indicated in my review email to you, Pascal and Thomas on this yesterday (copied below - email Thu Jan 8, 2015, 7:14pm EST).

Best regards, Rene

Thank you!