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

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

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.