Dear Cherlie, thanks so much for your comments. We will address them in the next revision.
regards, Xavi 2015-10-27 1:23 GMT+01:00 Charlie Perkins <[email protected]>: > Hello folks, > > I made a review of the draft. Attached, please find my revision of the > file that has a few editorial suggestions along with a rfcdiff output to > make it easy to see what's changed. > > Here are some other questions and observations... > > - There is a strong need for non-local statistics, for instance flow > statistics > - Do 6top commands go across at scheduled times, or on the "minimal" > channel SFR0? > - Local measurements are prone to oscillation. > - Shouldn't a retry facility be standardized? That way you can > specify binary exponential backoff, etc. > - Is there any movement towards use of PCE? I was thinking about > making a draft on that topic. > - Is it possible to carry protocol messages carried over IP? IPv6? > - Shouldn't IETF try to either use existing IEs, or explain the need > for new ones? It seems wrong to allocate new IE numbers in the IETF. > - In section 3.1.3, why are the OpCodes prefixed with IANA? Why not > 6TOP? > - Are 65,000 offsets really needed? 65,000 channels?? Are > applications going to request 256 cells from neighboring devices? > - The concept of a container needs definition. How is the length of a > container known? Is there any difference between "container" and > "SFID-specific data"? Unless it has some intuitive value, this seems like > a misleading bit of terminology. > - It seems likely that on many devices, scheduling functions will not > be callable at boot time. Why not mandate that a scheduling function needs > to describe some behavior when 6tisch launches? > - Is it now the intention that a scheduling function includes > monitoring and "actuation"? Did the text for these sections get moved to a > different draft? > > In my attached revision, please check for instances of "CEP" for a few > other questions. > > > On 10/19/2015 8:19 PM, Xavier Vilajosana wrote: > > Dear all, > > we have submitted a new version of the sublayer draft. > > kind regards, > Xavi > > ------------- > A new version of I-D, draft-wang-6tisch-6top-sublayer-03.txt > has been successfully submitted by Thomas Watteyne and posted to the > IETF repository. > > Name: draft-wang-6tisch-6top-sublayer > Revision: 03 > Title: 6TiSCH Operation Sublayer (6top) > Document date: 2015-10-19 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-sublayer-03.txt > Status: > https://datatracker.ietf.org/doc/draft-wang-6tisch-6top-sublayer/ > Htmlized: > https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-03 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-wang-6tisch-6top-sublayer-03 > > Abstract: > This document defines the 6TiSCH Operation Sublayer (6top), which > offers mechanisms for distributed scheduling in 6TiSCH networks. The > 6top sublayer is the next higher layer of the IEEE802.15.4e TSCH > medium access control layer. The 6top Protocol (6P) defined in this > document allows neighbor nodes to add/delete TSCH cells to one > another. To be able to match different application requirements, the > 6top Scheduling Function (SF) decides when to add/delete cells. The > SF is left out of scope, and will be specified in one or more > companion documents. > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > 6tisch mailing [email protected]https://www.ietf.org/mailman/listinfo/6tisch > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
