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

["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