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.carpen...@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 
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 
So I think you need to state what happens - maybe the inconsistency will be
discovered later? That's fine for something considered highly unlikely.
>> 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”

> 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. 

> ThanksQin
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

6tisch mailing list

Reply via email to