From thomas.r.henderson@boeing.com Tue Jan 1 23:23:53 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0621F910B for ; Tue, 1 Jan 2013 23:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXQc-VuVnMQx for ; Tue, 1 Jan 2013 23:23:52 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8821F879A for ; Tue, 1 Jan 2013 23:23:52 -0800 (PST) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r027OB8L017198 for ; Tue, 1 Jan 2013 23:24:11 -0800 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r027OBlJ017195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 1 Jan 2013 23:24:11 -0800 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 1 Jan 2013 23:23:51 -0800 From: "Henderson, Thomas R" To: "hipsec@ietf.org" Date: Tue, 1 Jan 2013 23:23:50 -0800 Thread-Topic: issue resolution on RFC5201-bis Thread-Index: Ac3ouhygxpKaWk33RbWmXptygd9/lQ== Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4D5DDF26@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [Hipsec] issue resolution on RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 07:23:53 -0000 I'd like to try to wrap up the open issues on RFC5201-bis. There are four = issues remaining in the tracker: 1) ticket 25: Orchid Generation Algorithm (http://trac.tools.ietf.org/wg/h= ip/trac/ticket/25) This issue was open to flag the need to revise RFC4843-bis. I believe that= this has been done and the documents are now consistent (although the 5201= -bis draft should point to the -03 version of the 4843-bis draft). I propo= se to close this with no further changes other than a reference refresh, if= there are no objections. 2) ticket 39: Improve text relating to R1 counter rollover (http://trac.t= ools.ietf.org/wg/hip/trac/ticket/39) I'd like to propose the following text change: OLD TEXT (sec 4.1.4): The R1 counter SHOULD NOT roll over. NEW TEXT: The R1 generation counter may roll over or may become reset. It is import= ant for an Initiator to be robust to the loss of state about the R1 generat= ion counter of a peer, or to a reset of the peer's counter. It is recommen= ded that, when choosing between multiple R1s, the Initiatior prefer to use = the R1 that is most consistent with the R1 generation counter, but that if = it is unable to make progress with that R1, the Initiator may try the other= R1s. 3) ticket 40: decreasing the per-packet overhead (http://trac.tools.ietf.o= rg/wg/hip/trac/ticket/40) Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding= , to make them more bit-efficient. The proposals seem reasonable to me but= there hasn't been much list discussion. Should we proceed with these chan= ges? (suggested in this email: http://www.ietf.org/mail-archive/web/hipse= c/current/msg03608.html) 4) ticket 41: LSI prefix range (http://trac.tools.ietf.org/wg/hip/trac/tic= ket/41) As I mentioned last month, it seems that the use of special IPv4 addresses = (loopback prefix or class E prefix) may cause problems on some operating sy= stems. =20 However, I just scanned the draft and couldn't find any place where we are = mentioning LSIs. It may be out of scope for 5201-bis. I propose to close = this with no changes, perhaps just updating the tracker issue with the resu= lts of the implementation survey. If there is a future need to specify LSI= ranges, it may be that RFC 1918 blocks or other address blocks known to be= unused in a HIP environment could be recommended as LSIs. We also have the open issue of IANA allocation of an Orchid prefix, but tha= t is a 4843-bis issue. - Tom From heer@informatik.rwth-aachen.de Tue Jan 8 14:11:50 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B011E80AE for ; Tue, 8 Jan 2013 14:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlRDk1vPMnmg for ; Tue, 8 Jan 2013 14:11:49 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5CE1F0CF5 for ; Tue, 8 Jan 2013 14:11:49 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MGB00FVVUZNZX30@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 08 Jan 2013 23:11:47 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.84,433,1355094000"; d="scan'208";a="206084729" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-1.rz.rwth-aachen.de with ESMTP; Tue, 08 Jan 2013 23:11:47 +0100 Received: from [192.168.1.100] ([unknown] [95.112.63.107]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MGB0004QUZNYA00@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 08 Jan 2013 23:11:47 +0100 (CET) Message-id: <50EC99A2.9020503@cs.rwth-aachen.de> Date: Tue, 08 Jan 2013 23:11:46 +0100 From: "Dr. Tobias Heer" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: hipsec@ietf.org References: <758141CC3D829043A8C3164DD3D593EA2E4D5DDF26@XCH-NW-16V.nw.nos.boeing.com> In-reply-to: <758141CC3D829043A8C3164DD3D593EA2E4D5DDF26@XCH-NW-16V.nw.nos.boeing.com> Subject: Re: [Hipsec] issue resolution on RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:11:50 -0000 Hello Tom, I'm sorry for the late reply. See my comments below. Am 02.01.2013 08:23, schrieb Henderson, Thomas R: > I'd like to try to wrap up the open issues on RFC5201-bis. There are four issues remaining in the tracker: > > 1) ticket 25: Orchid Generation Algorithm (http://trac.tools.ietf.org/wg/hip/trac/ticket/25) > > This issue was open to flag the need to revise RFC4843-bis. I believe that this has been done and the documents are now consistent (although the 5201-bis draft should point to the -03 version of the 4843-bis draft). I propose to close this with no further changes other than a reference refresh, if there are no objections. I agree. > > 2) ticket 39: Improve text relating to R1 counter rollover (http://trac.tools.ietf.org/wg/hip/trac/ticket/39) > > I'd like to propose the following text change: > > OLD TEXT (sec 4.1.4): > > The R1 counter SHOULD NOT roll over. > > NEW TEXT: > > The R1 generation counter may roll over or may become reset. It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer, or to a reset of the peer's counter. It is recommended that, when choosing between multiple R1s, the Initiatior prefer to use the R1 that is most consistent with the R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s. I think "most consistent" is ambiguous. I would rather say "with the least numerical distance" or "closest to" or even "identical to" because the last sentence already deals with the case that an identical counter is not available. The last sentence could be extended by: "may try other R1s with lower R1 counters beginning with the R1 packet with the highest counter". > > 3) ticket 40: decreasing the per-packet overhead (http://trac.tools.ietf.org/wg/hip/trac/ticket/40) > > Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding, to make them more bit-efficient. The proposals seem reasonable to me but there hasn't been much list discussion. Should we proceed with these changes? (suggested in this email: http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html) I think the proposals are valuable but I think the benefit of the changes would not justify the effort of implemeting these (at this late state). I would opt for leaving the protocol as it is now. > > 4) ticket 41: LSI prefix range (http://trac.tools.ietf.org/wg/hip/trac/ticket/41) > > As I mentioned last month, it seems that the use of special IPv4 addresses (loopback prefix or class E prefix) may cause problems on some operating systems. > > However, I just scanned the draft and couldn't find any place where we are mentioning LSIs. It may be out of scope for 5201-bis. I propose to close this with no changes, perhaps just updating the tracker issue with the results of the implementation survey. If there is a future need to specify LSI ranges, it may be that RFC 1918 blocks or other address blocks known to be unused in a HIP environment could be recommended as LSIs. I agree that this can be handled later if the need arises. Thanks for your work. Tobias > > We also have the open issue of IANA allocation of an Orchid prefix, but that is a 4843-bis issue. > > - Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From internet-drafts@ietf.org Wed Jan 16 09:55:57 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61B21F8B4C; Wed, 16 Jan 2013 09:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3luuOK2ZNSuj; Wed, 16 Jan 2013 09:55:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4821F8ACE; Wed, 16 Jan 2013 09:55:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130116175556.31195.22939.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2013 09:55:56 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:55:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Mobility with the Host Identity Protocol Author(s) : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-05.txt Pages : 33 Date : 2013-01-16 Abstract: This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5206-bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jan 16 09:56:18 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5177E21F8BC0; Wed, 16 Jan 2013 09:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RVFurTvIn7H; Wed, 16 Jan 2013 09:56:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16521F8BBA; Wed, 16 Jan 2013 09:56:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130116175617.31200.26597.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2013 09:56:17 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:56:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Multihoming with the Host Identity Protocol Author(s) : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-02.txt Pages : 22 Date : 2013-01-16 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-multihoming-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-multihoming-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.r.henderson@boeing.com Wed Jan 16 10:12:46 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3F21F86B2 for ; Wed, 16 Jan 2013 10:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3glTZ2944JRC for ; Wed, 16 Jan 2013 10:12:45 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id A2C9D21F86AE for ; Wed, 16 Jan 2013 10:12:45 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r0GICjN6001186 for ; Wed, 16 Jan 2013 10:12:45 -0800 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r0GICibH001183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 16 Jan 2013 10:12:44 -0800 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 16 Jan 2013 10:12:44 -0800 From: "Henderson, Thomas R" To: "'Dr. Tobias Heer'" , "hipsec@ietf.org" Date: Wed, 16 Jan 2013 10:12:44 -0800 Thread-Topic: [Hipsec] issue resolution on RFC5201-bis Thread-Index: Ac3t7Ss+zzu90ga+QlyMHs6RsW037wGJk1jA Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4D5DE018@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA2E4D5DDF26@XCH-NW-16V.nw.nos.boeing.com> <50EC99A2.9020503@cs.rwth-aachen.de> In-Reply-To: <50EC99A2.9020503@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [Hipsec] issue resolution on RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:12:46 -0000 Tobias, inline below... >=20 > > I'd like to try to wrap up the open issues on RFC5201-bis. There are > four issues remaining in the tracker: > > > > 1) ticket 25: Orchid Generation Algorithm > > (http://trac.tools.ietf.org/wg/hip/trac/ticket/25) > > > > This issue was open to flag the need to revise RFC4843-bis. I > believe that this has been done and the documents are now consistent > (although the 5201-bis draft should point to the -03 version of the > 4843-bis draft). I propose to close this with no further changes other > than a reference refresh, if there are no objections. >=20 > I agree. I closed this accordingly, as there were no other comments. > > > > 2) ticket 39: Improve text relating to R1 counter rollover > > (http://trac.tools.ietf.org/wg/hip/trac/ticket/39) > > > > I'd like to propose the following text change: > > > > OLD TEXT (sec 4.1.4): > > > > The R1 counter SHOULD NOT roll over. > > > > NEW TEXT: > > > > The R1 generation counter may roll over or may become reset. It is > important for an Initiator to be robust to the loss of state about the > R1 generation counter of a peer, or to a reset of the peer's counter. > It is recommended that, when choosing between multiple R1s, the > Initiatior prefer to use the R1 that is most consistent with the R1 > generation counter, but that if it is unable to make progress with that > R1, the Initiator may try the other R1s. > I think "most consistent" is ambiguous. I would rather say "with the > least numerical distance" or "closest to" or even "identical to" > because the last sentence already deals with the case that an identical > counter is not available. The last sentence could be extended by: "may > try other R1s with lower R1 counters beginning with the R1 packet with > the highest counter". New text proposal, based on your input: The R1 generation counter may roll over or may become reset. It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer, or to a reset of the peer's counter. It is recommended that, when choosing between multiple R1s, the Initiatior prefer to use the R1 that corresponds to the current R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s beginning with the R1 packet with the highest counter. >=20 > > > > 3) ticket 40: decreasing the per-packet overhead > > (http://trac.tools.ietf.org/wg/hip/trac/ticket/40) > > > > Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER > > encoding, to make them more bit-efficient. The proposals seem > > reasonable to me but there hasn't been much list discussion. Should > > we proceed with these changes? (suggested in this email: > > http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html) >=20 > I think the proposals are valuable but I think the benefit of the > changes would not justify the effort of implemeting these (at this late > state). I would opt for leaving the protocol as it is now. Since there were no other comments, I believe that we can stay with the status quo and leave these enhancements for future work. >=20 > > > > 4) ticket 41: LSI prefix range > > (http://trac.tools.ietf.org/wg/hip/trac/ticket/41) > > > > As I mentioned last month, it seems that the use of special IPv4 > addresses (loopback prefix or class E prefix) may cause problems on > some operating systems. > > > > However, I just scanned the draft and couldn't find any place where > we are mentioning LSIs. It may be out of scope for 5201-bis. I > propose to close this with no changes, perhaps just updating the > tracker issue with the results of the implementation survey. If there > is a future need to specify LSI ranges, it may be that RFC 1918 blocks > or other address blocks known to be unused in a HIP environment could > be recommended as LSIs. > I agree that this can be handled later if the need arises. I just closed this issue and left some documentation in the tracker. We have two open issues above but I think they can be closed as suggested a= bove; I'll close them on Friday if there are no other comments by then. - Tom