Subject: [6tisch] #35 (architecture): Last call comments: editorial

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 07 Apr 2015 07:08:07 -0000

#35: Last call comments: editorial

 '''Chonggang:'''

 ·         pp. 3, 2nd paragraph, “…control operations such industrial
 automation…” ---> ““…control operations such as industrial automation…”
 ·         pp.3, 3rd paragraph, “…timeSlotted Channel  Hopping …” --->
 “…Time Slotted Channel Hopping…”
 ·         pp.3, 4th paragraph, the fulling spelling of TSN was givning in
 the 2nd paragraph. Then, please put the acronym TSN in the 2nd paragraph
 ·         pp.3, both “deterministic” and “Deterministic” are used in a few
 places. Better use one form if they mean the same thing throughout the
 draft.
 ·         pp.4, 2nd paragraph “Route Computation may be achieved in a
 centralized fashion by a Path Computation Element (PCE), in a distributed
 fashion using the Routing Protocol for Low Power and Lossy Networks (RPL)
 [RFC6550], or in a mixed mode”,
 o   Is RPL claim to be a distributed route computation? I believe in the
 non-storing mode, the root calculates the route and use source routing to
 route the packet to the destination.
 ·         pp.4, last two paragraphs from the bottom and a few other place
 in the draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”
 ·         pp. 5, section 3, 1st paragraph,  “Some aspects of this
 architecture derive from existing industrial standards for Process Control
 by its focus on Deterministic Networking, in particular with the use of
 the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized PCE.”
 o   What are the “existing industrial standard”? WirelessHart? Certain
 references would help.
 ·         pp.6, the title of Figure could be more complete by saying
 something like “Figure 1, Basic Configuration of 6TiSCH Network”
 ·         pp. 6, the paragraph under Fig. 1, “neighbor Devices” --->
 “neighbor devices”
 ·         pp.6, 2nd paragraph from the bottom, “LLN Border Router (LBR)”
 were mentioned twice in one sentence.
 ·         pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol
 Stack”
 ·         pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is
 correct but it could imply that only HC is used there – which is not true.
 Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g. adaptation,
 header compression)”
 ·         pp.9, the 4th paragraph, “join process” was introduced all of a
 sudden. Wonder if it could read more smoothly by briefly mentioning these
 concepts (e.g. neighbor discovery, join process, track reservation, 6top,
 packet forwarding, etc.) together and their relationship from
 architectural perspective somewhere in Section 4 (e.g. at the beginning?).
 ·         pp.9, 3rd paragraph, “TEAS protocol will be required to expose
 the device capabilities and the network peerings to the PCE, and a
 protocol such as a lightweight PCEP or an adaptation of CCAMP G-MPLS
 formats and procedures will be used to publish the tracks, computed by the
 PCE, to the devices.”
 ·         Can you put the reference about “TEAS” and “CCAMP”?
 ·         pp.10, 2nd paragraph, “should be portable only other LLN link
 types”. It reads a little awkward and maybe some words missing around
 “only”
 ·         pp.10, 2nd paragraph, “A new version of the standard is expected
 in 2015”. What’s “the standard” refer to?
 ·         pp.10, 4th paragraph, do you want to add a reference for
 ISA100.20?
 ·         pp.16, 4th paragraph, “motes” was used. Can we change it to
 devices or nodes to make terms more consistent?
 ·         pp.17, 2nd paragraph, “but also allows an upper layer like RPL.”
 This sentence seems not finished
 ·         pp.18, 2nd paragraph, “that is is not capable of”. One “is”
 should be removed.
 ·         pp.19, the last paragraph, “an higher layer” ---> “a higher
 layer”
 ·         pp.19, the last paragraph, “DSCP can therefore be used”. Suggest
 giving the full spelling and reference to DSCP or removing this sentence.
 ·         pp.19, 5th paragraph, “A 6TISCH Instance is associated to one
 slotFrame.”,
 ·         Wonder what is a 6TiSCH Instance? Why associate to only “one”
 Slotframe? In previous paragraph, it mentions “Multiple slotFrames can
 coexist in a node schedule”.
 ·         pp.21, section 9, both “Static Scheduling” and “Minimal Static
 Scheduling” are used. Are they the same?
 ·         pp.22, 1st paragraph, “This scheduled can be” ---> “This
 schedule can be”
 ·         pp.24, section 10.1, 1st paragraph, “A bundle of cells set to
 receive (RX-cells) is uniquely paired to a bundle of cells that are set to
 transmit (TX-cells), representing a layer-2 forwarding state that can be
 used regardless of the network layer protocol.”
 ·         Is a Track uni-directional or bi-directional? Is there any ACK
 for the transmission?
 ·         pp.27, Figure 6, suggest adding what is the value “set dmac to”
 and “restore dmac”
 ·         pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress
 point does not have a MAC address that matches the configuration, the
 Track installation fails.”,
 ·         Wonder if it is ingress point or egress point that installs the
 Track
 ·         pp.30, 1st paragraph, “Centralized routes can for example
 computed”. The word “be” was missing.
 ·         pp.30, section 11, it will be helpful if the difference between
 routing discussed in this section and forwarding discussed in section 10
 could be clarified a little bit

 ----

 Anand:

 There is just one observation which I could not resist mentioning. It has
 to do with
 the coupling of real-time application demands with the rest of the
 architecture. There could be
 application specific "time critical and sudden" events that might call for
 on-demand resource allocation.
 While we can delegate such an event handling to NME and PCE, perhaps,
 bringing in an application awareness
 to the overall architecture might be useful so that we are not leaving out
 this possible scenario.

 ----

 Maria Rita:
 pag 8 LLN odes -> LLN nodes
 pag. 19 6TISCH -> 6TiSCH
 pag 23 as started -> has started
 pag 19 in the definition of CDU matrix, I would specify height and width,
 and after the timeslot duration (in the current version timeslot duration
 is in the middle, and it makes a bit hard to read and clearly understand
 the CDU matrix structure)
 pag 7 are we sure we want to mention in the next round of the document we
 will have evaluated PANA applicability? we may need/want to publish the
 second part of the architecture before that, we don’t know yet. So, we
 could skip that, if you agree.

 ----

 Rouhollah:

 Page 7 first paragraph. LLN odes
 Page 9 end of third paragraph. foster

 1-Do registration phase may work properly when network builds up, if when
 RPL tree  grows up and extends like a complete tree (I mean in distributed
 manner). Maybe some additional controls needed later?

 2-Do you think DICE(figure 3. page 7) should be defined in the Terminology
 draft.

 Typos:
 Page 21. scheduled

 ----

 Guillaume:

 1) The term reallocation/relocation of cells :
 8.1 p16 a cell reallocation
 differs from
 9.2 p22 the relocation of a soft cell / relocation is done
 => I am not sure if there has been a discussion on this term, but I vote
 for reallocation.

 2) 8.2 p16 a set of quality metrics (RSSI, LQI)
 I think you cannot be specific to just two metrics (RSSI, LQI).
 The words "a set of" allows to define more metrics. And I think it is
 fine.
 => what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.)
 " ?

 3) 8.2 p16 and used to compute a Rank Increment
 The statistics of 6top may have other usages than incrementing the ranks,
 for upper layers, and for resource management.
  => what about : "and used for instance to compute" ?

 4) 10.2 p28 : a degree of flow control base on => I think it should be
 "based on".

 5) (Already pointed out) 11 p 30 Centralized routes con for example
 computed => be computed

 ----

 Jonathan Simon:
 13 - Sending link-layer frames in the clear in the initial stage of
 joining is not providing any benefit. We should always use authentication,
 even if the key is not secret, as it provides the ability to reject
 similar frames from other 802.15.4-based protocols.  It also isn’t
 necessary to discuss such a detail here.

 13.1  -
 * "Triage" - So the JCE decides which nodes are more important and assigns
 resources to them first? How?  Note this term is not used in draft-
 richardson-6tisch-security-architecture-02.
 * "arbitrage" should be “arbitrate”

 Other than that, it seem to be capturing the overall spirit of the
 security architecture and highlights the open areas of security
 discussion, e.g. that PANA is an open issue.

 Couple minor points:

 1) Introduction and 3) Application and Goals sections need review. They
 kind of wander all over the place.

 5.1) What does "volume" mean in this context? Is this referring to other
 as yet defined documents, or later revisions of this document?

 ----

 Rene:
 One note: the second para of Clause 13 seems out of place and should be
 removed.

 ----

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6tisch-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:               |    Version:
  architecture           |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 07 Apr 2015 15:37:02 -0000

Comment (by [email-masked]):

 > ·         pp.3, 4th paragraph, the fulling spelling of TSN was givning
 in the 2nd paragraph. Then, please put the acronym TSN in the 2nd
 paragraph
 > ·         pp.3, both “deterministic” and “Deterministic” are used in a
 few places. Better use one form if they mean the same thing throughout the
 draft.
 > ·         pp.4, last two paragraphs from the bottom and a few other
 place in the draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”
 references would help.
 “neighbor devices”
 Stack”
 > ·         pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It
 is correct but it could imply that only HC is used there – which is not
 true. Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g.
 adaptation, header compression)”
 > ·         pp.9, the 4th paragraph, “join process” was introduced all of
 a sudden. Wonder if it could read more smoothly by briefly mentioning
 these concepts (e.g. neighbor discovery, join process, track reservation,
 6top, packet forwarding, etc.) together and their relationship from
 architectural perspective somewhere in Section 4 (e.g. at the beginning?).
 > ·         pp.10, 2nd paragraph, “A new version of the standard is
 expected in 2015”. What’s “the standard” refer to?
 ISA100.20?
 > ·         pp.17, 2nd paragraph, “but also allows an upper layer like
 RPL.” This sentence seems not finished
 should be removed.
 layer”
 > ·         pp.19, the last paragraph, “DSCP can therefore be used”.
 Suggest giving the full spelling and reference to DSCP or removing this
 sentence.
 slotFrame.”,
 schedule can be”
 for the transmission?
 > ·         pp.27, Figure 6, suggest adding what is the value “set dmac
 to” and “restore dmac”
 > ·         Wonder if it is ingress point or egress point that installs
 the Track
 > ·         pp.30, section 11, it will be helpful if the difference
 between routing discussed in this section and forwarding discussed in
 section 10 could be clarified a little bit
 >
 >
 > ----
 >
 >
 > Anand:
 >
 >
 > There is just one observation which I could not resist mentioning. It
 has to do with
 > application specific "time critical and sudden" events that might call
 for on-demand resource allocation.
 > to the overall architecture might be useful so that we are not leaving
 out this possible scenario.
 > pag 19 in the definition of CDU matrix, I would specify height and
 width, and after the timeslot duration (in the current version timeslot
 duration is in the middle, and it makes a bit hard to read and clearly
 understand the CDU matrix structure)
 > pag 7 are we sure we want to mention in the next round of the document
 we will have evaluated PANA applicability? we may need/want to publish the
 second part of the architecture before that, we don’t know yet. So, we
 could skip that, if you agree.
 > 1-Do registration phase may work properly when network builds up, if
 when RPL tree  grows up and extends like a complete tree (I mean in
 distributed manner). Maybe some additional controls needed later?
 >
 > 2-Do you think DICE(figure 3. page 7) should be defined in the
 Terminology draft.
 for reallocation.
 fine.
 > => what do you think of : "a set of quality metrics (e.g. RSSI, LQI,
 etc.) " ?
 > The statistics of 6top may have other usages than incrementing the
 ranks, for upper layers, and for resource management.
 "based on".
 computed => be computed
 >
 > 13.1  -
 > * "Triage" - So the JCE decides which nodes are more important and
 assigns resources to them first? How?  Note this term is not used in
 draft-richardson-6tisch-security-architecture-02.
 removed.

 Answer
 ------

 I addressed all the comments doing one commit per; and answer on the ML.
 The list of commits is in https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/all , each with a diff.

 I made the following changes; based on Michael's comments

 Pascal Thubert  ae7ea78  07     2015-03-10  https://bitbucket.org/6tisch
 /draft-ietf-6tisch-
 architecture/commits/ae7ea789ac066cb6b31fcdf9e6e8fdc2f6cf667e
 Pascal Thubert  62b2606  06 final       2015-03-09
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/62b2606b48d14cb83f4d1d87c600c3f333cc8f66
 Pascal Thubert  2b29626 trailing whitespace removal     2015-02-24
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/2b296269f964eae8a7d47216ed90cf969c405a9d

 Pascal Thubert  28c6316 Maria-Rita's review     2015-02-24
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/28c6316289ff06e21adc340c962acca94277de22

 Discussion
 ----------

 typos to be fixed:

 -> all fixed

 Moreover,
 page 19 in the definition of CDU matrix, I would specify height and width,
 and after the timeslot duration (in the current version timeslot duration
 is in the middle, and it makes a bit hard to read and clearly understand
 the CDU matrix structure)

 -> text now reads:
          In order to describe that formatting of time and frequencies, the
          6TiSCH architecture defines a global concept that is called a
 Channel
          Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
          cells with an height equal to the number of available channels
          (indexed by ChannelOffsets) and a width (in timeSlots) that is
 the
          period of the network scheduling operation (indexed by
 slotOffsets) for
          that CDU matrix. The size of a cell is a timeSlot duration, and
          values  of 10 to 15 milliseconds are typical in 802.15.4e TSCH to
          accommodate for the transmission of a frame and an ack, including
 the
          security validation on the receive side which may take up to a
 few
            milliseconds on some device architecture.

 -> I’d like to leave things open. What about:
       Future work on 6TiSCH security and will examine in deeper detail how
 SACM,
       ACE, DICE, IEEE802.15.9 and eventually PANA and 802.1x may apply to
 6TiSCH
       networks to perform Authentication and Authorization, to secure
 transactions
       end-to-end, and to maintain the  security posture of a device over
 its lifetime.
       The result of that work will be described in a subsequent volume of
 this
        architecture.

 Pascal Thubert  0e07e72 René Struik's review    2015-02-24
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/0e07e721ce096cbd02f93c5cfbf9e58e576ac124

 Comments:
 ---------

 I removed that section, and added an appendix that lists the 6TiSCH
 personal submissions that may impact the next volumes.
 The new text reads as follows

 Appendix A.  Personal submissions relevant to the next volumes

    This volume only covers a portion of the total work that is needed to
    cover the full 6TiSCH architecture.  Missing portions include
    Deterministic Networking with Track Forwarding, Dynamic Scheduling,
    and Security.

    [I-D.richardson-6tisch-security-architecture] elaborates on the
    potential use of 802.1AR certificates, and some options for the join
    process are presented in more details.

    [I-D.struik-6tisch-security-architecture-elements"]
    describes 6TiSCH security architectural elements with
    high level requirements and the security framework that are relevant
    for the design of the 6TiSCH security solution.

    [I-D.dujovne-6tisch-on-the-fly] discusses the use of the 6top
    sublayer [I-D.wang-6tisch-6top-sublayer] to adapt dynamically the
    number of cells between a RPL parent and a child to the needs of the
    actual traffic.

 Pascal Thubert  c34d7eb ChongGang's review      2015-02-24
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/c34d7ebf8abb67a51fb94717480fcc5cc931c572

 Pascal Thubert  1a72a0f updated 2015-02-24 https://bitbucket.org/6tisch
 /draft-ietf-6tisch-
 architecture/commits/1a72a0f578371be194832d6525c1e502e0055b92

 Comments
 --------

 Please see below for details:

 I have reviewed the architecture draft (-05) and support to publish it.

 A few minor comments I had are listed below.
 •         pp. 3, 2nd paragraph, “…control operations such industrial
 automation…” ---> ““…control operations such as industrial automation…”

 -> done
 •         pp.3, 3rd paragraph, “…timeSlotted Channel  Hopping …” --->
 “…Time Slotted Channel Hopping…”

 -> Actually I think the group settled for TimeSlotted, I migrated all to
 that

 •         pp.3, 4th paragraph, the fulling spelling of TSN was givning in
 the 2nd paragraph. Then, please put the acronym TSN in the 2nd paragraph

 -> It was but I changed the format to be more classical

 •         pp.3, both “deterministic” and “Deterministic” are used in a few
 places. Better use one form if they mean the same thing throughout the
 draft.

 -> Done, I used the uppercase because our Deterministic is not the one
 from math

 •         pp.4, 2nd paragraph “Route Computation may be achieved in a

 -> I see what you are saying. I agree that storing mode centralized the
 computation of routes down but that’s based on a parent selection that is
 still distributed. I do not think that being very specific like “RPL is
 mostly distributed but then there can be a bit of centralized computation”
 will help a lot the understanding of the section. I’d rather leave it at
 that.

 •         pp.4, last two paragraphs from the bottom and a few other place
 in the draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”

 -> sure, many occurrences fixed

 •         pp. 5, section 3, 1st paragraph,  “Some aspects of this

 -> OK, added

 •         pp.6, the title of Figure could be more complete by saying
 something like “Figure 1, Basic Configuration of 6TiSCH Network”

 -> OK

 •         pp. 6, the paragraph under Fig. 1, “neighbor Devices” --->
 “neighbor devices”

 -> OK

 •         pp.6, 2nd paragraph from the bottom, “LLN Border Router (LBR)”
 were mentioned twice in one sentence.

 ->reworded

 •         pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol
 Stack”

 -> Yes, I added envisioned since all is not fully cast in stone

 •         pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is
 correct but it could imply that only HC is used there – which is not true.
 Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g. adaptation,
 header compression)”

 -> added

 •         pp.9, the 4th paragraph, “join process” was introduced all of a

 -> will be hard without duplicating a lot; let me think of that one. In
 any fashion, I can clarify join there. I propose

          Security is often handled at Layer-2 and Layer 4. Authentication
          during the process on joining or re-joining the network
          is discussed in <xref target="sec"/> and the
          applicability of existing protocols such as
          the <xref target="RFC5191">
          Protocol for Carrying Authentication for Network access
 (PANA)</xref>
           will be studied in a next volume of this document.

 •         pp.9, 3rd paragraph, “TEAS protocol will be required to expose
 the device capabilities and the network peerings to the PCE, and a
 protocol such as a lightweight PCEP or an adaptation of CCAMP G-MPLS
 formats and procedures will be used to publish the tracks, computed by the
 PCE, to the devices.”
 •         Can you put the reference about “TEAS” and “CCAMP”?

 -> added, text looks like this now:

          The work on centralized track computation is deferred to a
 subsequent volume
          of the architecture. The Path Computation Element (PCE) is
 certainly
          the core component of that architecture. Around the PCE, a
 protocol
          such as an extension to a TEAS <xref target="TEAS"/> protocol
          (maybe running over CoAP as illustrated) will be required to
 expose the
          device capabilities and the network peers to the PCE, and a
 protocol
          such as a lightweight PCEP or an adaptation of CCAMP <xref
 target="CCAMP"/>
          G-MPLS formats and procedures will be used to publish the tracks,
          computed by the PCE, to the devices (maybe in a fashion similar
 to RSVP-TE).

 •         pp.10, 2nd paragraph, “should be portable only other LLN link
 types”. It reads a little awkward and maybe some words missing around
 “only”

 ->sure! The text now reads

       The current charter positions 6TiSCH on IEEE802.15.4 only.
       Though most of the design should be portable on other link types,
         6TiSCH has a strong dependency on 802.15.4 and its evolution.

 •         pp.10, 2nd paragraph, “A new version of the standard is expected
 in 2015”. What’s “the standard” refer to?

 -> clarified as follows

       The current charter positions 6TiSCH on IEEE802.15.4 only.
       Though most of the design should be portable on other link types,
       6TiSCH has a strong dependency on IEEE802.15.4 and its evolution.
       A new version of the IEEE802.15.4 standard is expected in 2015.

 •         pp.10, 4th paragraph, do you want to add a reference for
 ISA100.20?

 -> there’s no good link. I added a link to ISA100, and explained what CNM
 is.

       ISA100 <xref target="ISA100"/> Common Network Management (CNM) is
 another
       external work of interest for 6TiSCH. The group, referred to as
 ISA100.20,
       defines a Common Network Management framework that should enable the
       management of resources that are controlled by heterogeneous
 protocols
       such as ISA100.11a <xref target="ISA100.11a"/>, WirelessHART
       <xref target="WirelessHART"/>, and 6TiSCH. Interestingly, the
       establishment of 6TiSCH Deterministic paths, called tracks,
       are also in scope, and ISA100.20 is working on requirements for
 DetNet.

 •         pp.16, 4th paragraph, “motes” was used. Can we change it to
 devices or nodes to make terms more consistent?

 -> moved to devices, but added the following
 on behalf of the wireless devices (also called motes),

 •         pp.17, 2nd paragraph, “but also allows an upper layer like RPL.”
 This sentence seems not finished

 -> OK, the sentence now looks like

            The receiver of the Enhanced Beacon MAY
             be listening at the cell to get the Enhanced Beacon
 ([IEEE802154e]).
             6top takes this way to establish broadcast channel, which not
 only
             allows TSCH to broadcast Enhanced Beacons, but also allows
 protocol
              exchanges by an upper layer such as RPL.

 •         pp.18, 2nd paragraph, “that is is not capable of”. One “is”
 should be removed.

 -> ack

 •         pp.19, the last paragraph, “an higher layer” ---> “a higher
 layer”
 -> ack

 •         pp.19, the last paragraph, “DSCP can therefore be used”. Suggest
 giving the full spelling and reference to DSCP or removing this sentence.

 -> I used ‘Differentiated Services [RFC2474]’ instead

 •         pp.19, 5th paragraph, “A 6TISCH Instance is associated to one
 slotFrame.”,

 -> that’s really a 6top internal. Much too detailed, I removed the
 sentence.

 •         Wonder what is a 6TiSCH Instance? Why associate to only “one”
 Slotframe? In previous paragraph, it mentions “Multiple slotFrames can
 coexist in a node schedule”.

 -> same, that is an internal construct

 •         pp.21, section 9, both “Static Scheduling” and “Minimal Static
 Scheduling” are used. Are they the same?

 -> removed minimal. Intention was to say that this is the minimal support

 •         pp.22, 1st paragraph, “This scheduled can be” ---> “This
 schedule can be”

 -> gone

 •         pp.24, section 10.1, 1st paragraph, “A bundle of cells set to
 receive (RX-cells) is uniquely paired to a bundle of cells that are set to
 transmit (TX-cells), representing a layer-2 forwarding state that can be
 used regardless of the network layer protocol.”
 •         Is a Track uni-directional or bi-directional? Is there any ACK
 for the transmission?

 -> I added

             A Track is a unidirectional path between a source and a
 destination.
             In a Track cell, the normal operation of IEEE802.15.4e
             Automatic Repeat-reQuest (ARQ) usually happens, though the
             acknowledgment may be omitted in some cases, for instance if
 there
             is no scheduled cell for a retry.

 •         pp.27, Figure 6, suggest adding what is the value “set dmac to”
 and “restore dmac”

 -> done

 •         pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress
 point does not have a MAC address that matches the configuration, the
 Track installation fails.”,
 •         Wonder if it is ingress point or egress point that installs the
 Track

 I think the text is correct. The configuration of the tunnel is yet TBD by
 this group (RSVP-TE?), but the egress must be able to deliver a packet to
 the MAC address that is at the end of the tunnel.

 •         pp.30, 1st paragraph, “Centralized routes can for example
 computed”. The word “be” was missing.

 fixed
 •         pp.30, section 11, it will be helpful if the difference between
 routing discussed in this section and forwarding discussed in section 10
 could be clarified a little bit

 Added
         By forwarding, this specification means the per-packet operation
 that
          allows to deliver a packet to a next hop or an upper layer in
 this node.
          Forwarding is based on pre-existing state that was installed as a
           result of a routing computation.

 Pascal Thubert  cca7835 Rouhollah's comments    2015-02-23
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/cca78350db5d5ad3a8b031944e44ce15972453ae

 Comments
 ---------

 > Unsure what you really mean here. There can be issues with security and
 the join process work is looking at that. Then there’s RPL use of slotted
 aloha slots. Then there’s the resource allocation problem (chunks between
 parents and cells in a parent’s chunk between children). We’ll recharter
 for all these things but the first volume of the architecture does not
 cover that.

 Well, that’s a WG now, unsure what the standard name will be. I can add
 the following text:
 “        DTLS In Constrained Environments (DICE) is at the time of this
          writing the probable way LLN nodes will provide end-to-end
 security for
          UDP/CoAP packets.”

 Typos:
 Page 21. scheduled

 Ack

 On Mon, Feb 16, 2015 at 8:10 PM, Rouhollah Nabati(Google)
 <[email-masked]> wrote:
 Hello All,

 ack

 I missed the issue there?

 I agree with all Guillaume’s suggested edits. Changes:

 Pascal Thubert  5c2a38f Guillaume's edits       2015-02-23
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/5c2a38ffd0b74695b26551a0ca5b90fd0ab3d7fb

  architecture           |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35#comment:1>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Apr 2015 16:18:10 +0000

Dear all:

To address one issue about TCP/PCEP etc..., I suggest to change the stack representation as follows

         +-----+-----+

         | PCEP|TEAS/|

         | PCE |CCAMP|

   +-----+-----+-----+-----+-------+-----+

   |     (COMI)      |PANA |6LoWPAN| RPL |

   | CoAP  / DICE    | ACE |   ND  |     |

   +-----+-----+-----+-----+-------+-----+

   |       UDP       |          ICMP     |

   +-----+-----+-----+-----+-------+-----+-----+

   |                 IPv6                      |

   +-------------------------------------------+

   |  6LoWPAN adaptation and compression (HC)  |

   +-------------------------------------------+

   |                   6top                    |

   +-------------------------------------------+

   |             IEEE802.15.4e   TSCH          |

   +-------------------------------------------+

I’m trying to illustrate that whatever DetNet comes up with, we will need some conversion into COMI for whatever PCE/TEAS/CCAMP interactions.

Advice is needed: Is this readable or would you have an alternate view to propose?

Cheers,

Pascal

> -----Original Message-----

> From: 6tisch [mailto:[email-masked]] On Behalf Of 6tisch issue tracker

> Sent: mardi 7 avril 2015 09:08

> To: [email-masked]; Shwetha Bhandari (shwethab)

> Cc: [email-masked]

> Subject: [6tisch] #35 (architecture): Last call comments: editorial

>  ·         pp. 3, 2nd paragraph, “…control operations such industrial  automation…”

> ---> ““…control operations such as industrial automation…”

>  ·         pp.3, 3rd paragraph, “…timeSlotted Channel  Hopping …” --->  “…Time

> Slotted Channel Hopping…”

>  ·         pp.3, 4th paragraph, the fulling spelling of TSN was givning in  the 2nd

> paragraph. Then, please put the acronym TSN in the 2nd paragraph  ·         pp.3,

> both “deterministic” and “Deterministic” are used in a few  places. Better use

> one form if they mean the same thing throughout the  draft.

> [RFC6550], or in a mixed mode”,  o   Is RPL claim to be a distributed route

> computation? I believe in the  non-storing mode, the root calculates the route

> and use source routing to  route the packet to the destination.

>  ·         pp.4, last two paragraphs from the bottom and a few other place  in the

> draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”

>  ·         pp. 5, section 3, 1st paragraph,  “Some aspects of this  architecture derive

> from existing industrial standards for Process Control  by its focus on

> Deterministic Networking, in particular with the use of  the IEEE802.15.4e

> [IEEE802154e] TSCH MAC and a centralized PCE.”

>  ·         pp.6, the title of Figure could be more complete by saying  something like

> “Figure 1, Basic Configuration of 6TiSCH Network”

>  ·         pp. 6, the paragraph under Fig. 1, “neighbor Devices” --->  “neighbor

> devices”

>  ·         pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol  Stack”

>  ·         pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is  correct

> but it could imply that only HC is used there – which is not true.

>  ·         pp.9, the 4th paragraph, “join process” was introduced all of a  sudden.

> Wonder if it could read more smoothly by briefly mentioning these  concepts

> (e.g. neighbor discovery, join process, track reservation, 6top,  packet

> forwarding, etc.) together and their relationship from  architectural perspective

> somewhere in Section 4 (e.g. at the beginning?).

>  ·         pp.9, 3rd paragraph, “TEAS protocol will be required to expose  the device

> capabilities and the network peerings to the PCE, and a  protocol such as a

> lightweight PCEP or an adaptation of CCAMP G-MPLS  formats and procedures

> will be used to publish the tracks, computed by the  PCE, to the devices.”

>  ·         pp.10, 2nd paragraph, “should be portable only other LLN link  types”. It

> reads a little awkward and maybe some words missing around  “only”

>  ·         pp.10, 2nd paragraph, “A new version of the standard is expected  in

> 2015”. What’s “the standard” refer to?

>  ·         pp.10, 4th paragraph, do you want to add a reference for  ISA100.20?

>  ·         pp.16, 4th paragraph, “motes” was used. Can we change it to  devices or

> nodes to make terms more consistent?

>  ·         pp.19, the last paragraph, “an higher layer” ---> “a higher  layer”

>  ·         pp.19, the last paragraph, “DSCP can therefore be used”. Suggest  giving

> the full spelling and reference to DSCP or removing this sentence.

> slotFrame.”,  ·         Wonder what is a 6TiSCH Instance? Why associate to only

> “one”

>  Slotframe? In previous paragraph, it mentions “Multiple slotFrames can  coexist

> in a node schedule”.

>  ·         pp.21, section 9, both “Static Scheduling” and “Minimal Static  Scheduling”

> are used. Are they the same?

>  ·         pp.22, 1st paragraph, “This scheduled can be” ---> “This  schedule can be”

>  ·         pp.24, section 10.1, 1st paragraph, “A bundle of cells set to  receive (RX-

> cells) is uniquely paired to a bundle of cells that are set to  transmit (TX-cells),

> representing a layer-2 forwarding state that can be  used regardless of the

> network layer protocol.”

>  ·         Is a Track uni-directional or bi-directional? Is there any ACK  for the

> transmission?

>  ·         pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress  point does not

> have a MAC address that matches the configuration, the  Track installation

> fails.”,  ·         Wonder if it is ingress point or egress point that installs the  Track

> ·         pp.30, 1st paragraph, “Centralized routes can for example  computed”.

> The word “be” was missing.

>  ·         pp.30, section 11, it will be helpful if the difference between  routing

> discussed in this section and forwarding discussed in section 10  could be

> clarified a little bit

>  There is just one observation which I could not resist mentioning. It has  to do

> with  the coupling of real-time application demands with the rest of the

> architecture. There could be  application specific "time critical and sudden"

> events that might call for  on-demand resource allocation.

> bringing in an application awareness  to the overall architecture might be useful

> so that we are not leaving out  this possible scenario.

>  pag 19 in the definition of CDU matrix, I would specify height and width,  and

> after the timeslot duration (in the current version timeslot duration  is in the

> middle, and it makes a bit hard to read and clearly understand  the CDU matrix

> structure)  pag 7 are we sure we want to mention in the next round of the

> document we  will have evaluated PANA applicability? we may need/want to

> publish the  second part of the architecture before that, we don’t know yet. So,

> we  could skip that, if you agree.

>  9.2 p22 the relocation of a soft cell / relocation is done  => I am not sure if

> there has been a discussion on this term, but I vote  for reallocation.

>  2) 8.2 p16 a set of quality metrics (RSSI, LQI)  I think you cannot be specific to

> just two metrics (RSSI, LQI).

>  The words "a set of" allows to define more metrics. And I think it is  fine.

>  => what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.)  " ?

>  3) 8.2 p16 and used to compute a Rank Increment  The statistics of 6top may

> have other usages than incrementing the ranks,  for upper layers, and for

> resource management.

>  4) 10.2 p28 : a degree of flow control base on => I think it should be  "based

> on".

>  5) (Already pointed out) 11 p 30 Centralized routes con for example  computed

> => be computed

>  13 - Sending link-layer frames in the clear in the initial stage of  joining is not

> providing any benefit. We should always use authentication,  even if the key is

> not secret, as it provides the ability to reject  similar frames from other

> 802.15.4-based protocols.  It also isn’t  necessary to discuss such a detail here.

> resources to them first? How?  Note this term is not used in draft-  richardson-

> 6tisch-security-architecture-02.

>  Other than that, it seem to be capturing the overall spirit of the  security

> architecture and highlights the open areas of security  discussion, e.g. that PANA

> is an open issue.

>  1) Introduction and 3) Application and Goals sections need review. They  kind of

> wander all over the place.

>  5.1) What does "volume" mean in this context? Is this referring to other  as yet

> defined documents, or later revisions of this document?

> -------------------------+----------------------------------------------

> -------------------------+---

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

> -------------------------+----------------------------------------------

> -------------------------+---

> _______________________________________________

> 6tisch mailing list

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

> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 23 Apr 2015 05:11:06 +0000

Hello Reviewers,

With -07 the authors and I (as the shepherd of this draft) believe all the
comments have been addressed.
I will close this ticket and proceed with the submission of the draft for
IESG review by end of this week (25th April). Please respond if you think
there are unaddressed comments.

Thanks,
Shwetha

On 4/7/15 9:07 PM, "6tisch issue tracker" <[email-masked]>
wrote:

> Replying to [ticket:35 shwethab@Š]:
> > '''Chonggang:'''
> >
> > ·         pp. 3, 2nd paragraph, ³Šcontrol operations such industrial
> automationŠ² ---> ³³Šcontrol operations such as industrial automationŠ²
> > ·         pp.3, 3rd paragraph, ³ŠtimeSlotted Channel  Hopping Š² --->
> ³ŠTime Slotted Channel HoppingŠ²
> > ·         pp.3, both ³deterministic² and ³Deterministic² are used in a
> > ·         pp.4, 2nd paragraph ³Route Computation may be achieved in a
> [RFC6550], or in a mixed mode²,
> place in the draft, ³Šneighbor DiscoveryŠ² ---> ³Š Neighbor DiscoveryŠ²
> > ·         pp. 5, section 3, 1st paragraph,  ³Some aspects of this
> the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized PCE.²
> > o   What are the ³existing industrial standard²? WirelessHart? Certain
> references would help.
> something like ³Figure 1, Basic Configuration of 6TiSCH Network²
> > ·         pp. 6, the paragraph under Fig. 1, ³neighbor Devices² --->
> ³neighbor devices²
> > ·         pp.6, 2nd paragraph from the bottom, ³LLN Border Router
>(LBR)²
> > ·         pp.8, Figure 3, suggest changing its title to ³6TiSCH
>Protocol
> Stack²
> > ·         pp.8, Figure 3, ³6LoWPAN HC² shows between IPv6 and 6top. It
> is correct but it could imply that only HC is used there  which is not
> true. Suggest changing 6LoWPAN HC to something like ³6LoWPAN (e.g.
> adaptation, header compression)²
> > ·         pp.9, the 4th paragraph, ³join process² was introduced all of
> > ·         pp.9, 3rd paragraph, ³TEAS protocol will be required to
>expose
> PCE, to the devices.²
> > ·         Can you put the reference about ³TEAS² and ³CCAMP²?
> > ·         pp.10, 2nd paragraph, ³should be portable only other LLN link
> types². It reads a little awkward and maybe some words missing around
> ³only²
> > ·         pp.10, 2nd paragraph, ³A new version of the standard is
> expected in 2015². What¹s ³the standard² refer to?
> > ·         pp.16, 4th paragraph, ³motes² was used. Can we change it to
> > ·         pp.17, 2nd paragraph, ³but also allows an upper layer like
> RPL.² This sentence seems not finished
> > ·         pp.18, 2nd paragraph, ³that is is not capable of². One ³is²
> should be removed.
> > ·         pp.19, the last paragraph, ³an higher layer² ---> ³a higher
> layer²
> > ·         pp.19, the last paragraph, ³DSCP can therefore be used².
> > ·         pp.19, 5th paragraph, ³A 6TISCH Instance is associated to one
> slotFrame.²,
> > ·         Wonder what is a 6TiSCH Instance? Why associate to only ³one²
> Slotframe? In previous paragraph, it mentions ³Multiple slotFrames can
> coexist in a node schedule².
> > ·         pp.21, section 9, both ³Static Scheduling² and ³Minimal
>Static
> Scheduling² are used. Are they the same?
> > ·         pp.22, 1st paragraph, ³This scheduled can be² ---> ³This
> schedule can be²
> > ·         pp.24, section 10.1, 1st paragraph, ³A bundle of cells set to
> used regardless of the network layer protocol.²
> > ·         pp.27, Figure 6, suggest adding what is the value ³set dmac
> to² and ³restore dmac²
> > ·         pp.27, section 10.1.3, 1st paragraph, ³If the tunnel egress
> Track installation fails.²,
> > ·         pp.30, 1st paragraph, ³Centralized routes can for example
> computed². The word ³be² was missing.
> second part of the architecture before that, we don¹t know yet. So, we
> similar frames from other 802.15.4-based protocols.  It also isn¹t
> > * "arbitrage" should be ³arbitrate²
> >
> second part of the architecture before that, we don¹t know yet. So, we
> -> I¹d like to leave things open. What about:
> €         pp. 3, 2nd paragraph, ³Šcontrol operations such industrial
> automationŠ² ---> ³³Šcontrol operations such as industrial automationŠ²
>
> -> done
> €         pp.3, 3rd paragraph, ³ŠtimeSlotted Channel  Hopping Š² --->
> ³ŠTime Slotted Channel HoppingŠ²
>
> €         pp.3, 4th paragraph, the fulling spelling of TSN was givning in
> €         pp.3, both ³deterministic² and ³Deterministic² are used in a
>few
> €         pp.4, 2nd paragraph ³Route Computation may be achieved in a
> [RFC6550], or in a mixed mode²,
> computation of routes down but that¹s based on a parent selection that is
> still distributed. I do not think that being very specific like ³RPL is
> mostly distributed but then there can be a bit of centralized
>computation²
> will help a lot the understanding of the section. I¹d rather leave it at
> that.
>
> €         pp.4, last two paragraphs from the bottom and a few other place
> in the draft, ³Šneighbor DiscoveryŠ² ---> ³Š Neighbor DiscoveryŠ²
>
> €         pp. 5, section 3, 1st paragraph,  ³Some aspects of this
> the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized PCE.²
> o   What are the ³existing industrial standard²? WirelessHart? Certain
> references would help.
>
> -> OK, added
>
>
> €         pp.6, the title of Figure could be more complete by saying
> something like ³Figure 1, Basic Configuration of 6TiSCH Network²
>
> -> OK
>
> €         pp. 6, the paragraph under Fig. 1, ³neighbor Devices² --->
> ³neighbor devices²
>
> -> OK
>
> €         pp.6, 2nd paragraph from the bottom, ³LLN Border Router (LBR)²
> €         pp.8, Figure 3, suggest changing its title to ³6TiSCH Protocol
> Stack²
>
> €         pp.8, Figure 3, ³6LoWPAN HC² shows between IPv6 and 6top. It is
> correct but it could imply that only HC is used there  which is not
>true.
> Suggest changing 6LoWPAN HC to something like ³6LoWPAN (e.g. adaptation,
> header compression)²
>
> -> added
>
> €         pp.9, the 4th paragraph, ³join process² was introduced all of a
> €         pp.9, 3rd paragraph, ³TEAS protocol will be required to expose
> PCE, to the devices.²
> €         Can you put the reference about ³TEAS² and ³CCAMP²?
>
> €         pp.10, 2nd paragraph, ³should be portable only other LLN link
> types². It reads a little awkward and maybe some words missing around
> ³only²
>
> €         pp.10, 2nd paragraph, ³A new version of the standard is
>expected
> in 2015². What¹s ³the standard² refer to?
>
> -> clarified as follows
>
> €         pp.10, 4th paragraph, do you want to add a reference for
> ISA100.20?
>
> -> there¹s no good link. I added a link to ISA100, and explained what CNM
> is.
>
>
> €         pp.16, 4th paragraph, ³motes² was used. Can we change it to
> €         pp.17, 2nd paragraph, ³but also allows an upper layer like
>RPL.²
> €         pp.18, 2nd paragraph, ³that is is not capable of². One ³is²
> should be removed.
>
> -> ack
>
> €         pp.19, the last paragraph, ³an higher layer² ---> ³a higher
> layer²
> -> ack
>
> €         pp.19, the last paragraph, ³DSCP can therefore be used².
>Suggest
> -> I used ŒDifferentiated Services [RFC2474]¹ instead
>
> €         pp.19, 5th paragraph, ³A 6TISCH Instance is associated to one
> slotFrame.²,
>
> -> that¹s really a 6top internal. Much too detailed, I removed the
> sentence.
>
> €         Wonder what is a 6TiSCH Instance? Why associate to only ³one²
> Slotframe? In previous paragraph, it mentions ³Multiple slotFrames can
> coexist in a node schedule².
>
> €         pp.21, section 9, both ³Static Scheduling² and ³Minimal Static
> Scheduling² are used. Are they the same?
>
> €         pp.22, 1st paragraph, ³This scheduled can be² ---> ³This
> schedule can be²
>
> -> gone
>
> €         pp.24, section 10.1, 1st paragraph, ³A bundle of cells set to
> used regardless of the network layer protocol.²
> €         Is a Track uni-directional or bi-directional? Is there any ACK
> for the transmission?
>
> -> I added
>
> €         pp.27, Figure 6, suggest adding what is the value ³set dmac to²
> and ³restore dmac²
>
> -> done
>
> €         pp.27, section 10.1.3, 1st paragraph, ³If the tunnel egress
> Track installation fails.²,
> €         Wonder if it is ingress point or egress point that installs the
> Track
>
> €         pp.30, 1st paragraph, ³Centralized routes can for example
> computed². The word ³be² was missing.
>
> fixed
> €         pp.30, section 11, it will be helpful if the difference between
> the join process work is looking at that. Then there¹s RPL use of slotted
> aloha slots. Then there¹s the resource allocation problem (chunks between
> parents and cells in a parent¹s chunk between children). We¹ll recharter
>Terminology
> Well, that¹s a WG now, unsure what the standard name will be. I can add
> the following text:
> ³        DTLS In Constrained Environments (DICE) is at the time of this
>          UDP/CoAP packets.²
> I agree with all Guillaume¹s suggested edits. Changes:
>
>Ticket URL: 
><http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35#comment:1>
>[email-masked]

---

From: "S.V.R. Anand" <[email-masked]>
Date: Fri, 24 Apr 2015 11:27:20 +0530

Hi,

As my observation on the possibility of including 
application-in-the-loop as part of the architecture appears
along with the list of other comments, I guess it may be considered in 
the subsequent editions of the draft,
if found important. If it has already been addressed in the present 
draft itself, perhaps I would have missed
the relevant text !

There are no other comments from my side.

Anand

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Apr 2015 07:48:02 +0000

Hello Anand:

Anything we add to the daft must be discussed and agreed upon in the calls and the ML.
So I cannot just add stuff now, but please introduce the discussion to the ML for volume 2!

Cheers,

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of S.V.R. Anand
> Sent: vendredi 24 avril 2015 07:57
> To: [email-masked]
> Subject: Re: [6tisch] #35 (architecture): Last call comments: editorial
> 
> Hi,
> 
> As my observation on the possibility of including application-in-the-loop as part
> of the architecture appears along with the list of other comments, I guess it may
> be considered in the subsequent editions of the draft, if found important. If it
> has already been addressed in the present draft itself, perhaps I would have
> missed the relevant text !
> 
> > With -07 the authors and I (as the shepherd of this draft) believe all
> > the comments have been addressed.
> > I will close this ticket and proceed with the submission of the draft
> > for IESG review by end of this week (25th April). Please respond if
> > you think there are unaddressed comments.
> >
> > Thanks,
> > Shwetha
> >
> >> few places. Better use one form if they mean the same thing
> >> throughout the draft.
> >> centralized fashion by a Path Computation Element (PCE), in a
> >> distributed fashion using the Routing Protocol for Low Power and
> >> Lossy Networks (RPL) [RFC6550], or in a mixed mode²,
> >> non-storing mode, the root calculates the route and use source
> >> routing to route the packet to the destination.
> >> architecture derive from existing industrial standards for Process
> >> Control by its focus on Deterministic Networking, in particular with
> >> the use of the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized
> >> PCE.²
> >> is correct but it could imply that only HC is used there  which is
> >> not true. Suggest changing 6LoWPAN HC to something like ³6LoWPAN (e.g.
> >> these concepts (e.g. neighbor discovery, join process, track
> >> reservation, 6top, packet forwarding, etc.) together and their
> >> relationship from architectural perspective somewhere in Section 4
> >> (e.g. at the beginning?).
> >> formats and procedures will be used to publish the tracks, computed
> >> by the PCE, to the devices.²
> >> Suggest giving the full spelling and reference to DSCP or removing
> >> this sentence.
> >> Slotframe? In previous paragraph, it mentions ³Multiple slotFrames
> >> can coexist in a node schedule².
> >> receive (RX-cells) is uniquely paired to a bundle of cells that are
> >> set to transmit (TX-cells), representing a layer-2 forwarding state
> >> that can be used regardless of the network layer protocol.²
> >> width, and after the timeslot duration (in the current version
> >> timeslot duration is in the middle, and it makes a bit hard to read
> >> and clearly understand the CDU matrix structure)
> >> we will have evaluated PANA applicability? we may need/want to
> >> publish the second part of the architecture before that, we don¹t
> >> know yet. So, we could skip that, if you agree.
> >>>
> >>> ----
> >>>
> >>> Rouhollah:
> >>>
> >>> 9.2 p22 the relocation of a soft cell / relocation is done => I am
> >>> not sure if there has been a discussion on this term, but I
> >> vote
> >> for reallocation.
> >>> 2) 8.2 p16 a set of quality metrics (RSSI, LQI) I think you cannot
> >>> be specific to just two metrics (RSSI, LQI).
> >>> 3) 8.2 p16 and used to compute a Rank Increment The statistics of
> >>> 6top may have other usages than incrementing the
> >> joining is not providing any benefit. We should always use
> >> authentication, even if the key is not secret, as it provides the
> >> ability to reject similar frames from other 802.15.4-based protocols.
> >> It also isn¹t necessary to discuss such a detail here.
> >>> 13.1  -
> >> The list of commits is in
> >> page 19 in the definition of CDU matrix, I would specify height and
> >> width, and after the timeslot duration (in the current version
> >> timeslot duration is in the middle, and it makes a bit hard to read
> >> and clearly understand the CDU matrix structure)
> >>
> >> -> text now reads:
> >>           6TiSCH architecture defines a global concept that is called
> >> a Channel
> >>           (indexed by ChannelOffsets) and a width (in timeSlots) that
> >> is the
> >>           accommodate for the transmission of a frame and an ack,
> >> including the
> >>           security validation on the receive side which may take up
> >> to a few
> >> pag 7 are we sure we want to mention in the next round of the
> >> document we will have evaluated PANA applicability? we may need/want
> >> to publish the second part of the architecture before that, we don¹t
> >> know yet. So, we could skip that, if you agree.
> >>
> >>        Future work on 6TiSCH security and will examine in deeper
> >> detail how SACM,
> >>        ACE, DICE, IEEE802.15.9 and eventually PANA and 802.1x may
> >> apply to 6TiSCH
> >>        networks to perform Authentication and Authorization, to
> >> secure transactions
> >>        end-to-end, and to maintain the  security posture of a device
> >> over its lifetime.
> >>        The result of that work will be described in a subsequent
> >> volume of this
> >>         architecture.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -> Actually I think the group settled for TimeSlotted, I migrated all
> >> -> to
> >> that
> >>
> >> places. Better use one form if they mean the same thing throughout
> >> the draft.
> >>
> >> -> Done, I used the uppercase because our Deterministic is not the
> >> -> one
> >> from math
> >>
> >> centralized fashion by a Path Computation Element (PCE), in a
> >> distributed fashion using the Routing Protocol for Low Power and
> >> Lossy Networks (RPL) [RFC6550], or in a mixed mode²,
> >> non-storing mode, the root calculates the route and use source
> >> routing to route the packet to the destination.
> >>
> >> -> I see what you are saying. I agree that storing mode centralized
> >> -> the
> >> computation of routes down but that¹s based on a parent selection
> >> that is still distributed. I do not think that being very specific
> >> like ³RPL is mostly distributed but then there can be a bit of
> >> centralized computation² will help a lot the understanding of the
> >> section. I¹d rather leave it at that.
> >>
> >> architecture derive from existing industrial standards for Process
> >> Control by its focus on Deterministic Networking, in particular with
> >> the use of the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized
> >> PCE.²
> >> Suggest changing 6LoWPAN HC to something like ³6LoWPAN (e.g.
> >> sudden. Wonder if it could read more smoothly by briefly mentioning
> >> these concepts (e.g. neighbor discovery, join process, track
> >> reservation, 6top, packet forwarding, etc.) together and their
> >> relationship from architectural perspective somewhere in Section 4
> >> (e.g. at the beginning?).
> >>
> >> -> will be hard without duplicating a lot; let me think of that one.
> >> -> In
> >> formats and procedures will be used to publish the tracks, computed
> >> by the PCE, to the devices.²
> >>           (maybe running over CoAP as illustrated) will be required
> >> to expose the
> >>           computed by the PCE, to the devices (maybe in a fashion
> >> similar to RSVP-TE).
> >>
> >> -> there¹s no good link. I added a link to ISA100, and explained what
> >> -> CNM
> >> is.
> >>
> >>
> >>        ISA100 <xref target="ISA100"/> Common Network Management (CNM)
> >> is another
> >>        external work of interest for 6TiSCH. The group, referred to
> >> as ISA100.20,
> >>        are also in scope, and ISA100.20 is working on requirements
> >> for DetNet.
> >>
> >>              6top takes this way to establish broadcast channel,
> >> which not only
> >>              allows TSCH to broadcast Enhanced Beacons, but also
> >> allows protocol
> >> Slotframe? In previous paragraph, it mentions ³Multiple slotFrames
> >> can coexist in a node schedule².
> >>
> >> -> removed minimal. Intention was to say that this is the minimal
> >> -> support
> >>
> >> receive (RX-cells) is uniquely paired to a bundle of cells that are
> >> set to transmit (TX-cells), representing a layer-2 forwarding state
> >> that can be used regardless of the network layer protocol.²
> >>              acknowledgment may be omitted in some cases, for
> >> instance if there
> >> I think the text is correct. The configuration of the tunnel is yet
> >> TBD by this group (RSVP-TE?), but the egress must be able to deliver
> >> a packet to the MAC address that is at the end of the tunnel.
> >>
> >> routing discussed in this section and forwarding discussed in section
> >> 10 could be clarified a little bit
> >>
> >> Added
> >>          By forwarding, this specification means the per-packet
> >> operation that
> >>           allows to deliver a packet to a next hop or an upper layer
> >> in this node.
> >> the join process work is looking at that. Then there¹s RPL use of
> >> slotted aloha slots. Then there¹s the resource allocation problem
> >> (chunks between parents and cells in a parent¹s chunk between
> >> children). We¹ll recharter for all these things but the first volume
> >> of the architecture does not cover that.
> >>
> >> Well, that¹s a WG now, unsure what the standard name will be. I can
> >> add the following text:
> >> -------------------------+-------------------------------------------
> >> -------------------------+-----
> >> -
> >> -------------------------+-------------------------------------------
> >> -------------------------+-----
> >> -
> >>
> >> Ticket URL:
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>

---

From: "Wang, Chonggang" <[email-masked]>
Date: Fri, 24 Apr 2015 13:24:46 +0000

Hi Shwetha,

I do not have further comments.

Thanks,
Chonggang

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, April 23, 2015 1:11 AM
To: 6tisch issue tracker; [email-masked]; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tisch] #35 (architecture): Last call comments: editorial

Hello Reviewers,

With -07 the authors and I (as the shepherd of this draft) believe all the comments have been addressed.
I will close this ticket and proceed with the submission of the draft for IESG review by end of this week (25th April). Please respond if you think there are unaddressed comments.

Thanks,
Shwetha

On 4/7/15 9:07 PM, "6tisch issue tracker" <[email-masked]>
wrote:

> few places. Better use one form if they mean the same thing throughout
>the  draft.
> distributed fashion using the Routing Protocol for Low Power and Lossy
> Networks (RPL) [RFC6550], or in a mixed mode²,
> non-storing mode, the root calculates the route and use source routing
>to  route the packet to the destination.
>formats and procedures will be used to publish the tracks, computed by
>the  PCE, to the devices.²
> > document
> we will have evaluated PANA applicability? we may need/want to publish
>the  second part of the architecture before that, we don¹t know yet.
>So, we  could skip that, if you agree.
> >
> >
> > ----
> >
> > Rouhollah:
> >
>          security validation on the receive side which may take up to
>a  few
> we will have evaluated PANA applicability? we may need/want to publish
> the second part of the architecture before that, we don¹t know yet.
> So, we could skip that, if you agree.
>
>       Future work on 6TiSCH security and will examine in deeper detail
>how  SACM,
>       ACE, DICE, IEEE802.15.9 and eventually PANA and 802.1x may apply
>to  6TiSCH
>       The result of that work will be described in a subsequent volume
>of  this
>        architecture.
>
>
>
>
>
>
>
> distributed fashion using the Routing Protocol for Low Power and Lossy
> Networks (RPL) [RFC6550], or in a mixed mode²,
> non-storing mode, the root calculates the route and use source routing
> to route the packet to the destination.
>
> computation of routes down but that¹s based on a parent selection that
>is  still distributed. I do not think that being very specific like
>³RPL is  mostly distributed but then there can be a bit of centralized
>computation²  will help a lot the understanding of the section. I¹d
>rather leave it at  that.
>
>formats and procedures will be used to publish the tracks, computed by
>the  PCE, to the devices.²
>             6top takes this way to establish broadcast channel, which
> not only
>             acknowledgment may be omitted in some cases, for instance
> if there
>TBD by  this group (RSVP-TE?), but the egress must be able to deliver a
>packet to  the MAC address that is at the end of the tunnel.
>
>-------------------------+---------------------------------------------
>-------------------------+---------------------------------------------

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 24 Apr 2015 13:30:41 +0000

Hi Shwetha,
I also do not have any more comments.
Best regards,
Maria Rita

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Wang, Chonggang
Sent: Friday, April 24, 2015 3:25 PM
To: 'Shwetha Bhandari (shwethab)'; '6tisch issue tracker'; [email-masked]'; 'Pascal Thubert (pthubert)'
Cc: [email-masked]'
Subject: Re: [6tisch] #35 (architecture): Last call comments: editorial

Hi Shwetha,

Thanks,
Chonggang

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, April 23, 2015 1:11 AM
To: 6tisch issue tracker; [email-masked]; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tisch] #35 (architecture): Last call comments: editorial

Hello Reviewers,

Thanks,
Shwetha

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 24 Apr 2015 10:38:59 -0300

Swetha,
           I also don't have any further comments.
Regards,

                       Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Guillaume Gaillard <[email-masked]>
Date: Fri, 24 Apr 2015 15:51:18 +0200

Hello Shwetha,
My comments are addressed in version -07.
Regards,
Guillaume

2015-04-24 15:38 GMT+02:00 Prof. Diego Dujovne <[email-masked]>:

> 2015-04-24 10:24 GMT-03:00 Wang, Chonggang <
> [email-masked]>:
>
> Hi Shwetha,
>>