[Hipsec] RFC5206-bis status

Tom Henderson <tomhend@u.washington.edu> Mon, 23 November 2015 07:06 UTC

Return-Path: <tomhend@u.washington.edu>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ACF2A1B3169 for <hipsec@ietfa.amsl.com>; Sun, 22 Nov 2015 23:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id w7Lat0SA6VPo for <hipsec@ietfa.amsl.com>; Sun, 22 Nov 2015 23:06:32 -0800 (PST)
Received: from mxout26.s.uw.edu (mxout26.s.uw.edu []) (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 57A281B3166 for <hipsec@ietf.org>; Sun, 22 Nov 2015 23:06:32 -0800 (PST)
Received: from hymn03.u.washington.edu (hymn03.u.washington.edu []) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW15.02) with ESMTP id tAN75k3K028881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <hipsec@ietf.org>; Sun, 22 Nov 2015 23:05:47 -0800
Received: from hymn03.u.washington.edu (localhost []) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+UW14.04) with ESMTP id tAN75gVo020421 for <hipsec@ietf.org>; Sun, 22 Nov 2015 23:05:42 -0800
Received: from localhost (Unknown UID 15408@localhost) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id tAN75g1w020418 for <hipsec@ietf.org>; Sun, 22 Nov 2015 23:05:42 -0800
X-Auth-Received: from [] by hymn03.u.washington.edu via HTTP; Sun, 22 Nov 2015 23:05:42 PST
Date: Sun, 22 Nov 2015 23:05:42 -0800
From: Tom Henderson <tomhend@u.washington.edu>
To: hipsec@ietf.org
Message-ID: <alpine.LRH.2.01.1511222305420.23520@hymn03.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.11.23.65717
X-PMX-Server: mxout26.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/kOemfEtkJYYlIO1VZKojBSOGgHg>
Subject: [Hipsec] RFC5206-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: <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: Mon, 23 Nov 2015 07:06:33 -0000

Well, the previous message's formatting certainly wasn't what I had in mind, so let's try again below.

On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote: 
> Authors of the following drafts, 
> > could you please let the WG know their status and what needs to happen 
> next for each of them in order to be able to WGLC them at some point in 
> the future? 
> > https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ 
> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ 

There are six open issues on RFC5206-bis, listed here: 

One of them (#12) probably should be closed now based on the draft version 09 published in July. 

One related to flow bindings (#23) probably can be left for further study, with no action at this time, since it hasn't been pursued for many years. 

One (#21) suggests to include HI parameter in the UPDATE, for benefit of middleboxes. Any objection to adding specification text that HI MAY be included in UPDATE? 

One (#15) suggests to name UPDATE packets with different names such as UPDATE1, UPDATE2, and UPDATE3, for clarity. I wonder whether this can be handled editorially without requiring code point allocation. 

One (#9) suggests to make some mandatory features optional, since at least one implementation does not implement all mandatory features. I think that perhaps this will require a review of both of the open source implementations to see whether any should be relaxed. 

One (#8) asks to allow that locator announcement may be decoupled from SA creation. This requires the definition of another example use case and extending the specification. 

In summary, I think that we could aim for another draft shortly that closes all of these issues. Perhaps the last one or two listed above represent the most work. Does anyone have further comments on these or other issues? 

- Tom