Subject: Re: [Hipsec] Minor correction to rfc7401 4.4.4 state machine

From: Tom Henderson <[email-masked]>
Date: Fri, 3 Jul 2015 08:04:25 -0700 (PDT)

Gonzalo,
I had a look at the criteria here:

https://www.ietf.org/iesg/statement/errata-processing.html

and it states that this condition should be satisfied to log an erratum:

 Only errors that could cause implementation or deployment problems or significant confusion should be Verified. 

I'm wondering about whether this meets the criteria.  On the one hand, this is a mainstream state transition (I1-SENT gets to I2-SENT upon receiving an R1, not an R2).  On the other hand, this section is clearly informational (section 4.4) and the transition is correctly noted in the Table 3 in this section (also informative) and in the normative Section 6.8.

So, I wonder whether this is in the category of "could cause significant confusion" or rather whether an implementer would just recognize this as an obvious typo in conflict with other parts of the specification.

Any opinions about this?

- Tom

On 06/29/2015 01:36 PM, Gonzalo Camarillo wrote:> Yes, please log an erratum.
> 
> Thanks,
> 
> Gonzalo
> 
> On 29/06/2015 11:20 PM, Tom Henderson wrote:
>>
>>
>> On 06/28/2015 09:51 AM, Darren Lissimore wrote:> Hey all;
>>>
>>> Read through 7401, got to section 4.4.4
>>> ​page 36.
>>> There's an error in the transition from I1-SENT to I2-SENT
>>> ​.​
>>> The draft has it as  recv R2, send I2 and
>>> ​it ​
>>> should be
>>> ​probably be ​
>>> recv R1, send I2
>>> ​as per Table 3 page 29   "recevie r1, process" trigger.
>>>
>>> ​Darren Lissimore

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 3 Jul 2015 19:24:33 +0000

Hi Tom,

Yes, the trend is to only "verify" errata that can clearly lead to interop problems. Other errata are typically "held for document update".

Cheers,

Gonzalo

Sent from my mobile

---- Tom Henderson wrote ----

Gonzalo,

Any opinions about this?

- Tom

---

From: William Atwood <[email-masked]>
Date: Fri, 03 Jul 2015 15:43:00 -0400

As someone who ended up as interim Document Shepherd for a document that
had over 100 errata pending from the previous version of the
specification, I encourage you to file the erratum, even though it will
be classified as "held for document update".  The set of such errata
provides the preparers of the next revision with a convenient,
easy-to-find list of "things to fix".  No one is going to go through the
entire email archive of hipsec to (re)discover the error that you are
now reporting, but if it is in the errata list, it will be easy to find
when the time comes.

  Bill Atwood

On 03/07/2015 3:24 PM, Gonzalo Camarillo wrote:
> Hi Tom,
> 
> Yes, the trend is to only "verify" errata that can clearly lead to
> interop problems. Other errata are typically "held for document update".
> 
> Cheers,
> 
> Gonzalo
> 
> Sent from my mobile
> 
> 
> 
>  Only errors that could cause implementation or deployment problems or
> significant confusion should be Verified.
> 
> I'm wondering about whether this meets the criteria.  On the one hand,
> this is a mainstream state transition (I1-SENT gets to I2-SENT upon
> receiving an R1, not an R2).  On the other hand, this section is clearly
> informational (section 4.4) and the transition is correctly noted in the
> Table 3 in this section (also informative) and in the normative Section 6.8.
> 
> So, I wonder whether this is in the category of "could cause significant
> confusion" or rather whether an implementer would just recognize this as
> an obvious typo in conflict with other parts of the specification.
> 
> Any opinions about this?
> 
> - Tom
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8