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

["Shwetha Bhandari (shwethab)" <[e-mail]>]

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