Subject: Re: [6tisch] Adrian Farrel's No Objection on draft-ietf-6tisch-tsch-05: (with COMMENT)

From: Thomas Watteyne <[email-masked]>
Date: Fri, 6 Mar 2015 13:24:09 +0100

Adrian, Deborah,

Thanks a million for your in-depth review, which is
extremely thorough and constructive. We have integrated your comments into
a new revision (-06) which we will push in the next (very) few days,
together with other comments. The running version is at
https://bitbucket.org/6tisch/draft-ietf-6tisch-tsch/src.

FYI, please find *inline* how we have addressed your comments.

Thomas, Maria Rita, Alfredo

On Sat, Feb 28, 2015 at 8:32 PM, Adrian Farrel <[email-masked]> wrote:

> Adrian Farrel has entered the following ballot position for
> draft-ietf-6tisch-tsch-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-6tisch-tsch/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I don't object to the publication of this document, but I have a
> swathe of Comments that I think you should address before the draft is
> published as an RFC.
>
> Some of these comments arise from Deborah Brungard's review as "AD in
> training".
>
> In general, I found this document a very heavy way of saying "we need an
> adaptation function, and we need a control plane that can determine and
> enforce end-to-end paths subject to timeslot assignment." I don't
> suppose there is anything to be done about that now, but you used a lot
> of words!
>

*Point well taken, thank you. We will adapt our verbosity **level **in
future documents.*

> ---
>
> There are a number of abbreviations that the RFC Editor will ask you to
> expand on first use both in the Abstract and in the main body of text.
> If you have te document open for other edits, you should take a pass at
> this to make sure the right expansions are used.
>

*This was indeed raised by Roni Even
in https://www.ietf.org/mail-archive/web/gen-art/current/msg11355.html
<https://www.ietf.org/mail-archive/web/gen-art/current/msg11355.html>, we
detailed how we addressed these comments
in http://www.ietf.org/mail-archive/web/6tisch/current/msg03026.html
<http://www.ietf.org/mail-archive/web/6tisch/current/msg03026.html>.*

>
> ---
>
> Section 1, para 3
> Not sure whether "ultra-lower power" is a typo or an undefined term.
>

*typo. I fixed it to "low power operation**"*

>
> ---
>
> Section 1
>
>    Bringing industrial-like performance into the LLN stack...
>
> I'm not sure what "industrial-like performance" is supposed to mean.
> Two paragraphs earlier you described the industrial environment, but not
> anything that matches the term "industrial-like performance".
>
> Could you usefully reword as "Enabling the LLN protocol stack to operate
> in industrial environments..."
>

*done, thanks.*

*OLD*
*Bringing industrial-like performance into the LLN stack developed
by Internet of Things (IoT) related IETF working groups such as 6Lo, ROLL
and CoRE opens up new application domains for these networks.*
*NEW*

*Enabling the LLN protocol stack to operate in industrial environments
opens up new application domains for these networks.*

>
> ---
>
> Section 1
>
>    What is missing is a Logical
>    Link Control (LLC) layer between the IP abstraction of a link and the
>    TSCH MAC, which is in charge of scheduling a timeslot for a given
>    packet coming down the stack from the upper layer.
>
> I found this odd. Do you mean to say...
>
>    What is missing is a link layer control protocol that is in charge of
>    scheduling a timeslot for a given IP packet that will be encapsulated
>
>    in the TSCH MAC.
>

> But in Section 4 I see you have come back to the term "LLC". I'm not
> comfortable with this use of the term. It doesn't fit (as far as I can
> see) with the conventional (i.e., OSI) usage of the term. You might look
> to GMPLS for the way that this terminology issue was handled for
> adaptation into layer 2 or 1 technologies, and the way that those
> technologies are controlled by signaling or management protocols.
>
>
*Hmm. The message we are trying to convey is that we are missing an
"entity" responsible for managing the TSCH schedule. The ambition of the
6TiSCH WG is to define such a system, but in this informational draft, we
just want to highlight the missing pieces. We therefore refer to it in a
generic way as the "LLC".*

> ---
>
> It would seem that Section 2 is redundant and can be removed.
>
>
*Thanks for pointing this out. Adding the "requirements language" section
is a "reflex". Since don't use any of this language here, we removed
Section 2 (as well as the reference to 2119)*

> ---
>
> Section 3
>
>    Low-power WPANs are characterized
>    by small packet sizes
>
> Is this the characterisation that you want to call to our attention or
> is it the small maximum frame size?
>

*The latter. We have updated the text to make this clearer*

*OLD*
*Low-power WPANs are characterized by small packet sizes,*

*NEW*

*Low-power Wireless Personal Area Networks (WPANs) typically feature small
frame sizes,*

>
> ---
>
> The last paragraph of Section 3 seems to be out of place. It is
> certainly worth noting any implementation information, but, as
> recommended by RFC 6982 this information is better placed either in an
> implementation report (a separate document) or in a wiki. There are good
> political reasons for doing this, and also good practical reasons as the
> RFC will be an ossified record - you don't want endless updates to the
> RFC just because someone else has written some more code!
>
>
*Hmm. Rather than maintaining an up-to-date list of all implementations
(which we will do, for example through the IETT's initiative to maintain a
list of per-RFC compliant implementations), we want to acknowledge the
support for this technology from the open-source community. We cite
OpenWSN, since it is the first implementation, not because we want to
maintain an up-to-date list. We have made this clearer in the text:*

*OLD*
*   Several open-source initiatives have emerged around TSCH.  The
 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source   implementation
of a standards-based protocol stack, which aims at   evaluating the
applicability of TSCH to different applications.  This   implementation was
used as the foundation for an IP for Smart Objects   Alliance (IPSO) [IPSO]
interoperability event in 2011.  In the   absence of a standardized
scheduling mechanism for TSCH, a "slotted   Aloha" schedule was used.*
*NEW*
*   Open-source initiatives have emerged around TSCH, with the OpenWSN
 project [OpenWSN][OpenWSNETT] being the first open-source   implementation
of a standards-based protocol stack.  This   implementation was used as the
foundation for an IP for Smart Objects   Alliance (IPSO) [IPSO]
interoperability event in 2011.  In the   absence of a standardized
scheduling mechanism for TSCH, a "slotted   Aloha" schedule was used*

> ---
>
> Section 4
>
>    As highlighted in Appendix A, TSCH differs from traditional low-power
>    MAC protocols because of its scheduled nature.
>
> Is there a long tradition? Did your father's father code low-power MAC
> protocols, perhaps whittling them by hand from a single piece of
> hornbeam?  :-)
>
> Maybe s/traditional/other/
>

*I will definitely check my family tree. In the meantime, absolutely,
**s/traditional/other/
:-)*

>
> ---
>
> Section 4.1
>
>    1.  Define the Information Elements included in the Enhanced Beacons
>        advertising the presence of the network.
>
> Am I supposed to know what an "Enhanced Beacon" is? Should there be an
> explanation of a reference?
>

*Yes, good point. We added a reference to IEEE802154e.*

>
> ---
>
> Section 4.1
>
>    4.  Define a mechanism to secure the joining process and the
>        subsequent optional process of scheduling more communication
>        cells.
>
> This is the first mention of a cell. It would hav helped to either
> explain it or give a reference.
>
> Ah! There is the definition in 4.5. Is something out of order, or
> would a forward pointer be enough? Turns out a "cell" was not what I
> thought it was.
>

*Yes, this got lost when reshuffling the text. I have added both a forward
reference and a definition.*

>
> ---
>
> Section 4.5 mentions PCE. That is OK, but you will need to expand the
> abbreviation, and you should give a reference.
>
> Similarly, while 4.8 does expand "PCE" a reference would help.
>
>
*Thanks. We have expanded PCE in Section 4.5 and provided a reference to
RFC4655 in 4.8.*

> ---
>
> Section 4.6 has
>
>    The LLC needs to:
>
>    1.  Define a queuing policy for incoming and outgoing packets.
>
> It is not clear (to me) whether this needs to be a network-wide policy,
> a
> per-node policy that can be standardised and/or communicated, or is a
> per-node policy that can be configured or hard-wired at implementation.
>
> Maybe "the LLC has to allow for the implementation and configuration of
> a
> policy..."
>
>
*This indeed lack clarity. We updated as follows:*

*OLD*

*Define a queuing policy for incoming and outgoing packets*
*NEW*

*Allow for the implementation and configuration of policy to queue incoming
and outgoing packets.*

> ---
>
> Section 4.7
>
>    1.  Ensure timely delivery of such data.
>
> "Timely" might be subjective.
> What do you really mean?
>
>
*This indeed lack clarity. We updated as follows:*

*OLD*

*Ensure timely delivery of such data.*
*NEW*
*Ensure that the data is delivered to its final destination before a
deadline possibly determined by the application*

> ---
>
> Section 4.8
>
>    An example of decentralized
>    algorithm is provided in [tinka10decentralized].  This mechanism can
>    be used to establish multi-hop paths in a fashion similar to RSVP.
>
> I'm afraid I didn't hunt down the referenced paper. I wonder whether you
> mean RSVP or RSVP-TE. Probably you *do* mean RSVP in that the
> decentralised approach allows the reservations to form along the routes
> the packets happen to follow. Perhaps including a reference (probably
> RFC 2205 if you do man RSVP) and some explanation of what you mean by
> "decentralised" would help.
>
> I can see "decentralised" as meaning classic RSVP or just a signaling
> plane like RSVP-TE allowing the hops to select cells.
>

*We a referring to the concept developed in RSVP to allow reservations to
form along a multi-hop path. Per your suggestion (thanks!), we added a
reference to 2205. We clarified what we mean by decentralized:*

*OLD*

*An example of decentralized algorithm (i.e. no PCE is needed)*
*NEW*
*An example of decentralized algorithm*

>
> ---
>
> Section 4.8
>
>    1.  Provide a mechanism for two 6TiSCH devices to negotiate the
>        allocation and deallocation of cells between them.
>
> This is the first mention of 6TiSCH in a 6TiSCH document! Don't you
> think it would be good to define the term?
>
>
*We want this draft to describe IEEE802.15.4e independtly of the work at
6TiSCH. I have therefore removed the 2 occurences of "6TiSCH devices".*

> ---
>
> Section 4.9
>
>    3.  Define a mechanism to allow for the secure transfer of signaling
>        data between nodes and the LLC.
>
> This reads as though the LLC is now being treated as the centralised
> control entity not a "layer" as previously defined. Certainly, the
> transfer of data between a node and a "layer" is probably achieved
> within
> the node so security is not an issue.
>
> Fix this with s/and/within/ ?
>

*Absolutely, thanks!*

>
> ---
>
> I'm not convinced by your choice to put all but one reference as non-
> normative.
>
> [I-D.ietf-6tisch-terminology] seems to be required reading to understand
> the terms used in this document.
>
> [IEEE802154e] might reasonably be assumed to be fundamental to
> understanding what TSCH is.
>
> Equally, some of the references seemed a little gratuitous. For example:
>    To map the services required by the IP layer to the services provided
>    by the link layer, an adaptation layer is used
>    [palattella12standardized].
>
> I'm sure there are other issues with references, but I lacked the energy
> to go through them. Could you please work this issue with your AD.
>

*We will, thanks!*

>
> ---
>
> It would have been good to have included proper forward references to
> the two Appendixes from early in the document.
>

*Thanks. We added forward references to both Appendices in the
introduction.*

>
> ---
>
> Why is Appendix B titled "TSCH Gotchas" when many of the features
> described are positive attributes of TSCH?
>

*Good point, we don't want the title to read as if these are negative
attributes of TSCH. We renamed to "TSCH features".*

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 6 Mar 2015 13:24:09 +0100

Adrian, Deborah,

*done, thanks.*

*OLD*

*OLD*

*NEW*

*OLD*

*OLD*

*OLD*

*OLD*

*Absolutely, thanks!*

*We will, thanks!*

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Mar 2015 12:48:15 -0000

Thomas,

Congratulations on the speed of your turn-round!
Thanks for looking at my Comments. They remain just Comments and can be discarded if you and your AD don't think they merit further attention.

Cutting down to just a few issues.

> Hmm. The message we are trying to convey is that we are missing an
> "entity" responsible for managing the TSCH schedule. The ambition 
> of the 6TiSCH WG is to define such a system, but in this informational
> draft, we just want to highlight the missing pieces. We therefore refer
> to it in a generic way as the "LLC".
 
Ah!
Light comes on (with remote and wireless control :-)

The challenge is that you have:
- used LLC which is a pre-existing term
- said " What is missing is a Logical  Link Control (LLC) *layer*"
- intend to refer to an entity

I'd go further and say you man a "functional entity" because the realisation of the entity may be distributed or centralised or whatever.

A solution here would be to clean up a little:
- remove reference to a "layer"
- add text where LLC is first introduced and clearly describe it as a functional entity that performs specific functions
- ideally (but not mandatory) change the name from LLC to something less overloaded.

But (and sorry for my confusion when I reviewed)...

>> within the node so security is not an issue.
>>
> Absolutely, thanks!

Here I advised you to continue thinking of the LLC as a layer.
The discussion above seems (but perhaps I mistake something) to settle on the LLC as an entity.
If "entity" then 4.9 code was fine.
If "layer" then discussion of section is awry.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Mar 2015 12:48:15 -0000

Thomas,

 
Ah!

Thanks,
Adrian

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 7 Mar 2015 18:18:54 +0100

Adrian,

Thanks again for your very constructive comments, which I fully agree with.
Please see *inline* how we have addressed those in
https://bitbucket.org/6tisch/draft-ietf-6tisch-tsch/src.

We will publish the version by Monday.

Thomas

On Fri, Mar 6, 2015 at 1:48 PM, Adrian Farrel <[email-masked]> wrote:

> Thanks for looking at my Comments. They remain just Comments and can be
> discarded if you and your AD don't think they merit further attention.
>

*:-)*

> - intend to refer to an entity

*I see your point.*

>
> I'd go further and say you man a "functional entity" because the
> realisation of the entity may be distributed or centralised or whatever.
>

*Exactly*

> - remove reference to a "layer"

*done.*

*OLD*
*What is missing is a Logical   Link Control (LLC) layer between the IP
abstraction of a link and the   TSCH MAC, which is in charge of scheduling
a timeslot for a given   packet coming down the stack from the upper layer*
*NEW*

*What is missing is a functional entity which is in charge of scheduling
TSCH timeslots for frames to be sent on. In this document, we refer to this
entity as the "Logical Link Control (LLC)", bearing in mind that
realizations of this entity can of different types, including a distributed
protocol or a centralized server in charge of scheduling.*

> - add text where LLC is first introduced and clearly describe it as a
> functional entity that performs specific functions

*I agree to refer to te LLC as an entity, and have reverted the change.
That is, the text now reads:*

*Define a mechanism to allow for the secure transfer of signaling data
between nodes and the LLC.*

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 7 Mar 2015 18:18:54 +0100

Adrian,

Thomas

*:-)*

*I see your point.*

*Exactly*

*done.*

*OLD*

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Mar 2015 18:03:41 -0000

Good job.
Thanks.
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 07 March 2015 17:19
To: Adrian Farrel ([email-masked])
Cc: The IESG; [email-masked]; [email-masked]; Pascal Thubert; [email-masked]
Subject: Re: Adrian Farrel's No Objection on draft-ietf-6tisch-tsch-05: (with COMMENT)
 
Adrian,
 
Thanks again for your very constructive comments, which I fully agree with. Please see inline how we have addressed those in https://bitbucket.org/6tisch/draft-ietf-6tisch-tsch/src.

Thomas

Ah!
 
:-)

I see your point.

Exactly

done.
 
OLD
What is missing is a Logical
   Link Control (LLC) layer between the IP abstraction of a link and the
   TSCH MAC, which is in charge of scheduling a timeslot for a given
   packet coming down the stack from the upper layer
NEW
What is missing is a functional entity which is in charge of scheduling TSCH timeslots for frames to be sent on. In this document, we refer to this entity as the "Logical Link Control (LLC)", bearing in mind that realizations of this entity can of different types, including a distributed protocol or a centralized server in charge of scheduling.

 
I agree to refer to te LLC as an entity, and have reverted the change. That is, the text now reads:
 
Define a mechanism to allow for the secure transfer of signaling data between nodes and the LLC.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Mar 2015 18:03:41 -0000

Good job.
Thanks.
Adrian

Adrian,

 
Thomas

Ah!
 
:-)

I see your point.

Exactly

done.
 
OLD

 

Thanks,
Adrian