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
> <[email protected]> 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.
>
>> 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.
Regards
Brian
> ThanksQin
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
