Subject: Re: [6tisch] Early IoT-Dir review of draft-ietf-6tisch-architecture-19

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Mar 2019 16:59:58 +0100

Working backwards…. I like this text.

> On 28 Feb 2019, at 11:50, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello again Eliot
> 
> In response to your suggestion to introduce bundles etc… in section 3, here’s the proposed (modified) text:
> 
> 
> 3.3.  Scheduling TSCH
> 
>    A scheduling operation attributes cells in a Time-Division-
>    Multiplexing (TDM) / Frequency-Division Multiplexing (FDM) matrix
>    called the Channel distribution/usage (CDU) to either individual
>    transmissions or as multi-access shared resources.  The CDU matrix
>    can be formatted in chunks that can be allocated exclusively to
>    particular nodes to enable distributed scheduling without collision.
> 
>    From the standpoint of a 6TiSCH node (at the MAC layer), its schedule
>    is the collection of the timeslots at which it must wake up for
>    transmission, and the channels to which it should either send or
>    listen at those times.  The schedule is expressed as one or more
>    slotframes that repeat over and over.  Slotframes may collide and
>    require a device to wake up at a same time, in which case a the
>    slotframe with the highest priority is actionable.
> 
>    Scheduling enables multiple communications at a same time in a same
>    interference domain using different channels; but a node equipped
>    with a single radio can only either transmit or receive on one
>    channel at any point of time.  Scheduled cells that play an equal
>    role, e.g., receive IP packets from a peer, are grouped in bundles.
> 
>    The 6top sublayer hides the complexity of the schedule from the upper
>    layers.  The Link that IP may utilize between the 6TiSCH node and a
>    peer is composed of a pair of Layer-3 cell bundles, one to receive
>    and one to transmit.  Some of the cells may be shared, in which case
>    the 6top sublayer must perform some arbitration.
> 
> 
> All the best,
> 
> Pascal
> 
> From: Pascal Thubert (pthubert)
> Sent: mardi 26 février 2019 15:08
> To: 'Eliot Lear' <[email-masked] <mailto:[email-masked]>>; iot-dir <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Suresh Krishnan <[email-masked] <mailto:[email-masked]>>
> Cc: Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>>; CARLOS JESUS BERNARDOS CANO <[email-masked] <mailto:[email-masked]>>
> Subject: RE: Early IoT-Dir review of draft-ietf-6tisch-architecture-19
> 
> Hello Eliot
> 
> Many thanks for your early review! And yes, I agree that a smaller committee is great to clean up the major aspects before opening to the wider public.
> 
> Please see below (in purple in the text):
> 
> First, the good.
> 
> I commend you on using the early review option!  This provides you the opportunity to consider substantial changes prior to garnered consensus, saving you lots of time and energy.
> 
> You have much of the content that is necessary to explain the architecture.  In several reads I became confident that much of this will actually work.  Clearly the approach is quite flexible to support a great many deployments.  It seems to me you have identified all the right building blocks.
> 
> Ø   Yes, and we have built it (2 open source plus a major private implementations) and interop tested it (with ETSI) over the recent years : )
> 
> Major issues
> 
> The bad.  It took me several reads over a week to really get it, and I was trying.
> This document introduces a great many concepts.  It is not clear to me that they should all be introduced in one document.  As a test, ask yourself this question: what would the reader lose if you did not include Section 4.4.3?  If you are going to introduce all of these concepts, then you need to pay a bit more attention to the organization.  Your hint that you have a problem in this regard is your table of contents: you are spending roughly 12 pages to describe what you label as “High Level Architecture”.  Section 3 needs to be sufficiently succinct that it fits into Section 1.  Otherwise it must be combined into Section 4, which in turn could be broken up into major sections.  I also would have expected something of a mapping between Sections 3 and 4: that is, high level in one, details in the other.  But that’s not really what we get.  Section 3.7 and 3.8 feel as though it really belongs in Section 4.
> Section 4.4.3 positions the future work at PAW. This is what enables the “deterministic thing” and is the major mode of operation in the pre-6tisch art of process control network. We could not really ignore it. The split with a high level architecture is a result of a review by Ralph long ago. Ralph expected a succinct high level architecture and the doc with section 3 and 4 as one was too deep and wide. I agree with you that 3.7 and 3.8 could move to section 4, this would reduce section 3 down to 8 pages and get us closer to what Ralph expected I guess.
> The outlook of the ToC would then be:
>    2.  Terms and References  . . . . . . . . . . . . . . . . . . . .   4
>      2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   4
>      2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
>      2.3.  References  . . . . . . . . . . . . . . . . . . . . . . .  10
>      2.4.  Subset of a 6LoWPAN Glossary  . . . . . . . . . . . . . .  11
>    3.  High Level Architecture . . . . . . . . . . . . . . . . . . .  12
>      3.1.  6TiSCH Stack  . . . . . . . . . . . . . . . . . . . . . .  12
>      3.2.  TSCH: A Deterministic MAC Layer . . . . . . . . . . . . .  14
>      3.3.  Scheduling TSCH . . . . . . . . . . . . . . . . . . . . .  14
>      3.4.  Routing and Forwarding Over TSCH  . . . . . . . . . . . .  16
>      3.5.  A Non-Broadcast Multi-Access Radio Mesh Network . . . . .  17
>      3.6.  A Multi-Link Subnet Model . . . . . . . . . . . . . . . .  19
>    4.  Architecture Components . . . . . . . . . . . . . . . . . . .  20
>      4.1.  6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . .  20
>        4.1.1.  RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . .  21
>        4.1.2.  RPL Root And 6LBR . . . . . . . . . . . . . . . . . .  21
>      4.2.  Network Access and Addressing . . . . . . . . . . . . . .  22
>        4.2.1.  Join Process  . . . . . . . . . . . . . . . . . . . .  22
>        4.2.2.  Registration  . . . . . . . . . . . . . . . . . . . .  24
>      4.3.  TSCH and 6top . . . . . . . . . . . . . . . . . . . . . .  26
> 
> Works?
> 
> 
> 
> 
> While there are some illustrations, there are not any examples of how this stuff is intended to function in practice.  I will readily concede that examples are hard to write and get right, but they’re still important, and perhaps nowhere more-so with your AND and OR discussion in Section 4.7.2.  My suggestion is that you seriously consider the validity of any component that you cannot show an example for.  I think visualising schedules in several instances would help, for example.
> will do, but that will take time and I do not want to hold my answer : )
> You have quite a number of groupings and disparate explanations of them.  In this document alone you have cells, slots, slot frames, bundles, tracks, and packets.  These are fundamental to your architecture.  There needs to be a single section that introduces these, and shows how they fit together.  It is not necessary in this introductory session to detail every aspect of these groupings, but simply to show their relationship to one another.  You have a lot of the right diagrams in Sections 3 and 4, but one wants to understand the big picture before delving into the components.
> I can do that too, and place text in section 2 or 3. There is a difficult tension between the desire to shrink those sections that you expressed earlier and the request you’re making here.
> Sections 2.2, 2.3, and 2.4 should be combined and reduced.  Keep in mind that the style of the IETF is to define on first use.  What you want to avoid is the reader having to continuously flip back to the glossary.  People aren’t reading this stuff on paper anymore.  You might think this a minor issue.  However, what you have told me, your dear reader, in Section 2.3 in particular is that I am unlikely to understand this architecture without having a full understanding of a year’s worth of reading, when that’s clearly not the case.
> Problem there. We were asked to merge the 6TiSCH terminology document https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10 <https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10>  into the architecture to save RFC numbers and IESG cycles. We already used “define on first use” but the terminology was also useful when coming back to the doc or not reading it serially, as well as when reading another draft from the WG. I can move it to the appendix if that looks better, but I do not think we should eliminate or shrink dramatically what used to be a WG document just like that. We could try to convince Suresh (cc)  to resplit but there is little hope.
> ·        To this end, you should include in your introduction something like Figure 4 that introduces the components.  You might also state some of the operating assumptions of the devices involved, and focus on a few use cases as to how it would be applied (see examples above).
> Will do; I’ll come back to you when I have progressed on all the above and probably published a rev so you can diff through easily. Note that again, this goes against a desire for increased conciseness. My understanding of what you describe looks a lot like a full book on 6TiSCH. I have no time to write that, I would if I did, and the reader is probably not expecting that from an IETF specification
> Minor issues
> You are referencing BCP 14 but not really using it.  If you are referencing it to explain that you do not mean to be making normative statements, I think it is best to plainly say just that.
> It’s a nits thingy since we are going for std track. I’ll let the IESG sort that out with the DetNet architecture and will mimic when they are done.
> In Section 4.6, figures 12, 13, and 14: these diagrams are a bit too abstract. Please add the components and label what is being sent between them.
> I realise you probably didn’t originate the term but Join Registrar/Coordinator (JRC) is an odd acronym.  Is this intended to be two architectural components combined into one or just a bit of terminology indecision on the part of the designers ;-)?
> In Section 4.2.5, you write:
>    In order to ensure that the medium is free of
>    contending packets when time comes for a scheduled transmission, a
>    window of time is defined around the scheduled transmission where the
>    medium must, as much as practcally feasible, be free of contending
>    energy.
> ·       It is probably worth stating this in terms of whose responsibility it is to find that quiet frequency (thenode’s, right?).  One question this raises is how much energy the node must consume to do that search, the architectural assumption being that it can do so efficiently.
> 
> This really depends on the “Schedule Management Mechanism”. The optimal is when a central controller owns hard cells and assigns them, in that case the node is a slave and does not consume energy for scanning. Else the use of chunks reduces the space where a node needs to scan for activity.
> I suggest adding the marked text below (note that section 4.4 is now 4.5 after moving pieces of section 3 in section 4:
> 4.3.5.  SlotFrames and CDU matrix
> 
>    6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC
>    layer that is also capable of scheduled (deterministic)
>    transmissions.  In order to ensure that the medium is free of
>    contending packets when time comes for a scheduled transmission, a
>    window of time is defined around the scheduled transmission where the
>    medium must, as much as practically feasible, be free of contending
>    energy.
> 
>    One simple way to obtain such a window is to format time and
>    frequencies in cells of transmission of equal duration.  This is the
>    method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long
>    Term Evolution (LTE) of cellular networks.
> 
>    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 defined
>    centrally as part of the network definition.  It 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.  There are different models for scheduling the usage of the
>    cells, which place the responsibility of avoiding collisions either
>    on a central controller or on the devices themselves, at an extra
>    cost in terms of energy to scan for free cells (more in Section 4.5).
> 
> 
> Nits:
> 
> There are more nits than these, but this is a start.
> 
> Definitions:
> 
> Layer-2 vs. Layer 3 bundle:
> 
>               a Layer-3 bundle pair maps
> s/a Layer-3 bundle pair maps/A Layer-3 bundle maps/
> 
> o    I meant a pair of bundles. Reworded below:
> 
> 
> 
>    Layer-2 vs. Layer-3 bundle:  Bundles are associated for either
>                Layer-2 (switching) or Layer-3 (routing) forwarding
>                operations.  A pair of Layer-3 bundles (one for each
>                direction) maps to an IP Link with a neighbor, whereas a
>                set of Layer-2 bundles (a number per neighbor, either
>                from or to the neighbor) corresponds to the relation of
>                one or more incoming bundle(s) from the previous-hop
>                neighbor(s) with one or more outgoing bundle(s) to the
>                next-hop neighbor(s) along a Track.
> 
> Cell:
>        A single element in the TSCH schedule
> My suggestion is that you be more explicit: don’t use the word “element”.  Perhaps something like this: “A period of time in the TSCH schedule set aside for data transmission that is identified by…
> 
> o   It is really a cell in the CDU matrix identified by channeloffset and slotoffset. What about:
> 
>    cell:       A unit of transmission resource in the CDU matrix, a cell
>                is identified by a slotOffset and a channelOffset.  A
>                cell can be scheduled or unscheduled.
> 
> 
> channelOffset:
> 
> Does a channelOffset necessarily imply channel hopping?  What happens if the offset remains constant across a row?
> 
> o   It is really a cell in the CDU matrix identified by channeloffset and slotoffset. What about:
> 
>    channelOffset:  Identifies a row in the TSCH schedule.  The number of
>                channelOffset values is bounded by the number of
>                available frequencies.  The channelOffset translates into
>                a frequency with a function that depends o the absolute
>                time when the communication takes place, resulting in a
>                channel hopping operation.
> 
> 
> 
> 
> Hard cell:
>        A scheduled cell which the 6top sublayer cannot relocate
> “Cannot” means it is beyond its means to do so.  I think you mean “may not”.
> o   done
> 
> 
> Track:
> Expand DODAG-> Destination Oriented Directed Acyclic Graph
> o   proposal:
> 
> 
> 
>    Track:      A Track is a Directed Acyclic Graph (DAG) that is used as
>                a complex multi-hop path to the destination(s) of the
>                path.  In the case of unicast traffic, the Track is a
>                Destination Oriented DAG (DODAG) where the root of the
>                DODAG is the destination of the unicast traffic.  A Track
>                enables replication, elimination and reordering functions …
> 
> 
> Section 3.6, 1st para:
>        This architecture requires work to standardize the the
> s/the the/the/
> o   done
> 
> 
> 
> Section 4.1
> 
> First para, s/Root/root/, as used in RFC 6550.
> o   done
> 
> 
> 
> Section 4.2:
>    As a result of the process of chunk ownership appropriation, the RPL
>    parent has exclusive authority to decide which cell in the
>    appropriated chunk can be used by which node in its interference
>    domain.  In other words, it is implicitly delegated the right to
>    manage the portion of the CDU matrix that is represented by the
>    chunk.  The RPL parent may thus orchestrate which transmissions occur
>    in any of the cells in the chunk, by allocating cells from the chunk
>    to any form of communication (unicast, multicast) in any direction
>    between itself and its children.
> 
> This twice-redundant.  I can understand reinforcing the point.  My suggestion: drop the last sentence.
> 
> o   done
> 
> 
> 
> Section 4.5.5:
> 
> Formatting issues.  If you are quoting text, please source your quote.  Otherwise, do not indent.  Also...
>       In one hand, a
> Just remove that.
> o   done
> 
> 
> Same para below:
>        It results that a frame
> s/It results that a frame/It results in a frame/
> o   done, twice
> 
> 
> 
> 
> Section 4.7.2:
> This sentence does not parse:
>    As it goes, 6TiSCH expects that timeslots corresponding to copies of
>    a same packet along a Track are correlated by configuration, and does
>    not need to process the sequence numbers.
> Who does not need to process sequence #s?  Be specific.
> 
> 
> o    In DetNet Packet Replication and Elimination Function (PREF), multiple copies of a packet can be received and duplicates can be recognized and eliminated because they have the same sequence number.
> 
> o   What about
> 
> 4.8.2.  Replication, Retries and Elimination
> 
>    6TiSCH supports the PREOF operations of elimination and reordering of
>    packets along a complex Track, but has no requirement about whether a
>    sequence number would be tagged in the packet for that purpose.  With
>    6TiSCH, the schedule can tell when multiple receive timeslots
>    correspond to copies of a same packet, in which case the receiver may
>    avoid listening to the extra copies once it had received one instance
>    of the packet.
> 
> 
> 
>    The semantics of the configuration will enable correlated timeslots
>    to be grouped for transmit (and respectively receive) with a 'OR'
>    relations, and then a 'AND' relation would be configurable between
>    groups.
> s/with an ‘OR’/with an ‘OR’/
> s/with an ‘AND’/with an ‘AND’/
> o   done, for both
> 
> 
>    The 'OR' relation
>    indicates that if a transmission is acknowledged, then further
>    transmissions should not be attempted for timeslots in that group.
> s/acknowledged, then further transmissions/acknowledged.  In this case,/
> 
> o   done
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Mar 2019 17:00:24 +0100

I like this text.  Thank you.

> On 28 Feb 2019, at 11:34, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear Eliot and all:
> 
> For the AND/OR discussion, I propose the following example:
> 
>   As an example say that we have a simple network as represented in
>    Figure 17, and we want to enable PREOF between an ingress node I and
>    an egress node E.
> 
>                               +-+         +-+
>                            -- |A|  ------ |C| --
>                          /    +-+         +-+    \
>                        /                           \
>                   +-+                                +-+
>                   |I|                                |E|
>                   +-+                                +-+
>                        \                           /
>                          \    +-+         +-+    /
>                            -- |B| ------- |D| --
>                               +-+         +-+
> 
>               Figure 17: Scheduling PREOF on a Simple Network
> 
>    The assumption for this particular problem is that a 6TiSCH node has
>    a single radio, so it cannot perform 2 receive and/or transmit
>    operations at the same time, even on 2 different channels.
> 
>    Say we have 6 possible channels, and at least 10 timeslots per
>    slotframe.  Figure 18 shows a possible schedule whereby each
>    transmission is retried 2 or 3 times, and redundant copies are
>    forwarded in parallel via A and C on the one hand, and B and D on the
>    other, providing time diversity, spatial diversity though different
>    physical paths, and frequency diversity.
> 
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 0 |    |    |    |    |    |    |B->D|    |    | ...
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 1 |    |I->A|    |A->C|B->D|    |    |    |    | ...
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 2 |I->A|    |    |I->B|    |C->E|    |D->E|    | ...
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 3 |    |    |    |    |A->C|    |    |    |    | ...
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 4 |    |    |I->B|    |    |B->D|    |    |D->E| ...
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset 5 |    |    |A->C|    |    |    |C->E|    |    | ...
>                     +----+----+----+----+----+----+----+----+----+
>        slotOffset      0    1    2    3    4    5    6    7    9
> 
> 
>                     Figure 18: Example Global Schedule
> 
>    This translates in a different slotframe for every node that provides
>    the waking and sleeping times, and the channelOffset to be used when
>    awake.  Figure 19 shows the corresponding slotframe for node A.
> 
> 
>                     +----+----+----+----+----+----+----+----+----+
>     channelOffset   |CO 2|CO 1|CO 5|CO 1|CO 3|    |    |    |    | ...
>                     +----+----+----+----+----+----+----+----+----+
>        slotOffset      0    1    2    3    4    5    6    7    9
> 
> 
>                     Figure 19: Example Node A slotframe
> 
>    In that example, the logical relationship between the timeslots is:
> 
> 
>                +------+---------------------+------------------------+
>                | Node |    rcv slotOffset   |    xmit slotOffset     |
>                +------+---------------------+------------------------+
>                | I    |         N/A         | (0 OR 1) AND (2 OR 3)  |
>                | A    |       (0 OR 1)      |     (2 OR 3 OR 4)      |
>                | B    |       (2 OR 3)      |     (4 OR 5 OR 6)      |
>                | C    |    (2 OR 3 OR 4)    |        (5 OR 6)        |
>                | D    |    (4 OR 5 OR 6)    |        (7 OR 8)        |
>                | E    |  (5 OR 6 OR 7 OR 8) |          N/A           |
>                +------+---------------------+------------------------+
> 
> 
>                       Figure 20: Logical Relationship
> 
> 
> 
> All the best,
> 
> Pascal
> 
> To: 'Eliot Lear' <[email-masked]>; iot-dir <[email-masked]>; [email-masked]; [email-masked]; Suresh Krishnan <[email-masked]>
> Cc: Carlos Pignataro (cpignata) <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Mar 2019 17:09:57 +0100

> On 26 Feb 2019, at 15:08, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Eliot
> 

I think Ralph and I were agreeing in principle, then.
>      4.3.  TSCH and 6top . . . . . . . . . . . . . . . . . . . . . .  26

The only real issue is whether Sections 1 and 3 can be combined, and I would not stand on my head on it.  The key thing is to make sure that people can gain a clear understanding of what the architecture is trying to achieve in Section 1, and then how it does so.  The closer those two textual components are at the high level, the better you will be.  But that’s just me, and others may see this differently, and it is general (non-IoT) advice.

> I can do that too, and place text in section 2 or 3. There is a difficult tension between the desire to shrink those sections that you expressed earlier and the request you’re making here.

You addressed this, I think in the other email.
> Problem there. We were asked to merge the 6TiSCH terminology document https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10 <https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10>  in…

My suggestion is still to consolidate Terminology and Glossary.  References don’t go in the front.

> It’s a nits thingy since we are going for std track. I’ll let the IESG sort that out with the DetNet architecture and will mimic when they are done.

I don’t think you intend this draft to be normative.  By saying that clearly, you will save potential confusion; as in when in doubt, go find the normative reference.

>    cost in terms of energy to scan for free cells (more in Section 4.5).

ok.

> s/acknowledged, then further transmissions/acknowledged.  In this case,/

Ok

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Mar 2019 16:41:25 +0000

Hello Eliott

All the best,

Pascal

From: Eliot Lear <[email-masked]>
Sent: jeudi 7 mars 2019 17:10
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: iot-dir <[email-masked]>; [email-masked]; [email-masked]; Suresh Krishnan <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>
Subject: Re: Early IoT-Dir review of draft-ietf-6tisch-architecture-19

On 26 Feb 2019, at 15:08, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Eliot

First, the good.

>    Yes, and we have built it (2 open source plus a major private implementations) and interop tested it (with ETSI) over the recent years : )

Major issues

  *   This document introduces a great many concepts.  It is not clear to me that they should all be introduced in one document.  As a test, ask yourself this question: what would the reader lose if you did not include Section 4.4.3?  If you are going to introduce all of these concepts, then you need to pay a bit more attention to the organization.  Your hint that you have a problem in this regard is your table of contents: you are spending roughly 12 pages to describe what you label as “High Level Architecture”.  Section 3 needs to be sufficiently succinct that it fits into Section 1.  Otherwise it must be combined into Section 4, which in turn could be broken up into major sections.  I also would have expected something of a mapping between Sections 3 and 4: that is, high level in one, details in the other.  But that’s not really what we get.  Section 3.7 and 3.8 feel as though it really belongs in Section 4.

     *   Section 4.4.3 positions the future work at PAW. This is what enables the “deterministic thing” and is the major mode of operation in the pre-6tisch art of process control network. We could not really ignore it. The split with a high level architecture is a result of a review by Ralph long ago. Ralph expected a succinct high level architecture and the doc with section 3 and 4 as one was too deep and wide. I agree with you that 3.7 and 3.8 could move to section 4, this would reduce section 3 down to 8 pages and get us closer to what Ralph expected I guess.

     *
     *   The outlook of the ToC would then be:

     *   Works?

Ø    I’ll keep that in mind for the next round

  *   While there are some illustrations, there are not any examples of how this stuff is intended to function in practice.  I will readily concede that examples are hard to write and get right, but they’re still important, and perhaps nowhere more-so with your AND and OR discussion in Section 4.7.2.  My suggestion is that you seriously consider the validity of any component that you cannot show an example for.  I think visualising schedules in several instances would help, for example.

     *   will do, but that will take time and I do not want to hold my answer : )

  *   You have quite a number of groupings and disparate explanations of them.  In this document alone you have cells, slots, slot frames, bundles, tracks, and packets.  These are fundamental to your architecture.  There needs to be a single section that introduces these, and shows how they fit together.  It is not necessary in this introductory session to detail every aspect of these groupings, but simply to show their relationship to one another.  You have a lot of the right diagrams in Sections 3 and 4, but one wants to understand the big picture before delving into the components.

     *   I can do that too, and place text in section 2 or 3. There is a difficult tension between the desire to shrink those sections that you expressed earlier and the request you’re making here.

     *

  *   Sections 2.2, 2.3, and 2.4 should be combined and reduced.  Keep in mind that the style of the IETF is to define on first use.  What you want to avoid is the reader having to continuously flip back to the glossary.  People aren’t reading this stuff on paper anymore.  You might think this a minor issue.  However, what you have told me, your dear reader, in Section 2.3 in particular is that I am unlikely to understand this architecture without having a full understanding of a year’s worth of reading, when that’s clearly not the case.

     *   Problem there. We were asked to merge the 6TiSCH terminology document https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10  into the architecture to save RFC numbers and IESG cycles. We already used “define on first use” but the terminology was also useful when coming back to the doc or not reading it serially, as well as when reading another draft from the WG. I can move it to the appendix if that looks better, but I do not think we should eliminate or shrink dramatically what used to be a WG document just like that. We could try to convince Suresh (cc)  to resplit but there is little hope.

  *   There I distinction between the externam acronyms that come from outside sources and the 6TiSCH terminology. A merge would make it look like we define 6BBR here, which is not the case. The format used here echoes the one that went through successfully in RFC 8505. People found useful that all this IOT jargon
  *   I see I need to rename section 2.3. It is not a “reference” but a useful reading section. RFC 8505 called it “related documents” and calls terminology “New terms”. Is that better?

     *
•  To this end, you should include in your introduction something like Figure 4 that introduces the components.  You might also state some of the operating assumptions of the devices involved, and focus on a few use cases as to how it would be applied (see examples above).

     *   Will do; I’ll come back to you when I have progressed on all the above and probably published a rev so you can diff through easily. Note that again, this goes against a desire for increased conciseness. My understanding of what you describe looks a lot like a full book on 6TiSCH. I have no time to write that, I would if I did, and the reader is probably not expecting that from an IETF specification

Minor issues

  *   You are referencing BCP 14 but not really using it.  If you are referencing it to explain that you do not mean to be making normative statements, I think it is best to plainly say just that.

     *   It’s a nits thingy since we are going for std track. I’ll let the IESG sort that out with the DetNet architecture and will mimic when they are done.

Ø    I know it looks strange. The original intent was to go for Informational. But discussing the detnet architecture that I also co-author, we found rationale for going standard track, pretty much related to getting an appropriate review level for a doc that concerns outside of IETF bodies like IEEE. The IESG is looking at the case for the detnet architecture now. My take is that this doc should follow the same path for the same reason. Not sure which that will be : )
Many thanks!

Pascal