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

["Wang, Chonggang" <[e-mail]>]

Dear Maria Rita
It seems we did not send the email to the mailing list. I just forwarded it to the group.

Thanks,
Chonggang

From: Chonggang Wang [mailto:[e-mail]]
Sent: Tuesday, February 03, 2015 4:12 PM
To: Wang, Chonggang
Subject: Fwd: [6tisch] new (unpublished) version of terminology draft - please review


---------- Forwarded message ----------
From: Maria Rita PALATTELLA <[e-mail]<mailto:[e-mail]>>
Date: Wed, Jan 21, 2015 at 10:10 AM
Subject: RE: [6tisch] new (unpublished) version of terminology draft - please review
To: Chonggang Wang, Thomas Watteyne

Dear Chonggang,
many thanks for your detailed comments. It is never late to integrate them in the next version of the draft.
Please find inline some feedback.
It will be great if others can also let us know what they think about.
Thanks
Maria Rita

From: Chonggang Wang
Sent: Tuesday, January 20, 2015 11:13 PM
To: Maria Rita PALATTELLA; Thomas Watteyne
Subject: Re: [6tisch] new (unpublished) version of terminology draft - please review

Dear Maria Rita, Thomas,

Wonder if it is too late. I have read over your draft which was nicely written. I had a few comments below which feel free to reject if already addressed or not relevant.

1. The name format of each term
Terms such as "Communication Paradigm", "Distributed cell reservation", and "unscheduled cell" are described in Section 2. But these terms use different format (i.e. uppercase or lowercase of first letter of each word).
right, we have to be consistent and use same format. agreed!

2. (pp.1) Both "Time Sensitive Networks" and "Time Sensitive Networking" are used. If both mean the same thing, I suggest using one or the other to avoid potential confusion.
Time Sensitive Networking is related to IEEE802.1 and we cannot change it.
Time sensitive Networks has been introduced by 6tisch.
maybe we can delete this sentence:  At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time Sensitive Networking.

3. (pp.1) "deterministic networks" was introduced at the end of 3rd paragraph of "1. Introduction" in the first time and only once. Wonder if you like to add 1-2 sentence to define it, add its definition to Section 2, or just remove it if no harm to the draft.
I am not sure we need to add a definition. we can delete it if you think it is better in that way.

4. 6TiSCH definition
suggest replacing "schedule" with "TSCH schedule" since the latter was defined later.
agreed

5. 6F definition
RED (RFC2309) is a specific algorithm/protocol for implementing Active Queue Management. Wonder why RED was picked here and why not using more general term (i.e. Active Queue Management)
agreed, we used RED because this was the initial option we had in mind to use. @Pascal: is it fine for  you?

6. 6top definition
Do we need to give the full spelling of 6LoWPAN and RPL?
I would say NO because these terms are very  well known at IETF community.

7. 6top Data Convey Model
PDU has been for Protocol Data Unit (RFC994), which has been well known in IETF and networking community. Wonder if we like to give a different name/acronym for Payload Data Unit
Right, it would avoid confusion. thanks for the suggestion.

8. Blacklist definition
Wonder if a more meaningful name such as "Backlist of Frequencies" or "Forbidden Frequencies" will help. "Backlist" by its name could be a list of black devices.
I see your point and it makes sense.  we used blacklist as per IEEE802.15.4e std.

9. BBR definition
suggest giving the full spelling of LBR
no need given that it is included in the LBR definition

10. Channel distribution/usage (CDU) matrix definition
The first sentence is a little confusion and could be re-phrased. In addition, you can define this matrix using the symbol CDU (i, j) - just need to define i and j then.
Right, we will improve the definition.

11. CoAP definition
"CoAP runs over UDP". There are active discussions within CoRE about other transport alternatives for CoAP in addition to UDP. We could remove this sentence; but if you like to keep this sentence, we could re-word it a little bit.
based on others feedbacks, we may delete CoAP for the draft.

12. Communication Paradigm definition
The full spelling of P2MP and MP2MP is missing
agreed

13. DAR/DAC definition
"multicast Duplicate Address Detection" seems a client/server process too. Suggest replacing "a client/server process" with "a unicast-based multi-hop process between routers and the backbone router"
@Pascal: is it ok for you?

14. Distributed cell/track reservation definition
Do you like to add "Centralized cell/track reservation" too?
it makes sense. thanks for the suggestion.

15. EB definition
Suggest adding IEEE 802.15.4e reference. Also, the full spelling of ASN and PAN is missing. BTW, "mote" is not used in IEEE 802.15.4e and why not just use "node" or "device"
agreed. About “mote”, we agreed to use “node”. it will be fixed too.

16. JA definition
The full spelling of 6LR is missing.
right, we are still discussing if we should keep or not this term.

17. KMP definition
Is KMP used within JCE/JA/JN? If yes, can you add this into the definition of KMP?
right, we are still discussing if we should keep or not this term.

18. LBR definition
The full spelling of LLN is missing
right

19. NEAR definition
NEAR = ND-efficiency-aware Router on pp.4, which is different from this definition
right
20. Operational Network definition
Wonder if "some algorithms/protocols mean KMP". If yes, suggest saying KMP explicitly since it's been defined.
I would keep it as it is if we delete KMP from the definitions.

21. Both GMPLS and G-MPLS are used in the draft
we will fix it.

22. Track definition
Suggest replacing "the result of a reservation" with "the result of a track reservation"
agree

23. (pp. 14) "Hebei" should be replaced by "Beijing" or removed
ok


Thanks,
CG

On Tue, Jan 13, 2015 at 10:26 AM, Maria Rita PALATTELLA <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]><mailto:[e-mail]>

To:

Thomas Watteyne <[e-mail]><mailto:[e-mail]>

CC:

Pascal Thubert <[e-mail]><mailto:[e-mail]>, Maria Rita Palattella <[e-mail]><mailto:[e-mail]>


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.
[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?

c3) KMP (useless term and "acronymitis" example). Remove.
[MR]  agreed

c4) SA (kind of useless at this point in time). Remove.
[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: [e-mail]<mailto:[e-mail]> | Skype: rstruik

cell: [phone]<tel:%2B1%20%28647%29%20867-5658> | US: [phone]<tel:%2B1%20%28415%29%20690-7363>



From: Rene Struik [mailto:[e-mail]]
Sent: Friday, January 09, 2015 5:00 PM
To: Maria Rita PALATTELLA; [e-mail]<mailto:[e-mail]>
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


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



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



_______________________________________________
6tisch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch