Thanks Alissa. kind regards X
2018-04-03 20:00 GMT+02:00 Alissa Cooper <[email protected]>: > 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 > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
