Hi Bian, Thank you for your comments. Please see inline.
On Friday, February 23, 2018 6:11 PM, Brian E Carpenter <brian.e.carpen...@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.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 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 > > > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch