Re: [6tisch] recap of minimal review process
Thank you Xavi for posting these details to the public ML. On Fri, May 13, 2016 at 5:48 PM, Xavier Vilajosana < xvilajos...@eecs.berkeley.edu> wrote: > 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 > Date: 2016-05-03 9:54 GMT+02:00 > Subject: Re: Review for draft-ietf-6tisch-minimal-15 > To: "Pascal Thubert (pthubert)" > Cc: Charlie Perkins , Thomas Watteyne < > thomas.watte...@inria.fr> > > > 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) : > >> 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 n
[6tisch] recap of minimal review process
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 Date: 2016-05-03 9:54 GMT+02:00 Subject: Re: Review for draft-ietf-6tisch-minimal-15 To: "Pascal Thubert (pthubert)" Cc: Charlie Perkins , Thomas Watteyne < thomas.watte...@inria.fr> 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) : > 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 abou
