Re: [Gen-art] [6tisch] Genart last call review of draft-ietf-6tisch-msf-10

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.gurbani@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.chang@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 <
>> noreply@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
>>> 6tisch@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/
——————————————————————————————————————