Thanks for the suggestion! I will apply those changes in next the version of MSF.
Tengfei On Sat, Feb 15, 2020 at 11:07 PM Vijay Gurbani <vijay.gurb...@gmail.com> wrote: > Dear Tengfei: Thank you for getting back to me and your time to address my > review. > > The paragraph you suggest is very much improved, with one small change > that will make it even better, as described next. > > In the last sentence of your proposed change, s/The algorithm of limiting > the/However, any such algorithm of limiting the/ > > Once again, thanks. > > - vijay > > On Sat, Feb 15, 2020 at 7:35 AM Tengfei Chang <tengfei.ch...@gmail.com> > wrote: > >> H Vijay, >> >> Thanks a lot for the review! >> >> For the major comment, what we want to explain here is that there are >> multiple way to limit traffic to lighten the collisions. >> Trickle timer is one of those algorithm for that purpose. >> What "*This behavior is out of the scope for MSF*." means here actually >> is that we don't want to limit the various ways of limiting traffic by just >> using Trickle timer. >> The implementer can design their own algorithm to mitigate the traffic >> collisions on minimal cell. >> >> The paragraph is rephrased as following: >> >> *To ensure there is enough bandwidth available on the minimal cell, a >> node implementing MSF SHOULD enforce some rules for limiting the traffic of >> broadcast frames. * >> *For example, the overall broadcast traffic among the node and its >> neighbors **SHOULD NOT exceed 1/3 of the bandwidth of minimal cell.* >> *One of the algorithm met the rule is the Trickle timer defined in >> [RFC6206] which is applied on DIO messages [RFC6550]. * >> *The algorithm of limiting the broadcast traffic to meet those rules is >> implementation-specific and is out of the scope of MSF.* >> >> Does this version sound clear for you? >> >> Tengfei >> >> >> >> On Fri, Feb 14, 2020 at 5:43 PM Vijay Gurbani via Datatracker < >> nore...@ietf.org> wrote: >> >>> Reviewer: Vijay Gurbani >>> Review result: Almost Ready >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> >>> Document: draft-ietf-6tisch-msf-10 >>> Reviewer: Vijay K. Gurbani >>> Review Date: 2020-02-14 >>> IETF LC End Date: 2020-02-27 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary: The draft is almost ready to be published as a Proposed >>> Standard. >>> >>> Major issues: 1 >>> >>> Minor issues: 0 >>> >>> Nits/editorial comments: 1 >>> >>> Sn below stands for "Section n". >>> >>> Major: >>> >>> - S2, paragraph 4: The text says that "...a node implementing MSF SHOULD >>> enforce >>> some rules for limiting the traffic broadcast frames...". It goes >>> ahead and >>> gives an example of the "Trickle" operation, but in the very next >>> sentence, it >>> says, "This behavior is out of the scope for MSF." I am confused >>> since the >>> paragraph does not seem self consistent. >>> >>> The paragraph is asking the implementor to use normative strength >>> (SHOULD) to >>> enforce "some" rules, but does not enumerate the rules. To be fair, >>> the >>> paragraph gives one example of such a rule, but immediately >>> invalidates that >>> example! What would an implementor do? Where would he or she go to >>> get an >>> idea of "some" rules that can be used to limit the traffic of broadcast >>> frames? Perhaps some reference could be provided to a document that >>> contains >>> these rules? >>> >>> Nits: >>> >>> - S6: s/It is calculated/The timeout value is calculated/ >>> >>> Thank you. >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6ti...@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >> >> >> -- >> —————————————————————————————————————— >> >> Dr. Tengfei, Chang >> Postdoctoral Research Engineer, Inria >> >> www.tchang.org/ >> —————————————————————————————————————— >> > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
