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

[Guillaume Gaillard <[e-mail]>]

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

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

> Swetha,
>            I also don't have any further comments.
> Regards,
>
>                        Diego Dujovne
>
> 2015-04-24 10:24 GMT-03:00 Wang, Chonggang <
> [e-mail]>:
>
> Hi Shwetha,
>>
>> I do not have further comments.
>>
>> Thanks,
>> Chonggang
>>
>> -----Original Message-----
>> From: 6tisch [mailto:[e-mail]] On Behalf Of Shwetha
>> Bhandari (shwethab)
>> Sent: Thursday, April 23, 2015 1:11 AM
>> To: 6tisch issue tracker; [e-mail];
>> Pascal Thubert (pthubert)
>> Cc: [e-mail]
>> 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" <[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
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> 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
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>