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 <brian.e.carpen...@gmail.com>: > >> 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
