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

["S.V.R. Anand" <[e-mail]>]

Pascal,

Sure! Agreed.

Anand
________________________________
From: Pascal Thubert (pthubert)<mailto:[e-mail]>
Sent: ‎24-‎04-‎2015 13:18
To: S.V.R. Anand<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [6tisch] #35 (architecture): Last call comments: editorial

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


> -----Original Message-----
> From: 6tisch [mailto:[e-mail]] On Behalf Of S.V.R. Anand
> Sent: vendredi 24 avril 2015 07:57
> To: [e-mail]
> 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 !
>
> There are no other comments from my side.
>
> Anand
>
>
> On 04/23/2015 10:41 AM, Shwetha Bhandari (shwethab) wrote:
> > 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" <[e-mail]>
> > wrote:
> >
> >> #35: Last call comments: editorial
> >>
> >>
> >> Comment (by [e-mail]):
> >>
> >> 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, 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.
> >>>
> >>> ----
> >>>
> >>
> >>
> >> 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:
> >> pag 8 LLN odes -> LLN nodes
> >> pag. 19 6TISCH -> 6TiSCH
> >> pag 23 as started -> has started
> >>
> >> -> 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.
> >>
> >> 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.
> >>
> >> -> 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
> >> 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.
> >>
> >> -> 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
> >> 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.
> >>
> >> -> 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
> >> 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
> >> 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
> >> ---------
> >>
> >> 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?
> >>
> >>> 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.
> >>
> >> 2-Do you think DICE(figure 3. page 7) should be defined in the
> >> Terminology draft.
> >>
> >> 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)
> >> <[e-mail]> wrote:
> >> Hello All,
> >>
> >> Page 7 first paragraph. LLN odes
> >>
> >> ack
> >>
> >> Page 9 end of third paragraph. foster
> >>
> >> 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
> >>
> >> --
> >> -------------------------+-------------------------------------------
> >> -------------------------+-----
> >> -
> >> Reporter:               |       Owner:  draft-ietf-6tisch-
> >>   [e-mail]     |  [e-mail]
> >>      Type:  defect       |      Status:  new
> >> Priority:  minor        |   Milestone:
> >> Component:               |     Version:
> >>   architecture           |  Resolution:
> >> Severity:  In WG Last   |
> >>   Call                   |
> >> Keywords:               |
> >> -------------------------+-------------------------------------------
> >> -------------------------+-----
> >> -
> >>
> >> Ticket URL:
> >> <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35#comment:1>
> >> 6tisch <http://tools.ietf.org/6tisch/>
> >>
> >> _______________________________________________
> >> 6tisch mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/6tisch
> > _______________________________________________
> > 6tisch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch

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