From nobody Wed Aug 3 20:44:16 2016 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 C69FE12D63A for ; Wed, 3 Aug 2016 20:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VVbiCXwOL2I5 for ; Wed, 3 Aug 2016 20:44:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 33EE512D16F for ; Wed, 3 Aug 2016 20:44:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 656436226F for ; Wed, 3 Aug 2016 23:44:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hxXj-bFazKoU for ; Wed, 3 Aug 2016 23:44:05 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9B4E262234 for ; Wed, 3 Aug 2016 23:44:05 -0400 (EDT) References: <20160804033724.9697.45981.idtracker@ietfa.amsl.com> To: HIP From: Robert Moskowitz X-Forwarded-Message-Id: <20160804033724.9697.45981.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 3 Aug 2016 23:43:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160804033724.9697.45981.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D158288EED94F4A8400475D3" Archived-At: Subject: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 04 Aug 2016 03:44:15 -0000 This is a multi-part message in MIME format. --------------D158288EED94F4A8400475D3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hierarchical HITs were in the original HIP proposal. See: draft-moskowitz-hip-06.txt Xiaohu proposed them in hiprg: draft-jiang-hiprg-hhit-arch-04.txt Now I am working with Xiaohu on a 5GPP mobility proposal. Hierarchical HITs and HIP ID/Locator split are central to the proposal. Please take a look at this draft. In the coming months there will be more, fusing HIP to other mobility technology as appropriate. I want to reach out to others in developing and putting this concept forward. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt Date: Wed, 03 Aug 2016 20:37:24 -0700 From: internet-drafts@ietf.org To: Xiaohu Xu , Robert Moskowitz A new version of I-D, draft-moskowitz-hierarchical-hip-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hierarchical-hip Revision: 00 Title: Hierarchical HITs for HIPv2 Document date: 2016-08-03 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hierarchical-hip-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hierarchical-hip/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hierarchical-hip-00 Abstract: This document describes using a hierarchical HIT to facilitate large deployments in mobile networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------D158288EED94F4A8400475D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hierarchical HITs were in the original HIP proposal.  See:

draft-moskowitz-hip-06.txt

Xiaohu proposed them in hiprg:

draft-jiang-hiprg-hhit-arch-04.txt

Now I am working with Xiaohu on a 5GPP mobility proposal.  Hierarchical HITs and HIP ID/Locator split are central to the proposal.

Please take a look at this draft.  In the coming months there will be more, fusing HIP to other mobility technology as appropriate.  I want to reach out to others in developing and putting this concept forward.


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt
Date: Wed, 03 Aug 2016 20:37:24 -0700
From: internet-drafts@ietf.org
To: Xiaohu Xu <xuxiaohu@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


A new version of I-D, draft-moskowitz-hierarchical-hip-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-hierarchical-hip
Revision:	00
Title:		Hierarchical HITs for HIPv2
Document date:	2016-08-03
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-hierarchical-hip-00.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-hierarchical-hip/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-hierarchical-hip-00


Abstract:
   This document describes using a hierarchical HIT to facilitate large
   deployments in mobile networks.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------D158288EED94F4A8400475D3-- From nobody Wed Aug 3 21:42:46 2016 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 5040212D110; Wed, 3 Aug 2016 21:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 OnGBVQzpNDIk; Wed, 3 Aug 2016 21:42:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACF012D0FE; Wed, 3 Aug 2016 21:42:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COV96668; Thu, 04 Aug 2016 04:42:37 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Aug 2016 05:42:36 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 4 Aug 2016 12:42:31 +0800 From: Xuxiaohu To: Robert Moskowitz , HIP Thread-Topic: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt Thread-Index: AQHR7gGNHdZF1Xtm30WZNkoE25NI/KA3or0AgACOaxA= Date: Thu, 4 Aug 2016 04:42:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231@NKGEML515-MBX.china.huawei.com> References: <20160804033724.9697.45981.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57A2C7BE.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b52a9fd733c2833aa612cfcc091b6eb6 Archived-At: Cc: "5gangip@ietf.org" <5gangip@ietf.org> Subject: Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 04 Aug 2016 04:42:44 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KENjZWQgdG8gNWdhbmdpcCBtYWlsaW5nLWxpc3Qgc2luY2UgcGVvcGxlIGludm9sdmVkIGluIHRo YXQgbWFpbGluZy1saXN0IG1heSBiZSBpbnRlcmVzdGVkIG9uIHRoaXMpDQoNCkhpLA0KDQpJbiBh ZGRpdGlvbiwgdGhlIGNvbmNlcHQgb2YgaGllcmFyY2hpY2FsIGFuZCBzZWxmLWNlcnRpZmljYXRl ZCBob3N0IElEIGhhZCBldmVuIGJlZW4gY29uY3JldGVseSBkZXNjcmliZWQgaW4gKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1yYW5naS0wNCkgYW5kIHRoaXMgY29uY2VwdCBo YWQgYmVlbiB2ZXJpZmllZCBpbiBvdXIgcHJvdG90eXBlIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODIvc2xpZGVzL0hJUFJHLTcucGRmIGFuZCBodHRwOi8vd3d3LmlwY3Np dC5jb20vdm9sNDIvMDA5LUlDSU1UMjAxMC1EMDI5Mi5wZGYpLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0KRnJvbTogSGlwc2VjIFttYWlsdG86aGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBSb2JlcnQgTW9za293aXR6DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA0LCAy MDE2IDExOjQ0IEFNDQpUbzogSElQDQpTdWJqZWN0OiBbSGlwc2VjXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9za293aXR6LWhpZXJhcmNoaWNhbC1oaXAtMDAudHh0 DQoNCkhpZXJhcmNoaWNhbCBISVRzIHdlcmUgaW4gdGhlIG9yaWdpbmFsIEhJUCBwcm9wb3NhbC4g IFNlZToNCg0KZHJhZnQtbW9za293aXR6LWhpcC0wNi50eHQNCg0KWGlhb2h1IHByb3Bvc2VkIHRo ZW0gaW4gaGlwcmc6DQoNCmRyYWZ0LWppYW5nLWhpcHJnLWhoaXQtYXJjaC0wNC50eHQNCg0KTm93 IEkgYW0gd29ya2luZyB3aXRoIFhpYW9odSBvbiBhIDVHUFAgbW9iaWxpdHkgcHJvcG9zYWwuICBI aWVyYXJjaGljYWwgSElUcyBhbmQgSElQIElEL0xvY2F0b3Igc3BsaXQgYXJlIGNlbnRyYWwgdG8g dGhlIHByb3Bvc2FsLg0KDQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhpcyBkcmFmdC4gIEluIHRo ZSBjb21pbmcgbW9udGhzIHRoZXJlIHdpbGwgYmUgbW9yZSwgZnVzaW5nIEhJUCB0byBvdGhlciBt b2JpbGl0eSB0ZWNobm9sb2d5IGFzIGFwcHJvcHJpYXRlLiAgSSB3YW50IHRvIHJlYWNoIG91dCB0 byBvdGhlcnMgaW4gZGV2ZWxvcGluZyBhbmQgcHV0dGluZyB0aGlzIGNvbmNlcHQgZm9yd2FyZC4N Cg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0KTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tb3Nrb3dpdHotaGllcmFyY2hpY2FsLWhp cC0wMC50eHQNCg0KRGF0ZToNCg0KV2VkLCAwMyBBdWcgMjAxNiAyMDozNzoyNCAtMDcwMA0KDQpG cm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCg0KVG86DQoNClhpYW9odSBYdSA8eHV4aWFvaHVAaHVhd2VpLmNvbT48bWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb20+LCBSb2JlcnQgTW9za293aXR6IDxyZ21AaHR0LWNvbnN1bHQu Y29tPjxtYWlsdG86cmdtQGh0dC1jb25zdWx0LmNvbT4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1tb3Nrb3dpdHotaGllcmFyY2hpY2FsLWhpcC0wMC50eHQNCg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQgTW9za293aXR6IGFuZCBwb3N0ZWQgdG8g dGhlDQoNCklFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgICAgZHJhZnQtbW9za293 aXR6LWhpZXJhcmNoaWNhbC1oaXANCg0KUmV2aXNpb246ICAgICAwMA0KDQpUaXRsZTogICAgICAg IEhpZXJhcmNoaWNhbCBISVRzIGZvciBISVB2Mg0KDQpEb2N1bWVudCBkYXRlOiAyMDE2LTA4LTAz DQoNCkdyb3VwOiAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAg MTINCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tb3Nrb3dpdHotaGllcmFyY2hpY2FsLWhpcC0wMC50eHQNCg0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1vc2tvd2l0ei1oaWVy YXJjaGljYWwtaGlwLw0KDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW1vc2tvd2l0ei1oaWVyYXJjaGljYWwtaGlwLTAwDQoNCg0KDQoNCg0KQWJzdHJh Y3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHVzaW5nIGEgaGllcmFyY2hpY2FsIEhJ VCB0byBmYWNpbGl0YXRlIGxhcmdlDQoNCiAgIGRlcGxveW1lbnRzIGluIG1vYmlsZSBuZXR3b3Jr cy4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpjaXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDA2NjIxOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KENj ZWQgdG8gNWdhbmdpcCBtYWlsaW5nLWxpc3Qgc2luY2UgcGVvcGxlIGludm9sdmVkIGluIHRoYXQg bWFpbGluZy1saXN0IG1heSBiZSBpbnRlcmVzdGVkIG9uIHRoaXMpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox Ni4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JbiBhZGRpdGlvbiwgdGhlIGNvbmNlcHQgb2YgaGllcmFyY2hpY2FsIGFuZCBzZWxmLWNlcnRp ZmljYXRlZCBob3N0IElEIGhhZCBldmVuIGJlZW4gY29uY3JldGVseSBkZXNjcmliZWQgaW4gKDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1yYW5naS0wNCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXJhbmdpLTA0PC9hPikNCiBhbmQgdGhp cyBjb25jZXB0IGhhZCBiZWVuIHZlcmlmaWVkIGluIG91ciBwcm90b3R5cGUgKHNlZSA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9zbGlkZXMvSElQUkctNy5wZGYi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvc2xpZGVzL0hJUFJHLTcucGRm PC9hPiBhbmQgPGEgaHJlZj0iaHR0cDovL3d3dy5pcGNzaXQuY29tL3ZvbDQyLzAwOS1JQ0lNVDIw MTAtRDAyOTIucGRmIj4NCmh0dHA6Ly93d3cuaXBjc2l0LmNvbS92b2w0Mi8wMDktSUNJTVQyMDEw LUQwMjkyLnBkZjwvYT4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0 IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFv aHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+IEhpcHNlYyBbbWFpbHRvOmhpcHNlYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5Sb2JlcnQgTW9za293aXR6PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB dWd1c3QgMDQsIDIwMTYgMTE6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IEhJUDxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbSGlwc2VjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bW9za293aXR6LWhpZXJhcmNoaWNhbC1oaXAtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGllcmFyY2hpY2FsIEhJVHMgd2VyZSBpbiB0aGUgb3JpZ2luYWwgSElQIHBy b3Bvc2FsLiZuYnNwOyBTZWU6PGJyPg0KPGJyPg0KZHJhZnQtbW9za293aXR6LWhpcC0wNi50eHQ8 YnI+DQo8YnI+DQpYaWFvaHUgcHJvcG9zZWQgdGhlbSBpbiBoaXByZzo8YnI+DQo8YnI+DQpkcmFm dC1qaWFuZy1oaXByZy1oaGl0LWFyY2gtMDQudHh0PGJyPg0KPGJyPg0KTm93IEkgYW0gd29ya2lu ZyB3aXRoIFhpYW9odSBvbiBhIDVHUFAgbW9iaWxpdHkgcHJvcG9zYWwuJm5ic3A7IEhpZXJhcmNo aWNhbCBISVRzIGFuZCBISVAgSUQvTG9jYXRvciBzcGxpdCBhcmUgY2VudHJhbCB0byB0aGUgcHJv cG9zYWwuPGJyPg0KPGJyPg0KUGxlYXNlIHRha2UgYSBsb29rIGF0IHRoaXMgZHJhZnQuJm5ic3A7 IEluIHRoZSBjb21pbmcgbW9udGhzIHRoZXJlIHdpbGwgYmUgbW9yZSwgZnVzaW5nIEhJUCB0byBv dGhlciBtb2JpbGl0eSB0ZWNobm9sb2d5IGFzIGFwcHJvcHJpYXRlLiZuYnNwOyBJIHdhbnQgdG8g cmVhY2ggb3V0IHRvIG90aGVycyBpbiBkZXZlbG9waW5nIGFuZCBwdXR0aW5nIHRoaXMgY29uY2Vw dCBmb3J3YXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1l c3NhZ2UgLS0tLS0tLS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5 bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0Og0KPG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1vc2tvd2l0ei1oaWVyYXJjaGljYWwtaGlw LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5v d3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5EYXRlOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZWQsIDAzIEF1ZyAyMDE2IDIwOjM3OjI0IC0w NzAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFw PSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+VG86 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlhpYW9odSBYdSA8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbSI+DQombHQ7eHV4 aWFvaHVAaHVhd2VpLmNvbSZndDs8L2E+LCBSb2JlcnQgTW9za293aXR6IDxhIGhyZWY9Im1haWx0 bzpyZ21AaHR0LWNvbnN1bHQuY29tIj4NCiZsdDtyZ21AaHR0LWNvbnN1bHQuY29tJmd0OzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1vc2tvd2l0ei1oaWVyYXJjaGlj YWwtaGlwLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQgTW9za293aXR6 IGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LW1vc2tvd2l0ei1oaWVyYXJjaGljYWwtaGlwPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXZpc2lvbjombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBIaWVyYXJjaGljYWwgSElUcyBmb3IgSElQdjI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkRvY3VtZW50IGRhdGU6IDIwMTYtMDgtMDM8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkdyb3VwOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlBhZ2VzOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VVJMOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9za293aXR6LWhp ZXJhcmNoaWNhbC1oaXAtMDAudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbW9za293aXR6LWhpZXJhcmNoaWNhbC1oaXAtMDAudHh0PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U3RhdHVzOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb3Nrb3dpdHotaGllcmFyY2hpY2FsLWhpcC8i Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1vc2tvd2l0ei1oaWVyYXJj aGljYWwtaGlwLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9za293aXR6LWhpZXJhcmNo aWNhbC1oaXAtMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3Nrb3dpdHot aGllcmFyY2hpY2FsLWhpcC0wMDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB1c2lu ZyBhIGhpZXJhcmNoaWNhbCBISVQgdG8gZmFjaWxpdGF0ZSBsYXJnZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGRlcGxveW1lbnRz IGluIG1vYmlsZSBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRG IFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231NKGEML515MBXchi_-- From nobody Thu Aug 4 08:57:19 2016 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 D790E12D8BA; Thu, 4 Aug 2016 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5G_KIQrY7Fd3; Thu, 4 Aug 2016 08:57:15 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE70812D8C7; Thu, 4 Aug 2016 08:57:09 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id j59so177201349uaj.3; Thu, 04 Aug 2016 08:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xTpILKwSH7WpBcyvo+HUIOOBul31KsZzb86JdQOBykI=; b=SKtiq8Clc/CxynMBjPsHTD0jcZSZvUmzxD3h18F+o4qCvmUovoJZGk2guMBzW2+Nq3 aUbqBPMmzhYQhprdQViVgLL4MAa2dTMrGT1wjxpKyjXxkv4jaO4Kje+d65/80F0fIgT7 4cf3o0Nnm31CQCI1t0QylD3fWJIJaXdWoVEXimkDWRlWjChPtPcH4FeQMcTU0ZVPuSX6 LOHo6nZgxdaSqzzRnvDyXNMGT6EccdlTC7bSdF4HrkEXJ6v1yuOkYWVh/jEQsL5riA+z VnGPYIr/hR4q7PqqtIJUgfxt57Uhm0KjjJs/cr9PxitLFw2iq8R8m+QmdUNgZH5ofe+p gM8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=xTpILKwSH7WpBcyvo+HUIOOBul31KsZzb86JdQOBykI=; b=gpHnGNxjakp2x0WsYZDtXLr3Tv4Y98G3ZyrGbhFtXx83aliS9ien7R8vrI48FcKUAi qXmC4EPCj3xYPzEIfbcdciFg90bgGm+eZfiB4Qepw268ZMmJJDlHaEdatt21xldwUiYH eQahhLowuehAkAhlglliQ3C/o0NaxX/8J4Be0H5sWOx5BRZ5z2jYpOgbz1+sC+F0KBfq E3u8JUFx/sBtqOM7Bk1n/21dGVSl64aSjuIS5jV+TQyHGlejOJxYhIk7NGi9pRyJOymW DV+vyovsU03bR5+tu7InltWICdnk1s6TsfnU/ri1l7XXK0IBgLFCKfe62phAzCdX4fFa EQFw== X-Gm-Message-State: AEkoouulKFBWPD3n9QhF1oJxfQR0vD5haeqB5W8NoPMaQMBCYF1dRV13Gv25VtmufSfNY4fWHxhR1u9F2u7h1A== X-Received: by 10.176.2.242 with SMTP id 105mr3734573uah.10.1470326229016; Thu, 04 Aug 2016 08:57:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.112 with HTTP; Thu, 4 Aug 2016 08:57:08 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231@NKGEML515-MBX.china.huawei.com> References: <20160804033724.9697.45981.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E231@NKGEML515-MBX.china.huawei.com> From: Behcet Sarikaya Date: Thu, 4 Aug 2016 10:57:08 -0500 Message-ID: To: Xuxiaohu Content-Type: multipart/alternative; boundary=001a1142e55095ab1b0539410050 Archived-At: Cc: HIP , "5gangip@ietf.org" <5gangip@ietf.org> Subject: Re: [Hipsec] [5gangip] Fwd: New Version Notification for draft-moskowitz-hierarchical-hip-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org 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: Thu, 04 Aug 2016 15:57:18 -0000 --001a1142e55095ab1b0539410050 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 3, 2016 at 11:42 PM, Xuxiaohu wrote: > (Cced to 5gangip mailing-list since people involved in that mailing-list > may be interested on this) > > > > Hi, > > > > In addition, the concept of hierarchical and self-certificated host ID had > even been concretely described in (https://tools.ietf.org/html/ > draft-xu-rangi-04) and this concept had been verified in our prototype > (see https://www.ietf.org/proceedings/82/slides/HIPRG-7.pdf and > http://www.ipcsit.com/vol42/009-ICIMT2010-D0292.pdf). > > > I noticed that Bob Moskowitz is talking about 5G but he is not in 5G list. So I subscribed him to the list. Behcet > Best regards, > > Xiaohu > > > > *From:* Hipsec [mailto:hipsec-bounces@ietf.org] *On Behalf Of *Robert > Moskowitz > *Sent:* Thursday, August 04, 2016 11:44 AM > *To:* HIP > *Subject:* [Hipsec] Fwd: New Version Notification for > draft-moskowitz-hierarchical-hip-00.txt > > > > Hierarchical HITs were in the original HIP proposal. See: > > draft-moskowitz-hip-06.txt > > Xiaohu proposed them in hiprg: > > draft-jiang-hiprg-hhit-arch-04.txt > > Now I am working with Xiaohu on a 5GPP mobility proposal. Hierarchical > HITs and HIP ID/Locator split are central to the proposal. > > Please take a look at this draft. In the coming months there will be > more, fusing HIP to other mobility technology as appropriate. I want to > reach out to others in developing and putting this concept forward. > > > > -------- Forwarded Message -------- > > *Subject: * > > New Version Notification for draft-moskowitz-hierarchical-hip-00.txt > > *Date: * > > Wed, 03 Aug 2016 20:37:24 -0700 > > *From: * > > internet-drafts@ietf.org > > *To: * > > Xiaohu Xu , Robert Moskowitz > > > > > A new version of I-D, draft-moskowitz-hierarchical-hip-00.txt > > has been successfully submitted by Robert Moskowitz and posted to the > > IETF repository. > > > > Name: draft-moskowitz-hierarchical-hip > > Revision: 00 > > Title: Hierarchical HITs for HIPv2 > > Document date: 2016-08-03 > > Group: Individual Submission > > Pages: 12 > > URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hierarchical-hip-00.txt > > Status: https://datatracker.ietf.org/doc/draft-moskowitz-hierarchical-hip/ > > Htmlized: https://tools.ietf.org/html/draft-moskowitz-hierarchical-hip-00 > > > > > > Abstract: > > This document describes using a hierarchical HIT to facilitate large > > deployments in mobile networks. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > > --001a1142e55095ab1b0539410050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 3, 2016 at 11:42 PM, Xuxiaohu <xuxiaohu@huawei.com&g= t; wrote:

(Cced= to 5gangip mailing-list since people involved in that mailing-list may be = interested on this)

=C2=A0

Hi,

=C2=A0

In ad= dition, the concept of hierarchical and self-certificated host ID had even = been concretely described in (https://tools.ietf.org/html/draft-xu-ra= ngi-04) and this concept had been verified in our prototype (see https://www.ietf.org/proceedings/82/slides/HIPRG-7.pdf and http://www.ipcsit.com/vol42/009-ICIMT2010-D0292.pdf).

=C2=A0


I noticed t= hat Bob Moskowitz is talking about 5G but he is not in 5G list.
S= o I=C2=A0subscribed=C2=A0him=C2=A0to the list.

Beh= cet

Best = regards,

Xiaoh= u

=C2=A0

From: Hipsec [mailto:hipsec-bounces@ietf.<= wbr>org] On Behalf Of Robert Moskowitz
Sent: Thursday, August 04, 2016 11:44 AM
To: HIP
Subject: [Hipsec] Fwd: New Version Notification for draft-moskowitz-= hierarchical-hip-00.txt

=C2=A0

Hierarchical HITs were in the o= riginal HIP proposal.=C2=A0 See:

draft-moskowitz-hip-06.txt

Xiaohu proposed them in hiprg:

draft-jiang-hiprg-hhit-arch-04.txt

Now I am working with Xiaohu on a 5GPP mobility proposal.=C2=A0 Hierarchica= l HITs and HIP ID/Locator split are central to the proposal.

Please take a look at this draft.=C2=A0 In the coming months there will be = more, fusing HIP to other mobility technology as appropriate.=C2=A0 I want = to reach out to others in developing and putting this concept forward.



-------- Forwarded Message --------

Subject:

New Version Notification for dr= aft-moskowitz-hierarchical-hip-00.txt

Date:

Wed, 03 Aug 2016 20:37:24 -0700=

From:

internet-drafts@ietf.org

To:

Xiaohu Xu <xuxiaohu@huawei.com>, Robert Moskowitz <rgm@htt-consult.com>

=C2=A0

A new version of I-D, draft-moskowitz-hierarchica=
l-hip-00.txt
has been successfully submitted by Robert Moskowi=
tz and posted to the
IETF repository.
=C2=A0
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 draft-moskowitz-hierarchical-hip
Revision:=C2=A0=C2=A0=C2=A0=C2=A0 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Hierarchical HITs for HIPv2
Document date: 2016-08-03

Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Individual Submission


Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
12


URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/=
internet-drafts/draft-moskowitz-hierarchical-hip-00.txt


Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 https://datatracker.ietf.org/doc/draft-mo=
skowitz-hierarchical-hip/


Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-moskowitz-hierarchic=
al-hip-00


=C2=A0


=C2=A0


Abstract:


=C2=A0=C2=A0 This document describes using a hier=
archical HIT to facilitate large


=C2=A0=C2=A0 deployments in mobile networks.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 


=C2=A0


=C2=A0


Please note that it may take a couple of minutes =
from the time of submission


until the htmlized version and diff are available=
 at tools.ietf.org.=



=C2=A0


The IETF Secretariat


=C2=A0


=C2=A0

_______________________________________________
5gangip mailing list
5gangip@ietf.org
https://www.ietf.org/mailman/listinfo/5gangip<= br>

--001a1142e55095ab1b0539410050-- From nobody Thu Aug 4 17:40:16 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0912B029; Thu, 4 Aug 2016 17:40:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805004011.15868.62616.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 17:40:11 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:40:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Identity Protocol (HIP) Registration Extension Authors : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5203-bis-11.txt Pages : 16 Date : 2016-08-04 Abstract: This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC5203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5203-bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 17:40:42 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6112DB66; Thu, 4 Aug 2016 17:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805004033.15811.5397.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 17:40:33 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5204-bis-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extension Authors : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5204-bis-08.txt Pages : 14 Date : 2016-08-04 Abstract: This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5204-bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 17:40:58 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2072912DB50; Thu, 4 Aug 2016 17:40:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805004051.15876.72142.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 17:40:51 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5205-bis-10.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:40:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extension Author : Julien Laganier Filename : draft-ietf-hip-rfc5205-bis-10.txt Pages : 18 Date : 2016-08-04 Abstract: This document specifies a resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5205-bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5205-bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 17:42:30 2016 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 4C5BF12D636; Thu, 4 Aug 2016 17:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pIwny5lox9fL; Thu, 4 Aug 2016 17:42:27 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F3F12DB52; Thu, 4 Aug 2016 17:42:27 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j185so343824824oih.0; Thu, 04 Aug 2016 17:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DJX3MaS2ul4QUuA2M3ayTfvl1+ugn/jZYivq1SfuXeA=; b=OmPp/H6bDa3Sa26YpC5Q2+iG80wIVMzCCHEjzBiIkjmZXhpVM/accmpivAD8rOy3Bd SRqeq0/Zc1Q81WumWpa5X/EgLOxoMtT5ZFQri/tcNvK5kdrVf9dy6Ok7dCCoA0SB6At1 pv/BgycshWpPpwSF9G9XTV9tOS5UiCtCYFLl5EsiBm7aH6P8tEGk4dmN77rlpfe/YcKC 0QANYW8dxy4STr+DtbxmK/SkvePeNp9PlFVPTVpREdiPECYq3auKytXTb1osOm9Hmfyt 8MI7ifg7/ws+TcpiohidGLahsEH41QRpfjBj2A/GnCoR/DXOABEdyRNRNyipy6LODRrG J7rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DJX3MaS2ul4QUuA2M3ayTfvl1+ugn/jZYivq1SfuXeA=; b=ammo1rvK76kWAeSLpHPNEfntlzMbYvc00i7z/qT2vZ031PFtbeMVgdqPML1R34SYC7 xQuqrC6EP9uH01MdndEOsNp4RaquIa1xMNzgFuY0zeDw2jVdtmTMf9AsW9HyBwZ7TAfA r5TA0SWxVMYV17kiqo7N4AP3W3nECjxuhj/durqOl2IgwVzZKnewnlX2WzQrhjtSdTOj i0n/MN/+5ZsUC+btrnONRB5zVAI4m0eN2/2ja1mDcMYXWGgGKfa1pq7nXMatc8aO4h7o RkFuPhQZFPFmmo5H3d52t1X9fsWUAmWj21/azK7kOM80C6w2o2PGF6Z/bnZq2ASWWn8u lIGw== X-Gm-Message-State: AEkoousNsdFIOb+MpYDbIicS7ONOot7aJuNB/sujFLhZydY7YQENHWvTfOHRNmT8vO7dN7N+7z2faLCRO55sPQ== X-Received: by 10.157.32.33 with SMTP id n30mr16473841ota.120.1470357746469; Thu, 04 Aug 2016 17:42:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Thu, 4 Aug 2016 17:42:25 -0700 (PDT) In-Reply-To: <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> From: Julien Laganier Date: Thu, 4 Aug 2016 17:42:25 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:42:29 -0000 Hi Stephen, FYI I've implemented the proposed change in the last draft revision. Best, --julien On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell wrote: > > Hiya, > > That'd be fine for clearing my discuss. > > I'd encourage you to also get feedback from the WG though as I > don't think I've ever seen a list of cert handling errors that > was correct first time around:-) > > Cheers, > S. > > > > On 20/07/16 16:11, Julien Laganier wrote: >> Hi Stephen, >> >> Thanks for reviewing the document. >> >> I think there would be value in making the cause of certificate error >> explicit. Would the following change be acceptable? >> >> OLD: >> >> If the certificate in the parameter is not accepted, the registrar >> MUST reject the corresponding registrations with Failure Type [IANA >> TBD] (Invalid certificate). >> >> NEW: >> >> If the certificate in the parameter is not accepted, the registrar >> MUST reject the corresponding registrations with the appropriate >> Failure Type: >> [IANA TBD] (Bad certificate): The certificate is corrupt, contains >> invalid signatures, etc. >> [IANA TBD] (Unsupported certificate): The certificate is of an >> unsupported type. >> [IANA TBD] (Certificate expired): The certificate is no longer valid. >> [IANA TBD] (Certificate other): The certificate could not be >> validated for some unspecified reason. >> [IANA TBD] (Unknown CA): The issuing CA certificate could not be >> located or is not trusted. >> >> Please let us know. >> >> Best, >> >> --julien >> >> >> >> >> On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell >> wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-hip-rfc5203-bis-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> 3.3 - This fails to distinguish between an invalid >>> certificate (e.g. bad signature, unknown signer) and one >>> that is valid, but is not acceptable for this purpose. I >>> don't get why that is ok for HIP, can you explain? If it >>> is ok, I think you need to say so. If it is not ok (as I'd >>> suspect) then you appear to need to change text or one more >>> new error code. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> Section 7 - I'm fine that this doesn't repeat stuff >>> from 5203, but a sentence saying to go look there too >>> would maybe be good. (I'm not sure if that would fix >>> Alexey's discuss or not. If not, then ignore me and >>> just talk to him about his discuss.) >>> >>> > From nobody Thu Aug 4 17:44:39 2016 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 9BB0912D6B3 for ; Thu, 4 Aug 2016 17:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wHpTTqIJjwu3 for ; Thu, 4 Aug 2016 17:44:35 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5403312B011 for ; Thu, 4 Aug 2016 17:44:35 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id 4so134806101oih.2 for ; Thu, 04 Aug 2016 17:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ES5mS8AvIOQ9UmdYX05mZazeCXm09HKy4McX9Q7T9ns=; b=0zQEPDFGwncqDzhzMPmjqlcsAl0wfz5KqdQtyjv427u3AmxA7Bg1AIH1fm7AHYtynu esvHhUOjwFymcdbdYPV4MJ7UVQClZ34uCbwvJ3g0pJKygiDOdyNqcpXtX6qcBhiwfhRc i2vTeINC4Kv+tR0ZekdkCGUIAz2jCWejyMAuyAfgbNu2KQ324+D7pzxcURPUceoNqLe/ 7jxJxWcA4FTDxnoH9aACzziBiyvI741uHyOf7nZ/fIBCJE69ytin8Q95M3to78ZyH3/A AKHcBNN8UaA/nywZsfoih65tQVresyQ/fE82Q2EnceRd8t0Pi8pjyV8x+8YJ6SPDcQn8 CdYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ES5mS8AvIOQ9UmdYX05mZazeCXm09HKy4McX9Q7T9ns=; b=RQG8DlNEEu5zzYWfO3OAe3pk1mX0fE6+/ZDNcjWKmhVTw5BnnEBkM4ZBLDBHbRwDi4 Ok7optSIYwleFRLvRMruoTG+xY4ZigT3uCshw7vZHN7rQbs3PyrMNuEHhkXH3mC5C/0w g8Mht8S6nD3v2fVXjUZvJyAtckrJiO80cvft5eAqUWhV/1hs2eK1HgJtQ3AnAuoRQUKv rZPArEEmA06zmE2vQQ4FPfA+701FOIQYxPDhcKk9ku13fmYX364QeSBu0SZMiy0kXyVr I7om8Fq1Hfs9PrGS3eskIyTwRAGi9fAGk2bJ73nN6lHv6GHGbA/p6iS/x3PGM2gpbZqk o/OA== X-Gm-Message-State: AEkoouvlRE4Nc9nl1xIaR7sPrsnAFyBPhIVsBbupXZd2JVQBwrCNYNL/BoC4utKGojlIrLUqiWdj+dwcdLNHdw== X-Received: by 10.202.84.72 with SMTP id i69mr45795699oib.93.1470357874723; Thu, 04 Aug 2016 17:44:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Thu, 4 Aug 2016 17:44:34 -0700 (PDT) In-Reply-To: References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm> From: Julien Laganier Date: Thu, 4 Aug 2016 17:44:34 -0700 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , Alexey Melnikov Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:44:37 -0000 Hi Ben and Alexey, FYI, I've updated the three drafts with the proposal above for IANA considerations update. Best, --julien On Fri, Jul 15, 2016 at 12:17 AM, Ben Campbell wrote: > > >> On Jul 15, 2016, at 8:53 AM, Alexey Melnikov wrote: >> >> Hi Julien, >> >>> On 15 Jul 2016, at 02:17, Julien Laganier wrote: >>> >>> Hi Ben & Alexey, >>> >>> Thanks for clarifying. We've discussed your suggestion with Terry >>> Manderson from IANA and have agreed on proceeding as follows: >>> >>> RFCXXXX, obsoleted by this document, made the following IANA >>> allocation in : . >> >> ... and the allocation policy. > > Yes, that too. > >> >>> IANA is requested to replace references to [RFCXXXX] by references to >>> this document in the the registry. >>> >>> This document also requests IANA to make these additional >> new allocation> in ". >>> >>> If this is okay with you both I will proceed with updating >>> draft-ietf-hip-rfc520{3,4,5}-bis accordingly. >> >> Sounds good to me. > > Me, too. > > Thanks! > > Ben > >> >> Thank you, >> Alexey >>> >>> Best, >>> >>> --julien >>> >>> >>> >>>> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: >>>> On 8 Jul 2016, at 10:53, Tom Henderson wrote: >>>> >>>>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >>>>>> wrote: >>>>>>> >>>>>>> Alexey Melnikov has entered the following ballot position for >>>>>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>>>>> ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> The IANA considerations section does not seem to stand alone without >>>>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be >>>>>>> expected to read it in order to discover original IANA instructions. >>>>>>> I think you should copy information from RFC 5204. >>>>> >>>>>> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> The IANA Considerations used to be a copy of RFC 5204 but someone >>>>>> asked that it be cleaned up. I will copy it back in the next revision. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> --julien >>>>> >>>>> >>>>> I was probably the person suggesting the current writeup, based on my >>>>> previous interaction with IANA regarding RFC 7401 publication. >>>>> >>>>> Before making any IANA section changes, I would like to ask for further >>>>> clarification, because it seems to me that the guidance being given now >>>>> conflicts with instructions we received from IANA when revising RFC 5201 to >>>>> become RFC 7401. >>>>> >>>>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy >>>>> forward the IANA section" approach, but were told by IANA that they >>>>> preferred that we instead state the updates to be taken on existing >>>>> registries rather than repeating earlier actions that were already taken to >>>>> create the registries. >>>> >>>> >>>> In my opinion, you need both. The text needs to make it clear what actions >>>> IANA needs to take _now_. But it also needs to fully document any >>>> registries/registrations so that other readers can find it, keeping in mind >>>> that an obsoleted RFC is, well, obsolete. Note that this is usually at least >>>> somewhat different from simply copying the old text forward. This is >>>> especially true when updating the reference for a registry or registration >>>> to point to the bis document; this only makes sense if the bis draft >>>> actually describes that registry or registration. >>>> >>>> I think it's perfectly reasonable to say something of the form of "RFCXXXX, >>>> obsoleted by this document, made these requests of IANA: . This >>>> document mades these additional requests: " >>>> >>>> >>>>> >>>>> That led to the following revisions (where you can see, when using the >>>>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 it >>>>> updates the existing registries): >>>>> >>>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >>>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >>>>> >>>>> - Tom >> > From nobody Thu Aug 4 17:46:11 2016 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 93A1E12D68D; Thu, 4 Aug 2016 17:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qEv0ftV-AnfW; Thu, 4 Aug 2016 17:46:08 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD68812B011; Thu, 4 Aug 2016 17:46:08 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id f189so70019383oig.3; Thu, 04 Aug 2016 17:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OEAK0zE5QiewnZFvBASyqThe/0PkssFEhJvkUoTvaT8=; b=PvM0KtGfx28461wxWSYrFeQEvbOlQQ+xOPn4/Jey58I6/PIAxhGHViOeRHYrvsPzgT SYG5p7PU9GjCUe0R20Hoc8gAwMDZJPIVOC1WhT/19NZhe4YQ7Nm0K862FhVi/oymHrxb 7r9PhvFlk8zfDBbi07S3B9nVoe2ffGm0HXWucLfOwfUsBTU1BGY3aiOfS03wklOD+hjB 6sSMbZMXyN5fMeaIxaZbDC1axiYQKsZOX7yd65Mynyg+AE9Cr2DL9XN7cT8ZbEHXV+jF xhr4yH2u9rm5BXOGP7zua9EiuL+OX9/IgfAb9y6lXMGc4SH5v0mFMQkZOfDUVaoUnnsc hvzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OEAK0zE5QiewnZFvBASyqThe/0PkssFEhJvkUoTvaT8=; b=YeT7G2Gg2IXQX0oDeKUbYu+iN6WVTIE5+qJurMetWrjLL82EkzXjnYDdKPw/mFRRTX a4yw0DP8P6MF1HwqfnZClPdKnghIuncNQRBGfrBQHPg2g3BWhqsq7eJHXq1S0zBUji3Z QCYqJbzcIMfAGEYafAyhBQV0WfRQkx7cb1yP8azfsAzz3paHjV9D1X57Jm0+dyCMlXaQ uSMl0trgc1rKeWdYUHHvrdAKwvl1oGSqbHySCW4M8CZu+X5NOmBZsjDmvs9koxoNAsMM dzj/q85ZJ7RqhpjoSwNCnaQJaCHirUbGSuXs4N4vGky4/wY1lvdW0etoVHxVDhFTFv5+ lhkA== X-Gm-Message-State: AEkoousWzIBRq0UbOXwf8EGSFiDAL79q3QDjEJjT4cDnFSWqRoG4MSD8LurGZYTt+dAJ4VFigPcp2YL2ItP5tA== X-Received: by 10.202.83.16 with SMTP id h16mr1918574oib.189.1470357968255; Thu, 04 Aug 2016 17:46:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Thu, 4 Aug 2016 17:46:07 -0700 (PDT) In-Reply-To: <20160702103153.14866.7276.idtracker@ietfa.amsl.com> References: <20160702103153.14866.7276.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Thu, 4 Aug 2016 17:46:07 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:46:10 -0000 Hi Alexey, FYI I've addresses your concern with the IANA considerations as discussed in the last draft revision. Best, --julien On Sat, Jul 2, 2016 at 3:31 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-hip-rfc5203-bis-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I don't believe IANA Considerations section is correct: it points to a > document that gets obsoleted by this one, yet the original document > creates new subregistries. This makes the status of earlier established > registries unclear. Also, other sections have references to Section 7 > (e.g. for registration types) which no longer contain relevant > information. > I think you should copy the original IANA registration section in its > entirety and clearly mark new allocations in it. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found the "changed since" Appendix, so never mind that ;-) > > It would be good if the document said that a registration type is 1 octet > without the need to look at the packet diagrams or IANA registration text > from RFC 5203 that you deleted. > > From nobody Thu Aug 4 17:47:00 2016 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 BFB8912B011; Thu, 4 Aug 2016 17:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M_2-4-zoAL9c; Thu, 4 Aug 2016 17:46:57 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E8612D853; Thu, 4 Aug 2016 17:46:56 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l203so10353490oib.1; Thu, 04 Aug 2016 17:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=psgVlimOJRXiqTDnfWZEv3KwngcUCHkt8dgAwf+bLig=; b=DtEtgI+HZ45IhW1Hotulwq4wXqCy/yLgtcLc26y75q1WFIui90nn4Ace7eMF8Bb4+o YXuIpo6pqNHHZ48uT/PWaLQhmMl2up+mhuqXS3poat6GNWotVEht3OYP/vRwc3ZDD2jr MA3Fw4blYU44cFZaaFVv6x1Upua88h2po/LbTNzYookr9sSmgtThnk3G7bfaskDF8PFH mndxrbreaOYbe00d09zWBjJAzNtRQJxNLAH2YUZN/Bs4syvH0MXaIMImfhzQl9EfsP8n 9qbWQeOTAKz5mLXgloKE7JPBW2/X3mXYHzBM+v7fCQscGsPP87RCDZl8QC3w6JVTqroO K04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=psgVlimOJRXiqTDnfWZEv3KwngcUCHkt8dgAwf+bLig=; b=WoJmMHbfQvpVJLfrXjIRx2ahntqEyVtM9kXFIPLfp4SAe/0KXsbks2NTjriOfDj/pK ACZEHo1jewrf4TbEgU+hBsPXfeA2KlCkdhDG11rnulBoXItYAoxzg/8+Ik8uMZA+j5SJ //TcOH/IEYwr7wj6VAYzUk8+4gBnqfDeyXrG9u90jWfqDNYH1PU5UdOREPSadQAAG0KY xjno6IXoC45kEyX86x5TqFGxnsYW2AoOgp/1xViNbC3bwJM8P5oU8six1ajjryGGPaBv QG64feq1tOR1XrZs0KEycQOdSbt5OtelSvVfVxl4fCjFGXASceZWQfdfVMpfcbyuZhSi wbVA== X-Gm-Message-State: AEkoouvApJdKGhss1oegOMYLrU5GAO2f/25dfZQw6xakhRETmAuy9h9JV6YbKR98DjN4jad1kFsUswoixleJUA== X-Received: by 10.202.177.84 with SMTP id a81mr39268574oif.111.1470358016197; Thu, 04 Aug 2016 17:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Thu, 4 Aug 2016 17:46:55 -0700 (PDT) In-Reply-To: References: <20160706183132.26740.62538.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Thu, 4 Aug 2016 17:46:55 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , hip-chairs@ietf.org, The IESG , draft-ietf-hip-rfc5204-bis@ietf.org Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5204-bis-07: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:46:59 -0000 FYI I've addresses your concern with the IANA considerations as discussed in the last draft revision. Best, --julien On Fri, Jul 8, 2016 at 7:17 AM, Julien Laganier wrote: > Hi Alexey, > > The IANA Considerations used to be a copy of RFC 5204 but someone > asked that it be cleaned up. I will copy it back in the next revision. > > Thanks. > > --julien > > > On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-hip-rfc5204-bis-07: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The IANA considerations section does not seem to stand alone without >> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be >> expected to read it in order to discover original IANA instructions. >> I think you should copy information from RFC 5204. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In Section 6: >> >> This section is to be interpreted according to the Guidelines for >> Writing an IANA Considerations Section in RFCs [RFC5226]. >> >> This sentence is not needed, because RFC 5204 didn't define any >> registries, so none of the text from RFC 5226 applies. I suggest you >> delete this sentence. >> >> From nobody Thu Aug 4 17:47:31 2016 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 7DF2D12DB53; Thu, 4 Aug 2016 17:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Aqu6r0Dnvfqu; Thu, 4 Aug 2016 17:47:20 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B904412D853; Thu, 4 Aug 2016 17:47:17 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id 4so134868025oih.2; Thu, 04 Aug 2016 17:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W/FZbqRipe5eIzhCmXESD4j285QdeXxaIncfoe+eQ7k=; b=kKF3VI3GUrHSmQ7UPKIiJqE6zkDr5MJ6rFZqm7f6FheLlgPPkpS+sgmOqOe9piPApo 4BSXKB6ZTUgmWgOcb6x1LAkzPSa1y/ZUx36AYSy0u9oMYjyM6vp03D2acW8z81VqyBTW /6smfEUPSV549asK3Vaiv1QoBi2WlcgdV4/VQ36+gqrzDZY8rnV0ydzIRtAVILo58+s1 n/DkORIcRYoY63r5Xo4VwZJIzGnZy6KDzvyEvLdlzQ0j0mYDz7FW0cR/FrovbKtjQRZO vxgWFCkBcNMdt0hdwwMQ9+IDljwl1XqjDsY4Ro47ayBwokuFsiBg+EDP38JAVcyyKaPR 5HOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W/FZbqRipe5eIzhCmXESD4j285QdeXxaIncfoe+eQ7k=; b=RpQIB7qYOx5muBba7xNo+AIopF+rOkznRpczomLzwNyGQmHuNbmdEHa87XknuyfwrJ QXM2hSBizyh0kKF+34suW8qIgiiScYjqib3I+zpMDhl3IJPUmIKOVodq3F25M+6y4XGp dPWq8xXCpuveL/JNnycjpuQMpZbB07Z6XIdbJ5adv1/qo4iUiIelWBpH7iMUt2x33hMD 1QiW3UM1vDH8iu971/viGG20nCPKZgT1XheZVa4aJzVubOGJN8lLBzf3wBF7nGs1tsK9 d16QJ3NyKKm4sMGJwuEqORPDOjPnv+naFXKmjGFZFLLOtdfW+Ae5ZN+Vae8ApbjoXZuW siDA== X-Gm-Message-State: AEkoouvOLJxO5pryX6RQZOFkwjPpRyvIK+ju7kL4lY4OCH9+b/4JVtDCMbBjqVvQcNQu1vzxMz2p2L3qCxsLVg== X-Received: by 10.202.102.208 with SMTP id m77mr4147225oik.24.1470358037131; Thu, 04 Aug 2016 17:47:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Thu, 4 Aug 2016 17:47:16 -0700 (PDT) In-Reply-To: References: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Thu, 4 Aug 2016 17:47:16 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5205-bis-09: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 00:47:23 -0000 FYI I've addresses your concern with the IANA considerations as discussed in the last draft revision. Best, --julien On Fri, Jul 8, 2016 at 7:23 AM, Julien Laganier wrote: > Hi Alexey, > > The IANA Considerations used to be a copy of RFC 5205 but someone > asked that it be cleaned up. I will copy it back in the next revision. > I will also clarify that the base64 encoding from section 4 is to be > used, similar to DNSSEC RRs. > > Thanks. > > --julien > > On Wed, Jul 6, 2016 at 7:22 AM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-hip-rfc5205-bis-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is the same as Ben's DISCUSS point, but I think this is important >> enough to fix: >> >> Please replicate the appropriate info from the RFC 5205 IANA >> considerations. The similar section in this draft does not seem to stand >> alone. Readers should not need to refer back to the obsoleted RFC to >> understand this version. >> >> RFC 4648 actually has 2 base64 encodings, so you should say which section >> number you mean (section 4 or section 5). I suspect you meant section 5. >> >> >> >> From nobody Fri Aug 5 05:19:16 2016 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 3110412D61B; Fri, 5 Aug 2016 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Je_LXIu8cJ8U; Fri, 5 Aug 2016 05:19:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7DF1912D0BA; Fri, 5 Aug 2016 05:19:08 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-9a-57a48438802b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id C1.CC.02493.83484A75; Fri, 5 Aug 2016 14:19:06 +0200 (CEST) Received: from [100.94.2.45] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.301.0; Fri, 5 Aug 2016 14:19:04 +0200 To: Julien Laganier , Stephen Farrell References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> From: Miika Komu Organization: Ericsson AB Message-ID: Date: Fri, 5 Aug 2016 15:19:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010906000909080601080706" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2J7iK5Vy5Jwg/MTVS2erv/FbHGktYvd YuqiycwWM/5MZLb4cnQas8X0vdfYHdg81nZfZfPYOesuu8eSJT+ZApijuGxSUnMyy1KL9O0S uDIeTFnKUrDZt2LRd5sGxg63LkYODgkBE4nlp8O7GLk4hATWM0qsXrWVEcJZwSix90cvexcj J4ewQJ7Ex2/f2EBsEYEoiT0X1rBCFDUxSSy4spYJJMEsUCzRduk9I4jNJqAlserOdWYQm19A UmJDw24wm1fAXqLp4RUWEJtFQEXi5qYWMFtUIELi1qqPjBA1ghInZz4Bi3MKBEpM+XqMHWQZ s0A3o8Tjj29YQc4WAmq+eCx4AqPALCQts5CVzQK7yVbiztzdzBC2tsSyha+hbGuJGb8OskHY ihJTuh+yQ9imEq+PfmSEsI0llq37y7aAkWMVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAM Hdzy22oH48HnjocYBTgYlXh4FzQtDhdiTSwrrsw9xKgCNOfRhtUXGKVY8vLzUpVEeIWbl4QL 8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYMy7lPdozsq5 emXLPtx3yZ8w78P52m1hfzO/PUlSMbZXZX6pt6qSk/F98dOA9zZmnuyOT6InfW/avrV9n3tZ /8NdAUI3jgjeD7mgttdqQWc817L7/NNdPKJT5q/awHZb+cGfILUD19oPKu/zZfr0dj9zkFSn bd35vM2+nYYvH1YlymbVOlw2V1NiKc5INNRiLipOBACJfIE4qQIAAA== Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 12:19:11 -0000 --------------ms010906000909080601080706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, the proposed changes seemed fine at least to me. P.S. Sorry, got back from holidays this week. On 08/05/2016 03:42 AM, Julien Laganier wrote: > Hi Stephen, > > FYI I've implemented the proposed change in the last draft revision. > > Best, > > --julien > > On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell > wrote: >> >> Hiya, >> >> That'd be fine for clearing my discuss. >> >> I'd encourage you to also get feedback from the WG though as I >> don't think I've ever seen a list of cert handling errors that >> was correct first time around:-) >> >> Cheers, >> S. >> >> >> >> On 20/07/16 16:11, Julien Laganier wrote: >>> Hi Stephen, >>> >>> Thanks for reviewing the document. >>> >>> I think there would be value in making the cause of certificate error= >>> explicit. Would the following change be acceptable? >>> >>> OLD: >>> >>> If the certificate in the parameter is not accepted, the registrar= >>> MUST reject the corresponding registrations with Failure Type [IAN= A >>> TBD] (Invalid certificate). >>> >>> NEW: >>> >>> If the certificate in the parameter is not accepted, the registrar= >>> MUST reject the corresponding registrations with the appropriate >>> Failure Type: >>> [IANA TBD] (Bad certificate): The certificate is corrupt, contains= >>> invalid signatures, etc. >>> [IANA TBD] (Unsupported certificate): The certificate is of an >>> unsupported type. >>> [IANA TBD] (Certificate expired): The certificate is no longer val= id. >>> [IANA TBD] (Certificate other): The certificate could not be >>> validated for some unspecified reason. >>> [IANA TBD] (Unknown CA): The issuing CA certificate could not be >>> located or is not trusted. >>> >>> Please let us know. >>> >>> Best, >>> >>> --julien >>> >>> >>> >>> >>> On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell >>> wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-hip-rfc5203-bis-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= =2Ehtml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> 3.3 - This fails to distinguish between an invalid >>>> certificate (e.g. bad signature, unknown signer) and one >>>> that is valid, but is not acceptable for this purpose. I >>>> don't get why that is ok for HIP, can you explain? If it >>>> is ok, I think you need to say so. If it is not ok (as I'd >>>> suspect) then you appear to need to change text or one more >>>> new error code. >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> Section 7 - I'm fine that this doesn't repeat stuff >>>> from 5203, but a sentence saying to go look there too >>>> would maybe be good. (I'm not sure if that would fix >>>> Alexey's discuss or not. If not, then ignore me and >>>> just talk to him about his discuss.) >>>> >>>> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms010906000909080601080706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODA1MTIxOTAz WjAvBgkqhkiG9w0BCQQxIgQg/sgR7ICXnLoBV0RGbSmUSUr5CjLdgsqqsctRQqsHVLgwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAkhnniLnrm qQ0F5NyhB8REciY64BZ5Qg2ZCFo9EvD2mXALydzmOPW4FOxn+Ek+NyiTUd/64juxhuXzpcXy mjPeAon6SXC82vOSPTF5zTdyj5qR4g5otgNXbs8TQ5Ik7R75ODkiuX+Mz5FHYbPLBDLj0Pa2 hScNheJJZ63S9QA510fVpPTyJDq1ljiAUBOTOLAQg8gQYzpfQTOje9vlfbNV7SlDH4rXpxDY FvTiwanT1mpbAI3QgC12LMoobcE62p5MAtqyRKgn0VJTWVFC8m84xCDHs34N4XwgudACC/kx BWgJx6pzf7HlV4r7jVzs/9TgoAn0S0qlUEqeC2fqX+paAAAAAAAA --------------ms010906000909080601080706-- From nobody Fri Aug 5 05:26:33 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DEC12D198; Fri, 5 Aug 2016 05:26:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805122628.20508.38611.idtracker@ietfa.amsl.com> Date: Fri, 05 Aug 2016 05:26:28 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-rfc5203-bis-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 12:26:28 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hip-rfc5203-bis-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss point. From nobody Fri Aug 5 07:56:42 2016 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 3045612D8CE; Fri, 5 Aug 2016 07:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=WRY2jxUZ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=f3YyTMLb 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 5kueAZuZXgX4; Fri, 5 Aug 2016 07:56:31 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08D312D8D4; Fri, 5 Aug 2016 07:56:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B99FF206A0; Fri, 5 Aug 2016 10:56:26 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Fri, 05 Aug 2016 10:56:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ZRrRpMMMgX+EYGb42IOspXVRM+g=; b=WRY2jx UZV7KbZjCnqPrBjmk3gTvp4+Ug+l5wXhGp7o4BMV2/ov8/SuiZqQQftmRFicfgMI M8DFZnVgs0sJ1d9Zyy7UyiCi8YeRbJusXNw76H+YJyul6nRpEd4q4tUoLzoKsJ8v pE8khRne/O9/qi2ISy/c5/tHrvQfDBki4Th7A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ZRrRpMMMgX+EYGb 42IOspXVRM+g=; b=f3YyTMLbOTDJLMfEYjkBaMeEc6Wm3t5mKOgFcTvedrX9G0/ k9AMQamt6OjZ4ME2sSxG7iClwSD5jO6PPPOgMtvU92xAKld5p0hvC75DfWR2PLHt 9M/g7VfUUtrYzqC0wmOQTEWWt2TgvD6fuuaEhhxMhEjCda9AI1tNMqmgPa5I= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7FF236A256; Fri, 5 Aug 2016 10:56:26 -0400 (EDT) Message-Id: <1470408986.3305145.687024713.3CB59058@webmail.messagingengine.com> X-Sasl-Enc: DPFv68Gw+u/iyy6178E9kGeNz/j0GRfzULiJI8jXnU6P 1470408986 From: Alexey Melnikov To: Julien Laganier MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b9085e99 Date: Fri, 05 Aug 2016 15:56:26 +0100 In-Reply-To: References: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> Archived-At: Cc: HIP , draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5205-bis-09: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 14:56:33 -0000 Hi Julien, I have cleared my DISCUSS on the 3 drafts that you updated. On Fri, Aug 5, 2016, at 01:47 AM, Julien Laganier wrote: > FYI I've addresses your concern with the IANA considerations as > discussed in the last draft revision. > > Best, > > --julien > > On Fri, Jul 8, 2016 at 7:23 AM, Julien Laganier > wrote: > > Hi Alexey, > > > > The IANA Considerations used to be a copy of RFC 5205 but someone > > asked that it be cleaned up. I will copy it back in the next revision. > > I will also clarify that the base64 encoding from section 4 is to be > > used, similar to DNSSEC RRs. > > > > Thanks. > > > > --julien > > > > On Wed, Jul 6, 2016 at 7:22 AM, Alexey Melnikov wrote: > >> Alexey Melnikov has entered the following ballot position for > >> draft-ietf-hip-rfc5205-bis-09: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> This is the same as Ben's DISCUSS point, but I think this is important > >> enough to fix: > >> > >> Please replicate the appropriate info from the RFC 5205 IANA > >> considerations. The similar section in this draft does not seem to stand > >> alone. Readers should not need to refer back to the obsoleted RFC to > >> understand this version. > >> > >> RFC 4648 actually has 2 base64 encodings, so you should say which section > >> number you mean (section 4 or section 5). I suspect you meant section 5. > >> > >> > >> > >> From nobody Fri Aug 5 07:58:38 2016 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 2C71812D513; Fri, 5 Aug 2016 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 isUOfkQSpCgc; Fri, 5 Aug 2016 07:58:35 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2525B12B025; Fri, 5 Aug 2016 07:58:35 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id j185so366375380oih.0; Fri, 05 Aug 2016 07:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DbW3BoDpDnp5ulGiKTi2yZCELIo6E/Kspq1DWgsh4/8=; b=rDBLCOdpUnPYW1jtRg1+Quhy7funtl42TihnKthRU5BU89Xmr9Mw00CrjeQ1eQdCyS j5rVLFnD3WS+BuP53ST5lxPaBLKjhVB52UxLB0QFJ9aJS+S3QCUph5RJVESCLNA2B6Fx J2+0TK4Yn4nnUb/o/2VAgmqtw/R26pgAg6RXrD8doOnjokXVhFxmk6qhuSvrFZEHvg4k +XTFyy+Dv5OtY2Dso1djG9SPiWHzdHsH+k3X58osaBzcWOg2+9ct+I3zDkFilHx/Moyk x16gCTsSwISN1Gxn6ZZVF/2D0T8gtl3+2oFJ9dcMirHfCSbi0ecWDvUOs3V16L5/R1kZ b2MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DbW3BoDpDnp5ulGiKTi2yZCELIo6E/Kspq1DWgsh4/8=; b=MY9zmaqNFaZ0G0yqM/BQnO1iEH+yuE4XzBMc0aaDZsMu61ecGRPf5+WFP4q4cJy5fR 7CEhS8ftmVERLaVK9rYN8z6n39HtWc2S5SjHdR6BPETmP7LjO4vhQ4tD1XizifHc7JXi HTMPE5yRCPY9nporr7Uddp0RsBnFvlajFR9sfEbtxiM3xpDbd3Et3XHJpU04q+8Spobe nA9QJYxsPt4krdkplxLjbYSTEq/DIYkc+i6NBF9FABDqW6gr1KLRjaLlhLTM6KaTmvpR oBrYpro3gGabas/qr6lzF7Am1cv53IZ1te/G8skAbGbIkUfdElp5jE+lnCLkRHWjxNat JGjg== X-Gm-Message-State: AEkoousr/OZ+S+yx1tMHw7IE9ITSgFYJ7W2ObSd/xgPWD1AmmI297Xn/oClZg22KMFOuz9kxpgLtjdI8ZlE7zw== X-Received: by 10.157.8.4 with SMTP id 4mr22712230oty.17.1470409114461; Fri, 05 Aug 2016 07:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Fri, 5 Aug 2016 07:58:33 -0700 (PDT) In-Reply-To: <1470408986.3305145.687024713.3CB59058@webmail.messagingengine.com> References: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> <1470408986.3305145.687024713.3CB59058@webmail.messagingengine.com> From: Julien Laganier Date: Fri, 5 Aug 2016 07:58:33 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5205-bis-09: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 14:58:37 -0000 Hi Alexey, Thank you! --julien On Fri, Aug 5, 2016 at 7:56 AM, Alexey Melnikov wrote: > Hi Julien, > I have cleared my DISCUSS on the 3 drafts that you updated. > > On Fri, Aug 5, 2016, at 01:47 AM, Julien Laganier wrote: >> FYI I've addresses your concern with the IANA considerations as >> discussed in the last draft revision. >> >> Best, >> >> --julien >> >> On Fri, Jul 8, 2016 at 7:23 AM, Julien Laganier >> wrote: >> > Hi Alexey, >> > >> > The IANA Considerations used to be a copy of RFC 5205 but someone >> > asked that it be cleaned up. I will copy it back in the next revision. >> > I will also clarify that the base64 encoding from section 4 is to be >> > used, similar to DNSSEC RRs. >> > >> > Thanks. >> > >> > --julien >> > >> > On Wed, Jul 6, 2016 at 7:22 AM, Alexey Melnikov wrote: >> >> Alexey Melnikov has entered the following ballot position for >> >> draft-ietf-hip-rfc5205-bis-09: Discuss >> >> >> >> When responding, please keep the subject line intact and reply to all >> >> email addresses included in the To and CC lines. (Feel free to cut this >> >> introductory paragraph, however.) >> >> >> >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> >> The document, along with other ballot positions, can be found here: >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> >> ---------------------------------------------------------------------- >> >> >> >> This is the same as Ben's DISCUSS point, but I think this is important >> >> enough to fix: >> >> >> >> Please replicate the appropriate info from the RFC 5205 IANA >> >> considerations. The similar section in this draft does not seem to stand >> >> alone. Readers should not need to refer back to the obsoleted RFC to >> >> understand this version. >> >> >> >> RFC 4648 actually has 2 base64 encodings, so you should say which section >> >> number you mean (section 4 or section 5). I suspect you meant section 5. >> >> >> >> >> >> >> >> From nobody Fri Aug 5 09:36:14 2016 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 7F42712D6A1; Fri, 5 Aug 2016 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8VSdI1QF0IP7; Fri, 5 Aug 2016 09:36:11 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03EA12D666; Fri, 5 Aug 2016 09:36:11 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l203so36546483oib.1; Fri, 05 Aug 2016 09:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K0gQgoZFGKmRKpYm9EvmHAR+/NfS74VPnncPo/bnf0U=; b=LciTmpD8jCSaQWsuahE2ciIghW+BdMKzXqaYf62R5futBOYiuUrCMeRkhs9d2sVhBi TZT5bke1L3ewnOMkQWiQVkT9j9LfvpgAKmulwYCPa5zLiOlefeS3bBkvkq0dviak6ZsQ eeih3HtNaVZeuoZtffWclKYpnUL7ioKRsbXJog9JGMer+UVWzTdSqk71KKg4Nyk3BRDZ cTP8EeZ22OTW34jg2eIt8bwMn+5CWfaxSTS/ie/GYBH00Um3+Ke8g+pUdeteAQWlJTwE MpPSTV6ZO2QHosKGr5WyjQ2l4OsRmzI3KMLqe+NfCuR3QfR/Q01Hq2knE02kjJl5Blpp OV2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K0gQgoZFGKmRKpYm9EvmHAR+/NfS74VPnncPo/bnf0U=; b=nJdw5H38yeqWDikAOBZp2m5cjyAggL3PQiFx0iui9Pu1kehXR+JxAjZPlhF0p75bRG QOMkSnCXYkFzQlxnD151dLvBYrqTrluG39aSJvTZLlokX+zmNRura8nuhu82WjtPv7NR 6pWayTrqC5FfHfFCdJf0qWIDeBQ9IUyMXIEETqleGgl0tyBZI0g60j6ectZZCKMjmFEo 7SlBHl4q8u0bgvo4LLys4b7lNfE5vllQ85YrEzWcwLGl8AoxLNhI3yLFTIUWYXMUK7IT CUaiHEhj296Jx4TSOx5KYiKVrTt8sopaiq6uz316dAlQcOLZNborfxkjQmM5mF331u0P Kjsw== X-Gm-Message-State: AEkooutA1HhE7e+nq1giFT6svJ5QdPJHY6kx+JOt89p1HF6aHLCpDwqpQnmi14QIkFowYlamVXw85eA+dKw5xA== X-Received: by 10.202.241.66 with SMTP id p63mr49225860oih.166.1470414970943; Fri, 05 Aug 2016 09:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.52 with HTTP; Fri, 5 Aug 2016 09:36:10 -0700 (PDT) In-Reply-To: <20160706210829.26812.48474.idtracker@ietfa.amsl.com> References: <20160706210829.26812.48474.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Fri, 5 Aug 2016 09:36:10 -0700 Message-ID: To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 05 Aug 2016 16:36:13 -0000 Hi Spencer, I just realized looking at the IESG record for the draft that I didn't answer your comment, sorry. I don't remember how we ended up with writing this as a SHOULD NOT (e.g., as opposed to a MUST NOT), but at least the SHOULD NOT does not negatively affect interoperability since, at the end of the day, the registrar has the final word, whether it decides to grant a lifetime that's in the advertised interval, or grant the out-of-bound lifetime that was requested, and the granted lifetime value is communicated over to the requester in the REG_RESPONSE. --julien On Wed, Jul 6, 2016 at 2:08 PM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-hip-rfc5203-bis-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This bis draft was an improvement. I did have one question. > > I'm trying to visualize why > > The registrar indicates the minimum and maximum registration lifetime > that it is willing to offer to a requester. A requester SHOULD NOT > request registration with lifetime greater than the maximum > registration lifetime or smaller than the minimum registration > lifetime. > > is a SHOULD NOT - why would a requester choose to disregard the SHOULD > and send a request registration with (for example) a lifetime greater > than the maximum registration lifetime? > > Is the intention for the requester to allow this, and then (for example) > cap the lifetime at the maximum registration lifetime? Or is something > else supposed to happen? > > Whatever the intention is, it might be helpful to provide an explanation > about that. > > From nobody Tue Aug 9 07:35:50 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6012D5F4; Tue, 9 Aug 2016 07:35:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147075334486.30676.2296711619371290884.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 07:35:44 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [Hipsec] Protocol Action: 'Host Identity Protocol (HIP) Registration Extension' to Proposed Standard (draft-ietf-hip-rfc5203-bis-11.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 14:35:45 -0000 The IESG has approved the following document: - 'Host Identity Protocol (HIP) Registration Extension' (draft-ietf-hip-rfc5203-bis-11.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ Technical Summary: This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC5203. Working Group Summary: There was WG consensus behind this document. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel Gonzalo Camarillo is the document shepherd. Terry Manderson is the responsible area director. From nobody Tue Aug 9 07:37:51 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B5412D882; Tue, 9 Aug 2016 07:37:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147075346548.30680.14213337566600589829.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 07:37:45 -0700 Archived-At: Cc: hip-chairs@ietf.org, hipsec@ietf.org, The IESG , draft-ietf-hip-rfc5204-bis@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] Protocol Action: 'Host Identity Protocol (HIP) Rendezvous Extension' to Proposed Standard (draft-ietf-hip-rfc5204-bis-08.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 14:37:45 -0000 The IESG has approved the following document: - 'Host Identity Protocol (HIP) Rendezvous Extension' (draft-ietf-hip-rfc5204-bis-08.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ Technical Summary This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. Workgroup Summary There was WG consensus behind this document. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel Gonzalo Camarillo is the document shepherd. Terry Manderson is the responsible area director. From nobody Tue Aug 9 07:39:29 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16B12D81B; Tue, 9 Aug 2016 07:39:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147075356763.30699.2415942097567295565.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 07:39:27 -0700 Archived-At: Cc: hip-chairs@ietf.org, hipsec@ietf.org, draft-ietf-hip-rfc5205-bis@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [Hipsec] Protocol Action: 'Host Identity Protocol (HIP) Domain Name System (DNS) Extension' to Proposed Standard (draft-ietf-hip-rfc5205-bis-10.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 14:39:27 -0000 The IESG has approved the following document: - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extension' (draft-ietf-hip-rfc5205-bis-10.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ Technical Summary This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. Working Group Summary There were no unusual occurrences for this document Document Quality As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel Gonzalo Camarillo is the document shepherd. Terry Manderson is the responsible area director. From nobody Thu Aug 11 16:44:19 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6392612B05E; Thu, 11 Aug 2016 16:44:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147095905836.21314.911022551298681201.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2016 16:44:18 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Last Call: (Host Multihoming with the Host Identity Protocol) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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: Thu, 11 Aug 2016 23:44:18 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Multihoming with the Host Identity Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 11 16:45:26 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187412B05E; Thu, 11 Aug 2016 16:45:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147095912106.21253.18131262386523957382.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2016 16:45:21 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] Last Call: (Host Mobility with the Host Identity Protocol) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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: Thu, 11 Aug 2016 23:45:21 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Mobility with the Host Identity Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5206: End-Host Mobility and Multihoming with the Host Identity Protocol (Experimental - IETF stream) rfc5204: Host Identity Protocol (HIP) Rendezvous Extension (Experimental - IETF stream) rfc5203: Host Identity Protocol (HIP) Registration Extension (Experimental - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Fri Aug 12 03:04:11 2016 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 9F0A912D51C; Fri, 12 Aug 2016 03:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 3pgHdtVhL6oM; Fri, 12 Aug 2016 03:04:04 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7373912D533; Fri, 12 Aug 2016 03:04:00 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2016-01-27 mail.cs.helsinki.fi Fri, 12 Aug 2016 13:03:55 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= dkim20130528; bh=PKXTuPw5U3si31orvvc+0Mom0T3blHFgo3pZ9q+An0c=; b= N0+iQrCalK9lHVjR80EeB5xP/IXiIhsoUxkatFZLcK9psJXmIInfZJAR2xmKLGED byfoEpH97jTiDps/69MFNqOyflLRvh9FXwjbDlULfnHxwpbfDJI/fHh0iZmkK0Fe UXNL8iGzpeLH27s7LWRqQOt1v4cIEt17GU0pqm/FCYs= Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (AUTH: PLAIN sklvarjo, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Fri, 12 Aug 2016 13:03:55 +0300 id 00000000005C0069.0000000057AD9F0B.00003ACF To: Kathleen Moriarty , The IESG References: <20160705010848.2630.57374.idtracker@ietfa.amsl.com> From: Varjonen Samu Message-ID: <5ca851dc-ea8b-51cc-9482-0270026dbd9a@cs.helsinki.fi> Date: Fri, 12 Aug 2016 13:03:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160705010848.2630.57374.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org Subject: Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 12 Aug 2016 10:04:06 -0000 Hi, sorry for the delayed answer to the comment. The MAY is there to keep the options free to move on with the exchange regardless of unverifyable or missing certificate in cases where the certs are optional. Or in case the certificates are not for setting up a connection but serve as a general mechanism to communicate roles or capabilities, in which enforcing an error message may not be what is wanted. However, error signaling could be RECOMMENDED instead of MAY as it would still allow to omit error signaling. -Samu & Tobias On 05/07/16 04:08, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-hip-rfc6253-bis-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Why is MAY used int he error handling and not MUST or listing these > actions as RECOMMENDED? > > Thanks for addressing the SecDir review: > https://www.ietf.org/mail-archive/web/secdir/current/msg06366.html > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Fri Aug 12 09:17:37 2016 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 1059912B018; Fri, 12 Aug 2016 09:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7V2jbaQUnxJd; Fri, 12 Aug 2016 09:17:34 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAC912D091; Fri, 12 Aug 2016 09:17:34 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 97so49199803uav.3; Fri, 12 Aug 2016 09:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8lMVoCS7cTg+xfJ3AzEnP8MjB4KEJhr9jXFP3cQKIj8=; b=hTXKmHiThuGbUu7N4CI+GAVTcd2guvAcUPUZIGksMdyd5/rLwZTEkHtrJ54ST8SCSh F0XVJk1BhvQu1rmYbwQ/7VuTWrNRimzs0WCFEQKNJo4XwxpWL1Ob8oOKLjfmQFsBWLNO LOq/8xHNR8R8u8+qRfe0GXWZ9XUz3eiTn+wPSH+4SEfSF4ySoe+QfaASUELr8ctq4yPE BJT4mFnSzA4JwHaU6Wu2wV1Xyd0zokE+Co4kfU6EPBAvDGWqGqwQrQWCiwVyVNujDY4u ECPv8/sK+zLhz2BzwgzlnqY/9LGrdzu3ZQYX8i1q+d0GUjXViFQy/prxS3DKoaj/Xwoc BdUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8lMVoCS7cTg+xfJ3AzEnP8MjB4KEJhr9jXFP3cQKIj8=; b=ZaRJOKDndG3pjDyoV0AAeRUrXZ2vOGOam2oJ7Ce6OQPZB51oiMhG+EiGDdsyHkOXH/ /6yrahj80A8WQz72KBmO13QLyW/RTTU8xCOzi63kfpg0hWdPbcJ7MphjphWUYfLzcBY9 3cC2HUOXNruuj3+vXVKGSew95kUcalRzPeHLWvI1/ByDhi6GcbikkeUoGQgUmfED8tFz 87JgvwU8uazTwCt9tFKwpauKbrDxelISmHYDW1c114pfZtPfQUVaV0Wt/bP2TarDk8P/ yRsNqumCHW9jEYxEJUttO7FC7wqVeptPks1lyyBRH+be0XhaQP+7hMBVjfoD3SS371kv BgZg== X-Gm-Message-State: AEkooutelFP519D5FmXXDf2Nx4jNugVfI+b813DACKJgZLgvl5WVhrpv7EHQTjB0Xm2VNmICdIcDBWXNEhyJzg== X-Received: by 10.176.81.237 with SMTP id h42mr7913285uaa.95.1471018653663; Fri, 12 Aug 2016 09:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Fri, 12 Aug 2016 09:17:33 -0700 (PDT) In-Reply-To: <5ca851dc-ea8b-51cc-9482-0270026dbd9a@cs.helsinki.fi> References: <20160705010848.2630.57374.idtracker@ietfa.amsl.com> <5ca851dc-ea8b-51cc-9482-0270026dbd9a@cs.helsinki.fi> From: Kathleen Moriarty Date: Fri, 12 Aug 2016 12:17:33 -0400 Message-ID: To: Varjonen Samu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: hipsec@ietf.org, The IESG , draft-ietf-hip-rfc6253-bis@ietf.org, hip-chairs@ietf.org Subject: Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 12 Aug 2016 16:17:36 -0000 On Fri, Aug 12, 2016 at 6:03 AM, Varjonen Samu wrote: > Hi, > > sorry for the delayed answer to the comment. > > The MAY is there to keep the options free to move on with the exchange > regardless of unverifyable or missing certificate in cases where the certs > are optional. Or in case the certificates are not for setting up a > connection but serve as a general mechanism to communicate roles or > capabilities, in which enforcing an error message may not be what is wanted. > > However, error signaling could be RECOMMENDED instead of MAY as it would > still allow to omit error signaling. I'll leave this up to you, the WG and AD. Your response makes sense and it was just a comment. Thanks, Kathleen > > -Samu & Tobias > > > On 05/07/16 04:08, Kathleen Moriarty wrote: >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-hip-rfc6253-bis-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Why is MAY used int he error handling and not MUST or listing these >> actions as RECOMMENDED? >> >> Thanks for addressing the SecDir review: >> https://www.ietf.org/mail-archive/web/secdir/current/msg06366.html >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > -- Best regards, Kathleen From nobody Mon Aug 15 07:03:27 2016 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 B936912DDCB; Mon, 15 Aug 2016 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kgMd6_8dsiUv; Mon, 15 Aug 2016 07:03:25 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E370012DDCC; Mon, 15 Aug 2016 07:03:24 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j12so26588915ywb.2; Mon, 15 Aug 2016 07:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xKjwkY2PGS/zrHpEh4v8cVsy5Wti4/sC75EGkaIbHzU=; b=epcofneQLTHtoulhUAQklGFEjXa2v7yuhC0G0SYlDwbS1YNkFpgsOkELj2W+f9Nwkm C/tJL1Uo/5tMvEzYCsXo6yfFBVktGoWotzoPUI/u3gummpgu8gcC1OZ8fIDqyWOgZwf9 7VhbkoIphPe6V05NT3wQMUJ3C304J5qxdMyONU2FpSgxx+YMIy3/g1dPIZRm1Oq5MVyh riJmz7I0pTuoszrKQVnQllb7ReFEW19YBywiH5hfswjnp7KdMx3HU2dBSRvNwK6q0bwh m/MheB6Htm7Wa1QW5uUyqfz0jGSGl14ZYHsAOYJI6Y/Mf1ye6pDpWM+1iuGm/IuQhPjs xXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xKjwkY2PGS/zrHpEh4v8cVsy5Wti4/sC75EGkaIbHzU=; b=HE5/75ijP+rSLBK0sIWIMUTSlJy/PCOhNS3nhKlhG3nM0c5zHFzfoqv7Kgjc1o5DCG ZIaB1O42LWepDh2xS6mbUzVfLXpi3NvjLVuRe1k7kIyalRjX908lOhA/2j8pMB2vH5aq 26sjK2728+AxD7RlyVfhtLcFJPE2IVue7hVW9JuCjz1OH18G+s7CI9YVvB7cqmt7USZp 9Hf4EAyfjGRK232GIqh7N33RnHvADAPg4ipwmhOhf65t6JN9kAax0Br9GMLn4oX8qX0j 20fOLx642M3z15127SrrptLSTP+iXBa66VW+QgYyDzLiVRBEiDTsTrqYNLmcvhDlFpji LLRg== X-Gm-Message-State: AEkooutaWNKncqpXDe42di3ACoHyHZEy4/+QpbSrrMoxrrUGdlw8p+40WCu62XxZzO9ntahXxZe5rDs5qK4Saw== X-Received: by 10.129.105.136 with SMTP id e130mr20106233ywc.176.1471269804132; Mon, 15 Aug 2016 07:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.195 with HTTP; Mon, 15 Aug 2016 07:03:23 -0700 (PDT) In-Reply-To: References: <20160706210829.26812.48474.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 15 Aug 2016 09:03:23 -0500 Message-ID: To: Julien Laganier Content-Type: multipart/alternative; boundary=001a114715ee0b4fbb053a1cb252 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 15 Aug 2016 14:03:27 -0000 --001a114715ee0b4fbb053a1cb252 Content-Type: text/plain; charset=UTF-8 Hi, Julien, On Fri, Aug 5, 2016 at 11:36 AM, Julien Laganier wrote: > Hi Spencer, > > I just realized looking at the IESG record for the draft that I didn't > answer your comment, sorry. > > I don't remember how we ended up with writing this as a SHOULD NOT > (e.g., as opposed to a MUST NOT), but at least the SHOULD NOT does > not negatively affect interoperability since, at the end of the day, > the registrar has the final word, whether it decides to grant a > lifetime that's in the advertised interval, or grant the out-of-bound > lifetime that was requested, and the granted lifetime value is > communicated over to the requester in the REG_RESPONSE. Thanks for the feedback! Spencer > --julien > > On Wed, Jul 6, 2016 at 2:08 PM, Spencer Dawkins > wrote: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-hip-rfc5203-bis-10: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This bis draft was an improvement. I did have one question. > > > > I'm trying to visualize why > > > > The registrar indicates the minimum and maximum registration lifetime > > that it is willing to offer to a requester. A requester SHOULD NOT > > request registration with lifetime greater than the maximum > > registration lifetime or smaller than the minimum registration > > lifetime. > > > > is a SHOULD NOT - why would a requester choose to disregard the SHOULD > > and send a request registration with (for example) a lifetime greater > > than the maximum registration lifetime? > > > > Is the intention for the requester to allow this, and then (for example) > > cap the lifetime at the maximum registration lifetime? Or is something > > else supposed to happen? > > > > Whatever the intention is, it might be helpful to provide an explanation > > about that. > > > > > --001a114715ee0b4fbb053a1cb252 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Julien,

On Fri, Aug 5, 2016 at 11:36 AM, Julien Laganier <julien.ie= tf@gmail.com> wrote:
Hi Spe= ncer,

I just realized looking at the IESG record for the draft that I didn't<= br> answer your comment, sorry.

I don't remember how we ended up with writing this as a SHOULD NOT
(e.g., as opposed to a MUST NOT),=C2=A0 but at least the SHOULD NOT does not negatively affect interoperability since, at the end of the day,
the registrar has the final word, whether it decides to grant a
lifetime that's in the advertised interval, or grant the out-of-bound lifetime that was requested, and the granted lifetime value is
communicated over to the requester in the REG_RESPONSE.
Thanks for the feedback!

Spencer
=C2=A0
--julien

On Wed, Jul 6, 2016 at 2:08 PM, Spencer Dawkins
<spencerdawkins.ietf@gm= ail.com> wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-hip-rfc5203-bis-10: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-hip-rfc5203-bis/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> This bis draft was an improvement. I did have one question.
>
> I'm trying to visualize why
>
>=C2=A0 =C2=A0 The registrar indicates the minimum and maximum registrat= ion lifetime
>=C2=A0 =C2=A0 that it is willing to offer to a requester.=C2=A0 A reque= ster SHOULD NOT
>=C2=A0 =C2=A0 request registration with lifetime greater than the maxim= um
>=C2=A0 =C2=A0 registration lifetime or smaller than the minimum registr= ation
>=C2=A0 =C2=A0 lifetime.
>
> is a SHOULD NOT - why would a requester choose to disregard the SHOULD=
> and send a request registration with (for example) a lifetime greater<= br> > than the maximum registration lifetime?
>
> Is the intention for the requester to allow this, and then (for exampl= e)
> cap the lifetime at the maximum registration lifetime? Or is something=
> else supposed to happen?
>
> Whatever the intention is, it might be helpful to provide an explanati= on
> about that.
>
>

--001a114715ee0b4fbb053a1cb252-- From nobody Mon Aug 29 09:24:17 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D47CA12D5F2; Mon, 29 Aug 2016 09:24:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147248784882.19094.13496847686172545652.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 09:24:08 -0700 Archived-At: Cc: hip-chairs@ietf.org, hipsec@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [Hipsec] Protocol Action: 'Host Identity Protocol Certificates' to Proposed Standard (draft-ietf-hip-rfc6253-bis-09.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 29 Aug 2016 16:24:09 -0000 The IESG has approved the following document: - 'Host Identity Protocol Certificates' (draft-ietf-hip-rfc6253-bis-09.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ Technical Summary: The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates. The concrete use cases of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter. This document extends RFC7401 and obsoletes RFC6253. Working Group Summary: There was WG consensus behind this document. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux (HIPL) and OpenHIP will be updated to comply with the standards-track specs. The example in the RFC was tested with the HIPL implementation, which uses the openssl library. Personnel Gonzalo Camarillo is the document shepherd. Terry Manderson is the responsible area director. From nobody Tue Aug 30 04:22:41 2016 Return-Path: <7riw77@gmail.com> 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 A1C5112D1BB; Tue, 30 Aug 2016 04:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2n6_UlHWnRVC; Tue, 30 Aug 2016 04:22:38 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D357012D1AE; Tue, 30 Aug 2016 04:22:34 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f189so21077672oig.3; Tue, 30 Aug 2016 04:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=tSob+1uzrHTFYg0gyIqhKBV9HBMjeDj1I9yV3jDrvyE=; b=EKAr+7UMaWx1O3sormPB6fyzriacVquXK+vHSF+A+hP43X5RK/eGGhvc8fko8z9t1R 0DV+DoSblX5yvH1Q/IDg7EhAICGh8GbOReiEPBQJ9eI6PHXof1uVmOMZ6LTzAVLWKafn R3/XEEYyGdfFtLG0U74aIOQD3Yhvij3DamQkTQfGp3AjKL+A5FDdIRSA5vKCtPfy0m0p H7S6Bi3OcYnSw2BNtiRLrvr9EbAMA56sa1I0y7XA4Sh06OftRqPWp3fbnbOKO5XXsXUE 3mOuyLbjNmHTz7DC3IuS1/oFfQMD7x8GWAxC6iqAR5tXsonN/yxOuPCM7f9yWZXdjTEL OUCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=tSob+1uzrHTFYg0gyIqhKBV9HBMjeDj1I9yV3jDrvyE=; b=aqGJftqD2a3C+a3JmzSoywVhMMTRihrkuYectirA0q6kJaAMRhVjeKEOFcMTeGTc/a GQZPR4R4MYXV5PjwxstebxOWS8ncaqHs0RZvRXF+mZdsXgU0wAz249Kx/iSVJy/mdLCY KSgXm/dC+82hbrS5cLbC19Ra5XGgIlUJDKruzhLgkxd3LtvCV2iEIJyDVf8qY9R5cn2U tBq7qcauTftd6IVPNODWVvddGOv+gFNmewMOY1PNyUubnqiFRS7dO1xtognf+EcJBPIA E1kSjsE4cebYMzmQXyQgKkASd9rkeCAO87IDKibUrR1Sj1zenKhAxvASosFEdRbooKMq bRtQ== X-Gm-Message-State: AE9vXwOf7rwHT1mdiQRjF6MSKlfe5aqdWZMQ6boGtiOsGwHm7dDXZSMDvd033Tl/ef+J2A== X-Received: by 10.202.95.134 with SMTP id t128mr3256866oib.20.1472556154054; Tue, 30 Aug 2016 04:22:34 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id g7sm16477887otb.6.2016.08.30.04.22.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Aug 2016 04:22:33 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Tue, 30 Aug 2016 07:22:27 -0400 Message-ID: <011901d202b0$caf74cb0$60e5e610$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdICsGe8fx2mAatwRPCmfsTJEQXnmg== Content-Language: en-us Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-hip-multihoming.all@ietf.org, hipsec@ietf.org Subject: [Hipsec] RtgDir review: draft-ietf-hip-multihoming-10 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 30 Aug 2016 11:22:40 -0000 Y'all -- I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-hip-multihoming-10 Reviewer: Russ White Review Date: 30 August 2016 Intended Status: Standards Track Summary: No issues found. This document is ready for publication. Comments: This draft is well written; I did need to do some research on the background, but the pointers to the correct places to look are well called out in the draft. Major Issues: No major issues found. Minor Issues: No minor issues found. == /r From nobody Wed Aug 31 05:22:16 2016 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 3E42112D1B1 for ; Wed, 31 Aug 2016 05:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 5m89SsYt3wCu for ; Wed, 31 Aug 2016 05:22:02 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D375312DB07 for ; Wed, 31 Aug 2016 05:21:52 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-73-57c6cbde7ecc Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id D5.EC.04209.EDBC6C75; Wed, 31 Aug 2016 14:21:50 +0200 (CEST) Received: from [131.160.126.239] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 14:21:49 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> From: Gonzalo Camarillo Message-ID: Date: Wed, 31 Aug 2016 15:21:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5756C81D.3080601@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM2K7lu6908fCDSY8tbCYumgys8W7o99Z HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MZSs72Ap2eVa8nNbF1sDYYdbFyMkhIWAi MftgF3sXIxeHkMB6RokjT5ZBOWsZJZr+3GcDqRIWsJaY+uEmO4gtImAnseTIQ1aIolOMEkdP XwFLMAMVvV57mQXEZhOwkNhy6z6YzStgL/F3YSfYIBYBVYm5C/sYuxg5OEQFYiTW9yVAlAhK nJz5BKycU0BH4snC7UwQIw0kjiyawwphy0s0b53NDGILCWhLLH/WwjKBUWAWkvZZSFpmIWlZ wMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwMA9u+a26g/HyG8dDjAIcjEo8vAtOHg0X Yk0sK67MPcQowcGsJMJrBAxrId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NT C1KLYLJMHJxSDYySU3WfVN2KVz27rPXrAaOtM5fVHCj54NHRsKYyf+mPgqUzf/fNfrvD5vey /rfF+vMfLl4Qx+f7M3Wi275/Z58IHWR6cUXEQ+1TVm5hp5VJ7slTRVcufLgZYuurfMNBaDGn 3qHeS+4ttsKHGcyN5T8+teZeVWMmcWb9HPH3pwxPn6y+an3vqHGJEktxRqKhFnNRcSIAcJM5 gkgCAAA= Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 12:22:14 -0000 Hi Rene, please, note Miika's email below, which includes a couple of suggestions about the draft. Cheers, Gonzalo On 07/06/2016 4:11 PM, Miika Komu wrote: > Hi, > > On 06/03/2016 02:20 PM, René Hummen wrote: >> This is part 3 of 3. > > I am fine with your fixes. Some comments below. > >> On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > > wrote: >> [...] >> > 6.2.1. CMAC Calculation >> > >> > [...] >> > >> > >> > 5. Set Checksum and Header Length fields in the HIP header to >> > original values. Note that the Checksum and Length fields >> > contain incorrect values after this step. >> >> I guess also the values following HIP_MAC should be restored since >> they were wiped in the step 2. >> >> >> I also found this description a bit imprecise, but it is taken from >> RFC7401. Step 2 already hints at the fact that parameters following >> HIP_MAC may still be of interest: >> "Remove the HIP_MAC parameter, as well as all other parameters >> that follow it with greater Type value, saving the contents if >> they will be needed later." >> >> The question is whether we want to fix the description for HIP DEX or to >> keep things as they are for consistency reasons. In the former case, I >> would prefer to completely rewrite the verification procedure to work on >> the received packet without removing any parameters. However, we should >> then probably also post an errata to RFC7401. If there are no stong >> opinions about that, I would go for the latter option. > > Latter option works for me too. > >> > The CKDF-Extract function is the following operation: >> > >> > CKDF-Extract(I, IKM, info) -> PRK >> >> What does the arrow operator signify? I thought that it produces PRK, >> but PRK is actually defined below. >> >> >> The arrow is part of a basic mathematical function definition. So yes, >> PRK is the output (domain), but we still need to give it a proper name. >> I changed the artwork to clearly point out the inputs and outputs. > > Thanks, it is now better. > >> Please check this section again in the updated version and get back to >> me if the above changes do not sufficiently help your understanding. > > It is good now, thanks! > >> > L length of output keying material in octets >> > (<= 255*RHASH_len/8) >> > | denotes the concatenation >> > >> > The output keying material OKM is calculated as follows: >> > >> > N = ceil(L/RHASH_len/8) >> > T = T(1) | T(2) | T(3) | ... | T(N) >> > OKM = first L octets of T >> > >> > where >> > >> > T(0) = empty string (zero length) >> > T(1) = CMAC(PRK, T(0) | info | 0x01) >> > T(2) = CMAC(PRK, T(1) | info | 0x02) >> > T(3) = CMAC(PRK, T(2) | info | 0x03) >> > ... >> >> The Expand was a bit more clear, but still didn't understand how to >> get to the >> Expanded key material due the arrow notation. >> >> >> Ok, let's clarify this as several comments are related to the arrow >> notation. For the function definition we use the mathematical arrow >> notation (same as RFC 5869) and for the actual opertation we use the >> equals sign (same as RFC 5869). In the end, they denote the same thing: >> "assign X to Y". > > Ok, this is what I guessed too. > >> > (where the constant concatenated to the end of each T(n) is a >> > single octet.) >> >> Is there a max value? >> >> >> I am not sure what you mean here. If you refer to the N in T(N) then it >> is defined above as N = ceil(L/RHASH_len/8). > > Yes, I asked about the maximum value for N (which depends on L), but > never mind. > >> > 8. The R1 packet may have the A-bit set - in this case, the >> system >> > MAY choose to refuse it by dropping the R1 packet and returning >> > to state UNASSOCIATED. The system SHOULD consider dropping the >> > R1 packet only if it used a NULL HIT in the I1 packet. >> >> I didn't understand the logic in the last sentence. >> >> >> Someone must have had a reason for this recommendation, but that someone >> wasn't me. This is text from RFC7401. Any suggestions how to proceed? > > Fix similarly as the other RFC7401 issue in the beginning of this email. > >> > 6.7. Processing Incoming I2 Packets >> > >> > [...] >> > >> > 5. If the system's state machine is in the I2-SENT state, the >> > system MUST make a comparison between its local and sender's >> > HITs (similarly as in Section 6.3). If the local HIT is smaller >> > than the sender's HIT, it should drop the I2 packet, use the >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce >> > #I from the R1 packet received earlier, and get the local >> > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J >> > from the I2 packet sent to the peer earlier. Otherwise, the >> > system should process the received I2 packet and drop any >> > previously derived Diffie-Hellman keying material Kij and >> > ENCRYPTED_KEY keying material it might have generated upon >> > sending the I2 packet previously. The peer Diffie-Hellman key, >> > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived >> > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying >> > material, and the nonce #I are the ones that were sent earlier >> > in the R1 packet. >> >> Please replace "sender" with "peer" (or remote host) in this section >> for more symmetric terminology. >> >> get -> obtain >> >> >> I can make these changes if you insist, but I was going for a minimal >> diff to RFC 7401. > > Not insisting. > >> >> > 11. The implementation SHOULD also verify that the Initiator's >> HIT >> > in the I2 packet corresponds to the Host Identity sent in the I2 >> > packet. (Note: some middleboxes may not be able to make this >> > verification.) >> >> Why SHOULD? Why not MUST? I think we're talking about end-hosts here >> anyway. >> >> >> It is defined this way in RFC 7401. Do you really want to change the >> packet processing behavior for HIP DEX only? > > Fix similarly as the first RFC7401 issue in this email. > >> > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets >> >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in >> HIP DEX >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of >> [RFC7401]). >> > The only difference is the that the HIP_SIGNATURE is never present >> > and, therefore, is not required to be processed by the receiving >> > party. >> >> How does rekeying work with the extract and expand functions? >> >> >> Rekeying is not defined in this document, same as for RFC 7401. That >> being said, the rekeying procedure with reuse of the KEYMAT from RFC >> 7402 directly translates to HIP DEX. For new KEYMAT, the peers need to >> establish a new connection due to the use of static DH keys. > > Maybe this should be explicitly stated in the draft. > >> >> >> > 7. HIP Policies >> >> > There are a number of variables that will influence the HIP >> exchanges >> > that each host must support. All HIP DEX implementations SHOULD >> > provide for an ACL of Initiator's HI to Responder's HI. This ACL >> > SHOULD also include preferred transform and local lifetimes. >> > Wildcards SHOULD also be supported for this ACL. >> >> Why ACLs are mandatory? >> >> >> It is not a MUST and considering that HIP DEX is primarly targeted at >> things, there is the need to do basic device authorizations (based on >> their identities) without a human in the loop. Of course you are also >> allowed to use more suffisticated authorization mechanisms. > > Ok. > >> ACL -> ACL consisting of >> >> >> Changed to the following text that is closer to RFC 7401: >> " All HIP DEX implementations SHOULD provide for an Access Control List >> (ACL), representing for which hosts they accept HIP diet exchanges, >> and the preferred transport format and local lifetimes. Wildcarding >> SHOULD be supported for such ACLs." >> >> > 8. Security Considerations >> >> > o The HIP DEX HIT generation may present new attack >> opportunities. >> >> They cannot be used in ACLs. Maybe this could be mentioned. Can this >> be mitigated by always using full HIs? >> >> >> I changed the bullet-point as follows: >> "The HIP DEX HIT generation may present new attack opportunities. >> Hence, HIP DEX HITs should not be use as the only means to >> identify a peer in an ACL. Instead, the use of the peer's HI is >> recommended." > > Ok. > >> Note that I added a new Section 8 "Interoperability between HIP DEX and >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. > > Thanks! > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >