Re: [Hipsec] RFC5201-bis and RFC5202-bis status

Ted Lemon <Ted.Lemon@nominum.com> Tue, 28 October 2014 18:15 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 3D9761A9138 for <hipsec@ietfa.amsl.com>; Tue, 28 Oct 2014 11:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nnirkybYem3E for <hipsec@ietfa.amsl.com>; Tue, 28 Oct 2014 11:15:38 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B77C1AC3AF for <hipsec@ietf.org>; Tue, 28 Oct 2014 11:08:24 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id F1476DA00A9 for <hipsec@ietf.org>; Tue, 28 Oct 2014 18:11:31 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3308453E084; Tue, 28 Oct 2014 11:07:54 -0700 (PDT)
Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 11:07:53 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <544FC7E9.50301@tomh.org>
Date: Tue, 28 Oct 2014 14:07:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <ACF30959-BF48-424F-BF09-D0E3E5E1BDF4@nominum.com>
References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> <540C3EB0.2000004@gmail.com> <5416CF8D.1070707@ericsson.com> <5417C8A2.9070800@tomh.org> <544FA19B.8030306@cs.hut.fi> <544FC7E9.50301@tomh.org>
To: Tom Henderson <tomh@tomh.org>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/vIDJYbSBFbUuLRcnByt7b0Gw5Vs
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status
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: <http://www.ietf.org/mail-archive/web/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: Tue, 28 Oct 2014 18:15:41 -0000

On Oct 28, 2014, at 12:44 PM, Tom Henderson <tomh@tomh.org> wrote:
> While I am sympathetic to Rene's argument in 1), no one else has supported this change on the list, so given the late stage of this document, I would suggest to keep the encoding as is.  The changes proposed in 2) and 3) are editorial, in my view, so I don't see a problem to accept them.

I would definitely concur with this.   This is not the time to do further engineering.

> I regenerated the diff according to Rene's suggestions, and posted it here:
> 
> http://trac.tools.ietf.org/wg/hip/trac/attachment/ticket/51/rfc5201-bis-19-to-20-pre-2.diff
> 
> So in summary, I would like to now convey to our AD that we have a diff to the version -19 draft that is editorial/clarification in nature, and ask whether and how it can be handled procedurally, such as:
> 
> - publish a -20 and revisit some of the reviews (since version -19 was officially reviewed and approved, I don't know what it means to now post a -20 version)
> - avoid publishing a -20 and handle these changes similar to AUTH48 changes
> - scrap the diff and just publish version -19
> 
> Our AD can let us know how he prefers to handle it.

I would prefer that you publish the -20.   Assuming that that is the working group's final say, we can then push the publish button.