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

William Atwood <william.atwood@concordia.ca> Fri, 03 July 2015 19:43 UTC

Return-Path: <william.atwood@concordia.ca>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3FD1A7011 for <hipsec@ietfa.amsl.com>; Fri, 3 Jul 2015 12:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level:
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DnhooXZbU4O for <hipsec@ietfa.amsl.com>; Fri, 3 Jul 2015 12:43:05 -0700 (PDT)
Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5EC1A7008 for <hipsec@ietf.org>; Fri, 3 Jul 2015 12:43:05 -0700 (PDT)
Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id t63Jh1qU009862; Fri, 3 Jul 2015 15:43:01 -0400
Message-ID: <5596E5C4.2030904@concordia.ca>
Date: Fri, 03 Jul 2015 15:43:00 -0400
From: William Atwood <william.atwood@concordia.ca>
Organization: Concordia University, Montreal
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Tom Henderson <tomhend@u.washington.edu>
References: <alpine.LRH.2.01.1507030804250.21265@hymn02.u.washington.edu> <ororae35mhvddokj89i3su9m.1435951468706@email.android.com>
In-Reply-To: <ororae35mhvddokj89i3su9m.1435951468706@email.android.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-07-03 15:43:02 EDT
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/FaPq0ybkrJ_G8QhjdAPiFQxZVOg>
Cc: "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] Minor correction to rfc7401 4.4.4 state machine
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2015 19:43:07 -0000

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
> 
> 
> 
> ---- Tom Henderson wrote ----
> 
> 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
> 
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> 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:william.atwood@concordia.ca
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8