Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

Thanks, those changes look good.

Regards
   Brian

On 27/02/2018 05:31, Qin Wang wrote:
> Hi Bian,
> Thank you for your comments. Please see inline.
> 
> 
> 
>     On Friday, February 23, 2018 6:11 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>  
> 
>  Hi Qin, see in line:
> 
> On 24/02/2018 04:16, Qin Wang wrote:
>> Hi Brian,
>> Thank you very much for your comments. Please see inline.
>>
>> On Monday, February 19, 2018 6:22 PM, Brian Carpenter <brian.e.carpenter@gmail.com> wrote: 
>>
>>   Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-09
>>
>> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-6tisch-6top-protocol-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-02-20
>> IETF LC End Date: 2018-??-??
>> IESG Telechat date: 2018-03-06
>>
>> Summary: Ready with issues
>> --------
>>
>> Comment:
>> --------
>>
>> This is a Last Call review despite the subject field. When will the Last
>> Call be started?
>>
>> Major issues:
>> -------------
>>
>> In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
>> if A's timeout expires while B's Response is in flight. Can the 6top layer
>> prevent the L2 Ack being sent? (And similar race conditions seem to be
>> possible in the 3-step transaction.)
>>
>> [Qin] Firstly, sincethe L2 Ack is sent by L2 according to IEEE802.15.4, 6top layer cannot preventit happen. Secondly, the race condition described above unlikely happens,because it is required that “The value of the 6P Timeout should be larger thanthe longest possible time it can take for the exchange to finish.” (3.4.4)
> 
> I'm sorry but that sounds like magic. Then whole point of race conditions is that
> they happen in *very* unlikely cases such as the exchange taking 10 times normal
> for some reason. If it only happens one time in ten million it is still a problem.
> So I think you need to state what happens - maybe the inconsistency will be
> discovered later? That's fine for something considered highly unlikely.
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens during the communication, the TSCH schedule of node A may becomeinconsistent with the TSCH schedule of node B. 6top handles the schedule inconsistency in the way described in Section3.4.6.2
>>
>>> 3.4.3.  Concurrent 6P Transactions
>>>
>>>   Only a single 6P Transaction between two neighbors, in a given
>>>   direction, can take place at the same time.  That is, a node MUST NOT
>>>   issue a new 6P Request to a given neighbor before having received the
>>>   6P Response for a previous request to that neighbor, except when the
>>>   previous 6P Transaction has timed out.  If a node receives a 6P
>>>   Request from a given neighbor before having sent the 6P Response to
>>>   the previous 6P Request from that neighbor, it MUST send back a 6P
>>>   Response with a return code of RC_RESET (as per Figure 36).  A node
>>>   receiving RC_RESET code MUST abort the transaction and consider it
>>>   never happened.
>>
>> It isn't clear to me whether the RC_RESET aborts the first, the second,
>> or both transactions.
>>
>> [Qin] change textto “abort the second transaction”
> 
> OK! 
>> Minor issues:
>> -------------
>>
>>> 1.  Introduction
>> ...
>>>   6P
>>>   allows a node to communicate with a neighbor to add/delete TSCH cells
>>>   to one another.
>>
>> This sentence is almost unintelligible because of the sequence to...to...to.
>> Does it mean this?:
>>
>>   6P allows neighbours to add or delete TSCH cells in each other.
>>
>> [Qin] Because we want to emphasize that communication between two nodes is the way to add/deletecells, we change text to “6P allows a node to communicate with a neighbor toadd/delete TSCH cells in each other”
>  
> 
> OK, that will be less confusing.
>  
>>> 3.4.1.  Version Checking
>>
>> This may be a pointless worry, but is there a DOS attack of some kind
>> by sending rubbish version numbers?
>>
>> [Qin] I think thatnot only the field of Version Number, but also other fields, such as the fieldof Command Identifier can be filled with rubbish for DOS attack. So, I wonderif it is necessary for Version Number field to be treated differently. 
>>
>> I would like asksecurity people to help on the question.
> 
> Maybe you need to mention in the Security Considerations that you have
> no protection against a bad actor sending rubbish as a DOS. If all
> nodes are authenticated when they join the network, this seems an
> acceptable risk. 
> [Qin] Add text intoSecurity Consideration sectionThe 6P protocol does not provide protection against DOS attacks which involves sending garbage.
> 
> Regards
>     Brian
>  
>> ThanksQin
> ThanksQin
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>     
>>
> 
> 
>    
> 