From nobody Wed May 7 06:58:08 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE6C1A0305; Wed, 7 May 2014 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbcvwkgwnmOA; Wed, 7 May 2014 06:58:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDE31A0308; Wed, 7 May 2014 06:58:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507135803.9857.46012.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 06:58:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/L8u52rA51ncwAXujxixji7kWqxs Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-qos-wifi-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:58:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Mapping 802.11 QoS in a PMIPv6 Mobility Domain Authors : John Kaippallimalil Rajesh Pazhyannur Parviz Yegani Filename : draft-ietf-netext-pmip-qos-wifi-00.txt Pages : 18 Date : 2014-05-06 Abstract: This document provides a model for enabling end to end QoS in systems where there is a 802.11 based wireless system coupled with a PMIPv6 mobility domain consisting a local mobility anchor and mobility access gateway. This enables QoS policing and labeling of packets in a consistent manner on the 802.11 link between the MN and the AP as well as the link between the MAG and the LMA. To enable this, the document specifies mapping between QoS parameters on the 802.11 link and the QoS Mobility options in the PMIPv6 domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-00 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 Wed May 7 07:08:30 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0341A0859 for ; Wed, 7 May 2014 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 HD1pt1Nk_i-X for ; Wed, 7 May 2014 07:08:26 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BBCE11A07B3 for ; Wed, 7 May 2014 07:08:26 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so1231816obc.21 for ; Wed, 07 May 2014 07:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=PVCg4KHo3bJ9Bw4LMhTl5ydiQcibQURq3aDPrXdDdiU=; b=VqAHRTLYllZyL1k2Bgr+h1kJCPXAnY1y4Ezy/Uc0Epg/mz5FvtHOA5wuY/emfJEsQN msJdFhwWlFOM7gNxt96jthKZF9JvJs8dPvIGAFG3fYptrCMSKCEPqIu8x+qqSsgW5U1S IUBu+fxVUT+/C8a1/HtaZRBczE5UZWDEdVzxM52xNPrKRXUbf0X/0Hk5Jqk+jW5Mtk/J VeJu/RqyArFxuxTgM02VW6eZd/nYYIbWZWpIbcc22k5gWpZDo0CA+5iSW6EMRzUbSOs2 mBCwaDC0NY24yi+O9ogbbZ3ej5Z3pEI7Xz+tHLH+U3cQE7rNFZH+y9n87oSzRG7eYawm CU2A== MIME-Version: 1.0 X-Received: by 10.60.69.71 with SMTP id c7mr2736656oeu.82.1399471702536; Wed, 07 May 2014 07:08:22 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 7 May 2014 07:08:22 -0700 (PDT) Date: Wed, 7 May 2014 09:08:22 -0500 Message-ID: From: Basavaraj Patil To: draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1133194ab3f7c504f8cfe5b2 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/JfeWKIQlrpehRm1x6gywP5aGp9Q Cc: "netext@ietf.org" Subject: [netext] Question about extending the ANI option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:08:27 -0000 --001a1133194ab3f7c504f8cfe5b2 Content-Type: text/plain; charset=UTF-8 Hello authors, Couple of questions regarding the problem being that this I-D aims to solve: 1. Why is the existing ANI option not sufficient for encoding WLAN specific information? 2. Is the primary goal to provide information regarding location? And as a means for indoor location tracking? The I-D does not really explain the key problem to be solved other than saying that 3GPP has a requirement in WLAN deployments. It would be good if you can explain the motivation to the WG so that the WG can decide on adopting and progressing this I-D. -Raj -- Basavaraj Patil --001a1133194ab3f7c504f8cfe5b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello authors,

Couple of= questions regarding the problem being that this I-D aims to solve:

1. Why is the existing ANI option not sufficient for enco= ding WLAN specific information?
2. Is the primary goal to provide information regarding location? And = as a means for indoor location tracking?

The I-D d= oes not really explain the key problem to be solved other than saying that = 3GPP has a requirement in WLAN deployments. It would be good if you can exp= lain the motivation to the WG so that the WG can decide on adopting and pro= gressing this I-D.

-Raj

--
Basavaraj P= atil
--001a1133194ab3f7c504f8cfe5b2-- From nobody Wed May 7 07:42:33 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D101A0311 for ; Wed, 7 May 2014 07:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LK98iod5olb for ; Wed, 7 May 2014 07:42:28 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id B9A231A0324 for ; Wed, 7 May 2014 07:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19418; q=dns/txt; s=iport; t=1399473742; x=1400683342; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vJ9dVsx6GRWwhql8nfuOI+ibCUCMibMYebIF1Edowkk=; b=i18asQYNEloVX26F4CPnApAEVfDkUFF0Fh3x98Jx7l3Zgz0JstP7Ujq7 nzJB4hzTT+LRtgQjmuo/oG3XWfiE2ml6IONFbxsckL3CA49TLCeSRCQPa 6fUxC6tHCVxm/B5/vCRVQ0Dju2WgFd7DU+oHlIi3Gh1W/O3QRUU7A91we Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwIAFdFalOtJA2D/2dsb2JhbABQCoJCRE9YgmeoGwEBAQUBmg4BGX8WdIIlAQEBBCMKQQsQAgEIDgMEAQELHQMCAgIfERQJCAIEDgUIDIgZAxABqiqeaA2GSBeFVoZlgTsrMQYBgnQ2gRUEl0WPDIVhgzSCLw X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208,217";a="41765427" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 07 May 2014 14:42:22 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s47EgMfh019989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 14:42:22 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 7 May 2014 09:42:21 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Basavaraj Patil , "draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org" Thread-Topic: Question about extending the ANI option Thread-Index: AQHPaf3VpTqmG1NALUKU4SE67RUyxJs1LQpQ Date: Wed, 7 May 2014 14:42:21 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F7BA96@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.70.242.20] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F7BA96xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/_24YTDklIcvKwtYgPjdaA7Xz47Y Cc: "netext@ietf.org" Subject: Re: [netext] Question about extending the ANI option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:42:30 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F7BA96xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFqDQoNCjEuIFdoeSBpcyB0aGUgZXhpc3RpbmcgQU5JIG9wdGlvbiBub3Qgc3VmZmljaWVu dCBmb3IgZW5jb2RpbmcgV0xBTiBzcGVjaWZpYyBpbmZvcm1hdGlvbj8NCjIuIElzIHRoZSBwcmlt YXJ5IGdvYWwgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgbG9jYXRpb24/IEFuZCBh cyBhIG1lYW5zIGZvciBpbmRvb3IgbG9jYXRpb24gdHJhY2tpbmc/DQoNCg0KDQoNCjEpICAgICAg UkZDIDY3NTcgZGVmaW5lcyB0aHJlZSBBTkkgVHlwZXM6IE5ldHdvcmsgSWRlbnRpZmllciwgR2Vv LUxvY2F0aW9uLCBPcGVyYXRvciBJZGVudGlmaWVyLiAgRm9yIFdMQU4gZGVwbG95bWVudHMsIHRo ZXJlIGlzIGEgbmVlZCBpbiBtYW55IGNhc2VzIChlLmcuLCByZWd1bGF0b3J5LCAgbG9jYXRpb24g YmFzZWQgc2VydmljZXMsIGxvY2F0aW9uIGJhc2VkIHBvbGljeSwgZXRjKSB0byBpZGVudGlmeSB0 aGUgQVAgdGhlIHVzZXIgaXMgYXR0YWNoZWQgdG8uICBSRkMgNjc1NyBwcm92aWRlcyBvbmUgd2F5 IHRvIGRvIGl0IHZpYSBHZW8tTG9jYXRpb24uIEhvd2V2ZXIsIG1hbnkgaW5kb29yIEFQcyBhcmUg dW5saWtlbHkgdG8gaGF2ZSBHUFMgdG8gcHJvdmlkZSBHZW8tbG9jYXRpb24uIEhvd2V2ZXIsIHRo ZXNlIGluZG9vciBBUHMgYXJlIG9mdGVuIHByb3Zpc2lvbmVkIHdpdGggYSBDaXZpYyBsb2NhdGlv biB0b2RheS4gUkZDIDY3NTcgZG9lcyBub3QgcHJvdmlkZSBhIHdheSB0byBlbmNhcHN1bGF0ZSBD aXZpYyBMb2NhdGlvbi4gU28gd2UgYXJlIHByb3Bvc2luZyBhZGRpbmcgYSBuZXcgQU5JIFR5cGU6 IENpdmljIExvY2F0aW9uLiAgV2UgYXJlIGFsc28gZGVmaW5pbmcgYW5vdGhlciBBTkkgVHlwZTog R3JvdXAgSWRlbnRpZmllci4gSW4gbWFueSBleGlzdGluZyBkZXBsb3ltZW50cyBBUHMgYXJlIGdy b3VwZWQgdG9nZXRoZXIgd2l0aCBhIGdyb3VwLWlkLiBUaGUgZ3JvdXAgaWRlbnRpZmllciByZWZl cnMgdG8gYSBjb2Fyc2UgbG9jYXRpb24gc3VjaCBhcyBhIHNwZWNpZmljIGNvZmZlZS1zdG9yZSwg Ym9vay1zdG9yZSwgZXRjLiAgVGhpcyBmb3JtIG9mIEFOSSBpbmZvcm1hdGlvbiBpcyBhbHNvIHVz ZWZ1bCBpbiBmYWNpbGl0YXRpbmcgbWFueSBsb2NhdGlvbiBiYXNlZCBhcHBsaWNhdGlvbnMuDQoN CjIpICAgICAgVGhlIHByaW1hcnkgZ29hbCBpcyBpbmRlZWQgZm9yIHRoZSBNQUcgdG8gcHJvdmlk ZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQWNjZXNzIFBvaW50IHRoYXQgdGhlIHVz ZXIgaXMgYXR0YWNoZWQgdG8uIFJGQyA2NzU3IHByb3ZpZGVkIGEgd2F5IHRvIHByb3ZpZGUgR1BT LiBCdXQgR1BTIGRvZXMgbm90IHdvcmsgd2VsbCBpbiBpbmRvb3IgZGVwbG95bWVudHMgYW5kIHNv bWV0aW1lcyBpcyBjb25zaWRlcmVkIGV4cGVuc2l2ZSBmb3IgaW5kb29yIEFQcy4gQXMgYSByZXN1 bHQsIHdlIGFyZSBsb29raW5nIGZvciBhbHRlcm5hdGl2ZXMuIFRoZSB0d28gYWx0ZXJuYXRpdmVz IHByb3Bvc2VkOiBDaXZpYyBMb2NhdGlvbiwgYW5kIEdyb3VwLUlkZW50aWZpZXIuDQoNClRoZSBJ LUQgZG9lcyBub3QgcmVhbGx5IGV4cGxhaW4gdGhlIGtleSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBv dGhlciB0aGFuIHNheWluZyB0aGF0IDNHUFAgaGFzIGEgcmVxdWlyZW1lbnQgaW4gV0xBTiBkZXBs b3ltZW50cy4gSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIGV4cGxhaW4gdGhlIG1vdGl2YXRp b24gdG8gdGhlIFdHIHNvIHRoYXQgdGhlIFdHIGNhbiBkZWNpZGUgb24gYWRvcHRpbmcgYW5kIHBy b2dyZXNzaW5nIHRoaXMgSS1ELg0KDQoNCkhvcGVmdWxseSB0aGUgYWJvdmUgYW5zd2VycyBwcm92 aWRlIHNvbWUgZnVydGhlciBleHBsYW5hdGlvbi4gIEkgYWdyZWUgc2F5aW5nIHRoYXQgM0dQUCBo YXMgYSByZXF1aXJlbWVudCBpbiBub3QgYWRlcXVhdGUgYnkgaXRzZWxmLiBXZSBjaXRlZCB0aGF0 IGFzIGEgcmVmZXJlbmNlIG9yIGV2aWRlbmNlIHRoYXQgdGhlcmUgaXMgYSByZWFsIHByb2JsZW0g aW4gdGhlIGxhcmdlciBjb21tdW5pdHkgdGhhdCBuZWVkcyBhZGRyZXNzaW5nLg0KDQpXaGVuLCBJ IHByZXNlbnRlZCB0aGlzIGRyYWZ0IGluIFZhbmNvdXZlciBsYXN0IHllYXIsIHRoZXJlIHdhcyBh IGZhaXIgYml0IG9mIGludGVyZXN0IG9uIHRoZSBmbG9vci4gSWYgSSByZWNhbGwgY29ycmVjdGx5 LCBSYWplZXYgYXNrZWQgZm9yIGEgc2hvdyBvZiBoYW5kcyBhbmQgYSBudW1iZXIgb2YgaGFuZHMg d2VudCB1cCBpbiBzdXBwb3J0LiBJIGFtIGhvcGluZyB0byBnZXQgdGhlIHNhbWUgZm9sa3Mgdm9p Y2UgdGhlaXIgc3VwcG9ydCBvbiB0aGUgbWFpbGluZyBsaXN0IOKYug0KDQpSZWdhcmRzDQoNClJh amVzaA0KDQpGcm9tOiBCYXNhdmFyYWogUGF0aWwgW21haWx0bzpicGF0aWwxQGdtYWlsLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgTWF5IDA3LCAyMDE0IDc6MDggQU0NClRvOiBkcmFmdC1wYXpoeWFu bnVyLW5ldGV4dC1jaXZpYy1sb2NhdGlvbi1hbmktc3Vib3B0QHRvb2xzLmlldGYub3JnDQpDYzog bmV0ZXh0QGlldGYub3JnDQpTdWJqZWN0OiBRdWVzdGlvbiBhYm91dCBleHRlbmRpbmcgdGhlIEFO SSBvcHRpb24NCg0KDQpIZWxsbyBhdXRob3JzLA0KDQpDb3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2Fy ZGluZyB0aGUgcHJvYmxlbSBiZWluZyB0aGF0IHRoaXMgSS1EIGFpbXMgdG8gc29sdmU6DQoNCjEu IFdoeSBpcyB0aGUgZXhpc3RpbmcgQU5JIG9wdGlvbiBub3Qgc3VmZmljaWVudCBmb3IgZW5jb2Rp bmcgV0xBTiBzcGVjaWZpYyBpbmZvcm1hdGlvbj8NCjIuIElzIHRoZSBwcmltYXJ5IGdvYWwgdG8g cHJvdmlkZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgbG9jYXRpb24/IEFuZCBhcyBhIG1lYW5zIGZv ciBpbmRvb3IgbG9jYXRpb24gdHJhY2tpbmc/DQoNClRoZSBJLUQgZG9lcyBub3QgcmVhbGx5IGV4 cGxhaW4gdGhlIGtleSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBvdGhlciB0aGFuIHNheWluZyB0aGF0 IDNHUFAgaGFzIGEgcmVxdWlyZW1lbnQgaW4gV0xBTiBkZXBsb3ltZW50cy4gSXQgd291bGQgYmUg Z29vZCBpZiB5b3UgY2FuIGV4cGxhaW4gdGhlIG1vdGl2YXRpb24gdG8gdGhlIFdHIHNvIHRoYXQg dGhlIFdHIGNhbiBkZWNpZGUgb24gYWRvcHRpbmcgYW5kIHByb2dyZXNzaW5nIHRoaXMgSS1ELg0K DQotUmFqDQoNCi0tDQpCYXNhdmFyYWogUGF0aWwNCg== --_000_4ED2E36A22261145861BAB2C24088B4320F7BA96xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxMzAxOTU5NDI5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTQ1MzgzODg4MiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUmFq PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLiBXaHkgaXMgdGhlIGV4aXN0aW5nIEFOSSBvcHRpb24gbm90IHN1ZmZpY2llbnQg Zm9yIGVuY29kaW5nIFdMQU4gc3BlY2lmaWMgaW5mb3JtYXRpb24/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBJcyB0aGUgcHJpbWFyeSBnb2FsIHRvIHByb3ZpZGUgaW5m b3JtYXRpb24gcmVnYXJkaW5nIGxvY2F0aW9uPyBBbmQgYXMgYSBtZWFucyBmb3IgaW5kb29yIGxv Y2F0aW9uIHRyYWNraW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UkZDIDY3NTcgZGVmaW5lcyB0aHJlZSBBTkkgVHlwZXM6IE5ldHdv cmsgSWRlbnRpZmllciwgR2VvLUxvY2F0aW9uLCBPcGVyYXRvciBJZGVudGlmaWVyLiAmbmJzcDtG b3IgV0xBTiBkZXBsb3ltZW50cywgdGhlcmUgaXMgYSBuZWVkIGluIG1hbnkgY2FzZXMgKGUuZy4s IHJlZ3VsYXRvcnksICZuYnNwO2xvY2F0aW9uDQogYmFzZWQgc2VydmljZXMsIGxvY2F0aW9uIGJh c2VkIHBvbGljeSwgZXRjKSB0byBpZGVudGlmeSB0aGUgQVAgdGhlIHVzZXIgaXMgYXR0YWNoZWQg dG8uJm5ic3A7IFJGQyA2NzU3IHByb3ZpZGVzIG9uZSB3YXkgdG8gZG8gaXQgdmlhIEdlby1Mb2Nh dGlvbi4gSG93ZXZlciwgbWFueSBpbmRvb3IgQVBzIGFyZSB1bmxpa2VseSB0byBoYXZlIEdQUyB0 byBwcm92aWRlIEdlby1sb2NhdGlvbi4gSG93ZXZlciwgdGhlc2UgaW5kb29yIEFQcyBhcmUgb2Z0 ZW4gcHJvdmlzaW9uZWQNCiB3aXRoIGEgQ2l2aWMgbG9jYXRpb24gdG9kYXkuIFJGQyA2NzU3IGRv ZXMgbm90IHByb3ZpZGUgYSB3YXkgdG8gZW5jYXBzdWxhdGUgQ2l2aWMgTG9jYXRpb24uIFNvIHdl IGFyZSBwcm9wb3NpbmcgYWRkaW5nIGEgbmV3IEFOSSBUeXBlOiBDaXZpYyBMb2NhdGlvbi4gJm5i c3A7V2UgYXJlIGFsc28gZGVmaW5pbmcgYW5vdGhlciBBTkkgVHlwZTogR3JvdXAgSWRlbnRpZmll ci4gSW4gbWFueSBleGlzdGluZyBkZXBsb3ltZW50cyBBUHMgYXJlIGdyb3VwZWQgdG9nZXRoZXIN CiB3aXRoIGEgZ3JvdXAtaWQuIFRoZSBncm91cCBpZGVudGlmaWVyIHJlZmVycyB0byBhIGNvYXJz ZSBsb2NhdGlvbiBzdWNoIGFzIGEgc3BlY2lmaWMgY29mZmVlLXN0b3JlLCBib29rLXN0b3JlLCBl dGMuJm5ic3A7IFRoaXMgZm9ybSBvZiBBTkkgaW5mb3JtYXRpb24gaXMgYWxzbyB1c2VmdWwgaW4g ZmFjaWxpdGF0aW5nIG1hbnkgbG9jYXRpb24gYmFzZWQgYXBwbGljYXRpb25zLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByaW1hcnkgZ29hbCBpcyBpbmRlZWQg Zm9yIHRoZSBNQUcgdG8gcHJvdmlkZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQWNj ZXNzIFBvaW50IHRoYXQgdGhlIHVzZXIgaXMgYXR0YWNoZWQgdG8uIFJGQyA2NzU3IHByb3ZpZGVk IGEgd2F5IHRvIHByb3ZpZGUgR1BTLg0KIEJ1dCBHUFMgZG9lcyBub3Qgd29yayB3ZWxsIGluIGlu ZG9vciBkZXBsb3ltZW50cyBhbmQgc29tZXRpbWVzIGlzIGNvbnNpZGVyZWQgZXhwZW5zaXZlIGZv ciBpbmRvb3IgQVBzLiBBcyBhIHJlc3VsdCwgd2UgYXJlIGxvb2tpbmcgZm9yIGFsdGVybmF0aXZl cy4gVGhlIHR3byBhbHRlcm5hdGl2ZXMgcHJvcG9zZWQ6IENpdmljIExvY2F0aW9uLCBhbmQgR3Jv dXAtSWRlbnRpZmllci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEktRCBkb2VzIG5vdCByZWFsbHkgZXhwbGFpbiB0 aGUga2V5IHByb2JsZW0gdG8gYmUgc29sdmVkIG90aGVyIHRoYW4gc2F5aW5nIHRoYXQgM0dQUCBo YXMgYSByZXF1aXJlbWVudCBpbiBXTEFOIGRlcGxveW1lbnRzLiBJdCB3b3VsZCBiZSBnb29kIGlm IHlvdSBjYW4gZXhwbGFpbiB0aGUgbW90aXZhdGlvbiB0byB0aGUgV0cgc28gdGhhdCB0aGUgV0cg Y2FuIGRlY2lkZSBvbiBhZG9wdGluZyBhbmQgcHJvZ3Jlc3NpbmcNCiB0aGlzIEktRC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvcGVmdWxseSB0aGUgYWJvdmUgYW5zd2VycyBwcm92aWRlIHNvbWUgZnVydGhlciBl eHBsYW5hdGlvbi4mbmJzcDsgSSBhZ3JlZSBzYXlpbmcgdGhhdCAzR1BQIGhhcyBhIHJlcXVpcmVt ZW50IGluIG5vdCBhZGVxdWF0ZSBieSBpdHNlbGYuIFdlIGNpdGVkIHRoYXQgYXMgYSByZWZlcmVu Y2Ugb3IgZXZpZGVuY2UNCiB0aGF0IHRoZXJlIGlzIGEgcmVhbCBwcm9ibGVtIGluIHRoZSBsYXJn ZXIgY29tbXVuaXR5IHRoYXQgbmVlZHMgYWRkcmVzc2luZy4gPG86cD4NCjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2hlbiwgSSBwcmVzZW50ZWQgdGhpcyBkcmFmdCBpbiBWYW5jb3V2ZXIg bGFzdCB5ZWFyLCB0aGVyZSB3YXMgYSBmYWlyIGJpdCBvZiBpbnRlcmVzdCBvbiB0aGUgZmxvb3Iu IElmIEkgcmVjYWxsIGNvcnJlY3RseSwgUmFqZWV2IGFza2VkIGZvciBhIHNob3cgb2YgaGFuZHMg YW5kIGEgbnVtYmVyIG9mIGhhbmRzDQogd2VudCB1cCBpbiBzdXBwb3J0LiBJIGFtIGhvcGluZyB0 byBnZXQgdGhlIHNhbWUgZm9sa3Mgdm9pY2UgdGhlaXIgc3VwcG9ydCBvbiB0aGUgbWFpbGluZyBs aXN0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmFqZXNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmFzYXZhcmFqIFBhdGlsIFttYWlsdG86 YnBhdGlsMUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMDcs IDIwMTQgNzowOCBBTTxicj4NCjxiPlRvOjwvYj4gZHJhZnQtcGF6aHlhbm51ci1uZXRleHQtY2l2 aWMtbG9jYXRpb24tYW5pLXN1Ym9wdEB0b29scy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gbmV0 ZXh0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFF1ZXN0aW9uIGFib3V0IGV4dGVuZGlu ZyB0aGUgQU5JIG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGVsbG8gYXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvdXBsZSBvZiBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBwcm9ibGVtIGJlaW5nIHRoYXQg dGhpcyBJLUQgYWltcyB0byBzb2x2ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gV2h5IGlzIHRoZSBleGlzdGluZyBBTkkgb3B0aW9uIG5v dCBzdWZmaWNpZW50IGZvciBlbmNvZGluZyBXTEFOIHNwZWNpZmljIGluZm9ybWF0aW9uPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gSXMgdGhl IHByaW1hcnkgZ29hbCB0byBwcm92aWRlIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBsb2NhdGlvbj8g QW5kIGFzIGEgbWVhbnMgZm9yIGluZG9vciBsb2NhdGlvbiB0cmFja2luZz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEktRCBkb2VzIG5v dCByZWFsbHkgZXhwbGFpbiB0aGUga2V5IHByb2JsZW0gdG8gYmUgc29sdmVkIG90aGVyIHRoYW4g c2F5aW5nIHRoYXQgM0dQUCBoYXMgYSByZXF1aXJlbWVudCBpbiBXTEFOIGRlcGxveW1lbnRzLiBJ dCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gZXhwbGFpbiB0aGUgbW90aXZhdGlvbiB0byB0aGUg V0cgc28gdGhhdCB0aGUgV0cgY2FuIGRlY2lkZSBvbiBhZG9wdGluZyBhbmQgcHJvZ3Jlc3NpbmcN CiB0aGlzIEktRC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LVJhajxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpCYXNhdmFyYWogUGF0aWwgPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4ED2E36A22261145861BAB2C24088B4320F7BA96xmbalnx09ciscoc_-- From nobody Wed May 7 08:47:13 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB01A0793 for ; Wed, 7 May 2014 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 ke3f7K5573ic for ; Wed, 7 May 2014 08:47:09 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C186F1A07C0 for ; Wed, 7 May 2014 08:47:09 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wn1so1431714obc.13 for ; Wed, 07 May 2014 08:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i0N79s2hjCmScoXIqF1/HTSpMIVYwNDSbez+0q3OFWA=; b=xICD26h1ICMie9wF3Pl0RR2u2XwxjH5A4mRVg99TePMQ+TU6O+jjkR8Ll6LDbBvKPK vLE+GifPzRK0SoA4hXV8BhiPIvinllJPb0FPcnbvAsfS/VYIkgR92O5nrJ9uksMVWQBt eUxa88jVoIxla94zQ1ex0xRnK0KfeDrqZMdGnNFXdl2S5m2hb3/FM/+Zc+DCYcIoyKfF 50Dsgp82aIwIdlFrnfRoytlzpPsJ+CI+mU7UHfv+NxMP3J1VB9kSvndeGH0OAI4VN7px 1fk1Dof1GP/HMPUHe1jTw4sgNYhwvl1ew9geXoqRBgvAk3hs0jyb9QN8ChIT11WYnWfi mX8w== MIME-Version: 1.0 X-Received: by 10.182.246.40 with SMTP id xt8mr3815453obc.76.1399477625487; Wed, 07 May 2014 08:47:05 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 7 May 2014 08:47:05 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F7BA96@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F7BA96@xmb-aln-x09.cisco.com> Date: Wed, 7 May 2014 10:47:05 -0500 Message-ID: From: Basavaraj Patil To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: multipart/alternative; boundary=001a11c32246bd087904f8d14628 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/AyAtxjmlmCAiVRNTp4_px90KCFo Cc: "netext@ietf.org" , "draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org" Subject: Re: [netext] Question about extending the ANI option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:47:11 -0000 --001a11c32246bd087904f8d14628 Content-Type: text/plain; charset=UTF-8 Hi Rajesh, Thanks for the response. So the objective is for the LMA to get location information about the MN w.r.t the WiFi AP that it is attached to. In a 3GPP context, the LMA is part of the PGW. Does the PGW not have access to this information? The PGW has location information w.r.t the cellular location. And I agree that indoor location w.r.t GPS is an issue. Question is whether the only source of information for the PGW/LMA about the AP that the MN is attached to via the PMIP6 PBU? Rgds, -Raj On Wed, May 7, 2014 at 9:42 AM, Rajesh Pazhyannur (rpazhyan) < rpazhyan@cisco.com> wrote: > Hi Raj > > > > 1. Why is the existing ANI option not sufficient for encoding WLAN > specific information? > > 2. Is the primary goal to provide information regarding location? And as a > means for indoor location tracking? > > > > > > > > 1) RFC 6757 defines three ANI Types: Network Identifier, > Geo-Location, Operator Identifier. For WLAN deployments, there is a need > in many cases (e.g., regulatory, location based services, location based > policy, etc) to identify the AP the user is attached to. RFC 6757 provides > one way to do it via Geo-Location. However, many indoor APs are unlikely to > have GPS to provide Geo-location. However, these indoor APs are often > provisioned with a Civic location today. RFC 6757 does not provide a way to > encapsulate Civic Location. So we are proposing adding a new ANI Type: > Civic Location. We are also defining another ANI Type: Group Identifier. > In many existing deployments APs are grouped together with a group-id. The > group identifier refers to a coarse location such as a specific > coffee-store, book-store, etc. This form of ANI information is also useful > in facilitating many location based applications. > > 2) The primary goal is indeed for the MAG to provide location > information about the Access Point that the user is attached to. RFC 6757 > provided a way to provide GPS. But GPS does not work well in indoor > deployments and sometimes is considered expensive for indoor APs. As a > result, we are looking for alternatives. The two alternatives proposed: > Civic Location, and Group-Identifier. > > > > The I-D does not really explain the key problem to be solved other than > saying that 3GPP has a requirement in WLAN deployments. It would be good if > you can explain the motivation to the WG so that the WG can decide on > adopting and progressing this I-D. > > > > > > Hopefully the above answers provide some further explanation. I agree > saying that 3GPP has a requirement in not adequate by itself. We cited that > as a reference or evidence that there is a real problem in the larger > community that needs addressing. > > > > When, I presented this draft in Vancouver last year, there was a fair bit > of interest on the floor. If I recall correctly, Rajeev asked for a show of > hands and a number of hands went up in support. I am hoping to get the same > folks voice their support on the mailing list J > > > > Regards > > > > Rajesh > > > > *From:* Basavaraj Patil [mailto:bpatil1@gmail.com] > *Sent:* Wednesday, May 07, 2014 7:08 AM > *To:* draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org > *Cc:* netext@ietf.org > *Subject:* Question about extending the ANI option > > > > > > Hello authors, > > > > Couple of questions regarding the problem being that this I-D aims to > solve: > > > > 1. Why is the existing ANI option not sufficient for encoding WLAN > specific information? > > 2. Is the primary goal to provide information regarding location? And as a > means for indoor location tracking? > > > > The I-D does not really explain the key problem to be solved other than > saying that 3GPP has a requirement in WLAN deployments. It would be good if > you can explain the motivation to the WG so that the WG can decide on > adopting and progressing this I-D. > > > > -Raj > > > > -- > Basavaraj Patil > -- Basavaraj Patil --001a11c32246bd087904f8d14628 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rajesh,

Thanks for the response.=C2= =A0

So the objective is for the LMA to get locatio= n information about the MN w.r.t the WiFi AP that it is attached to.=C2=A0<= /div>
In a 3GPP context, the LMA is part of the PGW. Does the PGW not have access= to this information?

The PGW has location informa= tion w.r.t the cellular location. And I agree that indoor location w.r.t GP= S is an issue.=C2=A0
Question is whether the only source of information for the PGW/LMA abo= ut the AP that the MN is attached to via the PMIP6 PBU?

Rgds,
-Raj


On Wed, May 7, 2014 at 9:42 AM, Rajesh Pazhyannu= r (rpazhyan) <rpazhyan@cisco.com> wrote:

Hi Raj

=C2=A0

1. Why is the existing ANI option not sufficient for= encoding WLAN specific information?

2. Is the primary goal to provide information regard= ing location? And as a means for indoor location tracking?

=C2=A0

=C2=A0

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 6757 defines three ANI Types: Net= work Identifier, Geo-Location, Operator Identifier. =C2=A0For WLAN deployme= nts, there is a need in many cases (e.g., regulatory, =C2=A0location based services, location based policy, etc) to identify the AP the user is= attached to.=C2=A0 RFC 6757 provides one way to do it via Geo-Location. Ho= wever, many indoor APs are unlikely to have GPS to provide Geo-location. Ho= wever, these indoor APs are often provisioned with a Civic location today. RFC 6757 does not provide a way to encapsulat= e Civic Location. So we are proposing adding a new ANI Type: Civic Location= . =C2=A0We are also defining another ANI Type: Group Identifier. In many ex= isting deployments APs are grouped together with a group-id. The group identifier refers to a coarse location such as = a specific coffee-store, book-store, etc.=C2=A0 This form of ANI informatio= n is also useful in facilitating many location based applications.

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The primary goal is indeed for the MA= G to provide location information about the Access Point that the user is a= ttached to. RFC 6757 provided a way to provide GPS. But GPS does not work well in indoor deployments and sometimes is consider= ed expensive for indoor APs. As a result, we are looking for alternatives. = The two alternatives proposed: Civic Location, and Group-Identifier.

=C2=A0

The I-D does not really explain the key problem to b= e solved other than saying that 3GPP has a requirement in WLAN deployments.= It would be good if you can explain the motivation to the WG so that the W= G can decide on adopting and progressing this I-D.

=C2=A0

=C2=A0

Hopefully the above answers provide = some further explanation.=C2=A0 I agree saying that 3GPP has a requirement = in not adequate by itself. We cited that as a reference or evidence that there is a real problem in the larger community that needs addressing= .

=C2=A0

When, I presented this draft in Vancouver = last year, there was a fair bit of interest on the floor. If I recall corre= ctly, Rajeev asked for a show of hands and a number of hands went up in support. I am hoping to get the same folks voice their support = on the mailing list J

=C2=A0

Regards

=C2=A0

Rajesh

=C2=A0

From: Basavara= j Patil [mailto:bpat= il1@gmail.com]
Sent: Wednesday, May 07, 2014 7:08 AM
To: draft-pazhyannur-netext-civic-locatio= n-ani-subopt@tools.ietf.org
Cc: netext@ietf= .org
Subject: Question about extending the ANI option

=C2=A0

=C2=A0

Hello authors,

=C2=A0

Couple of questions regarding the problem being that= this I-D aims to solve:

=C2=A0

1. Why is the existing ANI option not sufficient for= encoding WLAN specific information?

2. Is the primary goal to provide information regard= ing location? And as a means for indoor location tracking?

=C2=A0

The I-D does not really explain the key problem to b= e solved other than saying that 3GPP has a requirement in WLAN deployments.= It would be good if you can explain the motivation to the WG so that the W= G can decide on adopting and progressing this I-D.

=C2=A0

-Raj

=C2=A0

--
Basavaraj Patil




--
Basavaraj Pa= til
--001a11c32246bd087904f8d14628-- From nobody Wed May 7 08:54:11 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5D1A0392 for ; Wed, 7 May 2014 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4XdX5QKTVqJ for ; Wed, 7 May 2014 08:54:08 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEF1A0791 for ; Wed, 7 May 2014 08:54:08 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9F1E1880E7; Wed, 7 May 2014 08:54:04 -0700 (PDT) Received: from 10252100174.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 35D9671B0001; Wed, 7 May 2014 08:54:04 -0700 (PDT) Message-ID: <536A5721.8000100@innovationslab.net> Date: Wed, 07 May 2014 11:54:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org, "netext@ietf.org" , Basavaraj Patil X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uNKXKNmkT1TrNQC9ScvPXgIBG8gtm9wAD" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/W4G2SiiXandf5F3Rte-5Ci5AKOE Subject: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:54:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uNKXKNmkT1TrNQC9ScvPXgIBG8gtm9wAD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I have performed my review of draft-ietf-netext-wifi-epc-eap-attributes as a part of the IETF publication process. These comments will need to be addressed prior to IETF Last Call. 1. The draft has several nits that need to be fixed. Please run id-nits and resolve the warnings generated. 2. The document states that these new EAP attributes can be used in WiFi networks. Later, it talks about networks that employ 802.1X. Please be more specific as to what is covered under the generic WiFi in the context of this specification. 3. Please change all occurrences of EUTRAN to E-UTRAN (per RFC 6459). 4. Given the use of PMIP as an example, please include an informative reference to the relevant PMIP RFC(s). 5. There is no expansion/definition of P-TMSI or M-TMSI in the draft. Those terms do not appear in RFC 6459. Please clarify these acronyms on first use. 6. The document notionally mentions 3GPP and references GPRS. Are those the target 3G/4G networks? Is this applicable to LTE or other technologies? More clarity here would be useful. 7. In section 4, it would be beneficial to include forward references to the actual option specification sections for the AT_* attributes. 8. Several of the attributes include strings in the data. What is the encoding for these strings? 9. The attributes all contain Length fields with no description of what fields are included in the length. 10. Are the sub-types and types in 5.2, 5.3, 5.5, & 5.6 set in stone? Could new ones be defined in the future? If so, you will want to consider if they should be IANA registries. Otherwise, future RFCs will need to update this spec to extend the type/sub-type values supported. 11. I am confused by the relationship between the attributes defined in sections 5.4 and 5.5. Would the AT_HANDOVER_SESSION_ID attribute ever be used without the AT_HANDOVER_INDICATION? If not, why have the session id in a separate attribute? It seems straightforward to include the session id info in the AT_HANDOVER_INDICATION attribute if Type=3D1. Am I missing something? 12. The formatting of figure 7 is messed up. 13. I see that there are no normative references. At a minimum, it seems like the EAP specs should be normative. 14. The Security Considerations section tells me nothing. Are there new threats with these new pieces of information flowing across the network? What are the privacy implications of these messages? Can any of the possible threat vectors be minimized? Regards, Brian --uNKXKNmkT1TrNQC9ScvPXgIBG8gtm9wAD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTalcnAAoJEBOZRqCi7goquMQH/26aZnpXlj6phFqgi/VqOCjv NtxU6nENQqq8NjTbHbY5AsjoOrUjGtK6vbKhThZr+EaLchoZm64eJrFYCbz61RcZ khQ9uaONlwtxJG3zUYlJuNyJ5oJiwbNls08s6gq+VhM7GKcRCshDIZ4DxGtvvDhz +P7W+t5UJLpxSNVQVv6Qd+OeX3U5HST0gjE4P79axCmpqOMMx1seWy6X7eOOAKn6 BBan8/I7qbfupzY3PaBbIhKGrLtt1UgNq0fuKkeYUKzasoshSqw/rU2Rpfcvm354 boIJ9oyNQvIcMpGibB88BnSr1Buh6yQPy56MuWfiw86ObNCwrr/buod/mKb98Po= =RWZF -----END PGP SIGNATURE----- --uNKXKNmkT1TrNQC9ScvPXgIBG8gtm9wAD-- From nobody Wed May 7 09:03:08 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24841A0791 for ; Wed, 7 May 2014 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7gJw6IDtR-n for ; Wed, 7 May 2014 09:03:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 864D71A07B2 for ; Wed, 7 May 2014 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30922; q=dns/txt; s=iport; t=1399478576; x=1400688176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OGg7Mt7dv2nbvShm0ufbynm8PXaGJt5+KCyoIC3sh5c=; b=avuauVa5jT0pKcex9V6o+cQ79HRJMWEM2CTWmhQLaDA7dO5qY1zFqznf URURgEQorQ+le73O44kmDmHt9i3TovH++sKAIZD9EFWXDhPqslNVhLEU7 CgLzlDhbq9ym6Wyjhq8y7IiqmcSQyWqKXJegLvWCjP8Cq3JbxeiHFAn6V I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwIAOtXalOtJA2M/2dsb2JhbABQCoJCRE9YgmeoHAEBAQUBmg4BGYEAFnSCJQEBAQQjCkELEAIBCA4DBAEBCxYHAwICAh8RFAkIAgQOBQgMiBkDEAGqOZ5uDYZIF4VWhmWBNQYLAR8xBgGCdDaBFQSXRY8MhWGDNIF2OQ X-IronPort-AV: E=Sophos;i="4.97,1004,1389744000"; d="scan'208,217";a="323035625" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 07 May 2014 16:02:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s47G2t5v012353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 16:02:55 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 7 May 2014 11:02:55 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Basavaraj Patil Thread-Topic: Question about extending the ANI option Thread-Index: AQHPaf3VpTqmG1NALUKU4SE67RUyxJs1LQpQgABp/ID//68WgA== Date: Wed, 7 May 2014 16:02:54 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F7BBB0@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F7BA96@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.70.242.20] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F7BBB0xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/H6OxLhHumDqIiR6cQvl71hbL30A Cc: "netext@ietf.org" , "draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org" Subject: Re: [netext] Question about extending the ANI option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:03:03 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F7BBB0xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UXVlc3Rpb24gaXMgd2hldGhlciB0aGUgb25seSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZm9yIHRo ZSBQR1cvTE1BIGFib3V0IHRoZSBBUCB0aGF0IHRoZSBNTiBpcyBhdHRhY2hlZCB0byB2aWEgdGhl IFBNSVA2IFBCVT8NCg0KDQrDmCAgVGhlIHRlY2huaWNhbGx5IHJpZ2h0IGFuc3dlciBpcyB0aGF0 IFBNSVB2NiAgaXMgKm5vdCogdGhlIG9ubHkgc291cmNlIG9mIGluZm9ybWF0aW9uLiBBcyBJIGlu ZGljYXRlZCBpbiBlYXJsaWVyIGVtYWlsLCB0b2RheeKAmXMgaW1wbGVtZW50YXRpb24gdXNlIFJh ZGl1cyA1NTgwIGFuZC9vciBESENQIE9wdGlvbiA4MiB0byBzZW5kIGxvY2F0aW9uIGluZm9ybWF0 aW9uLg0KDQrDmCAgSG93ZXZlciwgUkZDIDY3NTcgcHJvdmlkZWQgYSB3YXkgdG8gc2lnbmFsIGdl by1sb2NhdGlvbiDigJxpbi1iYW5k4oCdLiBUaGlzIGFwcHJvYWNoIGlzIHByZWZlcmFibGUgdG8g c29tZSBvcGVyYXRvcnMuIFdlIGZlZWwgdGhhdCBzdWNoIGRlcGxveW1lbnRzIHdpbGwgYmVuZWZp dCBmcm9tIGZ1cnRoZXIgZW5oYW5jZW1lbnQgaW4gdGhlIGZvcm0gb2YgQ2l2aWMtbG9jYXRpb24g YW5kIEdyb3VwLUlkLg0KRnJvbTogQmFzYXZhcmFqIFBhdGlsIFttYWlsdG86YnBhdGlsMUBnbWFp bC5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1heSAwNywgMjAxNCA4OjQ3IEFNDQpUbzogUmFqZXNo IFBhemh5YW5udXIgKHJwYXpoeWFuKQ0KQ2M6IGRyYWZ0LXBhemh5YW5udXItbmV0ZXh0LWNpdmlj LWxvY2F0aW9uLWFuaS1zdWJvcHRAdG9vbHMuaWV0Zi5vcmc7IG5ldGV4dEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFF1ZXN0aW9uIGFib3V0IGV4dGVuZGluZyB0aGUgQU5JIG9wdGlvbg0KDQpIaSBS YWplc2gsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLg0KDQpTbyB0aGUgb2JqZWN0aXZlIGlz IGZvciB0aGUgTE1BIHRvIGdldCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgTU4gdy5y LnQgdGhlIFdpRmkgQVAgdGhhdCBpdCBpcyBhdHRhY2hlZCB0by4NCkluIGEgM0dQUCBjb250ZXh0 LCB0aGUgTE1BIGlzIHBhcnQgb2YgdGhlIFBHVy4gRG9lcyB0aGUgUEdXIG5vdCBoYXZlIGFjY2Vz cyB0byB0aGlzIGluZm9ybWF0aW9uPw0KDQpUaGUgUEdXIGhhcyBsb2NhdGlvbiBpbmZvcm1hdGlv biB3LnIudCB0aGUgY2VsbHVsYXIgbG9jYXRpb24uIEFuZCBJIGFncmVlIHRoYXQgaW5kb29yIGxv Y2F0aW9uIHcuci50IEdQUyBpcyBhbiBpc3N1ZS4NClF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIG9u bHkgc291cmNlIG9mIGluZm9ybWF0aW9uIGZvciB0aGUgUEdXL0xNQSBhYm91dCB0aGUgQVAgdGhh dCB0aGUgTU4gaXMgYXR0YWNoZWQgdG8gdmlhIHRoZSBQTUlQNiBQQlU/DQoNClJnZHMsDQotUmFq DQoNCk9uIFdlZCwgTWF5IDcsIDIwMTQgYXQgOTo0MiBBTSwgUmFqZXNoIFBhemh5YW5udXIgKHJw YXpoeWFuKSA8cnBhemh5YW5AY2lzY28uY29tPG1haWx0bzpycGF6aHlhbkBjaXNjby5jb20+PiB3 cm90ZToNCkhpIFJhag0KDQoxLiBXaHkgaXMgdGhlIGV4aXN0aW5nIEFOSSBvcHRpb24gbm90IHN1 ZmZpY2llbnQgZm9yIGVuY29kaW5nIFdMQU4gc3BlY2lmaWMgaW5mb3JtYXRpb24/DQoyLiBJcyB0 aGUgcHJpbWFyeSBnb2FsIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGxvY2F0aW9u PyBBbmQgYXMgYSBtZWFucyBmb3IgaW5kb29yIGxvY2F0aW9uIHRyYWNraW5nPw0KDQoNCg0KDQox KSAgICAgIFJGQyA2NzU3IGRlZmluZXMgdGhyZWUgQU5JIFR5cGVzOiBOZXR3b3JrIElkZW50aWZp ZXIsIEdlby1Mb2NhdGlvbiwgT3BlcmF0b3IgSWRlbnRpZmllci4gIEZvciBXTEFOIGRlcGxveW1l bnRzLCB0aGVyZSBpcyBhIG5lZWQgaW4gbWFueSBjYXNlcyAoZS5nLiwgcmVndWxhdG9yeSwgIGxv Y2F0aW9uIGJhc2VkIHNlcnZpY2VzLCBsb2NhdGlvbiBiYXNlZCBwb2xpY3ksIGV0YykgdG8gaWRl bnRpZnkgdGhlIEFQIHRoZSB1c2VyIGlzIGF0dGFjaGVkIHRvLiAgUkZDIDY3NTcgcHJvdmlkZXMg b25lIHdheSB0byBkbyBpdCB2aWEgR2VvLUxvY2F0aW9uLiBIb3dldmVyLCBtYW55IGluZG9vciBB UHMgYXJlIHVubGlrZWx5IHRvIGhhdmUgR1BTIHRvIHByb3ZpZGUgR2VvLWxvY2F0aW9uLiBIb3dl dmVyLCB0aGVzZSBpbmRvb3IgQVBzIGFyZSBvZnRlbiBwcm92aXNpb25lZCB3aXRoIGEgQ2l2aWMg bG9jYXRpb24gdG9kYXkuIFJGQyA2NzU3IGRvZXMgbm90IHByb3ZpZGUgYSB3YXkgdG8gZW5jYXBz dWxhdGUgQ2l2aWMgTG9jYXRpb24uIFNvIHdlIGFyZSBwcm9wb3NpbmcgYWRkaW5nIGEgbmV3IEFO SSBUeXBlOiBDaXZpYyBMb2NhdGlvbi4gIFdlIGFyZSBhbHNvIGRlZmluaW5nIGFub3RoZXIgQU5J IFR5cGU6IEdyb3VwIElkZW50aWZpZXIuIEluIG1hbnkgZXhpc3RpbmcgZGVwbG95bWVudHMgQVBz IGFyZSBncm91cGVkIHRvZ2V0aGVyIHdpdGggYSBncm91cC1pZC4gVGhlIGdyb3VwIGlkZW50aWZp ZXIgcmVmZXJzIHRvIGEgY29hcnNlIGxvY2F0aW9uIHN1Y2ggYXMgYSBzcGVjaWZpYyBjb2ZmZWUt c3RvcmUsIGJvb2stc3RvcmUsIGV0Yy4gIFRoaXMgZm9ybSBvZiBBTkkgaW5mb3JtYXRpb24gaXMg YWxzbyB1c2VmdWwgaW4gZmFjaWxpdGF0aW5nIG1hbnkgbG9jYXRpb24gYmFzZWQgYXBwbGljYXRp b25zLg0KDQoyKSAgICAgIFRoZSBwcmltYXJ5IGdvYWwgaXMgaW5kZWVkIGZvciB0aGUgTUFHIHRv IHByb3ZpZGUgbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIEFjY2VzcyBQb2ludCB0aGF0 IHRoZSB1c2VyIGlzIGF0dGFjaGVkIHRvLiBSRkMgNjc1NyBwcm92aWRlZCBhIHdheSB0byBwcm92 aWRlIEdQUy4gQnV0IEdQUyBkb2VzIG5vdCB3b3JrIHdlbGwgaW4gaW5kb29yIGRlcGxveW1lbnRz IGFuZCBzb21ldGltZXMgaXMgY29uc2lkZXJlZCBleHBlbnNpdmUgZm9yIGluZG9vciBBUHMuIEFz IGEgcmVzdWx0LCB3ZSBhcmUgbG9va2luZyBmb3IgYWx0ZXJuYXRpdmVzLiBUaGUgdHdvIGFsdGVy bmF0aXZlcyBwcm9wb3NlZDogQ2l2aWMgTG9jYXRpb24sIGFuZCBHcm91cC1JZGVudGlmaWVyLg0K DQpUaGUgSS1EIGRvZXMgbm90IHJlYWxseSBleHBsYWluIHRoZSBrZXkgcHJvYmxlbSB0byBiZSBz b2x2ZWQgb3RoZXIgdGhhbiBzYXlpbmcgdGhhdCAzR1BQIGhhcyBhIHJlcXVpcmVtZW50IGluIFdM QU4gZGVwbG95bWVudHMuIEl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBleHBsYWluIHRoZSBt b3RpdmF0aW9uIHRvIHRoZSBXRyBzbyB0aGF0IHRoZSBXRyBjYW4gZGVjaWRlIG9uIGFkb3B0aW5n IGFuZCBwcm9ncmVzc2luZyB0aGlzIEktRC4NCg0KDQpIb3BlZnVsbHkgdGhlIGFib3ZlIGFuc3dl cnMgcHJvdmlkZSBzb21lIGZ1cnRoZXIgZXhwbGFuYXRpb24uICBJIGFncmVlIHNheWluZyB0aGF0 IDNHUFAgaGFzIGEgcmVxdWlyZW1lbnQgaW4gbm90IGFkZXF1YXRlIGJ5IGl0c2VsZi4gV2UgY2l0 ZWQgdGhhdCBhcyBhIHJlZmVyZW5jZSBvciBldmlkZW5jZSB0aGF0IHRoZXJlIGlzIGEgcmVhbCBw cm9ibGVtIGluIHRoZSBsYXJnZXIgY29tbXVuaXR5IHRoYXQgbmVlZHMgYWRkcmVzc2luZy4NCg0K V2hlbiwgSSBwcmVzZW50ZWQgdGhpcyBkcmFmdCBpbiBWYW5jb3V2ZXIgbGFzdCB5ZWFyLCB0aGVy ZSB3YXMgYSBmYWlyIGJpdCBvZiBpbnRlcmVzdCBvbiB0aGUgZmxvb3IuIElmIEkgcmVjYWxsIGNv cnJlY3RseSwgUmFqZWV2IGFza2VkIGZvciBhIHNob3cgb2YgaGFuZHMgYW5kIGEgbnVtYmVyIG9m IGhhbmRzIHdlbnQgdXAgaW4gc3VwcG9ydC4gSSBhbSBob3BpbmcgdG8gZ2V0IHRoZSBzYW1lIGZv bGtzIHZvaWNlIHRoZWlyIHN1cHBvcnQgb24gdGhlIG1haWxpbmcgbGlzdCDimLoNCg0KUmVnYXJk cw0KDQpSYWplc2gNCg0KRnJvbTogQmFzYXZhcmFqIFBhdGlsIFttYWlsdG86YnBhdGlsMUBnbWFp bC5jb208bWFpbHRvOmJwYXRpbDFAZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDA3 LCAyMDE0IDc6MDggQU0NClRvOiBkcmFmdC1wYXpoeWFubnVyLW5ldGV4dC1jaXZpYy1sb2NhdGlv bi1hbmktc3Vib3B0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1wYXpoeWFubnVyLW5ldGV4 dC1jaXZpYy1sb2NhdGlvbi1hbmktc3Vib3B0QHRvb2xzLmlldGYub3JnPg0KQ2M6IG5ldGV4dEBp ZXRmLm9yZzxtYWlsdG86bmV0ZXh0QGlldGYub3JnPg0KU3ViamVjdDogUXVlc3Rpb24gYWJvdXQg ZXh0ZW5kaW5nIHRoZSBBTkkgb3B0aW9uDQoNCg0KSGVsbG8gYXV0aG9ycywNCg0KQ291cGxlIG9m IHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhlIHByb2JsZW0gYmVpbmcgdGhhdCB0aGlzIEktRCBhaW1z IHRvIHNvbHZlOg0KDQoxLiBXaHkgaXMgdGhlIGV4aXN0aW5nIEFOSSBvcHRpb24gbm90IHN1ZmZp Y2llbnQgZm9yIGVuY29kaW5nIFdMQU4gc3BlY2lmaWMgaW5mb3JtYXRpb24/DQoyLiBJcyB0aGUg cHJpbWFyeSBnb2FsIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGxvY2F0aW9uPyBB bmQgYXMgYSBtZWFucyBmb3IgaW5kb29yIGxvY2F0aW9uIHRyYWNraW5nPw0KDQpUaGUgSS1EIGRv ZXMgbm90IHJlYWxseSBleHBsYWluIHRoZSBrZXkgcHJvYmxlbSB0byBiZSBzb2x2ZWQgb3RoZXIg dGhhbiBzYXlpbmcgdGhhdCAzR1BQIGhhcyBhIHJlcXVpcmVtZW50IGluIFdMQU4gZGVwbG95bWVu dHMuIEl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBleHBsYWluIHRoZSBtb3RpdmF0aW9uIHRv IHRoZSBXRyBzbyB0aGF0IHRoZSBXRyBjYW4gZGVjaWRlIG9uIGFkb3B0aW5nIGFuZCBwcm9ncmVz c2luZyB0aGlzIEktRC4NCg0KLVJhag0KDQotLQ0KQmFzYXZhcmFqIFBhdGlsDQoNCg0KDQotLQ0K QmFzYXZhcmFqIFBhdGlsDQo= --_000_4ED2E36A22261145861BAB2C24088B4320F7BBB0xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNv cmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDQ5NTk4ODUzOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY3OTEwMjQ5 OCAtMTI4OTAzMjE4OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1ZXN0 aW9uIGlzIHdoZXRoZXIgdGhlIG9ubHkgc291cmNlIG9mIGluZm9ybWF0aW9uIGZvciB0aGUgUEdX L0xNQSBhYm91dCB0aGUgQVAgdGhhdCB0aGUgTU4gaXMgYXR0YWNoZWQgdG8gdmlhIHRoZSBQTUlQ NiBQQlU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSB0ZWNobmljYWxseSByaWdodCBhbnN3ZXIgaXMgdGhhdCBQTUlQdjYmbmJzcDsgaXMgKjxi Pm5vdDwvYj4qIHRoZSBvbmx5IHNvdXJjZSBvZiBpbmZvcm1hdGlvbi4gQXMgSSBpbmRpY2F0ZWQg aW4gZWFybGllciBlbWFpbCwgdG9kYXnigJlzIGltcGxlbWVudGF0aW9uIHVzZSBSYWRpdXMgNTU4 MA0KIGFuZC9vciBESENQIE9wdGlvbiA4MiB0byBzZW5kIGxvY2F0aW9uIGluZm9ybWF0aW9uLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBSRkMgNjc1NyBw cm92aWRlZCBhIHdheSB0byBzaWduYWwgZ2VvLWxvY2F0aW9uIOKAnGluLWJhbmTigJ0uIFRoaXMg YXBwcm9hY2ggaXMgcHJlZmVyYWJsZSB0byBzb21lIG9wZXJhdG9ycy4gV2UgZmVlbCB0aGF0IHN1 Y2ggZGVwbG95bWVudHMgd2lsbCBiZW5lZml0IGZyb20gZnVydGhlcg0KIGVuaGFuY2VtZW50IGlu IHRoZSBmb3JtIG9mIENpdmljLWxvY2F0aW9uIGFuZCBHcm91cC1JZC4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJhc2F2YXJh aiBQYXRpbCBbbWFpbHRvOmJwYXRpbDFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgTWF5IDA3LCAyMDE0IDg6NDcgQU08YnI+DQo8Yj5Ubzo8L2I+IFJhamVzaCBQYXpo eWFubnVyIChycGF6aHlhbik8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXBhemh5YW5udXItbmV0ZXh0 LWNpdmljLWxvY2F0aW9uLWFuaS1zdWJvcHRAdG9vbHMuaWV0Zi5vcmc7IG5ldGV4dEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUXVlc3Rpb24gYWJvdXQgZXh0ZW5kaW5nIHRoZSBB Tkkgb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmFqZXNo LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZv ciB0aGUgcmVzcG9uc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRoZSBvYmplY3RpdmUgaXMgZm9yIHRoZSBMTUEgdG8gZ2V0 IGxvY2F0aW9uIGluZm9ybWF0aW9uIGFib3V0IHRoZSBNTiB3LnIudCB0aGUgV2lGaSBBUCB0aGF0 IGl0IGlzIGF0dGFjaGVkIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYSAzR1BQIGNvbnRleHQsIHRoZSBMTUEgaXMgcGFydCBv ZiB0aGUgUEdXLiBEb2VzIHRoZSBQR1cgbm90IGhhdmUgYWNjZXNzIHRvIHRoaXMgaW5mb3JtYXRp b24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBQR1cgaGFzIGxvY2F0aW9uIGluZm9ybWF0aW9uIHcuci50IHRoZSBjZWxsdWxhciBsb2Nh dGlvbi4gQW5kIEkgYWdyZWUgdGhhdCBpbmRvb3IgbG9jYXRpb24gdy5yLnQgR1BTIGlzIGFuIGlz c3VlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UXVlc3Rpb24gaXMgd2hldGhlciB0aGUgb25seSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24g Zm9yIHRoZSBQR1cvTE1BIGFib3V0IHRoZSBBUCB0aGF0IHRoZSBNTiBpcyBhdHRhY2hlZCB0byB2 aWEgdGhlIFBNSVA2IFBCVT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Umdkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi1SYWo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1h eSA3LCAyMDE0IGF0IDk6NDIgQU0sIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikgJmx0Ozxh IGhyZWY9Im1haWx0bzpycGF6aHlhbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5ycGF6aHlh bkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJhajwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4xLiBXaHkgaXMgdGhlIGV4aXN0aW5nIEFOSSBvcHRpb24gbm90IHN1 ZmZpY2llbnQgZm9yIGVuY29kaW5nIFdMQU4gc3BlY2lmaWMgaW5mb3JtYXRpb24/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIElzIHRoZSBwcmltYXJ5IGdvYWwgdG8g cHJvdmlkZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgbG9jYXRpb24/IEFuZCBhcyBhIG1lYW5zIGZv ciBpbmRvb3IgbG9jYXRpb24gdHJhY2tpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJGQyA2NzU3IGRlZmluZXMgdGhyZWUgQU5JIFR5cGVzOiBOZXR3b3JrIElkZW50aWZpZXIs IEdlby1Mb2NhdGlvbiwgT3BlcmF0b3IgSWRlbnRpZmllci4gJm5ic3A7Rm9yIFdMQU4gZGVwbG95 bWVudHMsIHRoZXJlIGlzIGEgbmVlZCBpbiBtYW55IGNhc2VzIChlLmcuLCByZWd1bGF0b3J5LCAm bmJzcDtsb2NhdGlvbiBiYXNlZCBzZXJ2aWNlcywNCiBsb2NhdGlvbiBiYXNlZCBwb2xpY3ksIGV0 YykgdG8gaWRlbnRpZnkgdGhlIEFQIHRoZSB1c2VyIGlzIGF0dGFjaGVkIHRvLiZuYnNwOyBSRkMg Njc1NyBwcm92aWRlcyBvbmUgd2F5IHRvIGRvIGl0IHZpYSBHZW8tTG9jYXRpb24uIEhvd2V2ZXIs IG1hbnkgaW5kb29yIEFQcyBhcmUgdW5saWtlbHkgdG8gaGF2ZSBHUFMgdG8gcHJvdmlkZSBHZW8t bG9jYXRpb24uIEhvd2V2ZXIsIHRoZXNlIGluZG9vciBBUHMgYXJlIG9mdGVuIHByb3Zpc2lvbmVk IHdpdGggYQ0KIENpdmljIGxvY2F0aW9uIHRvZGF5LiBSRkMgNjc1NyBkb2VzIG5vdCBwcm92aWRl IGEgd2F5IHRvIGVuY2Fwc3VsYXRlIENpdmljIExvY2F0aW9uLiBTbyB3ZSBhcmUgcHJvcG9zaW5n IGFkZGluZyBhIG5ldyBBTkkgVHlwZTogQ2l2aWMgTG9jYXRpb24uICZuYnNwO1dlIGFyZSBhbHNv IGRlZmluaW5nIGFub3RoZXIgQU5JIFR5cGU6IEdyb3VwIElkZW50aWZpZXIuIEluIG1hbnkgZXhp c3RpbmcgZGVwbG95bWVudHMgQVBzIGFyZSBncm91cGVkIHRvZ2V0aGVyDQogd2l0aCBhIGdyb3Vw LWlkLiBUaGUgZ3JvdXAgaWRlbnRpZmllciByZWZlcnMgdG8gYSBjb2Fyc2UgbG9jYXRpb24gc3Vj aCBhcyBhIHNwZWNpZmljIGNvZmZlZS1zdG9yZSwgYm9vay1zdG9yZSwgZXRjLiZuYnNwOyBUaGlz IGZvcm0gb2YgQU5JIGluZm9ybWF0aW9uIGlzIGFsc28gdXNlZnVsIGluIGZhY2lsaXRhdGluZyBt YW55IGxvY2F0aW9uIGJhc2VkIGFwcGxpY2F0aW9ucy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mik8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcmltYXJ5IGdvYWwgaXMgaW5k ZWVkIGZvciB0aGUgTUFHIHRvIHByb3ZpZGUgbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhl IEFjY2VzcyBQb2ludCB0aGF0IHRoZSB1c2VyIGlzIGF0dGFjaGVkIHRvLiBSRkMgNjc1NyBwcm92 aWRlZCBhIHdheSB0byBwcm92aWRlIEdQUy4gQnV0IEdQUyBkb2VzIG5vdCB3b3JrIHdlbGwNCiBp biBpbmRvb3IgZGVwbG95bWVudHMgYW5kIHNvbWV0aW1lcyBpcyBjb25zaWRlcmVkIGV4cGVuc2l2 ZSBmb3IgaW5kb29yIEFQcy4gQXMgYSByZXN1bHQsIHdlIGFyZSBsb29raW5nIGZvciBhbHRlcm5h dGl2ZXMuIFRoZSB0d28gYWx0ZXJuYXRpdmVzIHByb3Bvc2VkOiBDaXZpYyBMb2NhdGlvbiwgYW5k IEdyb3VwLUlkZW50aWZpZXIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIEktRCBkb2VzIG5vdCBy ZWFsbHkgZXhwbGFpbiB0aGUga2V5IHByb2JsZW0gdG8gYmUgc29sdmVkIG90aGVyIHRoYW4gc2F5 aW5nIHRoYXQgM0dQUCBoYXMgYSByZXF1aXJlbWVudCBpbiBXTEFOIGRlcGxveW1lbnRzLiBJdCB3 b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gZXhwbGFpbiB0aGUgbW90aXZhdGlvbg0KIHRvIHRoZSBX RyBzbyB0aGF0IHRoZSBXRyBjYW4gZGVjaWRlIG9uIGFkb3B0aW5nIGFuZCBwcm9ncmVzc2luZyB0 aGlzIEktRC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9wZWZ1bGx5IHRoZSBhYm92ZSBh bnN3ZXJzIHByb3ZpZGUgc29tZSBmdXJ0aGVyIGV4cGxhbmF0aW9uLiZuYnNwOyBJIGFncmVlIHNh eWluZyB0aGF0IDNHUFAgaGFzIGEgcmVxdWlyZW1lbnQgaW4gbm90IGFkZXF1YXRlDQogYnkgaXRz ZWxmLiBXZSBjaXRlZCB0aGF0IGFzIGEgcmVmZXJlbmNlIG9yIGV2aWRlbmNlIHRoYXQgdGhlcmUg aXMgYSByZWFsIHByb2JsZW0gaW4gdGhlIGxhcmdlciBjb21tdW5pdHkgdGhhdCBuZWVkcyBhZGRy ZXNzaW5nLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuLCBJIHBy ZXNlbnRlZCB0aGlzIGRyYWZ0IGluIFZhbmNvdXZlciBsYXN0IHllYXIsIHRoZXJlIHdhcyBhIGZh aXIgYml0IG9mIGludGVyZXN0IG9uIHRoZSBmbG9vci4gSWYgSSByZWNhbGwgY29ycmVjdGx5LA0K IFJhamVldiBhc2tlZCBmb3IgYSBzaG93IG9mIGhhbmRzIGFuZCBhIG51bWJlciBvZiBoYW5kcyB3 ZW50IHVwIGluIHN1cHBvcnQuIEkgYW0gaG9waW5nIHRvIGdldCB0aGUgc2FtZSBmb2xrcyB2b2lj ZSB0aGVpciBzdXBwb3J0IG9uIHRoZSBtYWlsaW5nIGxpc3QNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJhamVzaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCYXNhdmFyYWogUGF0 aWwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YnBhdGlsMUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5icGF0aWwxQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBNYXkgMDcsIDIwMTQgNzowOCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LXBhemh5YW5udXItbmV0ZXh0LWNpdmljLWxvY2F0aW9uLWFuaS1zdWJvcHRAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXBhemh5YW5udXItbmV0ZXh0LWNpdmljLWxv Y2F0aW9uLWFuaS1zdWJvcHRAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBo cmVmPSJtYWlsdG86bmV0ZXh0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0ZXh0QGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBRdWVzdGlvbiBhYm91dCBleHRlbmRpbmcgdGhl IEFOSSBvcHRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGVsbG8gYXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUg cHJvYmxlbSBiZWluZyB0aGF0IHRoaXMgSS1EIGFpbXMgdG8gc29sdmU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLiBXaHkgaXMgdGhl IGV4aXN0aW5nIEFOSSBvcHRpb24gbm90IHN1ZmZpY2llbnQgZm9yIGVuY29kaW5nIFdMQU4gc3Bl Y2lmaWMgaW5mb3JtYXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjIuIElzIHRoZSBwcmltYXJ5IGdvYWwgdG8gcHJvdmlkZSBpbmZvcm1h dGlvbiByZWdhcmRpbmcgbG9jYXRpb24/IEFuZCBhcyBhIG1lYW5zIGZvciBpbmRvb3IgbG9jYXRp b24gdHJhY2tpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgSS1EIGRvZXMgbm90IHJlYWxseSBleHBsYWluIHRoZSBrZXkgcHJv YmxlbSB0byBiZSBzb2x2ZWQgb3RoZXIgdGhhbiBzYXlpbmcgdGhhdCAzR1BQIGhhcyBhIHJlcXVp cmVtZW50IGluIFdMQU4gZGVwbG95bWVudHMuIEl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBl eHBsYWluIHRoZSBtb3RpdmF0aW9uDQogdG8gdGhlIFdHIHNvIHRoYXQgdGhlIFdHIGNhbiBkZWNp ZGUgb24gYWRvcHRpbmcgYW5kIHByb2dyZXNzaW5nIHRoaXMgSS1ELjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LVJhajxiciBjbGVhcj0i YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxi cj4NCkJhc2F2YXJhaiBQYXRpbCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxicj4NCkJhc2F2YXJhaiBQYXRpbCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4ED2E36A22261145861BAB2C24088B4320F7BBB0xmbalnx09ciscoc_-- From nobody Wed May 7 13:49:04 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A441A03ED for ; Wed, 7 May 2014 13:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 IYOoK9PKlsLT for ; Wed, 7 May 2014 13:49:02 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7011A01A0 for ; Wed, 7 May 2014 13:49:02 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i7so1955721oag.6 for ; Wed, 07 May 2014 13:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MT53YMlVTlCmHECSqxd1T857QR+XGAwUTWQvG29fol8=; b=utZUo+JrvyuPgAvaYPoXP8JSDzTDd97gddcoU1/KmDyCs4vqEKINprZztBx+dd4rdF 87v/FG9s/8CXzCi1gBFEJPk6kwaAcV+iU1RJbIW5naeSO1gfZt3nZUJwwk4Uch12+4tp WfpELbanZonf7Rvn6sjMPNa/Tx0+0/cOyHnQhOYz2U3mrfEdqA5gmpDczqepUfzBYGFn WGnv5HASzM5qFVIXUGihLPf3ZpG7FE45g1m0EOHB1wJuW56pfen7J1aOcaOFcNqsfI5I k69BG4wvho2knwLr6rkHJe+hhdiiwfcq78lkcOhq4NrlGlv8q1ZdXgmnsvK9YnwcwYIB rkig== MIME-Version: 1.0 X-Received: by 10.182.97.1 with SMTP id dw1mr48190445obb.23.1399495738310; Wed, 07 May 2014 13:48:58 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 7 May 2014 13:48:58 -0700 (PDT) Date: Wed, 7 May 2014 15:48:58 -0500 Message-ID: From: Basavaraj Patil To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b2e4c525a428904f8d57ee1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/CuUsqKwmZsesREswDBmEfAAy9Z0 Cc: "netext@ietf.org" , "draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org" Subject: [netext] Chairs recommendation on how to proceed with draft-pazhyannur-netext-civic-location-ani-subopt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:49:03 -0000 --047d7b2e4c525a428904f8d57ee1 Content-Type: text/plain; charset=UTF-8 Hi Brian, As we have indicated at the last IETF meeting, the netext WG is now essentially in a wrap-up and shutdown mode. With chair hat on: I have reviewed the I-D and the problem that it aims to solve. I have also discussed it with my co-chair (Rajeev). The recommendation in order of priority is as follows: 1. Do a bis of RFC6757 and include these proposed extensions. The work would be done within the int-area WG. 2. Consider this work to be added to the DMM WG charter. 3. Adopt the I-D as a Netext WG document following consensus call and progress it while the WG itself goes dormant (delaying shutdown). Thx. -Raj -- Basavaraj Patil --047d7b2e4c525a428904f8d57ee1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Brian,

As we have ind= icated at the last IETF meeting, the netext WG is now essentially in a wrap= -up and shutdown mode.=C2=A0

With chair hat on:
I have reviewed the I-D and the problem that it aims to solve. I have also = discussed it with my co-chair (Rajeev). The recommendation in order of prio= rity is as follows:

1. Do a bis of RFC6757 and inc= lude these proposed extensions. The work would be done within the int-area = WG.

2. Consider this work to be added to the DMM WG charter= .

3. Adopt the I-D as a Netext WG document followi= ng consensus call and progress it while the WG itself goes dormant (delayin= g shutdown).

Thx.
-Raj

--
Basavara= j Patil
--047d7b2e4c525a428904f8d57ee1-- From nobody Wed May 7 14:44:10 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1C31A03A6; Wed, 7 May 2014 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 UfVIKg4Voubz; Wed, 7 May 2014 14:44:06 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 06B221A0208; Wed, 7 May 2014 14:44:05 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id m1so2063316oag.0 for ; Wed, 07 May 2014 14:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4wGZ3Zj/QxtmVpdPtXDySzWXwwE/YFJI6tp2M6NXj04=; b=YJ4EEm753dnsrpEeuIptOPbfS8kpyW/SdGGcT7okEM0sFALQXHWowvC0jA8XouijS6 Yi+EghNbt0q2YkHLHytBR0YXrtqpDGUmEtp3BI6xO+E9g4Hs7u+Dmcwxo/ocrFmq8Q1Q HztmvCcBvYoIHKImmbmjnFgAznP03qdhozR55WcGMFZQKNSkUrYFmLYmOZXsyrQxjv0a hlQfLd6gxbuv23yUDiCjycKqFzLvWJ4aweM43/p6QLYO+wx5iEUogtsSTnsgGJlPzhmC b3c4jvJiBpbmCTcqZGKqp3JUcXJOk9EDJfOtdoYy+Fu+8em3K71BMzzw7mkHdUcB0yla ReVg== MIME-Version: 1.0 X-Received: by 10.60.44.135 with SMTP id e7mr12274143oem.63.1399499041748; Wed, 07 May 2014 14:44:01 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 7 May 2014 14:44:01 -0700 (PDT) Date: Wed, 7 May 2014 16:44:01 -0500 Message-ID: From: Basavaraj Patil To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=001a11333b203f3b7c04f8d64324 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/TQd1IR7X9coO1O2rA_jR-ES6c24 Cc: "netext@ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 21:44:08 -0000 --001a11333b203f3b7c04f8d64324 Content-Type: text/plain; charset=UTF-8 Hello, The Netext working group I-D: Separation of Control and User Plane for Proxy Mobile IPv6 has completed working group last call. The authors have addressed all review comments and submitted a revised I-D. It is now ready for IESG review and IETF last call. Please process accordingly. The protol writeup for this I-D is included below. Rgds, -Raj (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a Mobile Access Gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the Local Mobility Anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has sailed through the WG process because the problem that it aims to solve is clear and has strong consensus among the WG members. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No known implementations of the protocol exist at this time. No vendors have expressly stated a plan to implement this specification either. The I-D acknowledges the reviewers who have helped improve the I-D. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the I-D prior to the WG last call and provided input to the authors which has been implemented in the version that is now ready for submission to the IESG. The document is clearly ready for IESG review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Broader reviews of this I-D are not required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No special concerns about this document. It has strong WG consensus. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. Each author has confirmed conformance to the provisions of BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures associated with this I-D have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is strong and the larger WG understand the specification and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No special concern w.r.t ID-nits Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not specify a MIB, media type or URI type. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Publishing this I-D will not have an impact on the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations section is clear and has sufficient information for IANA to complete the actions. The registry to be used is specified in this section as well. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries will be required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No XML code, BNF rules or MIB definitions have been specified in this document. -- Basavaraj Patil --001a11333b203f3b7c04f8d64324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

The Ne= text working group I-D: Separation of Control and User Plane for
= Proxy Mobile IPv6 =C2=A0<draft-ietf-netext-pmip-cp-up-separation-03.txt&= gt; has
completed working group last call. The authors have addressed all
review comments and submitted a revised I-D. It is now ready for IESG=
review and IETF last call. Please process accordingly.=C2=A0

The protol writeup for this I-D is included below.

Rgds,
-Raj


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the<= /div>
title page header? =C2=A0=C2=A0

Proposed= Standard


(2) The IESG approval announcement inclu= des a Document Announcement
Write-Up. Please provide such a Docum= ent Announcement Write-Up. Recent
examples can be found in the &q= uot;Action" announcements for approved
documents. The approval announcement contains the following sections: = =C2=A0

Technical Summary:

=C2=A0 =C2=A0This document specifies a method to split the Control Plane (= CP) and
=C2=A0 =C2=A0User Plane (UP) for a Proxy Mobile IPv6 based network inf= rastructure.
=C2=A0 =C2=A0Existing specifications allow a Mobile = Access Gateway (MAG) to
=C2=A0 =C2=A0separate its control and use= r plane using the Alternate Care of
=C2=A0 =C2=A0address mobility option for IPv6, or Alternate IPv4 Care = of Address
=C2=A0 =C2=A0option for IPv4. =C2=A0However, the curre= nt specification does not provide
=C2=A0 =C2=A0any mechanism allo= wing the Local Mobility Anchor (LMA) to perform an
=C2=A0 =C2=A0analogous functional split. =C2=A0To remedy that shortcom= ing, this
=C2=A0 =C2=A0document specifies a mobility option enabl= ing a LMA to provide an
=C2=A0 =C2=A0alternate LMA address to be = used for the bi-directional user plane
=C2=A0 =C2=A0traffic between the MAG and LMA. =C2=A0With this new opti= on, a LMA will be
=C2=A0 =C2=A0able to use an IP address for its = user plane which is different than
=C2=A0 =C2=A0the IP address us= ed for the control plane.

Working Group Summary:

Was the= re anything in WG process that is worth noting? For example,
was = there controversy about particular points or were there decisions
where the consensus was particularly rough?=C2=A0

=
This document has sailed through the WG process because the problem
that it aims to solve is clear and has strong consensus among the W= G
members.=C2=A0

Document Quality:
Are there existing implementations of the protocol? Have a sig= nificant
number of vendors indicated their plan to implement the = specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a<= /div>
conclusion that the document had no substantive issues? If there = was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the<= /div>
request posted?=C2=A0

No known implement= ations of the protocol exist at this time. No
vendors have expressly stated a plan to implement this specification
either.=C2=A0
The I-D acknowledges the reviewers who hav= e helped improve the I-D.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Direct= or?

Document Shepherd: Basavaraj Patil
<= br>
Responsible AD: Brian Haberman

(3) B= riefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded= to
the IESG.=C2=A0

I have reviewed the = I-D prior to the WG last call and provided input
to the authors which has been implemented in the version that is now
ready for submission to the IESG. The document is clearly ready fo= r
IESG review and publication.

(4) Does = the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?=C2=A0

<= /div>
No.

(5) Do portions of the document need= review from a particular or from
broader perspective, e.g., secu= rity, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.=C2=A0

Broader reviews of this = I-D are not required.


(6) Describe = any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she i= s
uncomfortable with certain parts of the document, or has concer= ns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.=C2=A0
No special concerns about this document. It has strong WG consen= sus.

(7) Has each author confirmed that any and al= l appropriate IPR
disclosures required for full conformance with = the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?=C2=A0


Yes. Each author has confirmed conforma= nce to the provisions of BCP 78
and 79.

= (8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
=
disclosures.=C2=A0

No IPR disclosures associa= ted with this I-D have been filed.


= (9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it= ?=C2=A0

The WG consensus is strong and the larger = WG understand the
specification and agrees with it.

(10) Has an= yone threatened an appeal or otherwise indicated extreme
disconte= nt? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)=C2=A0<= /div>

No.

(11) Identify any ID = nits the Document Shepherd has found in this
Internet-Drafts Checklist). = Boilerplate checks are not enough; this
check needs to be thoroug= h.=C2=A0

No special concern w.r.t ID-nits

=C2=A0 =C2=A0 =C2=A0Summary: 0 errors (**), 0 flaws (~~), 0 warnings (= =3D=3D), 2 comments (--).

(12) Describe how the do= cument meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.=C2= =A0

The document does not specify a MIB, media typ= e or URI type.

(13) Have all references within thi= s document been identified as
either normative or informative?=C2=A0

Yes.= =C2=A0

(14) Are there normative references to docu= ments that are not ready
for advancement or are otherwise in an u= nclear state? If such
normative references exist, what is the plan for their completion?=C2= =A0

No. All normative references are published RFC= s.

(15) Are there downward normative references re= ferences (see RFC
3967)? If so, list these downward references to support the Area
=
Director in the Last Call procedure.=C2=A0

No= .

(16) Will publication of this document change th= e status of any
existing RFCs? Are those RFCs listed on the title page header, listed<= /div>
in the abstract, and discussed in the introduction? If the RFCs a= re
not listed in the Abstract and Introduction, explain why, and = point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.=C2=A0

Publishing this I-D will not have an impact on the status of= any
existing RFCs.

(17) Describe the Do= cument Shepherd's review of the IANA
considerations section, = especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations= in
IANA registries. Confirm that any referenced IANA registries = have been
clearly identified. Confirm that newly created IANA registries include=
a detailed specification of the initial contents for the registr= y,
that allocations procedures for future registrations are defin= ed, and
a reasonable name for the new registry has been suggested (see RFC
5226).=C2=A0

The IANA considerations sectio= n is clear and has sufficient
information for IANA to complete th= e actions. The registry to be used
is specified in this section as well.

(18) Li= st any new IANA registries that require Expert Review for
future = allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.=C2=A0

No new IANA registries will be required.
=
(19) Describe reviews and automated checks performed by the = Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.=C2=A0

No XML code, BNF rules or MIB definitions have been = specified in this document.


--
Basavaraj Patil
--001a11333b203f3b7c04f8d64324-- From nobody Thu May 8 07:17:39 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06191A03A5 for ; Thu, 8 May 2014 07:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CacDryvEG7S9 for ; Thu, 8 May 2014 07:17:34 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C09651A03F1 for ; Thu, 8 May 2014 07:17:33 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 868D8880CE; Thu, 8 May 2014 07:17:29 -0700 (PDT) Received: from 1025238232.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7DC291368071; Thu, 8 May 2014 07:17:28 -0700 (PDT) Message-ID: <536B91F2.3080607@innovationslab.net> Date: Thu, 08 May 2014 10:17:22 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Koodli, Rajeev" , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" , Basavaraj Patil References: <536A5721.8000100@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V9f1rnQEJbel3TowwVWBVwVRsC4pnq4Pn" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/8P0QyBxsM0MRZiG03NP1FdBDqXY Subject: Re: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 14:17:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V9f1rnQEJbel3TowwVWBVwVRsC4pnq4Pn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rajeev, Snipping down to just the open questions/issues... On 5/7/14 7:53 PM, Koodli, Rajeev wrote: >=20 > On 5/7/14, 8:54 AM, "Brian Haberman" wrote: >=20 >> >> 2. The document states that these new EAP attributes can be used in Wi= Fi >> networks. Later, it talks about networks that employ 802.1X. Please = be >> more specific as to what is covered under the generic WiFi in the >> context of this specification. >=20 >=20 > Reference to 802.1X is illustrative as in WiFi networks. The new EAP > attributes are applicable for trusted non-3GPP networks in general, but= to > WiFi in particular. >=20 I think that it would be good to clarify that in the Introduction. >> >> 8. Several of the attributes include strings in the data. What is the= >> encoding for these strings? >=20 > The encoding would follow 3GPP TS 23.003 as do the attributes in RFC 41= 87. > Will mention this. >=20 I see a single reference to ASCII encoding for the username string in 4187. Is ASCII encoding assumed here as well? >> >> 10. Are the sub-types and types in 5.2, 5.3, 5.5, & 5.6 set in stone? >> Could new ones be defined in the future? If so, you will want to >> consider if they should be IANA registries. Otherwise, future RFCs wi= ll >> need to update this spec to extend the type/sub-type values supported.= >=20 >=20 > This is a good point. AFAIK, there is no existing registry for these ki= nds > of sub-types and types. > Wondering pros and cons of creating a new registry..Thoughts? >=20 It depends on how much the authors/WG think this spec will be extended. If you don't envision much change to these (sub-)types, the registry isn't useful. If there is potential to see new values (e.g., new connectivity types for AT_CONNECTIVITY_TYPE), a registry minimizes the need to have future RFCs update this one. I would suggest an analysis of potential new (sub-)type values coming along in the future. >=20 >> >> 11. I am confused by the relationship between the attributes defined i= n >> sections 5.4 and 5.5. Would the AT_HANDOVER_SESSION_ID attribute ever= >> be used without the AT_HANDOVER_INDICATION? If not, why have the >> session id in a separate attribute? It seems straightforward to inclu= de >> the session id info in the AT_HANDOVER_INDICATION attribute if Type=3D= 1. >> Am I missing something? >=20 > AT_HANDOVER_SESSION_ID also includes the Access Technology in addition = to > the Session Id. >=20 >=20 > We can do this by embedding Access Technology into the existing Pad fie= ld > for Type =3D 1.=20 > (So, Pad if Type =3D 0, Access Technology if Type =3D 1). If this seems= okay, > I don=B9t mind combining the two. >=20 Combining them makes sense if AT_HANDOVER_SESSION_ID is never sent without the corresponding AT_HANDOVER_INDICATION. >> >> 14. The Security Considerations section tells me nothing. Are there n= ew >> threats with these new pieces of information flowing across the networ= k? >> What are the privacy implications of these messages? Can any of the >> possible threat vectors be minimized? >=20 > We are basically following RFC 4187 here. The relevant part is 12.7 whi= ch > refers to new attribute types: >=20 >=20 > "As described in Section 8, EAP-AKA allows the protocol to be extended > by defining new attribute types. When defining such attributes, it > should be noted that any extra attributes included in > EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are no= t > included in the MACs later on, and thus some other precautions must > be taken to avoid modifications to them.=B2 >=20 >=20 > We do not have attributes that fit this requirement ( I=B9ll double che= ck > again). > In any case, we can refer to this text. The security considerations in 4187 are quite detailed in some instances. I think it would be good to document any potential security/privacy issues that could arise if these new attributes are abused in some way. Regards, Brian --V9f1rnQEJbel3TowwVWBVwVRsC4pnq4Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTa5H4AAoJEBOZRqCi7goqpWwH/20oLjmCFkR7sXNDR9+lGqON azKVoqXAzPR3VgdsB4SHyTuECcD68lUxdxVodIdfRzO/iPxVssvXF1Es/GCVqbXU JNEHcYvoGkImutmMVsVrFwwsmLj69vYUVBfz3houtRgqAJ/xbmM6klf7p3H/AIU+ /sMuvQciMGK7FUE06U+i13nv+W5qtxgtyPL2Wt5ztFVOK2ieJrx65Ew/ChG53143 NDNnS321T14Viv0OJ0zd1UiSDDNlIPNlXxVa68trd307yr5ywI3ogO4XLZlAhlDs MqINP0HvpxdWVntF5Qg52o0ruJLYawIVVTQ0V/2W+Lzcn+TnbZ9zdXcN75FvPhs= =SOD1 -----END PGP SIGNATURE----- --V9f1rnQEJbel3TowwVWBVwVRsC4pnq4Pn-- From nobody Thu May 8 07:33:31 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D481A000A for ; Thu, 8 May 2014 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 ILd9D9jePqt2 for ; Thu, 8 May 2014 07:33:29 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E59341A0002 for ; Thu, 8 May 2014 07:33:28 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so3163739oag.40 for ; Thu, 08 May 2014 07:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dj2XTPdHPozPmOtDsU/t4X+3O89bfiysIX+z6z5YPZk=; b=WImUDt7AUwz5S+s/X+X/rD+kub3an8sKjvdDrt0XiBMhoRamUe+MfG6/LQxLbx+cIO o1Bl46vVuvezshFGT5ZXcIsPPuZ2drHEb2CeEYTxz/8U0WWkrF7mrpn/clfnb09GVX2W EvcfZ6y53NuCdehQD46CzJgXksSs9TsSlTDGPesUKdEvzpYIWELx3t6Xh+AckG832aXi Xck4NFoHir26V1K/Xi7aUe+rQlV0pD6oyB+KRSlKX9MaUqJKbrUoHZ3nWZHZo9GSNUn4 jZvhL/zBeWFr4EimbQGvMjI1zTdZPXJrUwStdLQAbh6UN0cR810Zdon+s5sxVpGqduLp 30bQ== MIME-Version: 1.0 X-Received: by 10.60.63.12 with SMTP id c12mr5075703oes.23.1399559604319; Thu, 08 May 2014 07:33:24 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Thu, 8 May 2014 07:33:24 -0700 (PDT) Date: Thu, 8 May 2014 09:33:24 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a11c20ce60ebb8504f8e45df2 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/S_biM40L1Fzkml0iN80yt-1g4wc Subject: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 14:33:30 -0000 --001a11c20ce60ebb8504f8e45df2 Content-Type: text/plain; charset=UTF-8 Hello, At the London IETF (89) there was consensus in the room to adopt the I-D: Extensions to the PMIPv6 Access Network Identifier Option as a Netext WG document. This document is a standards track I-D. This is a consensus call to adopt it. Please voice your opinion by May 22nd via the mailing list. Question to WG: Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a Netext WG document? Yes [ ] No [ ] -Chairs -- Basavaraj Patil --001a11c20ce60ebb8504f8e45df2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

At the London IET= F (89) there was consensus in the room to adopt the I-D:
Extension=
s to the PMIPv6 Access Network Identifier Option
<draft-pazhyannur-netext-civic-location-ani-subopt-02.txt> as a Netex=
t WG document. This document is a standards track I-D.
This is a consen=
sus call to adopt it. Please voice your opinion by May 22nd via the mailing=
 list.
Q=
uestion to WG:
Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a=
 Netext WG document?
<=
span style=3D"font-family:arial">
Yes [ ]
<=
span style=3D"font-family:arial">No [ ]
-Chairs

--
Basavaraj Patil
--001a11c20ce60ebb8504f8e45df2-- From nobody Thu May 8 09:28:57 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808781A0095 for ; Thu, 8 May 2014 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ut6QIgz9NAk for ; Thu, 8 May 2014 09:28:54 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3A1A0074 for ; Thu, 8 May 2014 09:28:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so3408462wib.7 for ; Thu, 08 May 2014 09:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rJf3keZQTCfm/ae3xgnmdhbd85vmTXxSsYdOgTdmBso=; b=IWV8Ydn3BGRNXENM+8SqjomzKKuKpTeCw5Df7R+6dh5qVwHcRpxGUOaiIsHL20AX4+ Yxz/jyCvVviufaJUhc+fbHDidwyixdYUu8q2syUEq0Kfp46NF0gsLBsNUkWKBIy9i/ez 8eCbN52F8+B4Trb+lvJN9Ny32GkvuSbnMrkciKwvvVNZju+NxNZ+9tS3Z5BIOA3jr6m3 Qo+mnG/TzvcdHDzzmfRyifnEK/8WplSuMnH7WvaYDvw6OKofkUBA76sjVkclqigrelqP Gc9gSNWSJp7d7j94aRoFO+MsFWcd+LhE9rMahi9ykBRwWAQcwKhpdavtqWa48pD8oBnQ B29A== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr13760843wib.32.1399566529254; Thu, 08 May 2014 09:28:49 -0700 (PDT) Received: by 10.194.178.162 with HTTP; Thu, 8 May 2014 09:28:49 -0700 (PDT) In-Reply-To: <536B91F2.3080607@innovationslab.net> References: <536A5721.8000100@innovationslab.net> <536B91F2.3080607@innovationslab.net> Date: Thu, 8 May 2014 09:28:49 -0700 Message-ID: From: Rajeev Koodli To: Brian Haberman Content-Type: multipart/alternative; boundary=f46d0442685ad0e87104f8e5f959 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Wxwu4kFkb0huxc5wxTgrJJIsSu4 Cc: "Koodli, Rajeev" , Basavaraj Patil , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:28:56 -0000 --f46d0442685ad0e87104f8e5f959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On Thu, May 8, 2014 at 7:17 AM, Brian Haberman wr= ote: > > The encoding would follow 3GPP TS 23.003 as do the attributes in RFC > 4187. > > Will mention this. > > > > I see a single reference to ASCII encoding for the username string in > 4187. Is ASCII encoding assumed here as well? > > Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does). > >> > >> 10. Are the sub-types and types in 5.2, 5.3, 5.5, & 5.6 set in stone? > >> Could new ones be defined in the future? If so, you will want to > >> consider if they should be IANA registries. Otherwise, future RFCs wi= ll > >> need to update this spec to extend the type/sub-type values supported. > > > > > > This is a good point. AFAIK, there is no existing registry for these > kinds > > of sub-types and types. > > Wondering pros and cons of creating a new registry..Thoughts? > > > > It depends on how much the authors/WG think this spec will be extended. > If you don't envision much change to these (sub-)types, the registry > isn't useful. If there is potential to see new values (e.g., new > connectivity types for AT_CONNECTIVITY_TYPE), a registry minimizes the > need to have future RFCs update this one. I would suggest an analysis > of potential new (sub-)type values coming along in the future. > > ok. > > > >> > >> 11. I am confused by the relationship between the attributes defined i= n > >> sections 5.4 and 5.5. Would the AT_HANDOVER_SESSION_ID attribute ever > >> be used without the AT_HANDOVER_INDICATION? If not, why have the > >> session id in a separate attribute? It seems straightforward to inclu= de > >> the session id info in the AT_HANDOVER_INDICATION attribute if Type=3D= 1. > >> Am I missing something? > > > > AT_HANDOVER_SESSION_ID also includes the Access Technology in addition = to > > the Session Id. > > > > > > We can do this by embedding Access Technology into the existing Pad fie= ld > > for Type =3D 1. > > (So, Pad if Type =3D 0, Access Technology if Type =3D 1). If this seems= okay, > > I don=C2=B9t mind combining the two. > > > > Combining them makes sense if AT_HANDOVER_SESSION_ID is never sent > without the corresponding AT_HANDOVER_INDICATION. > > Yes, I understand. > >> > >> 14. The Security Considerations section tells me nothing. Are there n= ew > >> threats with these new pieces of information flowing across the networ= k? > >> What are the privacy implications of these messages? Can any of the > >> possible threat vectors be minimized? > > > > We are basically following RFC 4187 here. The relevant part is 12.7 whi= ch > > refers to new attribute types: > > > > > > "As described in Section 8, EAP-AKA allows the protocol to be extended > > by defining new attribute types. When defining such attributes, it > > should be noted that any extra attributes included in > > EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are no= t > > included in the MACs later on, and thus some other precautions must > > be taken to avoid modifications to them.=C2=B2 > > > > > > We do not have attributes that fit this requirement ( I=C2=B9ll double = check > > again). > > In any case, we can refer to this text. > > The security considerations in 4187 are quite detailed in some > instances. I think it would be good to document any potential > security/privacy issues that could arise if these new attributes are > abused in some way. > > 4187 is extensive because the attributes there have to do with the EAP-AKA mechanism itself. The attributes here are not related to the EAP-AKA itself, but extensions carried along with the EAP-AKA messages. Let me think about this further. Regards, -Rajeev > Regards, > Brian > > > --f46d0442685ad0e87104f8e5f959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Brian,


On Thu, May 8, 2014 at 7:17 AM, Brian Habe= rman <brian@innovationslab.net> wrote:
> The encoding would foll= ow 3GPP TS 23.003 as do the attributes in RFC 4187.
> Will mention this.
>

I see a single reference to ASCII encoding for the username string in=
4187. =C2=A0Is ASCII encoding assumed here as well?


Rajeev> Yes, = and I would refer to 3GPP TS 23.003 (as 4187 does).

=C2=A0=C2=A0
>>
>> 10. Are the sub-types and types in 5.2, 5.3, 5.5, & 5.6 set in= stone?
>> Could new ones be defined in the future? =C2=A0If so, you will wan= t to
>> consider if they should be IANA registries. =C2=A0Otherwise, futur= e RFCs will
>> need to update this spec to extend the type/sub-type values suppor= ted.
>
>
> This is a good point. AFAIK, there is no existing registry for these k= inds
> of sub-types and types.
> Wondering pros and cons of creating a new registry..Thoughts?
>

It depends on how much the authors/WG think this spec will be extende= d.
=C2=A0If you don't envision much change to these (sub-)types, the regis= try
isn't useful. =C2=A0If there is potential to see new values (e.g., new<= br> connectivity types for AT_CONNECTIVITY_TYPE), a registry minimizes the
need to have future RFCs update this one. =C2=A0I would suggest an analysis=
of potential new (sub-)type values coming along in the future.


ok.
= =C2=A0
>
>>
>> 11. I am confused by the relationship between the attributes defin= ed in
>> sections 5.4 and 5.5. =C2=A0Would the AT_HANDOVER_SESSION_ID attri= bute ever
>> be used without the AT_HANDOVER_INDICATION? =C2=A0If not, why have= the
>> session id in a separate attribute? =C2=A0It seems straightforward= to include
>> the session id info in the AT_HANDOVER_INDICATION attribute if Typ= e=3D1.
>> Am I missing something?
>
> AT_HANDOVER_SESSION_ID also includes the Access Technology in addition= to
> the Session Id.
>
>
> We can do this by embedding Access Technology into the existing Pad fi= eld
> for Type =3D 1.
> (So, Pad if Type =3D 0, Access Technology if Type =3D 1). If this seem= s okay,
> I don=C2=B9t mind combining the two.
>

Combining them makes sense if AT_HANDOVER_SESSION_ID is never sent without the corresponding AT_HANDOVER_INDICATION.


Yes, I understan= d.=C2=A0

=C2=A0
>>
>> 14. The Security Considerations section tells me nothing. =C2=A0Ar= e there new
>> threats with these new pieces of information flowing across the ne= twork?
>> What are the privacy implications of these messages? =C2=A0Can any= of the
>> possible threat vectors be minimized?
>
> We are basically following RFC 4187 here. The relevant part is 12.7 wh= ich
> refers to new attribute types:
>
>
> "As described in Section 8, EAP-AKA allows the protocol to be ext= ended
> =C2=A0 =C2=A0by defining new attribute types. =C2=A0When defining such= attributes, it
> =C2=A0 =C2=A0should be noted that any extra attributes included in
> =C2=A0 =C2=A0EAP-Request/AKA-Identity or EAP-Response/AKA-Identity pac= kets are not
> included in the MACs later on, and thus some other precautions must > =C2=A0 =C2=A0be taken to avoid modifications to them.=C2=B2
>
>
> We do not have attributes that fit this requirement ( I=C2=B9ll double= check
> again).
> In any case, we can refer to this text.

The security considerations in 4187 are quite detailed in some
instances. =C2=A0I think it would be good to document any potential
security/privacy issues that could arise if these new attributes are
abused in some way.


4187 is extensive because the attribut= es there have to do with the EAP-AKA mechanism itself.

=
The attributes here are not related to the EAP-AKA itself, but extensi= ons carried along with the EAP-AKA messages.=C2=A0

Let me think about this further.

Regards,

-Rajeev


<= /div>
=C2=A0
Regards,
Brian



--f46d0442685ad0e87104f8e5f959-- From nobody Thu May 8 09:33:05 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F1D1A0081 for ; Thu, 8 May 2014 09:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHqlgG6BTu6X for ; Thu, 8 May 2014 09:32:59 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 300BA1A007D for ; Thu, 8 May 2014 09:32:59 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DC749880D1; Thu, 8 May 2014 09:32:54 -0700 (PDT) Received: from 1025238232.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 574991368071; Thu, 8 May 2014 09:32:54 -0700 (PDT) Message-ID: <536BB1A7.80205@innovationslab.net> Date: Thu, 08 May 2014 12:32:39 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Rajeev Koodli References: <536A5721.8000100@innovationslab.net> <536B91F2.3080607@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kxkMkxC7LEq6Q68Fmsnlqh4vFkdwEwcGC" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/zA-M25L1lq1IEEz8PdeqeBMaA-U Cc: "Koodli, Rajeev" , Basavaraj Patil , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kxkMkxC7LEq6Q68Fmsnlqh4vFkdwEwcGC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rajeev, On 5/8/14 12:28 PM, Rajeev Koodli wrote: > Hi Brian, >=20 >=20 > On Thu, May 8, 2014 at 7:17 AM, Brian Haberman wrote: >=20 >>> The encoding would follow 3GPP TS 23.003 as do the attributes in RFC >> 4187. >>> Will mention this. >>> >> >> I see a single reference to ASCII encoding for the username string in >> 4187. Is ASCII encoding assumed here as well? >> >> > Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does). >=20 >=20 That works. >>>> >>>> 14. The Security Considerations section tells me nothing. Are there= new >>>> threats with these new pieces of information flowing across the netw= ork? >>>> What are the privacy implications of these messages? Can any of the= >>>> possible threat vectors be minimized? >>> >>> We are basically following RFC 4187 here. The relevant part is 12.7 w= hich >>> refers to new attribute types: >>> >>> >>> "As described in Section 8, EAP-AKA allows the protocol to be extende= d >>> by defining new attribute types. When defining such attributes, i= t >>> should be noted that any extra attributes included in >>> EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are = not >>> included in the MACs later on, and thus some other precautions must >>> be taken to avoid modifications to them.=B2 >>> >>> >>> We do not have attributes that fit this requirement ( I=B9ll double c= heck >>> again). >>> In any case, we can refer to this text. >> >> The security considerations in 4187 are quite detailed in some >> instances. I think it would be good to document any potential >> security/privacy issues that could arise if these new attributes are >> abused in some way. >> >> > 4187 is extensive because the attributes there have to do with the EAP-= AKA > mechanism itself. >=20 > The attributes here are not related to the EAP-AKA itself, but extensio= ns > carried along with the EAP-AKA messages. >=20 > Let me think about this further. Sure. I want to make sure we head off any late issues when the Sec-Dir review occurs. Regards, Brian --kxkMkxC7LEq6Q68Fmsnlqh4vFkdwEwcGC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTa7G0AAoJEBOZRqCi7goqansH/iqYS9Jn1q6gGIx1fQ25foNY H5z46q2aoE9skzmNSUuH1wjTvmeOIgVczpAQZ8wFr4sBxnXGMt+rYLuNFlhAUity e938LKgE6JnhnuInI2Kks1GHj4Fcst76XJxgCWWjGVOLpED8hxNogyT/zJR7sWAW P8y+RmjjsAnQondcrjzK4ZGr1twDm5bwnUPZxDkbhupI5CZCCIr6SllDQh5qphEP X3mO1EIH7WU4dQZgdSxeWT6wn9CN1PIjjSTJx0+mXyMYf8/6eVEi5mURqGmZNvz1 BPvDDmkAUYNXi5ARjglF43gjm5YdSxhr7Rz+Eu459DzKPOKIa3wvlFW/6qRhVME= =BiCu -----END PGP SIGNATURE----- --kxkMkxC7LEq6Q68Fmsnlqh4vFkdwEwcGC-- From nobody Thu May 8 12:11:53 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8221A0118 for ; Thu, 8 May 2014 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhQ_nIwjArYj for ; Thu, 8 May 2014 12:11:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3671A00F4 for ; Thu, 8 May 2014 12:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5152; q=dns/txt; s=iport; t=1399576305; x=1400785905; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=g7GnlWwudaHe61u4OG7DWRntUvAOXENrnTO9J8+wV/M=; b=aFStY3zIucJXbKn3Czip/iP6LX0zOMG+Zir4ZKy2xSPF5PKkuvd7I76G j4k6kwi8rnsm9l5HIaFvp0TqWei8vfvS7uBd8MInrUgtQg+KnoTT7HfNv 8n7+BkE6Gp/FPoQ2RVmGz47WAMfOy8SOj0fSj2xJf4zUP0KPQXD3CsvI3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAFnWa1OtJA2L/2dsb2JhbABZgkJET1iCZ8J6ARl6FnSCJgEBBCMKXAIBCA4UGQcCAgIwJQIEARqIOAGsB6Q5F44hOIJ0NoEVBKwzgXeBP4Iv X-IronPort-AV: E=Sophos;i="4.97,1012,1389744000"; d="scan'208,217";a="323238283" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 08 May 2014 19:11:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s48JBjWU006575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 19:11:45 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 8 May 2014 14:11:44 -0500 From: "Kent Leung (kleung)" To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc Thread-Index: AQHPasp+6stXHlaxR0esFse19uKMEps3DISA Date: Thu, 8 May 2014 19:11:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.231.148] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB4DE6A571xmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/q_xCl5Ecs3V31NXluwzWATNLGH8 Subject: Re: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 19:11:51 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB4DE6A571xmbalnx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KRG8geW91IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIEktRDogZHJhZnQtcGF6aHlhbm51 ci1uZXRleHQtY2l2aWMtbG9jYXRpb24tYW5pLXN1Ym9wdC0wMi50eHQgYXMgYSBOZXRleHQgV0cg ZG9jdW1lbnQ/DQoNCg0KDQpZZXMgW1hdDQoNCk5vIFsgXQ0KDQoNCg== --_000_CD85F32117029D4F9AEF48BDEF5536AB4DE6A571xmbalnx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkRvIHlvdSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBJLUQ6 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ZHJhZnQtcGF6aHlhbm51ci1uZXRleHQtY2l2 aWMtbG9jYXRpb24tYW5pLXN1Ym9wdC0wMi50eHQgYXMgYSBOZXRleHQgV0cgZG9jdW1lbnQ/PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+WWVzIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5ObyBbIF08 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4g PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CD85F32117029D4F9AEF48BDEF5536AB4DE6A571xmbalnx03ciscoc_-- From nobody Fri May 16 14:39:21 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF541A0155; Fri, 16 May 2014 14:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzh__FXRTHO0; Fri, 16 May 2014 14:39:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A68B81A0151; Fri, 16 May 2014 14:39:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CA52318000D; Fri, 16 May 2014 14:38:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140516213805.CA52318000D@rfc-editor.org> Date: Fri, 16 May 2014 14:38:05 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/DLz1AtfPWuDsPAwxPXWMtArmZ-Q Cc: drafts-update-ref@iana.org, netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 7222 on Quality-of-Service Option for Proxy Mobile IPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 21:39:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7222 Title: Quality-of-Service Option for Proxy Mobile IPv6 Author: M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli Status: Standards Track Stream: IETF Date: May 2014 Mailbox: liebsch@neclab.eu, pierrick.seite@orange.com, yokota@kddilabs.jp, jouni.nospam@gmail.com, sgundave@cisco.com Pages: 58 Characters: 139026 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-pmip6-qos-12.txt URL: http://www.rfc-editor.org/rfc/rfc7222.txt This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches. This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 21 06:49:59 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670D1A035E for ; Wed, 21 May 2014 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEPJhO6G11B2 for ; Wed, 21 May 2014 06:49:54 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649C31A067C for ; Wed, 21 May 2014 06:49:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B629B8810B; Wed, 21 May 2014 06:49:53 -0700 (PDT) Received: from 1025237161.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6C74571C0002; Wed, 21 May 2014 06:49:53 -0700 (PDT) Message-ID: <537CAEFA.3070208@innovationslab.net> Date: Wed, 21 May 2014 09:49:46 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, "netext@ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fbIvnQPddVPPIcO3RmwAE4Tuahc1f7FEs" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/U8CY1lh1cqucBpDK9u2cWsyumDE Subject: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:49:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fbIvnQPddVPPIcO3RmwAE4Tuahc1f7FEs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I have completed my AD evaluation of draft-ietf-netext-pmip-cp-up-separation as a part of the publication process. This document is well-written, concise, and nearly ready for IETF Last Call. I only have two comments/issues I would like to see resolved. 1. The document uses several different terms to refer to the plane responsible for the transit of user data. I see "user plane" and "data plane" used within the document. Additionally, the folks in the routing area use the term "forwarding plane". Unless "user plane" is a term-of-art within the mobility space, I would suggest harmonizing the text and using a single term (data or forwarding) to describe the plane. 2. What is the plan for the publication of the CP separation requirements document that is referenced in this document? It seems rather silly to publish the solution spec before the requirements. Should they advance together? Incorporate the requirements into this document? Once we iron these issues out, the publication process can proceed. Regards, Brian --fbIvnQPddVPPIcO3RmwAE4Tuahc1f7FEs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTfK8AAAoJEBOZRqCi7goqCRgIALQpcEhRjo8WvysvPVt6wiyf Uf/s9ZEsUW1fi1iqySRPTcf2+MSEY9xwphdexaKqtytv7elNIx8iNH+PSmW+ysNO nRU2di1P44us25YCmV8aewRDEFbBcbaBWU50F8+sDCMkMAyggir5drtM74zFjvr7 mlxDJoS6IktgCfVIq7NpcQvRPW2S4EYHzPXLHJJpg2Wvir5IpPp2fTcuKqeL28hH e9xjpayVezktmg4FBdbSR8oskCDzgvgPVold4cTU6n49cnTMipOHWH7nWVUMDGxo +O+vyrYNYkbbmgIa/7QD+XS2NJg9UtYRw5Rfvph/8yNUSrh5ReKBH1A/FRMpQ4c= =LEfU -----END PGP SIGNATURE----- --fbIvnQPddVPPIcO3RmwAE4Tuahc1f7FEs-- From nobody Wed May 21 10:47:54 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2C1A085B for ; Wed, 21 May 2014 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHcd2_fITMZN for ; Wed, 21 May 2014 10:47:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092F51A0116 for ; Wed, 21 May 2014 10:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1400694471; x=1401904071; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=VUZG+AMTy/xJ0pAtsYcHSylTQC7HxuMvQp+qLG8TujY=; b=gY7n96DAZ1EM6AvJyfIu5EF3iLFahrcLvy3A/acgneXreTn9Haobx9no 5ba+gtThxSTZroFgJ4+6VsIu8wQFfwHQV15qYy5VP3PtNPjC/3OOeSfkW 7IYqHQIzMLiadBpSnLc1fzL88Ozr0K++zst9+bTWt7NkcMDw9IRkEhR20 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHACDmfFOtJA2H/2dsb2JhbABZgwmBKqlfAQEBAQEBBQGaMAGBDBZ0giw6UQEINkIlAgQBEhuIJtZHF4VViQCEQASZbpMkgziCMA X-IronPort-AV: E=Sophos;i="4.98,881,1392163200"; d="scan'208";a="326759810" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 21 May 2014 17:47:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4LHloG4024669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 17:47:50 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.80]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 21 May 2014 12:47:50 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPdRzILA7SF2BF+UurAM4jdDo2Rg== Date: Wed, 21 May 2014 17:47:49 +0000 Message-ID: In-Reply-To: <537CAEFA.3070208@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <6F0BCE545241934BB8428E05C9262F3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/CdxD1pWBTk23VcsU8MkHUsC5Z2U Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:47:53 -0000 Hi Brian, Thanks for your review comments. Please see inline. On 5/21/14 6:49 AM, "Brian Haberman" wrote: >All, > I have completed my AD evaluation of >draft-ietf-netext-pmip-cp-up-separation as a part of the publication >process. This document is well-written, concise, and nearly ready for >IETF Last Call. I only have two comments/issues I would like to see >resolved. > >1. The document uses several different terms to refer to the plane >responsible for the transit of user data. I see "user plane" and "data >plane" used within the document. Additionally, the folks in the routing >area use the term "forwarding plane". Unless "user plane" is a >term-of-art within the mobility space, I would suggest harmonizing the >text and using a single term (data or forwarding) to describe the plane. Agree. We will update the draft to reflect consistent terminology use. > >2. What is the plan for the publication of the CP separation >requirements document that is referenced in this document? It seems >rather silly to publish the solution spec before the requirements. >Should they advance together? Incorporate the requirements into this >document? We have the following text that talks about the assumptions around this interface. The draft is primarily driving this definition for the deployment-scenario where the CP and DP functions exist on the same IP node. Figure-1 reflects this. However, the draft does not disallow the separation of CP and DP functions across different IP nodes. That's surely the goal here. But, there is no desire to mandate one specific interface between CP and DP entities. That interface may emerge as a generic interface and this draft (PMIP-split-CP-DP) being one of the applications leveraging that interface. The interface can be based on OpenFlow, FORCES, some vendor specific interface, or the referenced draft based on extensions to routing control plane. There is no dependency on one specific interface for realizing the CP/DP split per this spec. Most likely vendors may not agree on a single interface between a controller and a data plane node and so we tried to stay neutral on that aspect. --- Section 1: Note that the interface between the control and user plane is out of scope in this document. It is required to setup a data path on the user plane according to the control signaling on the control plane. Several IETF working groups are addressing this interface as described in [RFC5415], [RFC5812], [RFC5810], [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software Defined Networking (SDN) [RFC7149] may also be applied. -- Regards Sri > >Once we iron these issues out, the publication process can proceed. > >Regards, >Brian > From nobody Wed May 21 21:14:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C424B1A00B0 for ; Wed, 21 May 2014 21:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] autolearn=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 WmpRU9evWxyl for ; Wed, 21 May 2014 21:13:56 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBB61A00B5 for ; Wed, 21 May 2014 21:13:56 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy4so354695vcb.26 for ; Wed, 21 May 2014 21:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ofdVumjGFmATW0C3pc9BHdsc/6q25Tg6P6pI0r3CpuM=; b=JlXOojNgaB3rYDX/pmOW+/1Q7Hc0nI4Inqy2MO1HaULBj7e68ZAWe1VhL0KeDGwH5K ak9Q68+20LmG7kdxEtAkavIf7RYYWlvFVaKZMPpLcpXrHv2mVABEH+GqrTaGeXuyjXA7 8zlI4ijhCFTcTswpdlT723qqVZRdvtsFGlWLrPXls2k/j774wMLyGMykYPffwqUbVJJc qLNdH8vJLsDE0L4UgGKhUiU7jIV0HbANYgoME6eCL+hK5y48K2sRbpLIOZ/WqCGubM5M wno3A/5CMIWmDgz5hEWWb3bKQkXxZjgar/uPlKcHa3haC/S0XY8kEaOUoqEo4rAiq1VY 9G2w== MIME-Version: 1.0 X-Received: by 10.52.74.196 with SMTP id w4mr6155154vdv.19.1400732034984; Wed, 21 May 2014 21:13:54 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Wed, 21 May 2014 21:13:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 12:13:54 +0800 Message-ID: From: Hui Deng To: "Kent Leung (kleung)" Content-Type: multipart/alternative; boundary=20cf3071ce585ef29204f9f55777 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/HH3X2Fg3X_CEz7hk2PsB4uq_o9Q Cc: "netext@ietf.org" , Basavaraj Patil Subject: Re: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 04:13:58 -0000 --20cf3071ce585ef29204f9f55777 Content-Type: text/plain; charset=UTF-8 Yes [X] No [ ] -Hui 2014-05-09 3:11 GMT+08:00 Kent Leung (kleung) : > > > > > Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a Netext WG document? > > > > Yes [X] > > No [ ] > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --20cf3071ce585ef29204f9f55777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Yes [X]
No [ ]

<= pre style=3D"white-space:pre-wrap;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:'Courier New';word-wrap:break-word">-Hui


2014-05= -09 3:11 GMT+08:00 Kent Leung (kleung) <kleung@cisco.com>:

=C2=A0

=C2=A0

Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a Netext=
 WG document?
=C2=A0
Yes [=
X]=

No [ ]

_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext


--20cf3071ce585ef29204f9f55777-- From nobody Thu May 22 02:41:54 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC701A007E for ; Thu, 22 May 2014 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UywFQFzXkiz2 for ; Thu, 22 May 2014 02:41:52 -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 B6D3F1A004E for ; Thu, 22 May 2014 02:41:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHB55568; Thu, 22 May 2014 09:41:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 May 2014 10:41:36 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 May 2014 10:41:47 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 22 May 2014 17:41:44 +0800 From: Xueli To: "Kent Leung (kleung)" , Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc Thread-Index: AQHPasp/PtDY4o7qZ024hkVs5dZV/Js2hwEAgBXnQlA= Date: Thu, 22 May 2014 09:41:44 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FAA660@nkgeml504-mbx.china.huawei.com> References: 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.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FAA660nkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/EIVCXHiReWTirMszWcmxT7WCBMs Subject: Re: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 09:41:53 -0000 --_000_01FE63842C181246BBE4CF183BD159B448FAA660nkgeml504mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIFtYXQ0KDQpObyBbIF0NCg0KDQpSZWdhcmRzDQpMaQ0KDQpGcm9tOiBuZXRleHQgW21haWx0 bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbnQgTGV1bmcgKGtsZXVu ZykNClNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDM6MTIgQU0NClRvOiBCYXNhdmFyYWogUGF0 aWw7IG5ldGV4dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxs IHRvIGFkb3B0IEktRDogZHJhZnQtcGF6aHlhbm51ci1uZXRleHQtY2l2aWMtbG9jYXRpb24tYW5p LXN1Ym9wdC0wMi50eHQgYXMgV0cgZG9jDQoNCg0KDQoNCkRvIHlvdSBzdXBwb3J0IHRoZSBhZG9w dGlvbiBvZiBJLUQ6IGRyYWZ0LXBhemh5YW5udXItbmV0ZXh0LWNpdmljLWxvY2F0aW9uLWFuaS1z dWJvcHQtMDIudHh0IGFzIGEgTmV0ZXh0IFdHIGRvY3VtZW50Pw0KDQoNCg0KWWVzIFtYXQ0KDQpO byBbIF0NCg0KDQo= --_000_01FE63842C181246BBE4CF183BD159B448FAA660nkgeml504mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1h dHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Izk5MzM2Njt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5ZZXMgWzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPl08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5ObyBb IF08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiPiA8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJl Z2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TGk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gbmV0ZXh0IFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgTGV1bmcgKGtsZXVuZyk8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBNYXkgMDksIDIwMTQgMzoxMiBBTTxicj4NCjxiPlRvOjwvYj4gQmFzYXZhcmFq IFBhdGlsOyBuZXRleHRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRleHRd IENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDogZHJhZnQtcGF6aHlhbm51ci1uZXRleHQtY2l2 aWMtbG9jYXRpb24tYW5pLXN1Ym9wdC0wMi50eHQgYXMgV0cgZG9jPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPkRvIHlvdSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBJLUQ6 IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmRyYWZ0LXBhemh5YW5u dXItbmV0ZXh0LWNpdmljLWxvY2F0aW9uLWFuaS1zdWJvcHQtMDIudHh0IGFzIGEgTmV0ZXh0IFdH IGRvY3VtZW50Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlllcyBbPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5YPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13 cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5vIFsgXTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFw Ij48c3BhbiBsYW5nPSJFTi1VUyI+IDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_01FE63842C181246BBE4CF183BD159B448FAA660nkgeml504mbxchi_-- From nobody Thu May 22 04:57:12 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B91A01BC for ; Thu, 22 May 2014 04:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MocSGuV0QUv7 for ; Thu, 22 May 2014 04:57:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E591A0039 for ; Thu, 22 May 2014 04:57:09 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4F2CA8813E; Thu, 22 May 2014 04:57:08 -0700 (PDT) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C3E6A71C0002; Thu, 22 May 2014 04:57:07 -0700 (PDT) Message-ID: <537DE60E.6010106@innovationslab.net> Date: Thu, 22 May 2014 07:57:02 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P2jM6OVCbqDjcIP08nt4s8GlpIwrRn4I7" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/nkJGaNxrp4K3340nXDke8MnNE8k Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 11:57:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P2jM6OVCbqDjcIP08nt4s8GlpIwrRn4I7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sri, On 5/21/14 1:47 PM, Sri Gundavelli (sgundave) wrote: > Hi Brian, >=20 > Thanks for your review comments. Please see inline. >=20 >=20 > On 5/21/14 6:49 AM, "Brian Haberman" wrote: >=20 >> All, >> I have completed my AD evaluation of >> draft-ietf-netext-pmip-cp-up-separation as a part of the publication >> process. This document is well-written, concise, and nearly ready for= >> IETF Last Call. I only have two comments/issues I would like to see >> resolved. >> >> 1. The document uses several different terms to refer to the plane >> responsible for the transit of user data. I see "user plane" and "dat= a >> plane" used within the document. Additionally, the folks in the routi= ng >> area use the term "forwarding plane". Unless "user plane" is a >> term-of-art within the mobility space, I would suggest harmonizing the= >> text and using a single term (data or forwarding) to describe the plan= e. >=20 >=20 > Agree. We will update the draft to reflect consistent terminology use. >=20 Cool. >=20 >> >> 2. What is the plan for the publication of the CP separation >> requirements document that is referenced in this document? It seems >> rather silly to publish the solution spec before the requirements. >> Should they advance together? Incorporate the requirements into this >> document? >=20 >=20 >=20 > We have the following text that talks about the assumptions around this= > interface. The draft is primarily driving this definition for the > deployment-scenario where the CP and DP functions exist on the same IP > node. Figure-1 reflects this. However, the draft does not disallow the > separation of CP and DP functions across different IP nodes. That's sur= ely > the goal here. But, there is no desire to mandate one specific interfac= e > between CP and DP entities. That interface may emerge as a generic > interface and this draft (PMIP-split-CP-DP) being one of the applicatio= ns > leveraging that interface. The interface can be based on OpenFlow, FORC= ES, > some vendor specific interface, or the referenced draft based on > extensions to routing control plane. There is no dependency on one > specific interface for realizing the CP/DP split per this spec. Most > likely vendors may not agree on a single interface between a controller= > and a data plane node and so we tried to stay neutral on that aspect. >=20 >=20 >=20 > --- > Section 1: >=20 > Note that the interface between the control and user plane is out of= > scope in this document. It is required to setup a data path on the > user plane according to the control signaling on the control plane. > Several IETF working groups are addressing this interface as > described in [RFC5415], [RFC5812], [RFC5810], > [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software > Defined Networking (SDN) [RFC7149] may also be applied. >=20 The above makes sense and would be a good addition to the draft, but I am still a little concerned with the text surrounding the reference to draft-wakikawa-req-mobile-cp-separation. I think that it is the wording:= This separation brings more flexible deployment and management of LMA and MAG(s) of Proxy Mobile IP as described in [I-D.wakikawa-req-mobile-cp-separation]. To meet this requirement... Should I parse this as the reference to the draft is only to relate the use cases rather than the actual requirements? If so, I could change "To meet this requirement" to "To facilitate this approach" or something similar. Or am I missing something? Regards, Brian --P2jM6OVCbqDjcIP08nt4s8GlpIwrRn4I7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTfeYWAAoJEBOZRqCi7goqITAIALjMMfim99ZbLxc3yJNgV0pN LEsdaKiYOsOoSzMiluDbLkgKD6wf9Zan8UVfbsEl6wgCVtuw4RJUbO1gj7xihiXs haPTOURHwAbu/1g0Tm5AWgHkpENvSGXw92I/hksRC2yLWVWhrc++sA4kvaYeO8+f 2tBIoo1Z0oHQ3VLq9nQBgqtvFDBTISBAjGH+U1sV1FGd+WPdpXVjaRKStIABKa1j 28jFuDOGMJEjOfNfr1prZTLsBrC56jBA4vRM6zCkkeHMRHywXH2UyPO3fUyxdZuS 1FX6T8zIeNvQGdOI7xSyy7WBXWyZ7GLiRGJDXpjKQIFo0S1g8I20H0cVoIGp78k= =VB8R -----END PGP SIGNATURE----- --P2jM6OVCbqDjcIP08nt4s8GlpIwrRn4I7-- From nobody Thu May 22 10:51:52 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C71A024B for ; Thu, 22 May 2014 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46PCpekC9cHo for ; Thu, 22 May 2014 10:51:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D66A1A0248 for ; Thu, 22 May 2014 10:51:45 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4MHpgwc013511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 May 2014 12:51:42 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4MHpget023110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 13:51:42 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 22 May 2014 13:51:42 -0400 From: "Muley, Praveen V (Praveen)" To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc Thread-Index: AQHPasqKGcyaeXFHtUmMnUM3NE4rnJs3UCwAgBWnFhA= Date: Thu, 22 May 2014 17:51:41 +0000 Message-ID: <22069265D1B36949926E9422EBF3B88173A9FCA1@US70TWXCHMBA10.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_22069265D1B36949926E9422EBF3B88173A9FCA1US70TWXCHMBA10z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/T6C3bnbPEtwF8E8sAYc_3DoGv2Y Subject: Re: [netext] Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:51:47 -0000 --_000_22069265D1B36949926E9422EBF3B88173A9FCA1US70TWXCHMBA10z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG8geW91IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIEktRDogZHJhZnQtcGF6aHlhbm51ci1uZXRl eHQtY2l2aWMtbG9jYXRpb24tYW5pLXN1Ym9wdC0wMi50eHQgYXMgYSBOZXRleHQgV0cgZG9jdW1l bnQ/DQoNCg0KDQpZZXMgW1hdDQoNCk5vIFsgXQ0KDQoNCg== --_000_22069265D1B36949926E9422EBF3B88173A9FCA1US70TWXCHMBA10z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRvIHlv dSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBJLUQ6IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+ZHJhZnQtcGF6aHlhbm51ci1uZXRleHQtY2l2aWMtbG9jYXRpb24tYW5pLXN1Ym9wdC0wMi50 eHQgYXMgYSBOZXRleHQgV0cgZG9jdW1lbnQ/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WWVzIFs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ XTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5ObyBbIF08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4gPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_22069265D1B36949926E9422EBF3B88173A9FCA1US70TWXCHMBA10z_-- From nobody Fri May 23 04:44:09 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABDF1A0171 for ; Fri, 23 May 2014 04:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Ce4o0ghuvay3 for ; Fri, 23 May 2014 04:44:06 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E571A0166 for ; Fri, 23 May 2014 04:44:06 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id ma3so4058963pbc.37 for ; Fri, 23 May 2014 04:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=65XDTCbR2sO4VwQUiZpdu2j1XIzIp60jJn9Ccblp35w=; b=Z81TTBzygT1AYyxwAvTQRJx7nHw2IONDR3afgSwmQq89XdjYgBYc/MfwXtqY+w3RMK lqcEktUnawua0zpyvjaR7sKWjFift1/NAbHqs9KtrzljfaGDRwwB32f/FJCqOKcVSf6w a9+qfubR/xFLRtUBJa7HqncXFr7H4yvGZz+MF4OWwNwN/dodSb8x9+Fpp6wgUkfYzWD+ ajzwETPd0N95fxl9MsW0Ct9jzpcGYhBy4S8YhQJyPij2C20tQZeMzTyD3QnAL2il19zh mR2I5veB/ICL/dKzwwsy9YRip0eXg/GAsoMRHovI+Sxk1vbgLRM975yJosYnnMw8BCYv pn0g== X-Received: by 10.68.245.162 with SMTP id xp2mr5148939pbc.69.1400845444943; Fri, 23 May 2014 04:44:04 -0700 (PDT) Received: from [192.168.1.102] ([111.206.27.178]) by mx.google.com with ESMTPSA id bw2sm13130046pad.46.2014.05.23.04.44.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 May 2014 04:44:04 -0700 (PDT) Date: Fri, 23 May 2014 19:47:15 +0800 From: Dapeng Liu To: Basavaraj Patil Message-ID: <52BD4A621CA54379A0D2A89DC9BDC15E@gmail.com> In-Reply-To: References: X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="537f3543_19495cff_556" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/B3p0pKNfC0SZCY2c1I3uvXVMXOU Cc: "=?utf-8?Q?netext=40ietf.org?=" Subject: [netext] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 11:44:07 -0000 --537f3543_19495cff_556 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Yes =5B X=5D > No =5B =5D > =20 -- =20 Dapeng Liu =E5=9C=A8 2014=E5=B9=B45=E6=9C=888=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF= =BC=8C22:33=EF=BC=8CBasavaraj Patil =E5=86=99=E9=81=93=EF=BC=9A > =20 > Hello, > =20 > At the London IET=46 (89) there was consensus in the room to adopt the = I-D: > Extensions to the PMIPv6 Access Network Identifier Option as a Netext WG document. Th= is document is a standards track I-D. > This is a consensus call to adopt it. Please voice your opinion by May = 22nd via the mailing list. > Question to WG: > Do you support the adoption of I-D: draft-pazhyannur-netext-civic-locat= ion-ani-subopt-02.txt as a Netext WG document=3F > =20 > Yes =5B =5D =20 > No =5B =5D > -Chairs > =20 > -- =20 > Basavaraj Patil =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > netext mailing list > netext=40ietf.org (mailto:netext=40ietf.org) > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 --537f3543_19495cff_556 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
<= pre style=3D=22word-wrap: break-word;=22>Yes =5B X=5D
No =5B =5D

-- 
Dapeng Liu

=20

=E5=9C=A8 2014=E5=B9=B4= 5=E6=9C=888=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C22:33=EF=BC=8CBa= savaraj Patil =E5=86=99=E9=81=93=EF=BC=9A


H= ello,

At the London IET=46 (89) there was consensus in= the room to adopt the I-D:
Extensions to the PMIPv6 Acces=
s Network Identifier Option
<draft-pazhyannur-netext-civic-location-ani-subopt-02.txt> as a Net=
ext WG document. This document is a standards track I-D.
This is =
a consensus call to adopt it. Please voice your opinion by May 22nd via t=
he mailing list.
Question to WG:
Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-an=
i-subopt-02.txt as a Netext WG document=3F

Yes =5B =5D
No =5B =5D
-C=
hairs

--
Basavaraj Patil
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
netext mailing list
 =20 =20 =20 =20

--537f3543_19495cff_556-- From nobody Tue May 27 10:05:35 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06E71A04B8 for ; Tue, 27 May 2014 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz90xF8B2g7T for ; Tue, 27 May 2014 10:05:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350EE1A0408 for ; Tue, 27 May 2014 10:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4249; q=dns/txt; s=iport; t=1401210328; x=1402419928; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=R1L+9TtT2UUmZXSkxTKu2T9lUDT/S/FLfmyB0Rj3ocA=; b=NRl0pDloyOf2EygJ67IbRRwxs/zlf9MMH+AyWOn85KpALjjsmOnDGELW rT3ovYQaFlyAjzfAxU8YoTMAmwdfq++HsYTjlfucN+OHaMUNxv6z3uhAR khg4ImIqyZ7Udu69jxi/SKVojvybMikDcvx7/7NwAvxMv6SOwtHx4EPVB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8HAJTEhFOtJV2Y/2dsb2JhbABZgweBKqoCAQEBAQEBBQGYDAGBDhZ0giw6UQEINkIlAgQBEhuIJ9UeF4VViQSEQASZc5MngziCLw X-IronPort-AV: E=Sophos;i="4.98,920,1392163200"; d="scan'208";a="47626935" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 27 May 2014 17:05:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4RH5Rhi006198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 17:05:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.80]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 27 May 2014 12:05:27 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPec3awPc3M3v9aE+ynsvSs2RFQQ== Date: Tue, 27 May 2014 17:05:26 +0000 Message-ID: In-Reply-To: <537DE60E.6010106@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/_9HsJlDUy4mBy3veGlmRwg84hJE Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:05:33 -0000 Hi Brian, Sorry for the delay. Please see inline. On 5/22/14 4:57 AM, "Brian Haberman" wrote: >Hi Sri, > >>> >>> 2. What is the plan for the publication of the CP separation >>> requirements document that is referenced in this document? It seems >>> rather silly to publish the solution spec before the requirements. >>> Should they advance together? Incorporate the requirements into this >>> document? >>=20 >>=20 >>=20 >> We have the following text that talks about the assumptions around this >> interface. The draft is primarily driving this definition for the >> deployment-scenario where the CP and DP functions exist on the same IP >> node. Figure-1 reflects this. However, the draft does not disallow the >> separation of CP and DP functions across different IP nodes. That's >>surely >> the goal here. But, there is no desire to mandate one specific interface >> between CP and DP entities. That interface may emerge as a generic >> interface and this draft (PMIP-split-CP-DP) being one of the >>applications >> leveraging that interface. The interface can be based on OpenFlow, >>FORCES, >> some vendor specific interface, or the referenced draft based on >> extensions to routing control plane. There is no dependency on one >> specific interface for realizing the CP/DP split per this spec. Most >> likely vendors may not agree on a single interface between a controller >> and a data plane node and so we tried to stay neutral on that aspect. >>=20 >>=20 >>=20 >> --- >> Section 1: >>=20 >> Note that the interface between the control and user plane is out of >> scope in this document. It is required to setup a data path on the >> user plane according to the control signaling on the control plane. >> Several IETF working groups are addressing this interface as >> described in [RFC5415], [RFC5812], [RFC5810], >> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >> Defined Networking (SDN) [RFC7149] may also be applied. >>=20 > >The above makes sense and would be a good addition to the draft, but I >am still a little concerned with the text surrounding the reference to >draft-wakikawa-req-mobile-cp-separation. I think that it is the wording: > > >This separation brings more flexible deployment and management of LMA >and MAG(s) of Proxy Mobile IP as described in >[I-D.wakikawa-req-mobile-cp-separation]. To meet this requirement... > > >Should I parse this as the reference to the draft is only to relate the >use cases rather than the actual requirements? If so, I could change >"To meet this requirement" to "To facilitate this approach" or something >similar. Reference to I-D.matsushima is intended to be an example. How about the following text: OLD: Note that the interface between the control and user plane is out of scope in this document. It is required to setup a data path on the user plane according to the control signaling on the control plane. Several IETF working groups are addressing this interface as described in [RFC5415], [RFC5812], [RFC5810], [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software Defined Networking (SDN) [RFC7149] may also be applied. NEW: The LMA-CP and the LMA-DP functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to split the LMA-CP and the LMA-DP functions across IP nodes. In such deployment models, there needs to be a protocol interface between the LMA-CP and the LMA-DP functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [Ref-1], FORCES [Ref-2], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc] or vendor specific approaches. This specification does not mandate a approach, or a specific protocol interface and views this interface as a generic interface relevant more broadly for other protocol systems as well (Ex: IPSec, L2TP, Mobile IPv6). Regards Sri > >Or am I missing something? > >Regards, >Brian > From nobody Tue May 27 11:58:41 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDE71A06E0 for ; Tue, 27 May 2014 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MyMhxjRzLGh for ; Tue, 27 May 2014 11:58:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835EE1A06DF for ; Tue, 27 May 2014 11:58:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 687BA88114; Tue, 27 May 2014 11:58:29 -0700 (PDT) Received: from 1025238225.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id BD52771C0002; Tue, 27 May 2014 11:58:28 -0700 (PDT) Message-ID: <5384E049.4000007@innovationslab.net> Date: Tue, 27 May 2014 14:58:17 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8f0hOqWkEF1ekmhDLHars0fNMaglQ5qww" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/SYvnvg2BzSo4DAcUbJcTDJ_Hp30 Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:58:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8f0hOqWkEF1ekmhDLHars0fNMaglQ5qww Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sri, I believe your proposed changes help clarify the text. Go ahead and submit an update with all the changes discussed. Regards, Brian On 5/27/14 1:05 PM, Sri Gundavelli (sgundave) wrote: > Hi Brian, >=20 > Sorry for the delay. Please see inline. >=20 >=20 > On 5/22/14 4:57 AM, "Brian Haberman" wrote: >=20 >> Hi Sri, >> >>>> >>>> 2. What is the plan for the publication of the CP separation >>>> requirements document that is referenced in this document? It seems= >>>> rather silly to publish the solution spec before the requirements. >>>> Should they advance together? Incorporate the requirements into thi= s >>>> document? >>> >>> >>> >>> We have the following text that talks about the assumptions around th= is >>> interface. The draft is primarily driving this definition for the >>> deployment-scenario where the CP and DP functions exist on the same I= P >>> node. Figure-1 reflects this. However, the draft does not disallow th= e >>> separation of CP and DP functions across different IP nodes. That's >>> surely >>> the goal here. But, there is no desire to mandate one specific interf= ace >>> between CP and DP entities. That interface may emerge as a generic >>> interface and this draft (PMIP-split-CP-DP) being one of the >>> applications >>> leveraging that interface. The interface can be based on OpenFlow, >>> FORCES, >>> some vendor specific interface, or the referenced draft based on >>> extensions to routing control plane. There is no dependency on one >>> specific interface for realizing the CP/DP split per this spec. Most >>> likely vendors may not agree on a single interface between a controll= er >>> and a data plane node and so we tried to stay neutral on that aspect.= >>> >>> >>> >>> --- >>> Section 1: >>> >>> Note that the interface between the control and user plane is out = of >>> scope in this document. It is required to setup a data path on th= e >>> user plane according to the control signaling on the control plane= =2E >>> Several IETF working groups are addressing this interface as >>> described in [RFC5415], [RFC5812], [RFC5810], >>> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >>> Defined Networking (SDN) [RFC7149] may also be applied. >>> >> >> The above makes sense and would be a good addition to the draft, but I= >> am still a little concerned with the text surrounding the reference to= >> draft-wakikawa-req-mobile-cp-separation. I think that it is the wordi= ng: >> >> >> This separation brings more flexible deployment and management of LMA >> and MAG(s) of Proxy Mobile IP as described in >> [I-D.wakikawa-req-mobile-cp-separation]. To meet this requirement... >> >> >> Should I parse this as the reference to the draft is only to relate th= e >> use cases rather than the actual requirements? If so, I could change >> "To meet this requirement" to "To facilitate this approach" or somethi= ng >> similar. >=20 >=20 > Reference to I-D.matsushima is intended to be an example. >=20 >=20 > How about the following text: >=20 > OLD: > Note that the interface between the control and user plane is out of= > scope in this document. It is required to setup a data path on the > user plane according to the control signaling on the control plane. > Several IETF working groups are addressing this interface as > described in [RFC5415], [RFC5812], [RFC5810], > [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software > Defined Networking (SDN) [RFC7149] may also be applied. >=20 >=20 >=20 > NEW: >=20 > The LMA-CP and the LMA-DP functions are typically deployed on the same = IP > node and in such scenario the interface between these functions is > internal to the implementation. Deployments may also choose to split th= e > LMA-CP and the LMA-DP functions across IP nodes. In such deployment > models, there needs to be a protocol interface between the LMA-CP and t= he > LMA-DP functions and which is outside the scope of this document. Possi= ble > options for such interface include OpenFlow [Ref-1], FORCES [Ref-2], us= e > of routing infrastructure [I-D.matsushima-stateless-uplane-vepc] or ven= dor > specific approaches. This specification does not mandate a approach, or= a > specific protocol interface and views this interface as a generic > interface relevant more broadly for other protocol systems as well (Ex:= > IPSec, L2TP, Mobile IPv6). >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> >> Or am I missing something? >> >> Regards, >> Brian >> --8f0hOqWkEF1ekmhDLHars0fNMaglQ5qww Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJThOBPAAoJEBOZRqCi7goqDXwH/2CIlUBDnI4yY24/CSrVdHGV zzkjTLWYqbNJRGeKSxBUlk1n4UxF3TtXwt7urgo21+4hgGknTmYWrT59PiUOq+HR Igg38WDgrUrqI7UPIQlexvsz5ydIFMHVBSatNzmKGtI8MqOtDERP5qtTLTvwGaV0 M8ft4azHAwpzQgjSHuhL2Ln9aDKbB/ZvUffV64HkqFC+Mf+xDRyFNU+LoefiIcLJ Y58KMwTItr3BU0aXgW/nOe5ccxDGQal/b1DqNoVO+K7romRhpjMvCF0KdhSJAlDO eGyzQOJUIlc+qUMnVMWZ7TPvPKm0CefPWKAsIoOjzy8rHXvUNknl7isa9Is2mBU= =4lZF -----END PGP SIGNATURE----- --8f0hOqWkEF1ekmhDLHars0fNMaglQ5qww-- From nobody Tue May 27 12:00:52 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323911A0709 for ; Tue, 27 May 2014 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWxijqt_0z4L for ; Tue, 27 May 2014 12:00:48 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074721A06F0 for ; Tue, 27 May 2014 12:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5017; q=dns/txt; s=iport; t=1401217242; x=1402426842; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7X7BR1czCJPlN+cYXZ8hoLe7mNQpm1iKoz807SX3o00=; b=Td8IZ1pFy2tRdXJDdWS6UuilPM5dhPlOKg7ee7AMuM3kvl12zylex5jj t1LMijh+drdpsdIuO8RgXz6jc3GXbTHnGUL8IDd66dAMYcV1BybgG9PsC 9sVtGbxv5oZiBgM1rnApuowKYGycUUkf7tjecUDkywiX+xo1+hrADYOwj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHANXfhFOtJV2R/2dsb2JhbABZgweBKqoEAQEBAQEFAZgMAYEOFnSCJQEBAQQ6UQEIGB5CJQIEARIbiCfVPReFVYkEhEAEmXOTJ4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,921,1392163200"; d="scan'208";a="47654519" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 27 May 2014 19:00:41 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4RJ0fw7010599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 19:00:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.80]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 27 May 2014 14:00:41 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPed3zDV83SmMqM0SRWkMj7Oh2cA== Date: Tue, 27 May 2014 19:00:40 +0000 Message-ID: In-Reply-To: <5384E049.4000007@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/B7kKjEjo8J-5H7eau0VYQ4HpwBI Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:00:50 -0000 Thanks Brian. We will post the revised I-D. Regards Sri On 5/27/14 11:58 AM, "Brian Haberman" wrote: >Sri, > I believe your proposed changes help clarify the text. Go ahead >and submit an update with all the changes discussed. > >Regards, >Brian > > >On 5/27/14 1:05 PM, Sri Gundavelli (sgundave) wrote: >> Hi Brian, >>=20 >> Sorry for the delay. Please see inline. >>=20 >>=20 >> On 5/22/14 4:57 AM, "Brian Haberman" wrote: >>=20 >>> Hi Sri, >>> >>>>> >>>>> 2. What is the plan for the publication of the CP separation >>>>> requirements document that is referenced in this document? It seems >>>>> rather silly to publish the solution spec before the requirements. >>>>> Should they advance together? Incorporate the requirements into this >>>>> document? >>>> >>>> >>>> >>>> We have the following text that talks about the assumptions around >>>>this >>>> interface. The draft is primarily driving this definition for the >>>> deployment-scenario where the CP and DP functions exist on the same IP >>>> node. Figure-1 reflects this. However, the draft does not disallow the >>>> separation of CP and DP functions across different IP nodes. That's >>>> surely >>>> the goal here. But, there is no desire to mandate one specific >>>>interface >>>> between CP and DP entities. That interface may emerge as a generic >>>> interface and this draft (PMIP-split-CP-DP) being one of the >>>> applications >>>> leveraging that interface. The interface can be based on OpenFlow, >>>> FORCES, >>>> some vendor specific interface, or the referenced draft based on >>>> extensions to routing control plane. There is no dependency on one >>>> specific interface for realizing the CP/DP split per this spec. Most >>>> likely vendors may not agree on a single interface between a >>>>controller >>>> and a data plane node and so we tried to stay neutral on that aspect. >>>> >>>> >>>> >>>> --- >>>> Section 1: >>>> >>>> Note that the interface between the control and user plane is out >>>>of >>>> scope in this document. It is required to setup a data path on the >>>> user plane according to the control signaling on the control plane. >>>> Several IETF working groups are addressing this interface as >>>> described in [RFC5415], [RFC5812], [RFC5810], >>>> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >>>> Defined Networking (SDN) [RFC7149] may also be applied. >>>> >>> >>> The above makes sense and would be a good addition to the draft, but I >>> am still a little concerned with the text surrounding the reference to >>> draft-wakikawa-req-mobile-cp-separation. I think that it is the >>>wording: >>> >>> >>> This separation brings more flexible deployment and management of LMA >>> and MAG(s) of Proxy Mobile IP as described in >>> [I-D.wakikawa-req-mobile-cp-separation]. To meet this requirement... >>> >>> >>> Should I parse this as the reference to the draft is only to relate the >>> use cases rather than the actual requirements? If so, I could change >>> "To meet this requirement" to "To facilitate this approach" or >>>something >>> similar. >>=20 >>=20 >> Reference to I-D.matsushima is intended to be an example. >>=20 >>=20 >> How about the following text: >>=20 >> OLD: >> Note that the interface between the control and user plane is out of >> scope in this document. It is required to setup a data path on the >> user plane according to the control signaling on the control plane. >> Several IETF working groups are addressing this interface as >> described in [RFC5415], [RFC5812], [RFC5810], >> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >> Defined Networking (SDN) [RFC7149] may also be applied. >>=20 >>=20 >>=20 >> NEW: >>=20 >> The LMA-CP and the LMA-DP functions are typically deployed on the same >>IP >> node and in such scenario the interface between these functions is >> internal to the implementation. Deployments may also choose to split the >> LMA-CP and the LMA-DP functions across IP nodes. In such deployment >> models, there needs to be a protocol interface between the LMA-CP and >>the >> LMA-DP functions and which is outside the scope of this document. >>Possible >> options for such interface include OpenFlow [Ref-1], FORCES [Ref-2], use >> of routing infrastructure [I-D.matsushima-stateless-uplane-vepc] or >>vendor >> specific approaches. This specification does not mandate a approach, or >>a >> specific protocol interface and views this interface as a generic >> interface relevant more broadly for other protocol systems as well (Ex: >> IPSec, L2TP, Mobile IPv6). >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> >>> Or am I missing something? >>> >>> Regards, >>> Brian >>> > From nobody Thu May 29 11:56:45 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249901A09AD for ; Thu, 29 May 2014 11:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4Vcdqxn2Pd9 for ; Thu, 29 May 2014 11:56:35 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC701A0A25 for ; Thu, 29 May 2014 11:56:22 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so890738wes.29 for ; Thu, 29 May 2014 11:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BDthR6iIHyfzxLcbfH8pZ4rP9OkC0y92It5wgaZectU=; b=SQWVTNj/49S9W57gHoN6S9bBl9vj23/YxGz/eRG802F/9sLRkRNogiu/AirDS1i8V3 auYGbV1N3kCZ5zFaAlWF+5GHEcYoh1tmHSt96a4N3+rXaupjdqkVVD3Nlyc8kZDUPytx wQ0qpEt9LMaQu1Fj97BE/hpDf6oLy8P9nqnRVfklejZq5UIG1wGmHkI83WkjDZefGU8E bJ/DmWT6ukoMSUpuaPQrss7clnHxf85+J5qnBRlRt73vPmgeTWzsDPQcNDAHi+GR911t jGK2MALCv6tjhOJjjwP/oK6SiWTC68yRuLDZlPfQ56ZbOuZnUzA2stnkKTk2ZhUwus1J 6SqQ== MIME-Version: 1.0 X-Received: by 10.194.243.3 with SMTP id wu3mr13548694wjc.29.1401389777512; Thu, 29 May 2014 11:56:17 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Thu, 29 May 2014 11:56:17 -0700 (PDT) Date: Thu, 29 May 2014 11:56:17 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e013d14c4e1702c04fa8e7b50 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/dq1yI12-zndiHWCGEPqFfqyELQc Subject: [netext] xml2RFC tool X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:56:37 -0000 --089e013d14c4e1702c04fa8e7b50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, is anyone else having problems with the tool? I am not able to compile the doc; I also tried a previously compile-worthy xml file. Thanks. -Rajeev ERROR: Unable to parse the XML document: INPUT INPUT: Line 0: Unable to resolve external request: "rfc2629-bis.dtd" Using XML_LIBRARY=3D/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/b= ibxml:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml2:/home/w= ww/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml3:/home/www/tools.ietf= .org/tools/xml2rfc/web/public/rfc/bibxml4:/home/www/tools.ietf.org/tools/xm= l2rfc/web/public/rfc/bibxml5 Parsing file INPUT --089e013d14c4e1702c04fa8e7b50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

is anyone else havin= g problems with the tool? I am not able to compile the doc; I also tried a = previously compile-worthy xml file.

Thanks.

-Rajeev

--089e013d14c4e1702c04fa8e7b50-- From nobody Thu May 29 13:10:46 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30711A0666 for ; Thu, 29 May 2014 13:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 dOMaSjEpqbZ1 for ; Thu, 29 May 2014 13:10:42 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356BD1A066D for ; Thu, 29 May 2014 13:10:37 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id b6so756455yha.17 for ; Thu, 29 May 2014 13:10:33 -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:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=oLc8ahfLHrMsf+fK5R53+iZIBiLQ2yYtBa43bBItlDs=; b=JBzE6B/4K3uK6P6ETIKFycWV8Uo7zDdbqLx2fJ9ZWE8gWzvMU2KbOuYYtYBOhnOlVl 7LQIZNA4dXOtLIyS0RkhsoeZlla2ZFSPjcRcyiY8j4dgd2vaE8WDJfrmCIZpF9LtWnNf OM4ukFl4R2J4oViRlHAGMTeZ3V36/Sj4TgYb2AvmYuOk1GVyNei38VsDX5biCXgoxJRn F+3cIFOQYAmq7I+0qOsSnUpzziW/PBFSboHw8B7v8g5XKglgezyvQibP0GPtTFpltLLs RrfxjHWlQMLsk6epzCDxQ63LaKOOIKvouyURcIUBh9nufHyI1yNzy0YorJY6YwAH5abm q+qQ== MIME-Version: 1.0 X-Received: by 10.236.191.132 with SMTP id g4mr13592079yhn.32.1401394232967; Thu, 29 May 2014 13:10:32 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Thu, 29 May 2014 13:10:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 May 2014 15:10:32 -0500 Message-ID: From: Behcet Sarikaya To: Rajeev Koodli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netext/OgkG4rulX4RCrJjVnzmt0hUfxHA Cc: "netext@ietf.org" Subject: Re: [netext] xml2RFC tool X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:10:44 -0000 Hi Rajeev, Use this link: http://xml2rfc.tools.ietf.org/ it just worked for me. Regards, Behcet On Thu, May 29, 2014 at 1:56 PM, Rajeev Koodli wr= ote: > > Hi, > > is anyone else having problems with the tool? I am not able to compile th= e > doc; I also tried a previously compile-worthy xml file. > > Thanks. > > -Rajeev > > ERROR: Unable to parse the XML document: INPUT > INPUT: Line 0: Unable to resolve external request: "rfc2629-bis.dtd" > > Using > XML_LIBRARY=3D/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxm= l:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml2:/home/www/t= ools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml3:/home/www/tools.ietf.org= /tools/xml2rfc/web/public/rfc/bibxml4:/home/www/tools.ietf.org/tools/xml2rf= c/web/public/rfc/bibxml5 > Parsing file INPUT > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From nobody Thu May 29 18:27:56 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22621A0704 for ; Thu, 29 May 2014 18:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o4ir9NK45te for ; Thu, 29 May 2014 18:27:52 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31201A0700 for ; Thu, 29 May 2014 18:27:51 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so266937wiw.3 for ; Thu, 29 May 2014 18:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=w/NXvZTWQiLLmnc0DR3syqdGqmLOUKWTbBaHCkDlm5E=; b=CFCE8LbrOOn3yBtRRN7WkVt6RDugMovemTtj4a6S6HloFc31iz0XmsyXfzMwfieYo3 STaPSssxjdv4prTVDuL/lyQaDIh83djQ2VE09B0yXhHBh+r0fTvNZAwiyrQUSNMyRNnz TJJb9pkCuVpLqyzJ80XHRQE/qAzuXJZ5ZF55X1a7PRWZGeWNh8t3DWhYUA0LfUZcaYIb 8f6xfqRJB+zo4ntqBMFbZDaXwZm7AFj9VI08yPsl6jEWKEIrJEGF5UMwt+H16MfI9wG2 qXBptNS36qp+kRvf9HoNmTPU9FEb5u+TF4kSktez7Pgi+6aTjtHDzBe4nWT1nnhhVL6Y +6eQ== MIME-Version: 1.0 X-Received: by 10.194.75.170 with SMTP id d10mr16553407wjw.2.1401413266642; Thu, 29 May 2014 18:27:46 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Thu, 29 May 2014 18:27:46 -0700 (PDT) In-Reply-To: <53878FD9.7030408@earthlink.net> References: <53878FD9.7030408@earthlink.net> Date: Thu, 29 May 2014 18:27:46 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04c96f11da104fa93f304 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/-MVL-0sd4-mSX8yNA55A6DCLDB0 Subject: [netext] Fwd: xml2RFC tool X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:27:54 -0000 --047d7bb04c96f11da104fa93f304 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Charlie Perkins Date: Thu, May 29, 2014 at 12:51 PM Subject: Re: [netext] xml2RFC tool To: Rajeev Koodli , netext@ietf.org Hello Rajeev, I also could not use it last week. Carsten sent a message containing the following advice: This outage is being discussed over at tools-discuss. Workaround for now: globally replace xml.resource.org with xml2rfc.tools.ietf.org in your XML files. I have not tried it. Regards, Charlie P. On 5/29/2014 11:56 AM, Rajeev Koodli wrote: Hi, is anyone else having problems with the tool? I am not able to compile the doc; I also tried a previously compile-worthy xml file. Thanks. -Rajeev ERROR: Unable to parse the XML document: INPUT INPUT: Line 0: Unable to resolve external request: "rfc2629-bis.dtd" Using XML_LIBRARY=3D/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/b= ibxml:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml2:/home/w= ww/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml3:/home/www/tools.ietf= .org/tools/xml2rfc/web/public/rfc/bibxml4:/home/www/tools.ietf.org/tools/xm= l2rfc/web/public/rfc/bibxml5 Parsing file INPUT _______________________________________________ netext mailing listnetext@ietf.orghttps://www.ietf.org/mailman/listinfo/net= ext --047d7bb04c96f11da104fa93f304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: Charlie Perkins= <cha= rles.perkins@earthlink.net>
Date: Thu, May 29, 2014 at 12:51 PM
Subject: Re: [netext] xml2RFC toolTo: Rajeev Koodli <rajeev.k= oodli@gmail.com>, netext@ietf.org=


=20 =20 =20

Hello Rajeev,

I also could not use it last week.

Carsten sent a message containing the following advice:

This outage is being discussed over at tools-discuss.

=C2=A0

Workaround for now: globally replace xml.resource.org with xml2rfc.t= ools.ietf.org in your XML files.

I have not tried it.

Regards,
Charlie P.



On 5/29/2014 11:56 AM, Rajeev Koodli wrote:

Hi,

is anyone else having problems with the tool? I am not able to compile the doc; I also tried a previously compile-worthy xml file.

Thanks.

-Rajeev



_______________________________________________
netext mailing list
netext@ietf.org
=
https://www.ietf.org/mailman/listinfo/netext


--047d7bb04c96f11da104fa93f304--