From nobody Tue Apr 1 01:13:06 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 637331A701F for ; Tue, 1 Apr 2014 01:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pUZ5XAQ8sfd9 for ; Tue, 1 Apr 2014 01:13:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id C74691A701D for ; Tue, 1 Apr 2014 01:13:00 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 3334E1B84C4; Tue, 1 Apr 2014 10:12:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0A955158083; Tue, 1 Apr 2014 10:12:56 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 10:12:55 +0200 From: To: Ryuji Wakikawa Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPSMy4Aa5CzPfKV0eGOYAugumCeZrz9MfdgAAqsICACFHhwA== Date: Tue, 1 Apr 2014 08:12:54 +0000 Message-ID: <10435_1396339976_533A7508_10435_5755_1_81C77F07008CA24F9783A98CFD706F7114218AC7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: , <53328E89.1060409@kddilabs.jp> <30516_1395873115_5333555B_30516_15540_1_v5mld5dmjy0sqv44fux4c1hd.1395873108462@email.android.com> <62EEA756-B793-4108-B704-3F4CC09ABC12@gmail.com> In-Reply-To: <62EEA756-B793-4108-B704-3F4CC09ABC12@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.1.65115 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/eK3HF_VP6uyZpJGehgpktJEZv4g Cc: "netext@ietf.org" Subject: Re: [netext] WG last call: 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, 01 Apr 2014 08:13:03 -0000 SGksDQoNClNvcnJ5IGZvciB0aGUgbGF0ZSBhbnN3ZXIsDQoNCj4tLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj5EZcKgOiBSeXVqaSBXYWtpa2F3YSBbbWFpbHRvOnJ5dWppLndha2lrYXdhQGdt YWlsLmNvbV0NCj5FbnZvecOpwqA6IGpldWRpIDI3IG1hcnMgMjAxNCAwMzowNQ0KPsOAwqA6IFNF SVRFIFBpZXJyaWNrIElNVC9PTE4NCj5DY8KgOiBuZXRleHRAaWV0Zi5vcmc7IEhpZGV0b3NoaSBZ b2tvdGENCj5PYmpldMKgOiBSZTogW25ldGV4dF0gV0cgbGFzdCBjYWxsOiBkcmFmdC1pZXRmLW5l dGV4dC1wbWlwLWNwLXVwLXNlcGFyYXRpb24NCj4NCj5IaSBQaWVycmljaw0KPg0KPnRoYW5rcyBm b3IgY29tbWVudHMuDQo+DQo+MjAxNC8wMy8yNyDljYjliY03OjMx44CBcGllcnJpY2suc2VpdGVA b3JhbmdlLmNvbSDjga7jg6Hjg7zjg6vvvJoNCj4NCj4+IEhpDQo+Pg0KPj4gSSBzdXBwb3J0IHRo aXMgZHJhZnQ7IGl0IGFkcmVzc2VzIHZhbGlkIGFyY2hpdGVjdHVyZSBzY2VuYXJpbyB3aXRoIHNl cGFyYXRlZA0KPmNvbnRyb2wgYW5kIGRhdGEgcGxhbmUgZW50aXRpZXMuDQo+PiBIb3dldmVyIGFy Y2hpdGVjdHVyZSBpbiBmaWd1cmUgMSBzaG91bGQgYmUgdXBkYXRlZCB0byBjbGVhcmx5IHNob3cg dGhpcw0KPnNlcGFyYXRpb24uIEZpZyAxIHB1dCBib3RoIG1hZyBjcCBhbmQgbWFnIHVwIHdpdGhp biB0aGUgc2FtZSBib3gsIHdoaWNoIGlzIGENCj5iaXQgY29uZnVzaW5nIHJlZ2FyZGluZyB0aGUg c2NvcGUgb2YgdGhlIGRvY3VtZW50Lg0KPg0KPldlIHdpbGwgZml4IHRoaXMuDQo+DQo+PiBBbHRo b3VnaCBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRvY3VtZW50LCBpdCB3b3VsZCBiZSB3b3J0aCB0byBn aXZlIGluZGljYXRpb24NCj5vbiBpbnRlcmZhY2UgYmV0d2VlbiBtYWcgY3AgYW5kIHVwIChlZyBD YXB3YXAgYmFzZWQpIGluIG9yZGVyIHRvIGhhdmUgdGhlDQo+ZnVsbCBwaWN0dXJlIG9uIGhvdyB0 aGUgc29sdXRpb24gY2FuIHdvcmsuDQo+DQo+V2UgY2FuIGNsYXJpZnkgdGhhdCB0aGlzIGludGVy ZmFjZSBpcyBvdXQgb2Ygc2NvcGUuDQo+RG8gd2UgbmVlZCBleGFtcGxlcyBsaWtlIGNhcHdhcC9m b3JjZXMvc2RuIGluIHRoZSBkb2N1bWVudD8NCj4NCg0KWWVzLCBJIHRoaW5rIHNvLiBBbHNvLCBp ZiBwb3NzaWJsZSwgeW91IGNvdWxkIGdpdmUgcmVxdWlyZW1lbnRzIGZvciB0aGlzIGludGVyZmFj ZS4gU28sIHRoZSByZWFkZXIgY291bGQga25vdyBpZiBsZWdhY3kgQ0FQV0FQIChmb3IgZXhhbXBs ZSkgY291bGQgYmUgdXNlZCBvciBpZiBleHRlbnNpb25zIGFyZSByZXF1aXJlZC4NCg0KQlIsDQpQ aWVycmljaw0KDQo+cmVnYXJkcywNCj5yeXVqaQ0KPg0KPg0KPg0KPj4NCj4+IFNlbnQgZnJvbSBt eSBtb2JpbGUNCj4+DQo+PiAtLS0tIEhpZGV0b3NoaSBZb2tvdGEgPA0KPj4geW9rb3RhQGtkZGls YWJzLmpwPiB3cm90ZSAtLS0tDQo+PiBIaSBhdXRob3JzLA0KPj4NCj4+IEkgdGhpbmsgdGhpcyBp cyBpbiBnb29kIHNoYXBlIGVub3VnaCB0byBnbywgYnV0IGp1c3Qgb25lIGNsYXJpZmljYXRpb24g cXVlc3Rpb246DQo+Pg0KPj4gSW4gU2VjdGlvbiA2LA0KPj4gICAgICAgICAgV2hlbiB0aGlzIHZh cmlhYmxlIG9uIHRoZSBNQUcgaXMgc2V0IHRvIGEgdmFsdWUgb2YgKDApLCB0aGUgTUFHDQo+PiAg ICAgICAgICBtdXN0IGV4cGxpY2l0bHkgaW5kaWNhdGUgaXRzIHN1cHBvcnQtY2FwYWJpbGl0eSBm b3IgdGhpcw0KPj4gICAgICAgICAgZmVhdHVyZSBieSBpbmNsdWRpbmcgdGhlIExNQSBVc2VyIFBs YW5lIEFkZHJlc3MgbW9iaWxpdHkgT3B0aW9uDQo+PiAgICAgICAgICBpbiB0aGUNCj4+IFByb3h5 IEJpbmRpbmcgQWNrbm93bGVkZ2VtZW50DQo+PiAuICBJZiB0aGUgb3B0aW9uIGlzIG5vdA0KPj4g ICAgICAgICAgcHJlc2VudCBpbiB0aGUgUHJveHkgQmluZGluZyBVcGRhdGUsIHRoZSBsb2NhbCBt b2JpbGl0eSBhbmNob3INCj4+ICAgICAgICAgIHdpbGwgbm90IGVuYWJsZSB0aGlzIGZlYXR1cmUg Zm9yIHRoYXQgbW9iaWxpdHkgc2Vzc2lvbi4NCj4+DQo+Pg0KPj4gSG93IGNhbiBNQUcgaW5kaWNh dGUgaXRzIHN1cHBvcnQgYnkgUEJBPyBJcyBpdCBQQlUgb3IgTE1BIGRvZXMgaXQgYnkgYW55DQo+ Y2hhbmNlPyBUaGUgc2FtZSBxdWVzdGlvbiBhcHBsaWVzIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdy YXBoIGluIHRoZQ0KPmRvY3VtZW50Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiAtLQ0KPj4gSGlkZXRv c2hpIFlva290YQ0KPj4NCj4+IEtEREkgUiZEIExhYm9yYXRvcmllcywgSW5jLg0KPj4NCj4+IGUt bWFpbDp5b2tvdGFAa2RkaWxhYnMuanANCj4+DQo+Pg0KPj4NCj4+DQo+PiAoMjAxNC8wMy8xMyAz OjQyKSwgQmFzYXZhcmFqIFBhdGlsIHdyb3RlOg0KPj4+IEhlbGxvLA0KPj4+DQo+Pj4gVGhpcyBp cyB0aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIEktRDogU2VwYXJhdGlvbiBvZiBDb250 cm9sIGFuZCBVc2VyDQo+UGxhbmUgZm9yIFByb3h5IE1vYmlsZSBJUHY2IDxkcmFmdC1pZXRmLW5l dGV4dC1wbWlwLWNwLXVwLXNlcGFyYXRpb24tDQo+MDIudHh0Pi4NCj4+Pg0KPj4+IFRoaXMgSS1E IGlzIGludGVuZGVkIHRvIGJlIHByb2dyZXNzZWQgYXMgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1l bnQuDQo+Pj4gUGxlYXNlIHJldmlldyBhbmQgcG9zdCB5b3VyIGNvbW1lbnRzIG9uIHRoZSBtYWls aW5nIGxpc3QuDQo+Pj4gVGhlIGxhc3QgY2FsbCB3aWxsIGV4cGlyZSBvbiBNYXJjaCAyN3RoLCAx NC4NCj4+Pg0KPj4+IC1DaGFpcnMNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5ldGV4dCBtYWlsaW5nIGxpc3QN Cj4+Pg0KPj4+IG5ldGV4dEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0ZXh0DQo+Pg0KPj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPl9fX19fX19fX19fDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PiBDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMNCj4+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPj4gcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcw0KPnBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91DQo+ZmFsc2lmaWUu IE1lcmNpLg0KPj4NCj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvcg0KPj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUNCj5kaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUNCj50aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+IEFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuDQo+bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4gVGhhbmsgeW91Lg0KPj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBu ZXRleHQgbWFpbGluZyBsaXN0DQo+PiBuZXRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Apr 25 15:28: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 571AD1A06D2; Fri, 25 Apr 2014 15:28:30 -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 1MSwdhQYIEBL; Fri, 25 Apr 2014 15:28:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 784DB1A03F2; Fri, 25 Apr 2014 15:28:28 -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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425222828.11853.80169.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 15:28:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/by8e4CjzkYUZke5rEpvC4ov_KxE Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-03.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: Fri, 25 Apr 2014 22:28:30 -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 : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-03.txt Pages : 11 Date : 2014-04-25 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-03 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 Apr 30 12:16:29 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 BC9BF1A0956; Wed, 30 Apr 2014 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 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, J_CHICKENPOX_22=0.6, 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 Ukkc1uTFYIFh; Wed, 30 Apr 2014 12:16:24 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF781A0946; Wed, 30 Apr 2014 12:16:24 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id gq1so2542299obb.33 for ; Wed, 30 Apr 2014 12:16: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=Gc0fJAGDBtTBP2G+dnuFOYpV2Gt+fzIHD/6EuFw7Bvg=; b=zIliaMPe5qAV/Ah1L4qkV+lGF7uZj2M3TdFJh5wVqgBg9HrOllp+hfc/SZBjX6p0wZ lP+JfJYLFQMjHrq40ggmo+ueonWZuvNOLE3pNLbT+9M7wRChDS4kTjIaeYmvVNkHyZiA M7gFt8MQ2Yf4nuvrXce8Ac5smiqZISLaVC9wNTBj7akFBQBbXTLGTwRZDZrLOpjSrJLz HGfexSZPeDUjHRkruimCK6DWGFnYS77XzF8rKG3IwRp5ZgKW4gkekmgFwKZljAhc+OyZ H4CWZkh5AUuGb9qhridml45oTG48fDIsj6MFrO+QSnDKG6/UOCgfVwfg8F6xauDH/+k9 OUGA== MIME-Version: 1.0 X-Received: by 10.182.33.6 with SMTP id n6mr5617244obi.48.1398885382614; Wed, 30 Apr 2014 12:16:22 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 30 Apr 2014 12:16:22 -0700 (PDT) Date: Wed, 30 Apr 2014 14:16:22 -0500 Message-ID: From: Basavaraj Patil To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=089e0158a836502b8c04f8476294 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/56OkKYqf8A0HIBTQb-5dSPC1qm0 Cc: "netext@ietf.org" , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" Subject: [netext] Request to progress I-D: draft-ietf-netext-wifi-epc-eap-attributes-07 to publication 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, 30 Apr 2014 19:16:26 -0000 --089e0158a836502b8c04f8476294 Content-Type: text/plain; charset=UTF-8 Hello, The Netext working group has completed the working group last call for I-D; EAP Attributes for WiFi - EPC Integration We would like to submit this I-D to the IESG for review and progress it for publication as an Informational RFC. The completed proto form for this I-D is below. -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? Informational. (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: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. 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 been in a dormant state for a while. There is no controversy regarding the document. Using EAP attributes to address a problem that is faced in mobile networks when attaching via WiFi is one solution. And there is enough consensus in the WG w.r.t the solution. 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? There are no known implementations of the attributes for EAP defined by this document. At this time there is'nt any indication from vendors or 3GPP to use the approach specified by this document. The document has acknowledged the one person who has helped in improving the specification. The document does not specify any media type or MIB and hence no specialists have been consulted for reviews. 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 document and provided feedback to the authors via the working group mailing list. See: http://www.ietf.org/mail-archive/web/netext/current/msg03035.html This version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I am satisfied with the depth and breadth of reviews this document has gone through. (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. No. (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. I have no concerns with any aspect of this document. (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 indicated that they are not aware of any IPRs and are in conformance of the provisions of BCP 78, 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 disclosure that references this document has 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? There is sufficient consensus in the WG about the proposed solution of using EAP attributes and publishing it as an Informational RFC. (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. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). == Missing Reference: 'RFC2119' is mentioned on line 172, but not defined == Unused Reference: 'EPC' is defined on line 557, but no explicit reference was found in the text (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 define any MIB or a media type or URI type. (13) Have all references within this document been identified as either normative or informative? The document only has informative references. (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. (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. No. This is an informational document and will not change 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 section is clear in terms ofthe registry to be used for adding the new attributes defined in the document. I am satisfied with the level of detail provided in the IANA section. (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 registeries need to be created. The document proposes the use of "EAP-AKA and EAP-SIM Parameters" registry for the attributes specified. (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 is defined in the document. -- Basavaraj Patil --089e0158a836502b8c04f8476294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

The Ne= text working group has completed the working group last call for
= I-D;
EAP Attributes =C2=A0for WiFi - EPC Integration
&l= t;draft-ietf-netext-wifi-epc-eap-attributes-07>

We would like to submit this I-D to the IESG for review= and progress
it for publication as an Informational RFC. The com= pleted proto form
for this I-D is below.

-Raj


(1) What type of RFC is b= eing requested (BCP, Proposed Standard,
Internet Standard, Inform= ational, Experimental, or Historic)? Why is
this the proper type = of RFC? Is this type of RFC indicated in the
title page header? =C2=A0 =C2=A0

Informationa= l.

(2) The IESG approval announcement includes a D= ocument Announcement
Write-Up. Please provide such a Document Ann= ouncement Write-Up. Recent
examples can be found in the "Action" announcements for appr= oved
documents. The approval announcement contains the following = sections:=C2=A0

Technical Summary:

<= /div>
=C2=A0 =C2=A0With WiFi beginning to establishing itself as a trusted a= ccess
=C2=A0 =C2=A0network for service providers, it has become i= mportant to provide
=C2=A0 =C2=A0functions commonly available in = 3G and 4G networks in WiFi access
=C2=A0 =C2=A0networks. =C2=A0Such functions include Access Point Name = (APN) Selection,
=C2=A0 =C2=A0multiple Packet Data Network (PDN) = connections and seamless mobility
=C2=A0 =C2=A0between WiFi and 3= G/4G networks.

=C2=A0 =C2=A0EAP/AKA (and EAP/AKA') is standardized by 3GPP as the= access
=C2=A0 =C2=A0authentication protocol for trusted access n= etworks. =C2=A0This IETF
=C2=A0 =C2=A0specification is required f= or mobile devices to access the 3GPP
=C2=A0 =C2=A0Evolved Packet Core (EPC) networks. =C2=A0This document d= efines a few new
=C2=A0 =C2=A0EAP attributes and procedures to pr= ovide the above-mentioned
=C2=A0 =C2=A0functions in trusted WiFi = access networks.

Working Group Summary:

Was there anythi= ng in WG process that is worth noting? For example,
was there con= troversy about particular points or were there decisions
where th= e consensus was particularly rough?=C2=A0

This document has been in a dormant state for a while. = There is no
controversy regarding the document. Using EAP attribu= tes to address a
problem that is faced in mobile networks when at= taching via WiFi is
one solution. And there is enough consensus in the WG w.r.t the
<= div>solution.=C2=A0


Document Qualit= y:

Are there existing implementations of the proto= col? Have a significant
number of vendors indicated their plan to implement the specification?=
Are there any reviewers that merit special mention as having don= e 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 cour= se
(briefly)? In the case of a Media Type review, on what date wa= s the
request posted?=C2=A0

There are no known impl= ementations of the attributes for EAP defined
by this document. A= t this time there is'nt any indication from vendors
or 3GPP t= o use the approach specified by this document.=C2=A0
The document has acknowledged the one person who has helped in
improving the specification. The document does not specify any media
type or MIB and hence no specialists have been consulted for reviews= .=C2=A0

Personnel:

Who is the Document= Shepherd? Who is the Responsible Area Director?

D= ocument Shepherd: Basavaraj Patil
Responsible AD: Brian Haberman<= /div>

(3) Briefly describe the review of this document that w= as performed by
the Document Shepherd. If this version of the doc= ument is not ready
for publication, please explain why the docume= nt is being forwarded to
the IESG.=C2=A0

I have reviewed the document = and provided feedback to the authors via
the working group mailin= g list. See:

This version of the document is ready for publication.<= /div>


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

I am satisfied with the depth and breadth of reviews th= is document has
gone through.=C2=A0

(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.=C2=A0

No.=C2=A0

(6) Describe any specific concerns or issues that the D= ocument
Shepherd has with this document that the Responsible Area= Director
and/or the IESG should be aware of? For example, perhap= s 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.=C2=A0

=
I have no concerns with any aspect of this document.=C2=A0
=


(7) Has each author confirmed that any a= nd 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?=C2=A0<= /div>

Yes. Each author has indicated that they are not a= ware of any IPRs and
are in conformance of the provisions of BCP 78, 79

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

No IPR disclosure that ref= erences this document has been filed.=C2=A0

(9) Ho= w solid is the WG consensus behind this document? Does it
represe= nt 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

There is sufficient consensus in the WG abo= ut the proposed solution of
using EAP attributes and publishing i= t as an Informational RFC.=C2=A0

(10) Has anyone threatened an appeal or otherwise indic= ated extreme
discontent? If so, please summarise the areas of con= flict in separate
email messages to the Responsible Area Director= . (It should be in a
separate email because this questionnaire is publicly available.)=C2= =A0

No.=C2=A0

(11) Identi= fy any ID nits the Document Shepherd has found in this
document. = (See http://www.ietf.org/tool= s/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.=C2=A0

Summary:= 0 errors (**), 0 flaws (~~), 2 warnings (=3D=3D), 1 comment (--).
=3D=3D Missing Reference: 'RFC2119' is mentioned on line 172, but= not
=C2=A0 =C2=A0 =C2=A0defined
=3D=3D Unused Reference: 'EP= C' is defined on line 557, but no explicit
=C2=A0 =C2=A0 =C2= =A0reference was found in the text

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

The document does not define any MIB or a medi= a type or URI type.=C2=A0

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

The do= cument only has informative references.=C2=A0

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

No.

(15) Are there do= wnward normative references references (see RFC
3967)? If so, lis= t 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
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 docum= ent to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.=C2=A0
<= br>
No. This is an informational document and will not change the= status
of any existing RFCs.=C2=A0

(17) Describe the= Document Shepherd's review of the IANA
considerations sectio= n, 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 hav= e been
clearly identified. Confirm that newly created IANA regist= ries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, an= d
a reasonable name for the new registry has been suggested (see = RFC
5226).=C2=A0

The IANA section is clear in ter= ms ofthe registry to be used for
adding the new attributes define= d in the document. I am satisfied with
the level of detail provid= ed in the IANA section.=C2=A0

(18) List any new IANA registries that require Expert R= eview for
future allocations. Provide any public guidance that th= e IESG would
find useful in selecting the IANA Experts for these = new registries.=C2=A0

No new registeries need to be created. The document pro= poses the use
of "EAP-AKA and EAP-SIM Parameters" regis= try for the attributes
specified.

(19) D= escribe 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 is defined in the docu= ment.


--
Basavaraj Patil
--089e0158a836502b8c04f8476294-- From nobody Wed Apr 30 15:20: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 31C751A094C for ; Wed, 30 Apr 2014 15:20:09 -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 K-CbU_R_BkAT for ; Wed, 30 Apr 2014 15:20:05 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D07071A09AC for ; Wed, 30 Apr 2014 15:20:04 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp4so2787018obc.34 for ; Wed, 30 Apr 2014 15:20:03 -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=/gVuHdwxzTYX0dbROeAuidrMRJdJIyjDKC3sFFOHQA0=; b=tzHY+cpd1wWZTaF41kFg2NZBlUlvfIk94f/HPsMKF6JW5yY6Pz1xU/obsd6/5nyUpw XaPIB4MFstCr4zUl6hFSyma3qQTRSbasLUtpkHG4IU3AWW0sgxgd+HsL9yTkDWwlgrUX Ep35eHe70e2/nY+jIDELxa8hzbJq52hveUae7kjL/pc+h1q66rCofWM2J4D+KbJrlHz2 QkgkqZKocMvEioTnlQV58WRZsa0rStSCq/uJP5QRVTQ4IOV+XtpaOAPwERUywBdNptkQ 1eu+JaycZZXl33I+kp5e10iAAf1ma28UOddUK0Lmc7tgWbAgxfzNUz3ISwq9+nEo9r/k sliw== MIME-Version: 1.0 X-Received: by 10.182.78.100 with SMTP id a4mr4730996obx.56.1398896403087; Wed, 30 Apr 2014 15:20:03 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 30 Apr 2014 15:20:03 -0700 (PDT) Date: Wed, 30 Apr 2014 17:20:03 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4a442f05bd04f849f3cd Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ZksUH0dhpczbQc0wHtZva55pAc8 Cc: draft-kaippallimalil-netext-pmip-qos-wifi@tools.ietf.org, "netext-chairs@tools.ietf.org" Subject: [netext] Summary and closure on consensus call to adopt I-D:draft-kaippallimalil-netext-pmip-qos-wifi 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: Wed, 30 Apr 2014 22:20:09 -0000 --047d7b2e4a442f05bd04f849f3cd Content-Type: text/plain; charset=UTF-8 Hello, We had issued a consensus call in February to adopt the I-D: draft-kaippallimalil-netext-pmip-qos-wifi as a working group document. Please see: http://www.ietf.org/mail-archive/web/netext/current/msg03021.html This I-D is being proposed as an Informational document. There has been support expressed by several WG members to adopt this I-D as a WG document. At this time, I would request the authors to submit it as a WG document. We will progress it as on the Informational track. Rgds, -Raj -- Basavaraj Patil --047d7b2e4a442f05bd04f849f3cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

We had issued a c= onsensus call in February to adopt the I-D: draft-kaippallimalil-netext-pmi= p-qos-wifi=C2=A0 as a working group document.
Please see:=C2=A0http://www.ietf.org/mail-archive/web/netext/current/msg03021.html

This I-D is being proposed as an Informational document= .

There has been support expressed by several WG m= embers to adopt this I-D as a WG document.=C2=A0

A= t this time, I would request the authors to submit it as a WG document. We = will progress it as on the Informational track.

Rgds,
-Raj
--
Basavaraj Patil
--047d7b2e4a442f05bd04f849f3cd--