Brian, thanks for your reviews. Authors, thanks for addressing Brian’s comments. I entered a No Objection ballot.
Alissa > On Mar 31, 2018, at 5:28 PM, Brian E Carpenter <[email protected]> > wrote: > > Hi, > > The published -11 text is even better than the proposal below. > > Thanks > Brian Carpenter > > On 23/03/2018 08:10, Brian E Carpenter wrote: >> That looks good to me. I think it will help implementers. >> >> Thanks >> Brian Carpenter >> >> On 22/03/2018 21:41, Xavi Vilajosana Guillen wrote: >>> Dear Brian, >>> >>> after the WG meeting we proceed to resolve your pointed issue. Thanks so >>> much for going through the draft again. >>> >>> We will publish v11 with the following update on the text as you suggested. >>> We hope this clarifies your point. >>> >>> >>> In section 3.1.1. 2-step 6P Transaction >>> we added: >>> Race conditions MAY happen when a timeout expires while a 6P >>> Response is on the air. Other inconsistencies can also happen >>> when the last L2 ACK for a 6P Response is lost or when one of the >>> nodes is power cycled. 6P provides an inconsistency detection >>> mechanism described in Section 3.4.6.1 to cope with such >>> situations. >>> >>> >>> In section 3.1.2. 3-step 6P Transaction >>> we added: >>> Race conditions MAY happen when a timeout expires while a 6P >>> Confirmation is on the air. Other inconsistencies can also >>> happen when the last L2 ACK for a 6P Confirmation is lost or when >>> one of the nodes is power cycled. 6P provides an inconsistency >>> detection mechanism described in Section 3.4.6.1 to cope with >>> such situations. >>> >>> >>> kind regards >>> Xavi >>> >>> >>> 2018-03-11 4:11 GMT+01:00 Brian Carpenter <[email protected]>: >>> >>>> Reviewer: Brian Carpenter >>>> Review result: Ready >>>> >>>> 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 >>>> >>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-6tisch-6top-protocol-10 >>>> Reviewer: Brian Carpenter >>>> Review Date: 2018-03-10 >>>> IETF LC End Date: 2018-03-26 >>>> IESG Telechat date: 2018-04-05 >>>> >>>> Summary: Ready >>>> >>>> Comment: >>>> >>>> Most of my previous comments have been fixed, thanks. I still disagree >>>> with the authors on one point, but not enough to delay the draft: >>>> >>>> In section 3.1.1 "2-step 6P Transaction" there seems to be a rare race >>>> condition >>>> if A's timeout expires while B's Response is in flight. This will be >>>> detected >>>> later as an inconsistency (section 3.4.6.2). The authors don't think it's >>>> necessary >>>> to mention this in 3.1.1. IMHO it would be useful to mention. (Similarly >>>> for >>>> section 3.1.2, 3-step transaction.) >>>> >>>> >>>> >>> >>> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
