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.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 >> 6ti...@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
