Re: [Gen-art] Genart last call review of draft-ietf-6tisch-6top-protocol-10

2018-04-04 Thread Xavi Vilajosana Guillen 
Thanks Alissa.

kind regards
X

2018-04-03 20:00 GMT+02:00 Alissa Cooper :

> 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 <
> brian.e.carpen...@gmail.com> 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  >:
> >>>
>  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
> 
>  .
> 
>  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
>
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajos...@uoc.edu 
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]
­
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-6tisch-6top-protocol-10

2018-04-03 Thread Alissa Cooper 
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  
> 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 :
>>> 
 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
 
 .
 
 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-6tisch-6top-protocol-10

2018-03-31 Thread Brian E Carpenter 
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 :
>>
>>> 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
>>>
>>> .
>>>
>>> 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

Re: [Gen-art] Genart last call review of draft-ietf-6tisch-6top-protocol-10

2018-03-22 Thread Brian E Carpenter 
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 :
> 
>> 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
>>
>> .
>>
>> 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

[Gen-art] Genart last call review of draft-ietf-6tisch-6top-protocol-10

2018-03-10 Thread Brian Carpenter 
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

.

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