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

[Thomas Watteyne <[e-mail]>]

Thanks Chonggang for the detailed review!

Maria Rita, did you plan on pushing a new version implementing Rene's and
Chonggang's comments? Feel free to unicast me if you wish to create tickets
in the IETF tracker (the right approach IMO)

Thomas

On Tue, Feb 3, 2015 at 10:14 PM, Wang, Chonggang <
[e-mail]> wrote:

>   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]>
> 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]> 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]> <[e-mail]>
>
> *To: *
>
> Thomas Watteyne <[e-mail]> <[e-mail]>
>
> *CC: *
>
> Pascal Thubert <[e-mail]> <[e-mail]>, Maria Rita
> Palattella <[e-mail]> <[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] | Skype: rstruik
>
> cell: [phone] | US: [phone]
>
>
>
>
>
>
>
> *From:* Rene Struik [mailto:[e-mail] <[e-mail]>]
>
> *Sent:* Friday, January 09, 2015 5:00 PM
> *To:* Maria Rita PALATTELLA; [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]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>