Subject: [6tisch] recap of minimal review process

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 13 May 2016 17:48:08 +0200

Dear all,

following the indications of Suresh raised today at the conf call, please
see the discussion thread that followed from Charlie's review of the
minimal draft. Sorry for not having posted this to the ML before.

the latest version of the draft is in the bitbucket repository ( See it
attached as well)
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/src

and includes all changes detailed below.

kind regards,
Xavi

From: Xavier Vilajosana <[email-masked]>
Date: 2016-05-03 9:54 GMT+02:00
Subject: Re: Review for draft-ietf-6tisch-minimal-15
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: Charlie Perkins <[email-masked]>, Thomas Watteyne <
[email-masked]>

Dear Pascal, Charlie,

I edited the draft. See it attached including your comments.  I also add
some details about the answers inline (to help the review). Let me know if
you consider that something else needs to be changed.
thanks a million for your review Charlie!! (I added you to the ACKs section)
X

2016-05-02 9:28 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> Hello Charlie
>
>
>
> Thanks so much for this highly constructive effort at a very busy time for
> you;
>
>
>
> Xavi, please find my notes below:
>
> Previously, I had noted:
>
>    obtained is out of the scope of this document.  More details are
>    given in Section 10.
> CEP: contradicts the last sentence.
>
> Maybe it would be clearer to say:
>
>     "More details about security are given in Section 10."
>
> PT> +1
>

done

> In section 8.1:
>
> 8.1.  Neighbor Table
>
>    The exact format of the neighbor table is implementation-specific.
>    Future version of the 6top Protocol [draft-wang-6tisch-sublayer] MAY
> CEP updated citation -- but this is better left out of scope?
>
> I did not understand why this was important to cite in a *minimal*
> specification.  It seems appropriate to notify implementers about the
> existence of 6top, but I don't see just how this is relevant to identifying
> what a *minimal* implementation has to do.
>
> PT> please remove that text;
>
>
>
done

>
>
> Regarding my previous comment:
>
>       ETX=(numTX/numTXAck)
> CEP: does not allow for unacknowledged flows.
>
> I was wondering whether the minimal implementation should allow for a
> metric that works better for flows that do not employ any per-packet (or
> per-frame) acknowledgement.  For such flows, numTXAck = 0 and the
> arithmetic fails.
>
> PT > Maybe we can add a note that the spec is designed for 802.15.4 which
> has a L2 ack. I think that future port of minimal to a MAC layer that does
> not exhibit similar behavior would entail a new operation beyond this
> draft. Personally, for the same reasons as the +1 above, I do not think
> that this draft has to fathom how that would be done.
>
>
> see in *italics*
The  ETX is computed as the inverse of the Packet Delivery Ratio (PDR),
      this is the number of transmitted packets, divided by the number
      of acknowledged packets to a certain node (e.g., ETX = numTX/
      numTXAck). * Note that this specification is designed for the*
*      IEEE802.15.4 MAC [IEEE802154-2015] which assumes L2 ACK.  In case*
*      that a future use of this specification relies on a MAC layer that*
*      does not provide L2 ACK this metric needs to be reconsidered. *

> The caption for figure 4 is:
>
> Rank computation example for 5 hop network where numTx=100
>    and numTxAck=75 for all nodes
>
> I think the phrase where "numTx=100 and numTxAck=75 for all nodes" belongs
> earlier, so that the reader can follow along the discussion.  For instance,
> at the beginning of section 11.1.2, instead of:
>
> (refer to Figure 4 for specific details)
>
> you might say:
>
>     "(Figure 4 uses numTx=100 and numTxAck=75 for all nodes)"
>
> PT> +1
>

Done

> In section 11.2.1, I noted:
>
>       ...     Non-storing mode of operation is the default mode that
>    a node selects when acting as a DAG root.
> CEP: How does it switch to storing?  This needs to be specified.
> CEP: Notably, the seemingly preferred status of non-storing mode reduces
>     battery life in order to save RAM.  Weir
>
> I still think it would be a good idea to point out how nodes switch to
> storing mode from the default.
>
> PT> Could you please add a sentence saying like, the Mode of Operation is
> an administrative action and changing it causes the DAG to rebuild entirely.
>
>
>
see in *italics*
 Non-storing mode of operation is the default mode that
   a node selects when acting as a DAG root.*  The latest is motivated*
*   because most of the practical usages of the RPL protocol in the IoT*
*   space make use of non-storing modes.  This is because storing mode*
*   limits the size of the network to the storage capabilities of the*
*   devices, and is more complex to operate due to the distributed*
*   routing operation for routing downwards.  In addition, it is important*
*   to note that the Mode of Operation is an administrative action and*
*   changing it causes the DAG to rebuild entirely.*

> Also I am still curious about why non-storing is the default.  If you feel
> is it appropriate to insert some explanatory text, or simply tell me by
> email in response, I would appreciate that.
>
> PT> I’d suggest that the text indicates that “most practical usages of the
> RPL protocol in the IOT space leverages non-storing modes. This is because
> storing mode limits the size of the network to the storage capabilities of
> the devices, and is more complex to operate due to the distributed routing
> operation for routing downwards.”
>
>
see above

> I noticed a residual typo in draft ...-16.  In section 8.1,
>
> Future version of the 6top Protocol
>
> "Future" -> "future"  (sorry this was my typo also :-)
>
> Thank you both !!!
>
>
>
this has been removed -- see previous comments.

> Pascal
>
> Regards,
> Charlie P.
>
>
>
>
>
>
>
> On 4/29/2016 7:16 AM, Xavier Vilajosana wrote:
>
> Dear Charlie,
>
>
>
> thanks again for your comments. They were really valuable. I addressed all
> of them. See the reviewed version (16).
>
>
>
> let me know if there is something that is still not clear. After your
> answer I will move the discussion to the ML.
>
>
>
> kind regards,
>
> Xavi
>
>
>
>
>
>
>
> 2016-04-24 18:23 GMT+02:00 Charlie Perkins <[email-masked]
> >:
>
>
> Hello folks,
>
> Here's what I have so far.  I wanted to finish going through the Appendix,
> but things are burning up elsewhere right now.
>
> I put in various comments in the text, and made a diff to highlight them.
> Many of these are simply syntax errors or stylistic problems, but there are
> some minor technical issues.
>
> Overall, the document is in reasonable shape and could be published after
> another close proofreading.
>
> The document seems ambivalent about whether or not RPL is mandated for
> minimal use.  I think that RPL should not be mandated but only
> recommended.  In the future, I hope that other protocols besides RPL will
> be seen to offer advantages, and I think that it would be pretty simple for
> the minimal draft to identify which routing protocol was in use.  In that
> case, RPL could be the "default", but nodes could use the minimal slot
> assignments to agree on another protocol for *their* minimal
> configuration.  Choice of routing protocol is a good bit different than
> choice of slot assignments and other layer-2 parameters.
>
> Regards,
> Charlie P.
>
>
>
>
>

From: Charlie Perkins <[email-masked]>
Date: 2016-04-29 20:48 GMT+02:00
Subject: Re: Review for draft-ietf-6tisch-minimal-15
To: Xavier Vilajosana <[email-masked]>
Cc: "Pascal Thubert (pthubert)" <[email-masked]>, Thomas Watteyne <
[email-masked]>

Hello Xavi,

Thanks much for resolving my comments.

I did have a few questions, which aren't terribly important but if you have
follow-up answers that would be helpful for me.

Previously, I had noted:

   obtained is out of the scope of this document.  More details are
   given in Section 10.
CEP: contradicts the last sentence.

Maybe it would be clearer to say:

    "More details about security are given in Section 10."

In section 8.1:

8.1.  Neighbor Table

   The exact format of the neighbor table is implementation-specific.
   Future version of the 6top Protocol [draft-wang-6tisch-sublayer] MAY
CEP updated citation -- but this is better left out of scope?

I did not understand why this was important to cite in a *minimal*
specification.  It seems appropriate to notify implementers about the
existence of 6top, but I don't see just how this is relevant to identifying
what a *minimal* implementation has to do.

Regarding my previous comment:

      ETX=(numTX/numTXAck)
CEP: does not allow for unacknowledged flows.

I was wondering whether the minimal implementation should allow for a
metric that works better for flows that do not employ any per-packet (or
per-frame) acknowledgement.  For such flows, numTXAck = 0 and the
arithmetic fails.

The caption for figure 4 is:

Rank computation example for 5 hop network where numTx=100
   and numTxAck=75 for all nodes

I think the phrase where "numTx=100 and numTxAck=75 for all nodes" belongs
earlier, so that the reader can follow along the discussion.  For instance,
at the beginning of section 11.1.2, instead of:

(refer to Figure 4 for specific details)

you might say:

    "(Figure 4 uses numTx=100 and numTxAck=75 for all nodes)"

In section 11.2.1, I noted:

      ...     Non-storing mode of operation is the default mode that
   a node selects when acting as a DAG root.
CEP: How does it switch to storing?  This needs to be specified.
CEP: Notably, the seemingly preferred status of non-storing mode reduces
    battery life in order to save RAM.  Weir

I still think it would be a good idea to point out how nodes switch to
storing mode from the default.

Also I am still curious about why non-storing is the default.  If you feel
is it appropriate to insert some explanatory text, or simply tell me by
email in response, I would appreciate that.

I noticed a residual typo in draft ...-16.  In section 8.1,

Future version of the 6top Protocol

"Future" -> "future"  (sorry this was my typo also :-)

Regards,
Charlie P.

On 4/29/2016 7:16 AM, Xavier Vilajosana wrote:

Dear Charlie,

thanks again for your comments. They were really valuable. I addressed all
of them. See the reviewed version (16).

let me know if there is something that is still not clear. After your
answer I will move the discussion to the ML.

kind regards,
Xavi

2016-04-24 18:23 GMT+02:00 Charlie Perkins <[email-masked]>:

>
> Hello folks,
>
> Here's what I have so far.  I wanted to finish going through the Appendix,
> but things are burning up elsewhere right now.
>
> I put in various comments in the text, and made a diff to highlight them.
> Many of these are simply syntax errors or stylistic problems, but there are
> some minor technical issues.
>
> Overall, the document is in reasonable shape and could be published after
> another close proofreading.
>
> The document seems ambivalent about whether or not RPL is mandated for
> minimal use.  I think that RPL should not be mandated but only
> recommended.  In the future, I hope that other protocols besides RPL will
> be seen to offer advantages, and I think that it would be pretty simple for
> the minimal draft to identify which routing protocol was in use.  In that
> case, RPL could be the "default", but nodes could use the minimal slot
> assignments to agree on another protocol for *their* minimal
> configuration.  Choice of routing protocol is a good bit different than
> choice of slot assignments and other layer-2 parameters.
>
> Regards,
> Charlie P.
>
>
>

-- 
xvilajosana.org

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 23 May 2016 13:54:32 +0200

Thank you Xavi for posting these details to the public ML.

On Fri, May 13, 2016 at 5:48 PM, Xavier Vilajosana <
[email-masked]> wrote:

>> Thanks so much for this highly constructive effort at a very busy time
>> for you;
>>
>>
>>
>> I think the phrase where "numTx=100 and numTxAck=75 for all nodes"
>> belongs earlier, so that the reader can follow along the discussion.  For
>> instance, at the beginning of section 11.1.2, instead of:
>>
>> Also I am still curious about why non-storing is the default.  If you
>> feel is it appropriate to insert some explanatory text, or simply tell me
>> by email in response, I would appreciate that.
>>
>> PT> I’d suggest that the text indicates that “most practical usages of
>> the RPL protocol in the IOT space leverages non-storing modes. This is
>> because storing mode limits the size of the network to the storage
>> capabilities of the devices, and is more complex to operate due to the
>> distributed routing operation for routing downwards.”
>>
>>
> see above
>
>> thanks again for your comments. They were really valuable. I addressed
>> all of them. See the reviewed version (16).
>>
>>
>>
>> Here's what I have so far.  I wanted to finish going through the
>> Appendix, but things are burning up elsewhere right now.
>>
>> I put in various comments in the text, and made a diff to highlight
>> them.  Many of these are simply syntax errors or stylistic problems, but
>> there are some minor technical issues.
>>
> I did have a few questions, which aren't terribly important but if you
> have follow-up answers that would be helpful for me.
>
> Previously, I had noted:
>
>> Here's what I have so far.  I wanted to finish going through the
>> Appendix, but things are burning up elsewhere right now.
>>
>> I put in various comments in the text, and made a diff to highlight
>> them.  Many of these are simply syntax errors or stylistic problems, but
>> there are some minor technical issues.
>>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________