Thank you Xavi for posting these details to the public ML. On Fri, May 13, 2016 at 5:48 PM, Xavier Vilajosana < [email protected]> 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 <[email protected]> > Date: 2016-05-03 9:54 GMT+02:00 > Subject: Re: Review for draft-ietf-6tisch-minimal-15 > To: "Pascal Thubert (pthubert)" <[email protected]> > Cc: Charlie Perkins <[email protected]>, Thomas Watteyne < > [email protected]> > > > 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 protected]>: > >> 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 protected] >> >: >> >> >> 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 protected]> > Date: 2016-04-29 20:48 GMT+02:00 > Subject: Re: Review for draft-ietf-6tisch-minimal-15 > To: Xavier Vilajosana <[email protected]> > Cc: "Pascal Thubert (pthubert)" <[email protected]>, Thomas Watteyne < > [email protected]> > > > 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 protected]> > : > >> >> 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 > > _______________________________________________ > 6tisch mailing list > [email protected] > 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
