From nobody Sat Mar 1 13:53: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 AD9651A048C for ; Sat, 1 Mar 2014 13:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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.547, 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 29Y1ZfL58o90 for ; Sat, 1 Mar 2014 13:52:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AAAA21A0354 for ; Sat, 1 Mar 2014 13:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5509; q=dns/txt; s=iport; t=1393710776; x=1394920376; h=from:to:subject:date:message-id:mime-version; bh=ptScTRnGX11ehamZWTxzpEbjhxWx8vaU/YR38nYfHPY=; b=PV6O5POAngXjzcFXQpPkAmYlw/rM69WDZeHlptnIGaIHy3xMOTnxJ9Kd D6MmS2u0t/x6HUQ2wzuVqvgI9V7yFBAeYWjfzaY3ZtA8V2C92KBYLgNJu ST2Ptw08N3r1jVXN9Hn9tLJ1/ViOJqGZpkwc3UgoaTn3rIdlgEqPUZ0Xa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFABRWElOtJXG//2dsb2JhbABagkJEO1fBIIESFnSCJwEELTokASpWJgEEG4dxnDavUheOKINcgRQEqmeDLYIq X-IronPort-AV: E=Sophos;i="4.97,569,1389744000"; d="scan'208,217";a="307378322" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 01 Mar 2014 21:52:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s21LquOk017392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Mar 2014 21:52:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Sat, 1 Mar 2014 15:52:55 -0600 From: "Kent Leung (kleung)" To: "netext@ietf.org" Thread-Topic: Comments on draft-pazhyannur-netext-civic-location-ani-subopt-01 Thread-Index: Ac81mJfVU9ZLtL04QXO+pHe0Aluxsw== Date: Sat, 1 Mar 2014 21:52:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.125.20] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB4DE180BAxmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/s8MyIZ_PnBf8ECYwCbN9iyuFnas Subject: [netext] Comments on draft-pazhyannur-netext-civic-location-ani-subopt-01 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: Sat, 01 Mar 2014 21:53:01 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB4DE180BAxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. I believe the proposal is a good idea and would be useful. In general, = the draft looks good. The scheme allows the MAG to propose the interval for= location change notifications and LMA can override that value. A few comme= nts below. 1. Title: Typo "Acess" 2. Sect.1: Typos - "mobiility" 3. Sect.4: Group Identifier: need description, though obvious. 4. The intent of the text, "then MAG behavior with respect to up= dating the ANI values is left to implementation choices", is to state that = MAG behavior is implemented in accordance to RFC 6757 since response indica= tes LMA does not understand the ANI option? 5. Is the Group ID a global value? What happens if handover happ= ens between providers that happened to have the same adjacent group IDs? 6. Why not two byte Group ID? 64K groups is not sufficient? It w= ould save 4 bytes by fitting in the Reserved field. I guess it depends on h= ow #5 is addressed. 7. If LMA configuration changes, can LMA notify MAG about the lo= cation update interval? Since ANI option is only in PBU and PBA, the introd= uction of Update-Timer suboption may be useful as a "push" message. So can = this be carried in Update Notification message? Kent --_000_CD85F32117029D4F9AEF48BDEF5536AB4DE180BAxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi. I believe the proposal is a good idea and would = be useful. In general, the draft looks good. The scheme allows the MAG to p= ropose the interval for location change notifications and LMA can override = that value. A few comments below.

 

1.        &n= bsp;   Title: Typo “Acess”

2.        &n= bsp;   Sect.1: Typos - “mobiility”

3.        &n= bsp;   Sect.4: Group Identifier: need description, though obvious= .

4.        &n= bsp;   The intent of the text, “then MAG behavior with resp= ect to updating the ANI values is left to implementation choices”, is= to state that MAG behavior is implemented in accordance to RFC 6757 since = response indicates LMA does not understand the ANI option?

5.        &n= bsp;   Is the Group ID a global value? What happens if handover h= appens between providers that happened to have the same adjacent group IDs?=

6.        &n= bsp;   Why not two byte Group ID? 64K groups is not sufficient? I= t would save 4 bytes by fitting in the Reserved field. I guess it depends o= n how #5 is addressed.

7.         &= nbsp;  If LMA configuration changes, can LMA notify MAG about the loca= tion update interval? Since ANI option is only in PBU and PBA, the introduc= tion of Update-Timer suboption may be useful as a “push” messag= e. So can this be carried in Update Notification message?

 

Kent

 

--_000_CD85F32117029D4F9AEF48BDEF5536AB4DE180BAxmbalnx03ciscoc_-- From nobody Sun Mar 2 22:23:19 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 716D41A0D1B for ; Sun, 2 Mar 2014 22:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 2yM3EE7O8wqB for ; Sun, 2 Mar 2014 22:23:14 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 973941A0B97 for ; Sun, 2 Mar 2014 22:23:14 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s2367ukM004978 for ; Mon, 3 Mar 2014 07:23:07 +0100 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 3 Mar 2014 07:14:42 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.208]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Mon, 3 Mar 2014 07:14:38 +0100 From: To: Thread-Topic: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc Thread-Index: AQHPNL53AiZxI040VE2gAJ9CYicf/5rO5YqtgAAAr/k= Date: Mon, 3 Mar 2014 06:14:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [80.229.76.233] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F432F57EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=15; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vLwSn76r - 929ce69495bc - 20140303 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/e0T00R_Lndu8BsNU6VvrzZKck9s Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 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: Mon, 03 Mar 2014 06:23:17 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F432F57EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have read the drat and I think that it is very useful and IMO can get the= status of a WG draft. However, I have some comments that I am listing belo= w, which mat be worked out after the draft gets the WG status: Comment_1: The draft considers the E2E QoS path as the path that goes throu= gh the IEEE 802.11 and PMIP domains. It will be useful to also discuss what= happens if the E2E QoS path goes beyond the IEEE 802.11 and PMIP domains. In order to realise the above you may discuss how the IEEE 802.11 QoS and P= MIP QoS signalling can be used together with an e2e QoS signalling protocol= , like RSVP. Comment_2: Agree with one of the comments of Pierrick, to map the Mean Data= Rate into a vendor specific option in PMIP QoS. Best regards, Georgios ________________________________ Van: netext [netext-bounces@ietf.org] namens Basavaraj Patil [bpatil1@gmail= .com] Verzonden: vrijdag 28 februari 2014 20:51 To: netext@ietf.org Onderwerp: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netex= t-pmip-qos-wifi-04 as WG doc Hello, The WG has discussed the following I-D: Mapping 802.11 QoS in a PMIPv6 Mobility Domain at several WG meetings. This is a consensus call to adopt this I-D as a working group document and = progress it as on the Informational track. Please respond to the following question; Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-= wifi-04 as a Netext WG document? Yes [ ] No [ ] -Chairs --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F432F57EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have read the drat and I think that it is very useful and IMO ca= n get the status of a WG draft. However, I have some comments that I am listing below, which mat be worked out after = the draft gets the WG status:

 

Comment_1: The draft considers the E2E QoS path as the path that g= oes through the IEEE 802.11 and PMIP domains. It will be useful to also discuss what happens if the E2E QoS path goes be= yond the IEEE 802.11 and PMIP domains.

In order to realise the above you may discuss how the IEEE 802.11 = QoS and PMIP QoS signalling can be used together with an e2e QoS signalling protocol, like RSVP.

 

Comment_2: Agree with one of the comments of Pierrick, to map the = Mean Data Rate into a vendor specific option in PMIP QoS.

 

Best regards,

Georgios

Van: netext [netext-bounces@ietf.org] name= ns Basavaraj Patil [bpatil1@gmail.com]
Verzonden: vrijdag 28 februari 2014 20:51
To: netext@ietf.org
Onderwerp: [netext] Consensus call to adopt I-D: draft-kaippallimali= l-netext-pmip-qos-wifi-04 as WG doc


Hello,

The WG has discussed the following I-D: 
Mapping 802.11 QoS in a PMIPv6 Mobility Dom=
ain
<draft-kaippallimalil-netext-pmip-qos-wifi-04>

at several WG meetings. 

This is a consensus call to adopt this I-D as a working group document= and progress it as on the Informational track.

Please respond to the following question;

Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmi= p-qos-wifi-04  as a Netext WG document?

Yes  [  ]
No   [  ]

-Chairs

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F432F57EXMBX23adutwent_-- From nobody Mon Mar 3 01:28: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 9327F1A0D3E for ; Mon, 3 Mar 2014 01:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 6jERfT8QMeax for ; Mon, 3 Mar 2014 01:28:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 663E61A07AF for ; Mon, 3 Mar 2014 01:28:49 -0800 (PST) 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 BEE16145; Mon, 03 Mar 2014 09:28:46 +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; Mon, 3 Mar 2014 09:27:48 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 09:28:11 +0000 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 3 Mar 2014 17:28:08 +0800 From: Xueli To: "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc Thread-Index: Ac82wtVJyeUIUhx8TvCBxpU3t6pEtQ== Date: Mon, 3 Mar 2014 09:28:07 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F81908@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.107.244] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448F81908nkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/7MMNWLFyQpK2ztbW0cnxMQAPX48 Subject: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 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: Mon, 03 Mar 2014 09:28:52 -0000 --_000_01FE63842C181246BBE4CF183BD159B448F81908nkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkNCg0KDQoNCkl0IGlzIHVzZWZ1bCBpbiBXTEFOIG5ldHdvcmsuDQoNCg0KDQpJIHN1cHBvcnQg dG8gYWRvcHQgaXQuDQoNCg0KDQpCUg0KDQpMaSBYdWUNCg0KDQoNCiAgKiAgIEZyb206IEJhc2F2 YXJhaiBQYXRpbCA8YnBhdGlsMSBhdCBnbWFpbC5jb208bWFpbHRvOmJwYXRpbDFARE9NQUlOLkhJ RERFTj4+DQogICogICBUbzogIm5ldGV4dCBhdCBpZXRmLm9yZzxtYWlsdG86bmV0ZXh0QERPTUFJ Ti5ISURERU4+IiA8bmV0ZXh0IGF0IGlldGYub3JnPG1haWx0bzpuZXRleHRARE9NQUlOLkhJRERF Tj4+DQogICogICBEYXRlOiBGcmksIDI4IEZlYiAyMDE0IDEzOjUxOjIwIC0wNjAwDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkhlbGxvLA0KDQpUaGUgV0cgaGFzIGRpc2N1 c3NlZCB0aGUgZm9sbG93aW5nIEktRDoNCg0KTWFwcGluZyA4MDIuMTEgUW9TIGluIGEgUE1JUHY2 IE1vYmlsaXR5IERvbWFpbg0KPGRyYWZ0LWthaXBwYWxsaW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13 aWZpLTA0Pg0KDQphdCBzZXZlcmFsIFdHIG1lZXRpbmdzLg0KDQpUaGlzIGlzIGEgY29uc2Vuc3Vz IGNhbGwgdG8gYWRvcHQgdGhpcyBJLUQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGFuZCBw cm9ncmVzcyBpdCBhcyBvbiB0aGUgSW5mb3JtYXRpb25hbCB0cmFjay4NCg0KUGxlYXNlIHJlc3Bv bmQgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbjsNCg0KUTogRG8geW91IHN1cHBvcnQgYWRvcHRp b24gb2YgdGhlIEktRCBkcmFmdC1rYWlwcGFsbGltYWxpbC1uZXRleHQtcG1pcC1xb3Mtd2lmaS0w NCAgYXMgYSBOZXRleHQgV0cgZG9jdW1lbnQ/DQoNClllcyAgWyAgXQ0KTm8gICBbICBdDQoNCi1D aGFpcnMNCg== --_000_01FE63842C181246BBE4CF183BD159B448F81908nkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi

 

It is useful in WLAN network.

 

I support to adopt it.

 

BR

Li Xue

 


Hello,

The WG has discussed the following I-D: 
Mapping 802.11 QoS in a PMIPv6 Mobility Dom=
ain
<draft-kaippallimalil-netext-pmip-qos-wifi-04>

at several WG meetings. 

This is a consensus call to adopt this I-D as a working group document= and progress it as on the Informational track.

Please respond to the following question;

Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmi= p-qos-wifi-04  as a Netext WG document?

Yes  [  ]
No   [  ]

-Chairs
--_000_01FE63842C181246BBE4CF183BD159B448F81908nkgeml504mbxchi_-- From nobody Mon Mar 3 01:44: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 8EABF1A0D69 for ; Mon, 3 Mar 2014 01:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 qp0eZwsn3OhG for ; Mon, 3 Mar 2014 01:44:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5E1A0D56 for ; Mon, 3 Mar 2014 01:44:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBR52844; Mon, 03 Mar 2014 09:44:12 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 09:43:47 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 09:44:11 +0000 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 3 Mar 2014 17:44:05 +0800 From: Xueli To: "netext@ietf.org" , "rpazhyan@cisco.com" Thread-Topic: [netext] Comments on draft-pazhyannur-netext-civic-location-ani-subopt-01 Thread-Index: Ac82w5w6Zb7oOsGYQi+f0jYaK2Z0gw== Date: Mon, 3 Mar 2014 09:44:04 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F8199C@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.107.244] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448F8199Cnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/TT-e2TaCJTwAh1ehObneTLFqwmY Subject: [netext] Comments on draft-pazhyannur-netext-civic-location-ani-subopt-01 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: Mon, 03 Mar 2014 09:44:19 -0000 --_000_01FE63842C181246BBE4CF183BD159B448F8199Cnkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkNCg0KDQoNCkkgcmVhZCB0aGlzIGRyYWZ0LiBJdCBpcyB1c2VmdWwgaW4gV0xBTiBuZXR3b3Jr LCBlc3BlY2lhbGx5IGZvciBzZXJ2aWNlIHByb3Zpc2lvbiBiYXNlZCB0aGUgbG9jYXRpb24gaW5m by4NCg0KDQoNCnNvbWUgY29tbWVudHM6DQoNCjEgc2VjdGlvbiAxDQoNClRoZSBNQUcgc2VuZHMg dGhlIGFib3ZlIGluZm9ybWF0aW9uIGlzIHNlbmQgdG8gdGhlIExNQTsNCg0KMiBzZWN0aW9uIDEN Ck1vYmxpaWxpdHkgLT4gTW9iaWxpdHkuDQoNCjMgR3JvdXAtSUQNCg0KSXQgaXMgcG9zc2libGUs IHRoYXQgYW4gQVAgY2FuIGJlbG9uZyB0byBtdWx0aXBsZSBHUk9VUHMgaW4gcHJhY3RpY2UuDQpJ biB0aGlzIHNjZW5hcmlvLCB0aGVyZSBhcmUgb3ZlcmxhcCBpc3N1ZXMgdGhhdCBzaG91bGQgYmUg Y29uc2lkZXJlZC4uDQpTdWNoIGFzIHdoaWNoIEdyb3VwLUlEIHNob3VsZCBiZSBub3RpZmllZCwg ZXRjLi4NCg0KIEkgc3VnZ2VzdCB0aGUgc2NlbmFyaW8gYWJvdXQgdGhlIHVzYWdlIGFuZCBkZXBs b3ltZW50IG9mIEdyb3VwLUlEIGNhbiBiZSBjbGFpcmZpZWQgaW4gdGhlIGRyYWZ0Lg0KDQpCZXN0 IFJlZ2FyZHMNCkxpIFh1ZQ0KDQoNCg0KDQo= --_000_01FE63842C181246BBE4CF183BD159B448F8199Cnkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi

 

I read this draft. It is useful in WLA= N network, especially for service provision based the location info.=

 

some comments:

 

1 section 1

 

The MAG sends the above information is send to the LMA;

 

2 section 1

Mobliility -> Mobility.

 

3 Group-ID

 

It is possible, that an AP can belong to multiple GROUPs in pr= actice.

In this scenario, there are overlap issues that should be= considered..

Such as which Group-ID should be notified, etc..= =

 
 I suggest the scenario about the usage and deployment = of Group-ID can be clairfied in the draft.
 
Best Regards
Li Xue
 
 

 

--_000_01FE63842C181246BBE4CF183BD159B448F8199Cnkgeml504mbxchi_-- From nobody Mon Mar 3 01:51:22 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 46BEB1A0DAC for ; Mon, 3 Mar 2014 01:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 MsMiAyEVdNfd for ; Mon, 3 Mar 2014 01:51:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E1FF21A0974 for ; Mon, 3 Mar 2014 01:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1393840268; x=1395049868; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=lB3hOo5H6M0IF62/DkRGlQk1iuRtboVKUfbdFh7iatI=; b=gfkdgkWZuE7gqCFo8kZR8fjUWf2g6U3umoPkTXZlhKjmQgQ/Hg7fhIIo E3JHNDh4PAqiHE+D7nOjeOUeMPYpGxvyVo+124l+UJm7S0oE2N9GTpWE+ +WcvrKMXmbmm3rJJ80j1tbsY9FcmLDqbrMNWm54JODKnJM+WZ1LaPNKPO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAhQFFOtJV2Z/2dsb2JhbABagwaBEsBOgR4WdIIsOlEBPkIlAgQTh3mcUK9vF45ghDgEmDySK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,576,1389744000"; d="scan'208";a="24437925" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 03 Mar 2014 09:51:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s239p70Y010680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 09:51:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 03:51:07 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: Logical Interface document - Reviews Thread-Index: AQHPNsYZ9CideX7TzkeRBOPQat7AVA== Date: Mon, 3 Mar 2014 09:51:06 +0000 Message-ID: In-Reply-To: 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.21.79.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <5577AC1BDD16A24AAE6B23078BC47444@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/KCFBt6Z4b3SvM1ZaRsBA5hmoESg Subject: [netext] Logical Interface document - Reviews 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: Mon, 03 Mar 2014 09:51:12 -0000 Folks, Please review the Logical interface document and provide any comments. We have addressed all the open issues and we plan to close this work very soon. Regards Sri On 2/11/14 4:27 PM, "Sri Gundavelli (sgundave)" wrote: >Hi Carlos, > >> BTW, can I ask what is the current status of >>draft-ietf-netext-logical-interface-support? I think we should also close >>that document. > >Absolutely. We need to close this work. Here is the document status. > >- There were around 6 technical issues that were reported in the issue >tracker >- We have discussed those issues some time back during the meeting and >presented the fixes. The AD (Jari) at that time also was present during >the presentation and agreed with the fixes >- We addresses those comments and updated the draft. Julien had additional >comments and that held the draft for a while >- In the last rev, we addresses Julien's comments (in fact it was his >text) that we adopted > >AFAIK, there is no open issue that the Authors are aware off. Raj wanted >to do a detailed review and provide some text/updates. Once we get that >feedback, we can WGLC. > >I think we need some good reviews on the draft to ensure the WG is >comfortable with the quality of the document. > > > > > >Regards >Sri > From nobody Mon Mar 3 02:37:42 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 02F921A0EA7 for ; Mon, 3 Mar 2014 02:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 1_RKTNYbEOJo for ; Mon, 3 Mar 2014 02:37:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B31A0E7C for ; Mon, 3 Mar 2014 02:37:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEE24257; Mon, 03 Mar 2014 10:37:28 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 10:37:02 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 10:37:26 +0000 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.106]) by dfweml705-chm.china.huawei.com ([169.254.7.50]) with mapi id 14.03.0158.001; Mon, 3 Mar 2014 02:37:16 -0800 From: John Kaippallimalil To: "karagian@cs.utwente.nl" , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc Thread-Index: AQHPNL579DyO6ERCKkePrDVEdU5/RprPbFSA//++ZzA= Date: Mon, 3 Mar 2014 10:37:15 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D9BF77E@dfweml703-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.132] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171D9BF77Edfweml703chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/NSeou8SpWsOLM-9DQWzWqVFjqac Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 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: Mon, 03 Mar 2014 10:37:41 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171D9BF77Edfweml703chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Georgios, Thanks a lot for the review and the comments. Some short responses inline. Best Regards, John From: netext [mailto:netext-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Monday, March 03, 2014 12:15 AM To: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallimalil-net= ext-pmip-qos-wifi-04 as WG doc Hi all, I have read the drat and I think that it is very useful and IMO can get the= status of a WG draft. However, I have some comments that I am listing belo= w, which mat be worked out after the draft gets the WG status: Comment_1: The draft considers the E2E QoS path as the path that goes throu= gh the IEEE 802.11 and PMIP domains. It will be useful to also discuss what= happens if the E2E QoS path goes beyond the IEEE 802.11 and PMIP domains. In order to realise the above you may discuss how the IEEE 802.11 QoS and P= MIP QoS signalling can be used together with an e2e QoS signalling protocol= , like RSVP. >> OK - I can mention the relationship between a connectivity session (or Q= oS) setup protocol - RSVP, WCS (3GPP 23.402). Not sure if I got the full intent here. Comment_2: Agree with one of the comments of Pierrick, to map the Mean Data= Rate into a vendor specific option in PMIP QoS. >> Agree - this needs to be described. Best regards, Georgios ________________________________ Van: netext [netext-bounces@ietf.org] namens Basavaraj Patil [bpatil1@gmail= .com] Verzonden: vrijdag 28 februari 2014 20:51 To: netext@ietf.org Onderwerp: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netex= t-pmip-qos-wifi-04 as WG doc Hello, The WG has discussed the following I-D: Mapping 802.11 QoS in a PMIPv6 Mobility Domain at several WG meetings. This is a consensus call to adopt this I-D as a working group document and = progress it as on the Informational track. Please respond to the following question; Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-= wifi-04 as a Netext WG document? Yes [ ] No [ ] -Chairs --_000_6561EABF52675C45BCDACA1B4D7AA1171D9BF77Edfweml703chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Georgios,

Thanks a lot for the revi= ew and the comments.

 <= /p>

Some  short response= s inline.

 <= /p>

Best Regards,<= /span>

John

 <= /p>

From: netext [= mailto:netext-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Monday, March 03, 2014 12:15 AM
To: netext@ietf.org
Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallima= lil-netext-pmip-qos-wifi-04 as WG doc

 

Hi all,

 =

I have read the drat and I think that it is very useful and IMO can= get the status of a WG draft. However, I have some comments that I am list= ing below, which mat be worked out after the draft gets the WG status:

&nbs= p;

Comment_1: The draft considers the E2E QoS path as the path that go= es through the IEEE 802.11 and PMIP domains. It will be useful to also= discuss what happens if the E2E QoS path goes beyond the IEEE 802.11 and PMIP domains.

In order to realise the above you may discuss how the IEEE 802.11 Q= oS and PMIP QoS signalling can be used together with an e2e QoS signalling = protocol, like RSVP.

>> O= K – I can mention the relationship between a connectivity session (or= QoS) setup protocol – RSVP, WCS (3GPP 23.402).

Not sure i= f I got the full intent here.

 = ;

&nbs= p;

Comment_2: Agree with one of the comments of Pierrick, to map the M= ean Data Rate into a vendor specific option in PMIP QoS.<= /p>

>> A= gree – this needs to be described.

&nbs= p;

Best regards,

Georgios

Van: netext [netext-bounces@ietf.o= rg] namens Basavaraj Patil [bpatil1@gmail.com]
Verzonden: vrijdag 28 februari 2014 20:51
To: netext@ietf.org
Onderwerp: [netext] Consensus call to adopt I-D: draft-kaippallimali= l-netext-pmip-qos-wifi-04 as WG doc

 

Hello,

 

The WG has discussed the fol= lowing I-D: 

Mapping 802.1=
1 QoS in a PMIPv6 Mobility Domain
<draft-kai=
ppallimalil-netext-pmip-qos-wifi-04>

 

at several WG meetings. = ;

 

This is a consensus call to = adopt this I-D as a working group document and progress it as on the Inform= ational track.

 

Please respond to the follow= ing question;

 

Q: Do you support adoption o= f the I-D draft-kaippallimalil-netext-pmip-qos-wifi-04  as a= Netext WG document?

 

Yes  [  ]

No   [  ]

 

-Chairs

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171D9BF77Edfweml703chmchi_-- From nobody Mon Mar 3 08:13:55 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 1F60F1A00B6 for ; Mon, 3 Mar 2014 08:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EDpg7qy5w5ff for ; Mon, 3 Mar 2014 08:13:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5471A0134 for ; Mon, 3 Mar 2014 08:13:45 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 8499C190B82; Mon, 3 Mar 2014 17:13:41 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 68821180042; Mon, 3 Mar 2014 17:13:41 +0100 (CET) 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; Mon, 3 Mar 2014 17:13:40 +0100 From: To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc Thread-Index: AQHPNL524B2NiLygsEetMqGW8gLv85rPjIJQ Date: Mon, 3 Mar 2014 16:13:41 +0000 Message-ID: <17302_1393863221_5314AA35_17302_3093_1_81C77F07008CA24F9783A98CFD706F71142092FA@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71142092FAPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.3.53017 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/e5X2LVRrVHh_lpzH8PTfrhLchz0 Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 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: Mon, 03 Mar 2014 16:13:48 -0000 --_000_81C77F07008CA24F9783A98CFD706F71142092FAPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support this document, as I said in the review I sent a couple of days ag= o, I think that this draft is a good companion document of draft-ietf-netex= t-pmip6-qos; it clarifies well how to use the option on a Wi-Fi link. BR, Pierrick De : netext [mailto:netext-bounces@ietf.org] De la part de Basavaraj Patil Envoy=E9 : vendredi 28 f=E9vrier 2014 20:51 =C0 : netext@ietf.org Objet : [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-p= mip-qos-wifi-04 as WG doc Hello, The WG has discussed the following I-D: Mapping 802.11 QoS in a PMIPv6 Mobility Domain at several WG meetings. This is a consensus call to adopt this I-D as a working group document and = progress it as on the Informational track. Please respond to the following question; Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-= wifi-04 as a Netext WG document? Yes [ ] No [ ] -Chairs ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71142092FAPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p> 

I support this document, as =
I said in the review I sent a couple of days ago, I think that this draft i=
s a good companion document of draft-ietf-netext-pmip6-qos; it clarifies we=
ll how to use the option on a Wi-Fi link.
 

BR,


Pierrick



 =
;








De : nete=
xt [mailto:netext-bounces@ietf.org]
De la part de Basavaraj Patil

Envoy=E9 : vendredi 28 f=E9vrier 2014 20:51

=C0 : netext@ietf.org

Objet : [netext] Consensus call to adopt I-D: draft-kaippallima=
lil-netext-pmip-qos-wifi-04 as WG doc






 






 






Hello,






 






The WG has discussed the following I-D: 






 


Mapping 802.1=
1 QoS in a PMIPv6 Mobility Domain


<draft-kai=
ppallimalil-netext-pmip-qos-wifi-04> 






 




at several WG meetings. 




 






This is a consensus call to adopt this I-D as a work=
ing group document and progress it as on the Informational track.






 






Please respond to the following question;=







 






Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-wi=
fi-04  as a Netext WG document?








 






Yes  [  ]






No   [  ]






 






-Chairs






 










______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71142092FAPEXCVZYM12corpo_-- From nobody Tue Mar 4 16:16: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 F2F8D1A0088; Tue, 4 Mar 2014 16:16:01 -0800 (PST) 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 2CZ6DWVETRlK; Tue, 4 Mar 2014 16:16:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD31A0040; Tue, 4 Mar 2014 16:16:00 -0800 (PST) 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.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140305001600.16743.73609.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 16:16:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/VlpWxGoQVALzGbOoBlIi0seYqt8 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-09.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, 05 Mar 2014 00:16:02 -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 : Logical Interface Support for multi-mode IP Hosts Authors : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-09.txt Pages : 19 Date : 2014-03-04 Abstract: A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-logical-interface-support-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 6 13:11:19 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 F15281A0110 for ; Thu, 6 Mar 2014 13:11:15 -0800 (PST) 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 MUpkCAx9FoEn for ; Thu, 6 Mar 2014 13:11:14 -0800 (PST) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id AF9121A00F1 for ; Thu, 6 Mar 2014 13:11:14 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id i4so3183953oah.38 for ; Thu, 06 Mar 2014 13:11:10 -0800 (PST) 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=CNzCrno/cFpoQtxA8cYPjTMfiKoZONcXAPIoim7DAYY=; b=YP3vGdntZVZFiId9bi8hE+DF8C8LmoUCv3c2BiaV0sN1CgD+bGEl9doAXpdjxd8gJV qqQawV1BrnXEg9NmZXbaoRMl3E8IktNwnISjKJsbidIFvbMiHje38rIanuw/eZJiJjIE FJxhQyir8asMkajgEq+1iHHUuzDts05ttVqKN/O6uA78IZ7mGf8NrZyteMD2XVfi9V6E 2pJQtNHgnsEHSD58JK9xPRmL3eQG0juhaUGPq/k5Rc7Dr2b97wVe6wP7Uona01aOU9Sq /9LrpJ9nRKRwII1rPNLeDv1gKV9HT01CXNWmFll0w4YSavgA5/cg/3/8WVTnyGBQI2Yq fxGQ== MIME-Version: 1.0 X-Received: by 10.60.132.12 with SMTP id oq12mr7577968oeb.42.1394140270588; Thu, 06 Mar 2014 13:11:10 -0800 (PST) Received: by 10.182.161.42 with HTTP; Thu, 6 Mar 2014 13:11:10 -0800 (PST) Date: Thu, 6 Mar 2014 15:11:10 -0600 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b47286e9878e504f3f693fb Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Ypd3cfAW9dxP8RgqxXzgdnSk9tc Cc: draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: [netext] Way forward for I-D: draft-ietf-netext-logical-interface-support 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, 06 Mar 2014 21:11:16 -0000 --047d7b47286e9878e504f3f693fb Content-Type: text/plain; charset=ISO-8859-1 Hello, The logical interface support I-D (Logical Interface Support for multi-mode IP Hosts ) has been discussed by the Netext WG almost since the time the WG was formed. The key objective of this document was to provide information of how to maintain session continuity within a PMIP6 domain when the mobile device does a handover across access technologies. The suggestion was to use a virtual/logical interface and this I-D was capturing information about such interfaces. The logical or virtual interface is a fairly well understood concept today and is available in a host of different operating systems today (as the document also mentions). The relevance and need for this I-D in my opinion has diminished and it is no longer needed. I do not see an essential requirement or clamoring from the developer community for such an I-D. Additionally the functionality of a virtual/logical interface is best left to individual operating systems. The document itself has improved in quality over 9 revisions. I appreciate the effort and work put in this I-D by the authors. But IMHO I do not see value or anything to be gained by progressing this I-D as an Informational RFC. The WG is better served by working on documents that solve a problem which addresses deployment or enhances functionality. We need to make a decision about work items which may have made sense when we initiatally began but have evolved subsequently. My recommendation w.r.t this I-D is to drop it from the WG. The authors could consider asking the int-area if they see value in progressing this work. -Raj -- Basavaraj Patil --047d7b47286e9878e504f3f693fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

The lo= gical interface support I-D (Logical Interface Support for multi-mode IP Ho= sts <draft-ietf-netext-logical-interface-support>) has been discussed= by the Netext WG almost since the time the WG was formed. The key objectiv= e of this document was to provide information of how to maintain session co= ntinuity within a PMIP6 domain when the mobile device does a handover acros= s access technologies. The suggestion was to use a virtual/logical interfac= e and this I-D was capturing information about such interfaces.

The logical or virtual interface is a fairly well under= stood concept today and is available in a host of different operating syste= ms today (as the document also mentions). The relevance and need for this I= -D in my opinion has diminished and it is no longer needed.=A0
I do not see an essential requirement or clamoring from the developer = community for such an I-D. Additionally the functionality of a virtual/logi= cal interface is best left to individual operating systems.=A0

The document itself has improved in quality over 9 revisions= . I appreciate the effort and work put in this I-D by the authors. But IMHO= I do not see value or anything to be gained by progressing this I-D as an = Informational RFC. The WG is better served by working on documents that sol= ve a problem which addresses deployment or enhances functionality. We need = to make a decision about work items which may have made sense when we initi= atally began but have evolved subsequently.=A0

My recommendation w.r.t this I-D is to drop it from the= WG. The authors could consider asking the int-area if they see value in pr= ogressing this work.

-Raj

--
Basavaraj Patil
--047d7b47286e9878e504f3f693fb-- From nobody Mon Mar 10 06:12:27 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 C03891A044D; Mon, 10 Mar 2014 06:12:21 -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 WqV4EyZOiW-K; Mon, 10 Mar 2014 06:12:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 769301A0439; Mon, 10 Mar 2014 06:12:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140310131220.17239.33561.idtracker@ietfa.amsl.com> Date: Mon, 10 Mar 2014 06:12:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/mS6uAQvvuwQ3MOesv3Bw4YISg7U Cc: netext@ietf.org Subject: [netext] Last Call: (Quality of Service Option for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.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: Mon, 10 Mar 2014 13:12:22 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Quality of Service Option for Proxy Mobile IPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Mar 12 11:43:02 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 C80BB1A075D for ; Wed, 12 Mar 2014 11:42:49 -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 vEkTsRAIi6RS for ; Wed, 12 Mar 2014 11:42:48 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C770E1A0758 for ; Wed, 12 Mar 2014 11:42:48 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so10339911obc.14 for ; Wed, 12 Mar 2014 11:42:42 -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=rWZ/Rm0RaB2e0sH2FnkeFP+CzAAvXbVMdnhokCuM0/U=; b=MkceMak0ebVRpyl4JNzjbb1G7qpax+QUixVksLIlC5LjzgIMpNYYl8rpQl6IVEGTAP WzG98bxwcColrIrxEwLSUWIocd+U/C6KyIGhgwWzJbfsl/uPqLWGIp5j3MEhGLjNRcxT mvXTDeVQILJnoPyiiSRO9TJPUEwquDWS7ZsBsqOqK9smSdAG1Nl45yp0ZTxo48Dyoppf tDuANIEQ7+wQQ7nI3VKVyBEc8MKVssaWz9lEZMcIxqg8gsdOxY3wG8bipYDzpRiadhLX Qr/VcxgFLn0ht1LYOa4EswRCGLK7dBE/F5EvhWLjKEfJwYhEV0gyoxkNwWaI7Y/4vnF5 IF4A== MIME-Version: 1.0 X-Received: by 10.60.233.227 with SMTP id tz3mr35680377oec.3.1394649762498; Wed, 12 Mar 2014 11:42:42 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Wed, 12 Mar 2014 11:42:42 -0700 (PDT) Date: Wed, 12 Mar 2014 13:42:42 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a1136ae86ae62a704f46d3372 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ZpZbUnkXnGUO5mL7rxQMy2Wymtk Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: [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: Wed, 12 Mar 2014 18:42:50 -0000 --001a1136ae86ae62a704f46d3372 Content-Type: text/plain; charset=ISO-8859-1 Hello, This is the working group last call for I-D: Separation of Control and User Plane for Proxy Mobile IPv6 < draft-ietf-netext-pmip-cp-up-separation-02.txt>. This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs --001a1136ae86ae62a704f46d3372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

This is the working group last c= all for I-D:=A0Separa= tion of Control and User Plane for Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-sep= aration-02.txt>.

This I-D is intended to be progressed as a standards tr= ack document.=A0
Please review and post your comments on the mail= ing list.
The last call will expire on March 27th, 14.=A0

-Chairs

--001a1136ae86ae62a704f46d3372-- From nobody Wed Mar 12 12:45:17 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 174C21A04A4; Wed, 12 Mar 2014 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 ogtdaXzqnjGd; Wed, 12 Mar 2014 12:45:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4F91A0479; Wed, 12 Mar 2014 12:45:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8C9C37FC39F; Wed, 12 Mar 2014 12:45:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140312194500.8C9C37FC39F@rfc-editor.org> Date: Wed, 12 Mar 2014 12:45:00 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/BefEiSHq6buHUlvjgo0BmvEnwmk Cc: drafts-update-ref@iana.org, netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 7148 on Prefix Delegation Support 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: Wed, 12 Mar 2014 19:45:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7148 Title: Prefix Delegation Support for Proxy Mobile IPv6 Author: X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos Status: Standards Track Stream: IETF Date: March 2014 Mailbox: zhou.xingyue@zte.com.cn, jouni.nospam@gmail.com, carlw@mcsr-labs.org, sgundave@cisco.com, cjbc@it.uc3m.es Pages: 27 Characters: 60422 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-pd-pmip-14.txt URL: http://www.rfc-editor.org/rfc/rfc7148.txt This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. 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 Mon Mar 17 14:48:42 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 211B51A031F for ; Mon, 17 Mar 2014 14:48:40 -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 XE1jDBRSXQXs for ; Mon, 17 Mar 2014 14:48:38 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A467D1A0303 for ; Mon, 17 Mar 2014 14:48:38 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i4so6404007oah.29 for ; Mon, 17 Mar 2014 14:48:30 -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=uE61yYea9HgEltZzMdocyM+whBWkJWHrxhqKC+FrbCo=; b=JC46ImHO8KY3W3Bl/P5OMa93w4+aCpgW5k4sB0kETojTyr4rBn7+OuED12tmVnWtxX +ra8HjSG8cqSfrJlG/wD+7C6Le4CmFgO0xr5DolTccKejAdPtwnG3T6MV78OzHIkQFP6 u3vonfIZy3MUCejKeIqKPbZipEPYORBkzU0erFDd4A6g76YWwcEOlS/fKndTUalToE7A YrUURJ6gu0e6LaoueoDdyOXuOaUuwE0e2QyV/BL1R6YmZMgDBhGxqYKl07/xEOmRt9l8 OX3Cy1wDFIUaKajPyA23lVBp1QlWVQzfkS0c2A23R/15DouHw1HVQVbO/46z9UoswaJ0 fN/A== MIME-Version: 1.0 X-Received: by 10.182.87.42 with SMTP id u10mr22547766obz.22.1395092910457; Mon, 17 Mar 2014 14:48:30 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Mon, 17 Mar 2014 14:48:30 -0700 (PDT) Date: Mon, 17 Mar 2014 17:48:30 -0400 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e013cba625b488b04f4d461e6 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/XTBz0j87WWOCaHMQJ0_8DN5zQUM Cc: draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org Subject: [netext] Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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: Mon, 17 Mar 2014 21:48:40 -0000 --089e013cba625b488b04f4d461e6 Content-Type: text/plain; charset=ISO-8859-1 Hello, A few comments following my review of this I-D: 1. A lot of the 3GPP concepts are covered in this document. And there is not enough explanation of things like the APN etc. I would recommend referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP contexts etc. 2. It is not clear as to which EAP messages would include the attributes such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier for implementers if it was clearly spelled out in a message flow. 3. The attributes to co-relate sessions when moving between 3/4G networks and WiFi no doubt are useful. But I am not sure if this is sufficient to enable seamless mobility between these disparate networks. Maybe it would be useful to clarify that these attributes are required in the context of an overall 3/4G<->WiFi mobility design. 4. The following statement in Sec 5.3 is not clear as to its intent and the outcome : "For Multiple PDN Connections only, a Mobile Node uses this attribute to indicate whether it wishes the connectivity type to be Non- Seamless WLAN Offload or EPC." 5. Lastly I am wondering if it is worth trying to solve multiple problems such as APN indication, Mobility between networks and Simultaneous connections to different APNs in this I-D. I see the APN indication and simulatenous connections to different APNs as something that would be required in WiFI networks. Maybe the I-D would be simplified if it did not tackle the seamless mobility aspect and drop the associated attributes proposed. -Raj -- Basavaraj Patil --089e013cba625b488b04f4d461e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

A few = comments following my review of this I-D:

1. A lot= of the 3GPP concepts are covered in this document. And there is not enough= explanation of things like the APN etc. I would recommend referencing RFC6= 459 (Secs 2, 3 and 4) for a better overview of APNs, PDP contexts etc.

2. It is not clear as to which EAP messages would inclu= de the attributes such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. = Would be easier for implementers if it was clearly spelled out in a message= flow.

3. The attributes to co-relate sessions when moving bet= ween 3/4G networks and WiFi no doubt are useful. But I am not sure if this = is sufficient to enable seamless mobility between these disparate networks.= Maybe it would be useful to clarify that these attributes are required in = the context of an overall 3/4G<->WiFi mobility design.

4. The following statement in Sec 5.3 is not clear as t= o its intent and the outcome : "For Multiple PDN Connections only, a M= obile Node uses this attribute
=A0 =A0to indicate whether it wish= es the connectivity type to be Non-
=A0 =A0Seamless WLAN Offload or EPC."

5.= Lastly I am wondering if it is worth trying to solve multiple problems suc= h as APN indication, Mobility between networks and Simultaneous connections= to different APNs in this I-D. I see the APN indication and simulatenous c= onnections to different APNs as something that would be required in WiFI ne= tworks. Maybe the I-D would be simplified if it did not tackle the seamless= mobility aspect and drop the associated attributes proposed.

-Raj

--
Basavaraj Patil
--089e013cba625b488b04f4d461e6-- From nobody Tue Mar 18 22:09:22 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 AE1C01A049E for ; Tue, 18 Mar 2014 22:09:20 -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 gEtgGuxFTbwM for ; Tue, 18 Mar 2014 22:09:18 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0D27E1A046F for ; Tue, 18 Mar 2014 22:09:17 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id t19so10706769igi.0 for ; Tue, 18 Mar 2014 22:09:09 -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=6HcqrXq18tjx2vZynhaEjzgoCdvn3kAUWRtmVyk9K+E=; b=dCljqOr6aJuS2YVNLrSAwUEAoVAGMfn9QX3sPv1V+9prSPhWLyr/W+r4B8jYQlXS/l jtzqBdZO/rDEiw/hizMCINa7Mh9c3M3sbsp3Q6zJgeQ1selk7aBUEWtimYtK7iiWWVAo heh/3wLmCZxa/DKCRFX2L/WhVLdrO5fj/ihMNsvnTy/7bPGtg2q6gRHtVnZiC7Ylqvx9 yWAA8D0XjRkBAh04ktL4D30fnYYtQJjFchzmy/Y656XeNLM7ve+/2QOINwjEFe5aWwgb SrBWIP3WHDZgtEXtTsLb3k+RCjqQN4+NU564tRTseUQiZljN6SUtzUWWdz5w6fS5mE4n Yltg== MIME-Version: 1.0 X-Received: by 10.50.33.11 with SMTP id n11mr23476213igi.0.1395205749331; Tue, 18 Mar 2014 22:09:09 -0700 (PDT) Received: by 10.64.159.40 with HTTP; Tue, 18 Mar 2014 22:09:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Mar 2014 22:09:09 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e0153873e13dcdc04f4eea749 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/C5_25JG89tLxEAEg_OF9hzchEBY Subject: [netext] Fwd: FW: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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, 19 Mar 2014 05:09:21 -0000 --089e0153873e13dcdc04f4eea749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- On 3/17/14, 7:13 PM, "Koodli, Rajeev" wrote: > >Hi Raj, > >Thanks for the review. Responses inline: > >From: Basavaraj Patil > >Date: Monday, March 17, 2014 at 2:48 PM >To: "netext@ietf.org" >> >Cc: >"draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.orgf-netext-wifi-epc-eap-attributes@tools.ietf.org>" >f-netext-wifi-epc-eap-attributes@tools.ietf.org>> >Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 >Resent-To: Rajeev Koodli >>, >> > > >Hello, > >A few comments following my review of this I-D: > >1. A lot of the 3GPP concepts are covered in this document. And there is >not enough explanation of things like the APN etc. I would recommend >referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP >contexts etc. > >Rajeev> okay, good idea. > > >2. It is not clear as to which EAP messages would include the attributes >such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier >for implementers if it was clearly spelled out in a message flow. > >Rajeev> we do specify that in statements such as "This attribute can be >included in any of the EAP Request message that > are integrity protected, such as EAP-Response/AKA-Challenge.". Since >these are just the attributes, it is up to the implementations to >incorporate them in the appropriate EAP messages. However, perhaps it >would be better to indicate specific EAP messages which can be used to >carry the corresponding attributes. Will take a look. > > >3. The attributes to co-relate sessions when moving between 3/4G networks >and WiFi no doubt are useful. But I am not sure if this is sufficient to >enable seamless mobility between these disparate networks. Maybe it would >be useful to clarify that these attributes are required in the context of >an overall 3/4G<->WiFi mobility design. > >Rajeev> Right, the attribute itself is not sufficient, but is an enabler. > > >4. The following statement in Sec 5.3 is not clear as to its intent and >the outcome : "For Multiple PDN Connections only, a Mobile Node uses this >attribute > to indicate whether it wishes the connectivity type to be Non- > Seamless WLAN Offload or EPC." > >Rajeev> So, both Offload and EPC connectivity choices come into play only >when multiple PDN connectivity is supported. (It is one or the other for >single PDN connectivity) > > >5. Lastly I am wondering if it is worth trying to solve multiple problems >such as APN indication, Mobility between networks and Simultaneous >connections to different APNs in this I-D. I see the APN indication and >simulatenous connections to different APNs as something that would be >required in WiFI networks. Maybe the I-D would be simplified if it did >not tackle the seamless mobility aspect and drop the associated >attributes proposed. > >Rajeev> I assume by =B3Mobility between networks=B2 you mean the attribute >AT_HANDOVER_SESSION_ID. This is an optional attribute which can be useful >in determining the previous attachment of the UE. Other than that, there >are no other attributes. > >Thanks. > >-Rajeev > > >-Raj > >-- >Basavaraj Patil --089e0153873e13dcdc04f4eea749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



--------= -- Forwarded message ----------


On 3/17/14, 7:13 PM, "Koodli, Rajeev" <rajeev.koodli@intel.com> wrote:

>
>Hi Raj,
>
>Thanks for the review. Responses inline:
>
>From: Basavaraj Patil <bpatil1@= gmail.com<mailto:bpatil1@gmail.= com>>
>Date: Monday, March 17, 2014 at 2:48 PM
>To: "netext@ietf.org<mai= lto:netext@ietf.org>"
><netext@ietf.org<mailto:netext@ietf.org>>
>Cc:
>"draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org<= mailto:draft-iet
>f-ne= text-wifi-epc-eap-attributes@tools.ietf.org>"
><draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org<ma= ilto:draft-iet
>f-ne= text-wifi-epc-eap-attributes@tools.ietf.org>>
>Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 >Resent-To: Rajeev Koodli
><rajeev.koodli@intel.com<= /a><mailto:rajeev.koodli@inte= l.com>>,
><valmikam@gmail.com<mai= lto:valmikam@gmail.com>>
>
>
>Hello,
>
>A few comments following my review of this I-D:
>
>1. A lot of the 3GPP concepts are covered in this document. And there i= s
>not enough explanation of things like the APN etc. I would recommend >referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PD= P
>contexts etc.
>
>Rajeev> okay, good idea.
>
>
>2. It is not clear as to which EAP messages would include the attribute= s
>such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easie= r
>for implementers if it was clearly spelled out in a message flow.
>
>Rajeev> we do specify that in statements such as "This at= tribute can be
>included in any of the EAP Request message that
> =A0 are integrity protected, such as EAP-Response/AKA-Challenge."= . Since
>these are just the attributes, it is up to the implementations to
>incorporate them in the appropriate EAP messages. However, perhaps it >would be better to indicate specific EAP messages which can be used to<= br> >carry the corresponding attributes. Will take a look.
>
>
>3. The attributes to co-relate sessions when moving between 3/4G networ= ks
>and WiFi no doubt are useful. But I am not sure if this is sufficient t= o
>enable seamless mobility between these disparate networks. Maybe it wou= ld
>be useful to clarify that these attributes are required in the context = of
>an overall 3/4G<->WiFi mobility design.
>
>Rajeev> Right, the attribute itself is not sufficient, but is = an enabler.
>
>
>4. The following statement in Sec 5.3 is not clear as to its intent and=
>the outcome : "For Multiple PDN Connections only, a Mobile Node us= es this
>attribute
> =A0 to indicate whether it wishes the connectivity type to be Non-
> =A0 Seamless WLAN Offload or EPC."
>
>Rajeev> So, both Offload and EPC connectivity choices come int= o play only
>when multiple PDN connectivity is supported. (It is one or the other fo= r
>single PDN connectivity)
>
>
>5. Lastly I am wondering if it is worth trying to solve multiple proble= ms
>such as APN indication, Mobility between networks and Simultaneous
>connections to different APNs in this I-D. I see the APN indication and=
>simulatenous connections to different APNs as something that would be >required in WiFI networks. Maybe the I-D would be simplified if it did<= br> >not tackle the seamless mobility aspect and drop the associated
>attributes proposed.
>
>Rajeev> I assume by =B3Mobility between networks=B2 you mean t= he attribute
>AT_HANDOVER_SESSION_ID. This is an optional attribute which can be usef= ul
>in determining the previous attachment of the UE. Other than that, ther= e
>are no other attributes.
>
>Thanks.
>
>-Rajeev
>
>
>-Raj
>
>--
>Basavaraj Patil


--089e0153873e13dcdc04f4eea749-- From nobody Thu Mar 20 07:54: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 B8C7A1A03EF for ; Thu, 20 Mar 2014 07:54:48 -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 Ev7SBHgf7Tep for ; Thu, 20 Mar 2014 07:54:46 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 087B11A08E4 for ; Thu, 20 Mar 2014 07:54:32 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id eb12so1020145oac.2 for ; Thu, 20 Mar 2014 07:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w1QjvblV0dDtjLVbO4DzQW4KgS1Q5zKLitagAUPJppw=; b=EVhzSN3NJCnA1HaSikQDAUfDvEDKsA95XpGqeV8dF8e/KL8vseynkFZT1wkQgZxicS 93RsTxYpfODl+OfYc4uNGEauY9EIyWPuAQTPtfHMDfZV/TdOHd7mdMW23yvE++hXbh2s r00sJKFaqPeiSmkTCh1QVY7yhGcNVxvKNjsBIjxS57QAkThF8CfPTHfrdojIUpNe6R51 onlNPLykz9T62g9ZO56by8SMcQunPVlGp6okz6bzgUiiTcYro2MLM5E4n0NYIzTPP3EI j074WfrIfIUfsHIPfWl5hG2AekpE3/aBNxi1hPUv2jUYg5kYMEHUP8/Ro5b4r05Ei7yC DWvw== MIME-Version: 1.0 X-Received: by 10.183.3.102 with SMTP id bv6mr7592340obd.18.1395327263981; Thu, 20 Mar 2014 07:54:23 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Thu, 20 Mar 2014 07:54:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Mar 2014 10:54:23 -0400 Message-ID: From: Basavaraj Patil To: "Koodli, Rajeev" Content-Type: multipart/alternative; boundary=001a1134a45cea4b7604f50af1b4 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/K6JecIB7b2XsPXeSmuvAlvGFnKE Cc: "netext@ietf.org" , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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, 20 Mar 2014 14:54:49 -0000 --001a1134a45cea4b7604f50af1b4 Content-Type: text/plain; charset=ISO-8859-1 Thanks for your responses Rajeev. Please send an updated I-D. Also note that there are editorial issues as well which I did not cover. You may want to take care of them as well when you revise the I-D. -Raj On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev wrote: > > Hi Raj, > > Thanks for the review. Responses inline: > > From: Basavaraj Patil > Date: Monday, March 17, 2014 at 2:48 PM > To: "netext@ietf.org" > Cc: "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" < > draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org> > Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 > Resent-To: Rajeev Koodli , > > > Hello, > > A few comments following my review of this I-D: > > 1. A lot of the 3GPP concepts are covered in this document. And there is > not enough explanation of things like the APN etc. I would recommend > referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP > contexts etc. > > Rajeev> okay, good idea. > > > 2. It is not clear as to which EAP messages would include the attributes > such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier > for implementers if it was clearly spelled out in a message flow. > > Rajeev> we do specify that in statements such as "This attribute can be > included in any of the EAP Request message that > are integrity protected, such as EAP-Response/AKA-Challenge.". Since > these are just the attributes, it is up to the implementations to > incorporate them in the appropriate EAP messages. However, perhaps it would > be better to indicate specific EAP messages which can be used to carry the > corresponding attributes. Will take a look. > > > 3. The attributes to co-relate sessions when moving between 3/4G > networks and WiFi no doubt are useful. But I am not sure if this is > sufficient to enable seamless mobility between these disparate networks. > Maybe it would be useful to clarify that these attributes are required in > the context of an overall 3/4G<->WiFi mobility design. > > Rajeev> Right, the attribute itself is not sufficient, but is an > enabler. > > > 4. The following statement in Sec 5.3 is not clear as to its intent and > the outcome : "For Multiple PDN Connections only, a Mobile Node uses this > attribute > to indicate whether it wishes the connectivity type to be Non- > Seamless WLAN Offload or EPC." > > Rajeev> So, both Offload and EPC connectivity choices come into play > only when multiple PDN connectivity is supported. (It is one or the other > for single PDN connectivity) > > > 5. Lastly I am wondering if it is worth trying to solve multiple > problems such as APN indication, Mobility between networks and Simultaneous > connections to different APNs in this I-D. I see the APN indication and > simulatenous connections to different APNs as something that would be > required in WiFI networks. Maybe the I-D would be simplified if it did not > tackle the seamless mobility aspect and drop the associated attributes > proposed. > > Rajeev> I assume by "Mobility between networks" you mean the attribute > AT_HANDOVER_SESSION_ID. This is an optional attribute which can be useful > in determining the previous attachment of the UE. Other than that, there > are no other attributes. > > Thanks. > > -Rajeev > > > -Raj > > -- > Basavaraj Patil > -- Basavaraj Patil --001a1134a45cea4b7604f50af1b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for your responses Rajeev. Please send an = updated I-D. Also note that there are editorial issues as well which I did = not cover. You may want to take care of them as well when you revise the I-= D.

-Raj


On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev <rajeev.koodli@intel.com> wrote:

Hi Raj,

Thanks for the review. Responses inline:

From: Basavaraj Patil <bpatil1@gmail.com> Date: Monday, March 17, 2014 at 2:4= 8 PM
To: "netext@ietf.org" <netext@ietf.org>
Cc: "draft-= ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" <draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org> Subject: Review of I-D: draft-ietf-= netext-wifi-epc-eap-attributes-06
Resent-To: Rajeev Koodli <rajeev.koodli@intel.= com>, <va= lmikam@gmail.com>


Hello,

A few comments following my review of this I-D:

1. A lot of the 3GPP concepts are covered in this document. And there = is not enough explanation of things like the APN etc. I would recommend ref= erencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP conte= xts etc.

Rajeev> okay, good idea.
=


2. It is not clear as to which EAP messages would include the attribut= es such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier= for implementers if it was clearly spelled out in a message flow.

Rajeev> we do specify that in s= tatements such as "This attribute can be= included in any of the EAP Request message that
  &nb= sp;are integrity protected, such as EAP-Response/AKA-Challenge.". Since these are just the attributes, it is up to the implementations to = incorporate them in the appropriate EAP messages. However, perhaps it would be better to indicate specific EAP= messages which can be used to carry the corresponding attributes. Will tak= e a look.


3. The attributes to co-relate sessions when moving between 3/4G netwo= rks and WiFi no doubt are useful. But I am not sure if this is sufficient t= o enable seamless mobility between these disparate networks. Maybe it would= be useful to clarify that these attributes are required in the context of an overall 3/4G<->WiFi mob= ility design.

Rajeev> Right, the attribute it= self is not sufficient, but is an enabler. 


4. The following statement in Sec 5.3 is not clear as to its int= ent and the outcome : "For Multiple PDN Connections only, a Mobile Nod= e uses this attribute
   to indicate whether it wishes the connectivity type= to be Non-
   Seamless WLAN Offload or EPC."

Rajeev> So, both Offload and EP= C connectivity choices come into play only when multiple PDN connectivity i= s supported. (It is one or the other for single PDN connectivity)
 

5. Lastly I am wondering if it is worth trying to solve multiple probl= ems such as APN indication, Mobility between networks and Simultaneous conn= ections to different APNs in this I-D. I see the APN indication and simulat= enous connections to different APNs as something that would be required in WiFI networks. Maybe the I-D would = be simplified if it did not tackle the seamless mobility aspect and drop th= e associated attributes proposed.

Rajeev> I assume by “Mobi= lity between networks” you mean the attribute AT_HANDOVER_SESSION_ID. This is an optional attribute wh= ich can be useful in determining the previous attachment of the UE. Other than that, there are no other att= ributes.

Thanks.

-Rajeev


-Raj

--
Basavaraj Patil



--
Basavaraj Pa= til
--001a1134a45cea4b7604f50af1b4-- From nobody Thu Mar 20 10:31:25 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 75B681A07C1 for ; Thu, 20 Mar 2014 10:31:23 -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 mWRq6D1BZJEC for ; Thu, 20 Mar 2014 10:31:19 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 402CF1A07F6 for ; Thu, 20 Mar 2014 10:31:19 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so1251164iec.9 for ; Thu, 20 Mar 2014 10:31:10 -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=RsdL5TcIQtJ3x0XOfaA3R5wW2yN+oJZSYxipAnDsVzs=; b=DEDaybYICKWL4yu7Kdtc4byUm8biqk3O0MArMtwe6iYdV81uu7heLVUIWVPSF7+kug BFz+XPQ8mnDtXofpiVCYNh6Guecs4iTPOCh8tpzV/q3dJCnTd4pIY6RB+j1JnYKQy+sz 4hM58Y86BpRxhwja6vfc76K4CtlzYl31xIUpV9EfIg00VO26VVeDc3h+v5jO0czx37GE xjpyckXhG+qbb+xE78gkyNFdbl73t6mtNkKl5D+9fBeUhfe5pMcZGvbaolApsjbI3pRQ rxXjYe4RE+R1KCnh8Gt9M6RiZUQMdR94w9bWIvAQNijpDQ9MV3BHSpMEyRNAiS8n5mD3 LnMA== MIME-Version: 1.0 X-Received: by 10.50.117.69 with SMTP id kc5mr32293219igb.25.1395336670151; Thu, 20 Mar 2014 10:31:10 -0700 (PDT) Received: by 10.64.159.40 with HTTP; Thu, 20 Mar 2014 10:31:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Mar 2014 10:31:10 -0700 Message-ID: From: Rajeev Koodli To: Basavaraj Patil Content-Type: multipart/alternative; boundary=e89a8f643d1091258304f50d22cd Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ZR1b22MRi7FG063_B_5CcZlojfo Cc: "Koodli, Rajeev" , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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, 20 Mar 2014 17:31:23 -0000 --e89a8f643d1091258304f50d22cd Content-Type: text/plain; charset=ISO-8859-1 Okay. Where can I find the editorial issues? :) -Rajeev On Thu, Mar 20, 2014 at 7:54 AM, Basavaraj Patil wrote: > > Thanks for your responses Rajeev. Please send an updated I-D. Also note > that there are editorial issues as well which I did not cover. You may want > to take care of them as well when you revise the I-D. > > -Raj > > > On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev wrote: > >> >> Hi Raj, >> >> Thanks for the review. Responses inline: >> >> From: Basavaraj Patil >> >> Date: Monday, March 17, 2014 at 2:48 PM >> To: "netext@ietf.org" >> Cc: "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" < >> draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org> >> >> Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 >> Resent-To: Rajeev Koodli , >> >> >> Hello, >> >> A few comments following my review of this I-D: >> >> 1. A lot of the 3GPP concepts are covered in this document. And there >> is not enough explanation of things like the APN etc. I would recommend >> referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP >> contexts etc. >> >> Rajeev> okay, good idea. >> >> >> 2. It is not clear as to which EAP messages would include the >> attributes such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would >> be easier for implementers if it was clearly spelled out in a message flow. >> >> Rajeev> we do specify that in statements such as "This attribute can be >> included in any of the EAP Request message that >> are integrity protected, such as EAP-Response/AKA-Challenge.". Since >> these are just the attributes, it is up to the implementations to >> incorporate them in the appropriate EAP messages. However, perhaps it would >> be better to indicate specific EAP messages which can be used to carry the >> corresponding attributes. Will take a look. >> >> >> 3. The attributes to co-relate sessions when moving between 3/4G >> networks and WiFi no doubt are useful. But I am not sure if this is >> sufficient to enable seamless mobility between these disparate networks. >> Maybe it would be useful to clarify that these attributes are required in >> the context of an overall 3/4G<->WiFi mobility design. >> >> Rajeev> Right, the attribute itself is not sufficient, but is an >> enabler. >> >> >> 4. The following statement in Sec 5.3 is not clear as to its intent and >> the outcome : "For Multiple PDN Connections only, a Mobile Node uses this >> attribute >> to indicate whether it wishes the connectivity type to be Non- >> Seamless WLAN Offload or EPC." >> >> Rajeev> So, both Offload and EPC connectivity choices come into play >> only when multiple PDN connectivity is supported. (It is one or the other >> for single PDN connectivity) >> >> >> 5. Lastly I am wondering if it is worth trying to solve multiple >> problems such as APN indication, Mobility between networks and Simultaneous >> connections to different APNs in this I-D. I see the APN indication and >> simulatenous connections to different APNs as something that would be >> required in WiFI networks. Maybe the I-D would be simplified if it did not >> tackle the seamless mobility aspect and drop the associated attributes >> proposed. >> >> Rajeev> I assume by "Mobility between networks" you mean the attribute >> AT_HANDOVER_SESSION_ID. This is an optional attribute which can be >> useful in determining the previous attachment of the UE. Other than that, >> there are no other attributes. >> >> Thanks. >> >> -Rajeev >> >> >> -Raj >> >> -- >> Basavaraj Patil >> > > > > -- > Basavaraj Patil > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --e89a8f643d1091258304f50d22cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Okay. Where can I find the editorial issues? :)

-Rajeev



On Thu, Mar 20, 2014 at 7:54 A= M, Basavaraj Patil <bpatil1@gmail.com> wrote:

Thanks for your re= sponses Rajeev. Please send an updated I-D. Also note that there are editor= ial issues as well which I did not cover. You may want to take care of them= as well when you revise the I-D.

-Raj


On Mon, Mar 17, 2014 at 10:13 PM, Ko= odli, Rajeev <rajeev.koodli@intel.com> wrote:

Hi Raj,

Thanks for the review. Responses inline:

From: Basavaraj Patil <bpatil1@gmail.com>
Date: Monday, March 17, 2014 at 2:4= 8 PM
To: "netext@ietf.org" <netext@ietf.org>
Cc: "draft-= ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" <draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org>
Subject: Review of I-D: draft-ietf-= netext-wifi-epc-eap-attributes-06
Resent-To: Rajeev Koodli <= rajeev.koodli@= intel.com>, <valmikam@gmail.com>


Hello,

A few comments following my review of this I-D:

1. A lot of the 3GPP concepts are covered in this document. And there = is not enough explanation of things like the APN etc. I would recommend ref= erencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP conte= xts etc.

Rajeev> okay, good idea.


2. It is not clear as to which EAP messages would include the attribut= es such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier= for implementers if it was clearly spelled out in a message flow.

Rajeev> we do s= pecify that in statements such as "This = attribute can be included in any of the EAP Request message that
   are= integrity protected, such as EAP-Response/AKA-Challenge.". Sin= ce these are just the attributes, it is up to the implementations to incorp= orate them in the appropriate EAP messages. However, perhaps it would be better to indicate specific EAP= messages which can be used to carry the corresponding attributes. Will tak= e a look.


3. The attributes to co-relate sessions when moving between 3/4G netwo= rks and WiFi no doubt are useful. But I am not sure if this is sufficient t= o enable seamless mobility between these disparate networks. Maybe it would= be useful to clarify that these attributes are required in the context of an overall 3/4G<->WiFi mob= ility design.

Rajeev> Right, the at= tribute itself is not sufficient, but is an enabler. 


4. The following statement in Sec 5.3 is not clear as to its intent an= d the outcome : "For Multiple PDN Connections only, a Mobile Node uses= this attribute
   to indicate whether it wishes the connectivity type to be= Non-
   Seamless WLAN Offload or EPC."

Rajeev> So, both Offl= oad and EPC connectivity choices come into play only when multiple PDN conn= ectivity is supported. (It is one or the other for single PDN connectivity)=
 

5. Lastly I am wondering if it is worth trying to solve multiple probl= ems such as APN indication, Mobility between networks and Simultaneous conn= ections to different APNs in this I-D. I see the APN indication and simulat= enous connections to different APNs as something that would be required in WiFI networks. Maybe the I-D would = be simplified if it did not tackle the seamless mobility aspect and drop th= e associated attributes proposed.

Rajeev> I assume by &= ldquo;Mobility between networks” you mean the attribute AT_HANDOVER_SESSION_ID. This is an optional att= ribute which can be useful in determining the previous attachment of the UE. Other than that, there are no other att= ributes.

Thanks.

-Rajeev


-Raj

--
Basavaraj Patil



--
Basavaraj Patil

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


--e89a8f643d1091258304f50d22cd-- From nobody Thu Mar 20 11:20: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 DAA921A0429 for ; Thu, 20 Mar 2014 11:20:06 -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 DrW6eQm2BWzL for ; Thu, 20 Mar 2014 11:20:04 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BDEEC1A07E3 for ; Thu, 20 Mar 2014 11:20:02 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so1333392obc.30 for ; Thu, 20 Mar 2014 11:19:53 -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=NGXisjOf30Qkl10jxt5SsuKOQP/fTYhdEkBxKCCDL0A=; b=oQes8EDiTNpcbuRovTKCZzumIP1JjsXQhze7toLfZuFGF+pTG3RRes5ILRuochzK69 baZkb0/WRASwNU0fybzdXPDZDVf2BudVUO73DYEWkVxYS7QAgYdEO3svPN82QKlldwMA PQECdzV6x58meqvyxahfmGmCgNsqZn/sm3DqQYFVcU7tjsjA4+Gwky/5p71iIoMOQNqS t7gU8uz0eC+yj5o4oMNzydZdpCHE7M+LjvcCnvIWJQHvZgThz2QpEY1RJWyW5noUOAn5 zIxwSoGFPKpBiIBoTZrbmQrUsLzlXyKc+RuRGYf2mcK+2/entA6B4qiLwSJ3GlTpmzC8 NqbQ== MIME-Version: 1.0 X-Received: by 10.60.83.234 with SMTP id t10mr38811381oey.4.1395339593599; Thu, 20 Mar 2014 11:19:53 -0700 (PDT) Received: by 10.182.161.42 with HTTP; Thu, 20 Mar 2014 11:19:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Mar 2014 14:19:53 -0400 Message-ID: From: Basavaraj Patil To: Rajeev Koodli Content-Type: multipart/alternative; boundary=089e0116019cd152fd04f50dd099 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/vThEzcHmd1T4ijh5GoL0EDXSArE Cc: "Koodli, Rajeev" , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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, 20 Mar 2014 18:20:07 -0000 --089e0116019cd152fd04f50dd099 Content-Type: text/plain; charset=ISO-8859-1 I was hoping you would catch then yourself :) But I can send you a few that I noticed while reviewing it. -Raj On Thu, Mar 20, 2014 at 1:31 PM, Rajeev Koodli wrote: > > Okay. Where can I find the editorial issues? :) > > -Rajeev > > > > On Thu, Mar 20, 2014 at 7:54 AM, Basavaraj Patil wrote: > >> >> Thanks for your responses Rajeev. Please send an updated I-D. Also note >> that there are editorial issues as well which I did not cover. You may want >> to take care of them as well when you revise the I-D. >> >> -Raj >> >> >> On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajeev > > wrote: >> >>> >>> Hi Raj, >>> >>> Thanks for the review. Responses inline: >>> >>> From: Basavaraj Patil >>> >>> Date: Monday, March 17, 2014 at 2:48 PM >>> To: "netext@ietf.org" >>> Cc: "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" < >>> draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org> >>> >>> Subject: Review of I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 >>> Resent-To: Rajeev Koodli , >>> >>> >>> Hello, >>> >>> A few comments following my review of this I-D: >>> >>> 1. A lot of the 3GPP concepts are covered in this document. And there >>> is not enough explanation of things like the APN etc. I would recommend >>> referencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP >>> contexts etc. >>> >>> Rajeev> okay, good idea. >>> >>> >>> 2. It is not clear as to which EAP messages would include the >>> attributes such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would >>> be easier for implementers if it was clearly spelled out in a message flow. >>> >>> Rajeev> we do specify that in statements such as "This attribute can >>> be included in any of the EAP Request message that >>> are integrity protected, such as EAP-Response/AKA-Challenge.". Since >>> these are just the attributes, it is up to the implementations to >>> incorporate them in the appropriate EAP messages. However, perhaps it would >>> be better to indicate specific EAP messages which can be used to carry the >>> corresponding attributes. Will take a look. >>> >>> >>> 3. The attributes to co-relate sessions when moving between 3/4G >>> networks and WiFi no doubt are useful. But I am not sure if this is >>> sufficient to enable seamless mobility between these disparate networks. >>> Maybe it would be useful to clarify that these attributes are required in >>> the context of an overall 3/4G<->WiFi mobility design. >>> >>> Rajeev> Right, the attribute itself is not sufficient, but is an >>> enabler. >>> >>> >>> 4. The following statement in Sec 5.3 is not clear as to its intent >>> and the outcome : "For Multiple PDN Connections only, a Mobile Node uses >>> this attribute >>> to indicate whether it wishes the connectivity type to be Non- >>> Seamless WLAN Offload or EPC." >>> >>> Rajeev> So, both Offload and EPC connectivity choices come into play >>> only when multiple PDN connectivity is supported. (It is one or the other >>> for single PDN connectivity) >>> >>> >>> 5. Lastly I am wondering if it is worth trying to solve multiple >>> problems such as APN indication, Mobility between networks and Simultaneous >>> connections to different APNs in this I-D. I see the APN indication and >>> simulatenous connections to different APNs as something that would be >>> required in WiFI networks. Maybe the I-D would be simplified if it did not >>> tackle the seamless mobility aspect and drop the associated attributes >>> proposed. >>> >>> Rajeev> I assume by "Mobility between networks" you mean the attribute >>> AT_HANDOVER_SESSION_ID. This is an optional attribute which can be >>> useful in determining the previous attachment of the UE. Other than that, >>> there are no other attributes. >>> >>> Thanks. >>> >>> -Rajeev >>> >>> >>> -Raj >>> >>> -- >>> Basavaraj Patil >>> >> >> >> >> -- >> Basavaraj Patil >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > -- Basavaraj Patil --089e0116019cd152fd04f50dd099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I was hoping you would catch then yourself :)

But I can send you a few that I noticed while reviewi= ng it.

-Raj
=

On Thu, Mar 20, 2014 at 1:31 PM, Rajeev Kood= li <rajeev.koodli@gmail.com> wrote:

Okay. Where can I find the editorial issues? :)

-Rajeev



On Thu,= Mar 20, 2014 at 7:54 AM, Basavaraj Patil <bpatil1@gmail.com> wrote:

Thanks for your responses Rajeev. Please send an updated = I-D. Also note that there are editorial issues as well which I did not cove= r. You may want to take care of them as well when you revise the I-D.

-Raj


On Mon, Mar 17, 2014 at 10:13 PM, Koodli, Rajee= v <rajeev.koodli@intel.com> wrote:

Hi Raj,

Thanks for the review. Responses inline:

From: Basavaraj Patil <bpatil1@gmail.com>
Date: Monday, March 17, 2014 at 2:4= 8 PM
To: "netext@ietf.org" <netext@ietf.org>
Cc: "draft-= ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" <draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org>
Subject: Review of I-D: draft-ietf-= netext-wifi-epc-eap-attributes-06
Resent-To: Rajeev Koodli <= rajeev.koodli@= intel.com>, <valmikam@gmail.com>


Hello,

A few comments following my review of this I-D:

1. A lot of the 3GPP concepts are covered in this document. And there = is not enough explanation of things like the APN etc. I would recommend ref= erencing RFC6459 (Secs 2, 3 and 4) for a better overview of APNs, PDP conte= xts etc.

Rajeev> okay, good idea.
<= div>


2. It is not clear as to which EAP messages would include the attribut= es such as AT_VIRTUAL_NETWORK_ID or AT_HANDOVER_INDICATION. Would be easier= for implementers if it was clearly spelled out in a message flow.

Rajeev> we do specify that= in statements such as "This attribute c= an be included in any of the EAP Request message that
   are= integrity protected, such as EAP-Response/AKA-Challenge.". Sin= ce these are just the attributes, it is up to the implementations to incorp= orate them in the appropriate EAP messages. However, perhaps it would be better to indicate specific EAP= messages which can be used to carry the corresponding attributes. Will tak= e a look.


3. The attributes to co-relate sessions when moving between 3/4G netwo= rks and WiFi no doubt are useful. But I am not sure if this is sufficient t= o enable seamless mobility between these disparate networks. Maybe it would= be useful to clarify that these attributes are required in the context of an overall 3/4G<->WiFi mob= ility design.

Rajeev> Right, the attribute its= elf is not sufficient, but is an enabler. 


4. The following statement in Sec 5.3 is not clear as to its intent an= d the outcome : "For Multiple PDN Connections only, a Mobile Node uses= this attribute
   to indicate whether it wishes the connectivity type to be= Non-
   Seamless WLAN Offload or EPC."

Rajeev> So, both Offload and EPC= connectivity choices come into play only when multiple PDN connectivity is= supported. (It is one or the other for single PDN connectivity)
 

5. Lastly I am wondering if it is worth trying to solve multiple probl= ems such as APN indication, Mobility between networks and Simultaneous conn= ections to different APNs in this I-D. I see the APN indication and simulat= enous connections to different APNs as something that would be required in WiFI networks. Maybe the I-D would = be simplified if it did not tackle the seamless mobility aspect and drop th= e associated attributes proposed.

Rajeev> I assume by “Mobil= ity between networks” you mean the attribute AT_HANDOVER_SESSION_ID. This is an optional attribute wh= ich can be useful in determining the previous attachment of the UE. Other than that, there are no other att= ributes.

Thanks.

-Rajeev


-Raj

--
Basavaraj Patil



--
Basavaraj Patil

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





--
Basavaraj Pa= til --089e0116019cd152fd04f50dd099-- From nobody Wed Mar 26 01:23:49 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 212781A02D5 for ; Wed, 26 Mar 2014 01:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.221 X-Spam-Level: *** X-Spam-Status: No, score=3.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4mvYJdvKxFz7 for ; Wed, 26 Mar 2014 01:23:46 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 5330A1A0138 for ; Wed, 26 Mar 2014 01:23:45 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0A67F17481A1 for ; Wed, 26 Mar 2014 17:23:43 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCOyDPDmViPh for ; Wed, 26 Mar 2014 17:23:42 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 12D7917481A0 for ; Wed, 26 Mar 2014 17:23:42 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 2424D1B860 for ; Wed, 26 Mar 2014 17:10:26 +0900 (JST) Message-ID: <53328E89.1060409@kddilabs.jp> Date: Wed, 26 Mar 2014 17:23:37 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "netext@ietf.org" References: In-Reply-To: Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netext/2V_9BmZos13p92z1FFqjsBmHlfc 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: Wed, 26 Mar 2014 08:23:48 -0000 Hi authors,

I think this is in good shape enough to go, but just one clarification question:

In Section 6,
 
         When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate its support-capability for this
         feature by including the LMA User Plane Address mobility Option
         in the Proxy Binding Acknowledgement.  If the option is not
         present in the Proxy Binding Update, the local mobility anchor
         will not enable this feature for that mobility session.

How can MAG indicate its support by PBA? Is it PBU or LMA does it by any chance? The same question applies in the following paragraph in the document.

Regards,
 
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
(2014/03/13 3:42), Basavaraj Patil wrote:
Hello,

This is the working group last call for I-D: Separation of Control and User Plane for Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.

This I-D is intended to be progressed as a standards track document. 
Please review and post your comments on the mailing list.
The last call will expire on March 27th, 14. 

-Chairs



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

From nobody Wed Mar 26 15:32:03 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 CDDDA1A03DF for ; Wed, 26 Mar 2014 15:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SsEGJigoMxUh for ; Wed, 26 Mar 2014 15:31:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB591A03E9 for ; Wed, 26 Mar 2014 15:31:57 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1C57A2AC7F7; Wed, 26 Mar 2014 23:31:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 02D83384084; Wed, 26 Mar 2014 23:31:55 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 23:31:54 +0100 From: To: "netext@ietf.org" , Hidetoshi Yokota Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPSMy4Aa5CzPfKV0eGOYAugumCeZrz9Mfd Date: Wed, 26 Mar 2014 22:31:54 +0000 Message-ID: <30516_1395873115_5333555B_30516_15540_1_v5mld5dmjy0sqv44fux4c1hd.1395873108462@email.android.com> References: , <53328E89.1060409@kddilabs.jp> In-Reply-To: <53328E89.1060409@kddilabs.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_v5mld5dmjy0sqv44fux4c1hd1395873108462emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.173915 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/jp5oNWjdGHFnkoCLNwufV2D-zQY 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: Wed, 26 Mar 2014 22:32:01 -0000 --_000_v5mld5dmjy0sqv44fux4c1hd1395873108462emailandroidcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi I support this draft; it adresses valid architecture scenario with separate= d control and data plane entities. However architecture in figure 1 should be updated to clearly show this sep= aration. Fig 1 put both mag cp and mag up within the same box, which is a b= it confusing regarding the scope of the document. Although out of scope of the document, it would be worth to give indication= on interface between mag cp and up (eg Capwap based) in order to have the = full picture on how the solution can work. Sent from my mobile ---- Hidetoshi Yokota wrote ---- Hi authors, I think this is in good shape enough to go, but just one clarification ques= tion: In Section 6, When this variable on the MAG is set to a value of (0), the MAG must explicitly indicate its support-capability for this feature by including the LMA User Plane Address mobility Option in the Proxy Binding Acknowledgement. If the option is not present in the Proxy Binding Update, the local mobility anchor will not enable this feature for that mobility session. How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch= ance? The same question applies in the following paragraph in the document. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/03/13 3:42), Basavaraj Patil wrote: Hello, This is the working group last call for I-D: Separation of Control and User= Plane for Proxy Mobile IPv6 . This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_v5mld5dmjy0sqv44fux4c1hd1395873108462emailandroidcom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable 
Hi

I support this draft; it adresses valid architecture scenario with separate=
d control and data plane entities.
However architecture in figure 1 should be updated to clearly show this sep=
aration. Fig 1 put both mag cp and mag up within the same box, which is a b=
it confusing regarding the scope of the document.

Although out of scope of the document, it would be worth to give indication=
 on interface between mag cp and up (eg Capwap based) in order to have the =
full picture on how the solution can work.

Sent from my mobile

---- Hidetoshi Yokota <yokota@kddilabs.jp> wrote ----
Hi authors,

I think this is in good shape enough to go, but just one clarification ques= tion:

In Section 6,
 
     =
    When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate its support-capability for this
         feature by including the LMA User Plane Address mobility Option
         in the Proxy Binding Acknowledgement.  If the option is not
         present in the Proxy Binding Update, the local mobility anchor
         will not enable this feature for that mobility session.


How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch=
ance? The same question =
applies in the following paragraph in the document.



Regards,



--=20
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp











(2014/03/13 3:42), Basavaraj Patil wrote:






Hello,






This is the working group last call for I-D: Separation of Control and User Plane for=
 Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.







This I-D is intended to be progressed as a standards track document.&n=
bsp;


Please review and post your comments on the mailing list.


The last call will expire on March 27th, 14. 







-Chairs













 


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







______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_v5mld5dmjy0sqv44fux4c1hd1395873108462emailandroidcom_-- From nobody Wed Mar 26 16:19:16 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 0AD641A03F8 for ; Wed, 26 Mar 2014 16:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0ZpTpE0eeKC1 for ; Wed, 26 Mar 2014 16:19:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2E1A034E for ; Wed, 26 Mar 2014 16:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6856; q=dns/txt; s=iport; t=1395875950; x=1397085550; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=xB8ZHPGhVWki5I8wex32DFCcb6UroGylrV+g3/ufeUw=; b=EUKSaCxJWZYhtTIm2UV5kG+4peasMcSeZztqMx5v/Bz00Yf3cn7d0Nna qpDdrJ90dy8FJtVbPxZP72ZOqXBRQjW5ULhrgDTZqm6CWBuq8yEF52O+u 92Luvtu9e8deA0Z0cusfKeJnyrM03Yyahk6VXdwXkY0bJ36p3Ro5TCZMW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIpfM1OtJXHB/2dsb2JhbABZgkJEO1e7QIZqUYEZFnSCJQEBAQMBAQEBGlEQDQEIEQMBAiguCxQJCAIEARIJh2gIDdE8F4xGghoYhDgEmE2SM4Mugis X-IronPort-AV: E=Sophos;i="4.97,738,1389744000"; d="scan'208,217";a="313145279" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 26 Mar 2014 23:19:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2QNJAxQ003655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 23:19:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 18:19:09 -0500 From: "Sri Gundavelli (sgundave)" To: Hidetoshi Yokota , "netext@ietf.org" Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPSUnKkq9dc7kLnk6zaaw6lcDsSw== Date: Wed, 26 Mar 2014 23:19:08 +0000 Message-ID: In-Reply-To: <53328E89.1060409@kddilabs.jp> 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.211] Content-Type: multipart/alternative; boundary="_000_CF58AE33126690sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/YRD9sI6fHPOJe_tScnKBmAbmQjs 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: Wed, 26 Mar 2014 23:19:14 -0000 --_000_CF58AE33126690sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yokota-san, Thanks for the review. > How can MAG indicate its support by PBA? Its a typo. Thanks for pointing to this. Will fix it. Regards Sri From: Hidetoshi Yokota > Date: Wednesday, March 26, 2014 1:23 AM To: "netext@ietf.org" > Subject: Re: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Hi authors, I think this is in good shape enough to go, but just one clarification ques= tion: In Section 6, When this variable on the MAG is set to a value of (0), the MAG must explicitly indicate its support-capability for this feature by including the LMA User Plane Address mobility Option in the Proxy Binding Acknowledgement. If the option is not present in the Proxy Binding Update, the local mobility anchor will not enable this feature for that mobility session. How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch= ance? The same question applies in the following paragraph in the document. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/03/13 3:42), Basavaraj Patil wrote: Hello, This is the working group last call for I-D: Separation of Control and User= Plane for Proxy Mobile IPv6 . This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs _______________________________________________ netext mailing list netext@ietf.orghttps://www.ietf.org/mailman/listinf= o/netext --_000_CF58AE33126690sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9389F545C64EB14BA21555FD80C74E32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Yokota-san,

Thanks for the review. 

> How can MAG indicate its support by PBA? =

Its a typo. Thanks for pointing to this. Will fix it.

Regards
Sri




From: Hidetoshi Yokota <yokota@kddilabs.jp>
Date: Wednesday, March 26, 2014 1:2= 3 AM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: Re: [netext] WG last call:= draft-ietf-netext-pmip-cp-up-separation

Hi authors,

I think this is in good shape enough to go, but just one clarification ques= tion:

In Section 6,
 
       =
  When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate its support-capability for this
         feature by including the LMA User Plane Address mobility Option
         in the Proxy Binding Acknowledgement.  If the option is not
         present in the Proxy Binding Update, the local mobility anchor
         will not enable this feature for that mobility session.


How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch=
ance? The same question ap=
plies in the following paragraph in the document.



Regards,



--=20
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp











(2014/03/13 3:42), Basavaraj Patil wrote:





Hello,






This is the working group last call for I-D: Separation of Control and User Plane for =
Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.







This I-D is intended to be progressed as a standards track document.&n=
bsp;


Please review and post your comments on the mailing list.


The last call will expire on March 27th, 14. 







-Chairs













 


_______________________________________________
netext mailing list
netex=
t@ietf.orghttps://www.ietf.org/mailman/listinfo/netext
--_000_CF58AE33126690sgundaveciscocom_-- From nobody Wed Mar 26 16:20:28 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 2E27B1A03F8 for ; Wed, 26 Mar 2014 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vCCorQjN-rSs for ; Wed, 26 Mar 2014 16:20:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 06DF31A0380 for ; Wed, 26 Mar 2014 16:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10429; q=dns/txt; s=iport; t=1395876022; x=1397085622; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=vbThsUUIod0P8szWZ19itKTP/5i8yASbFg6Nasq9vVk=; b=Ig/F8GkyPqhFs8j6DHGA0KkCBjH6bit0tzSyjzJCWwmObwjzJv3gC8n/ 8RaThR8R5oCvABDv5TvAOapOYhbGdsceRDyO18Qfq/5RMDex44AWDgjcw SOIpKjDwEagsjGYrZX0OCp5zXD2j2syBoJpX0xRUx3vg1IjaJrT+/frAb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIpfM1OtJV2c/2dsb2JhbABZgkJEO1e7QIZqUYEZFnSCJQEBAQMBAQEBGlEQDQEIEQECAQIoLgsUAwYIAgQBEgkSh1YIDdE8F4xGgUkRAT8MDAaEMgSUYYNskjODLoFyOQ X-IronPort-AV: E=Sophos;i="4.97,738,1389744000"; d="scan'208,217";a="313176045" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 26 Mar 2014 23:20:21 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2QNKLQG019781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 23:20:21 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 18:20:20 -0500 From: "Sri Gundavelli (sgundave)" To: "pierrick.seite@orange.com" , "netext@ietf.org" , Hidetoshi Yokota Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPSUn0kq9dc7kLnk6zaaw6lcDsSw== Date: Wed, 26 Mar 2014 23:20:19 +0000 Message-ID: In-Reply-To: <30516_1395873115_5333555B_30516_15540_1_v5mld5dmjy0sqv44fux4c1hd.1395873108462@email.android.com> 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.211] Content-Type: multipart/alternative; boundary="_000_CF58AE8A126697sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/8BYgdpGJcwliNGJMZU55eJrfmS4 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: Wed, 26 Mar 2014 23:20:26 -0000 --_000_CF58AE8A126697sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pierrick, Thanks for the review. > However architecture in figure 1 should be updated to clearly show this s= eparation. Ack. Will update the figure. Regards Sri From: "pierrick.seite@orange.com" > Date: Wednesday, March 26, 2014 3:31 PM To: "netext@ietf.org" >, Hidetoshi Yokota > Subject: Re: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Hi I support this draft; it adresses valid architecture scenario with separate= d control and data plane entities. However architecture in figure 1 should be updated to clearly show this sep= aration. Fig 1 put both mag cp and mag up within the same box, which is a b= it confusing regarding the scope of the document. Although out of scope of the document, it would be worth to give indication= on interface between mag cp and up (eg Capwap based) in order to have the = full picture on how the solution can work. Sent from my mobile ---- Hidetoshi Yokota > wrote= ---- Hi authors, I think this is in good shape enough to go, but just one clarification ques= tion: In Section 6, When this variable on the MAG is set to a value of (0), the MAG must explicitly indicate its support-capability for this feature by including the LMA User Plane Address mobility Option in the Proxy Binding Acknowledgement. If the option is not present in the Proxy Binding Update, the local mobility anchor will not enable this feature for that mobility session. How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch= ance? The same question applies in the following paragraph in the document. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/03/13 3:42), Basavaraj Patil wrote: Hello, This is the working group last call for I-D: Separation of Control and User= Plane for Proxy Mobile IPv6 . This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs _______________________________________________ netext mailing list netext@ietf.orghttps://www.ietf.org/mailman/listinf= o/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CF58AE8A126697sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6631DA097698F047A1C498DF14EDE849@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Pierrick,

Thanks for the review.

> However architecture in figure 1 should = be updated to clearly show this separation.

Ack. Will update the figure.

Regards
Sri


From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>
Date: Wednesday, March 26, 2014 3:3= 1 PM
To: "netext@ietf.org" <= netext@ietf.org>, Hidetoshi Yokota <yokota@kddilabs.jp>
Subject: Re: [netext] WG last call:= draft-ietf-netext-pmip-cp-up-separation

Hi

I support this draft; it adresses valid architecture scenario with separate=
d control and data plane entities.
However architecture in figure 1 should be updated to clearly show this sep=
aration. Fig 1 put both mag cp and mag up within the same box, which is a b=
it confusing regarding the scope of the document.

Although out of scope of the document, it would be worth to give indication=
 on interface between mag cp and up (eg Capwap based) in order to have the =
full picture on how the solution can work.

Sent from my mobile

---- Hidetoshi Yokota <yokota@kddi=
labs.jp> wrote ----
Hi authors,

I think this is in good shape enough to go, but just one clarification ques= tion:

In Section 6,
 
       =
  When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate its support-capability for this
         feature by including the LMA User Plane Address mobility Option
         in the Proxy Binding Acknowledgement.  If the option is not
         present in the Proxy Binding Update, the local mobility anchor
         will not enable this feature for that mobility session.


How can MAG indicate its support by PBA? Is it PBU or LMA does it by any ch=
ance? The same question ap=
plies in the following paragraph in the document.



Regards,



--=20
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp











(2014/03/13 3:42), Basavaraj Patil wrote:





Hello,






This is the working group last call for I-D: Separation of Control and User Plane for=
 Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.







This I-D is intended to be progressed as a standards track document.&n=
bsp;


Please review and post your comments on the mailing list.


The last call will expire on March 27th, 14. 







-Chairs













 


_______________________________________________
netext mailing list
netex=
t@ietf.orghttps://www.ietf.org/mailman/listinfo/netext






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CF58AE8A126697sgundaveciscocom_-- From nobody Wed Mar 26 19:04:51 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 74A1F1A0433 for ; Wed, 26 Mar 2014 19:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 GoozbnP9I7d5 for ; Wed, 26 Mar 2014 19:04:46 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9777C1A042E for ; Wed, 26 Mar 2014 19:04:46 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so2769514pbc.34 for ; Wed, 26 Mar 2014 19:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rWKIf0IZY1UrR1ZEfehr/gQLBZ16zzyF6eWiT6sR69Q=; b=rAdhZ718QPhe1+tkTTlMxBZlacOP7RkvMrXq0mWvxgexsvqiID5ruAf9BunsMBMw/Y PIhDDfLcS3a1jS4dY45zXeKNnmWg/EhLLKjqXjEplLBaquU0cpIIXaBpdNy8W45TPoFW R0793D4uZkRhxQRqw0c44VRzgkwOB0Wq9dmJoQQi9DuzBZaMaxP4uCPIdpI1JOXKhqju GV7u1Rd8rgBHHm67dzanGL8ZgTh1zS3t71ih7f0umPmwURG0J5BQcIJnz3ol6o7sKhEj tbmKwT05RQ/ygvzxd+/4nw472E0MoRLU43kTqKQvH7W96sK4gzCJ/WJQg3hjheWwgVgr dJ5Q== X-Received: by 10.66.149.231 with SMTP id ud7mr89967309pab.8.1395885885115; Wed, 26 Mar 2014 19:04:45 -0700 (PDT) Received: from [10.201.84.2] ([202.45.12.142]) by mx.google.com with ESMTPSA id tk5sm1467301pbc.63.2014.03.26.19.04.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 19:04:44 -0700 (PDT) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ryuji Wakikawa In-Reply-To: <30516_1395873115_5333555B_30516_15540_1_v5mld5dmjy0sqv44fux4c1hd.1395873108462@email.android.com> Date: Thu, 27 Mar 2014 11:04:41 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <62EEA756-B793-4108-B704-3F4CC09ABC12@gmail.com> References: , <53328E89.1060409@kddilabs.jp> <30516_1395873115_5333555B_30516_15540_1_v5mld5dmjy0sqv44fux4c1hd.1395873108462@email.android.com> To: pierrick.seite@orange.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/u_FIXujAOkD9wHNq1bfvuqj-ffk 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: Thu, 27 Mar 2014 02:04:48 -0000 Hi Pierrick thanks for comments. 2014/03/27 =1B$B8aA0=1B(B7:31=1B$B!"=1B(Bpierrick.seite@orange.com = =1B$B$N%a!<%k!'=1B(B > Hi >=20 > I support this draft; it adresses valid architecture scenario with = separated control and data plane entities. > However architecture in figure 1 should be updated to clearly show = this separation. Fig 1 put both mag cp and mag up within the same box, = which is a bit confusing regarding the scope of the document. We will fix this.=20 > Although out of scope of the document, it would be worth to give = indication on interface between mag cp and up (eg Capwap based) in order = to have the full picture on how the solution can work. We can clarify that this interface is out of scope.=20 Do we need examples like capwap/forces/sdn in the document? regards, ryuji >=20 > Sent from my mobile >=20 > ---- Hidetoshi Yokota < > yokota@kddilabs.jp> wrote ---- > Hi authors, >=20 > I think this is in good shape enough to go, but just one clarification = question: >=20 > In Section 6, > When this variable on the MAG is set to a value of (0), the = MAG > must explicitly indicate its support-capability for this > feature by including the LMA User Plane Address mobility = Option > in the=20 > Proxy Binding Acknowledgement > . If the option is not > present in the Proxy Binding Update, the local mobility = anchor > will not enable this feature for that mobility session. >=20 >=20 > How can MAG indicate its support by PBA? Is it PBU or LMA does it by = any chance? The same question applies in the following paragraph in the = document. >=20 > Regards, > --=20 > Hidetoshi Yokota >=20 > KDDI R&D Laboratories, Inc. >=20 > e-mail:yokota@kddilabs.jp >=20 >=20 >=20 >=20 > (2014/03/13 3:42), Basavaraj Patil wrote: >> Hello, >>=20 >> This is the working group last call for I-D: Separation of Control = and User Plane for Proxy Mobile IPv6 = . >>=20 >> This I-D is intended to be progressed as a standards track document.=20= >> Please review and post your comments on the mailing list. >> The last call will expire on March 27th, 14.=20 >>=20 >> -Chairs >>=20 >>=20 >>=20 >> _______________________________________________ >> netext mailing list >>=20 >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From nobody Wed Mar 26 19:05: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 6CA491A043A for ; Wed, 26 Mar 2014 19:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Dpm0w2cPJjmc for ; Wed, 26 Mar 2014 19:05:20 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4151A0438 for ; Wed, 26 Mar 2014 19:05:19 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so2670838pdj.34 for ; Wed, 26 Mar 2014 19:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PkTpAnMPBQGyhnuDNAQVCPS1TY5IUr/z0LfU8jmznpU=; b=Lar+70J75RlrGZikislmjs94ZJJHIvQC0rPSFYIy6mXA2ewSwkuOpoktkfjFV+VM1X k87+02Q05XnT+dYL2jgbipVXv2cQ0GryXHHSqHe0Ci+iseIexfulesh9RQ7KuTOHMpeP 7nvTboKcFlwkDq5EtXO3wTAE8KT72nYVYYwdfluNWOWUqbEv3bED+dfUFndSNokh9jr9 Q4zZB9+pse8OW33RVX4ThcYif8xhDYxkHH8am7DmJFpPSO0hJEibGiNfvp4+MrVYxCzs zt6JGL3Drlalnig0HdTNuf0IAIUcBbJ2Vv/yhcx7RB/JjKNIZJUjDJd8Fse8pSTj9cPT qZjw== X-Received: by 10.66.149.37 with SMTP id tx5mr8339645pab.81.1395885918543; Wed, 26 Mar 2014 19:05:18 -0700 (PDT) Received: from [10.201.84.2] ([202.45.12.142]) by mx.google.com with ESMTPSA id tk5sm1467301pbc.63.2014.03.26.19.05.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 19:05:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ryuji Wakikawa In-Reply-To: Date: Thu, 27 Mar 2014 11:05:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sri Gundavelli X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/h95R9nxipT2J3wtOul6IrMZr7lE 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: Thu, 27 Mar 2014 02:05:23 -0000 X-List-Received-Date: Thu, 27 Mar 2014 02:05:23 -0000 Thanks Yokota-san for review! We will fix it. ryuji 2014/03/27 =E5=8D=88=E5=89=8D8:19=E3=80=81Sri Gundavelli (sgundave) = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > Hi Yokota-san, >=20 > Thanks for the review.=20 >=20 > > How can MAG indicate its support by PBA?=20 >=20 > Its a typo. Thanks for pointing to this. Will fix it. >=20 > Regards > Sri >=20 >=20 >=20 >=20 > From: Hidetoshi Yokota > Date: Wednesday, March 26, 2014 1:23 AM > To: "netext@ietf.org" > Subject: Re: [netext] WG last call: = draft-ietf-netext-pmip-cp-up-separation >=20 > Hi authors, >=20 > I think this is in good shape enough to go, but just one clarification = question: >=20 > In Section 6, > =20 > When this variable on the MAG is set to a value of (0), the = MAG > must explicitly indicate its support-capability for this > feature by including the LMA User Plane Address mobility = Option > in the=20 > Proxy Binding Acknowledgement > . If the option is not > present in the Proxy Binding Update, the local mobility = anchor > will not enable this feature for that mobility session. >=20 >=20 > How can MAG indicate its support by PBA? Is it PBU or LMA does it by = any chance? The same question applies in the following paragraph in the = document. >=20 > Regards, > =20 > --=20 > Hidetoshi Yokota >=20 > KDDI R&D Laboratories, Inc. >=20 > e-mail:yokota@kddilabs.jp >=20 >=20 >=20 >=20 > (2014/03/13 3:42), Basavaraj Patil wrote: >> Hello, >>=20 >> This is the working group last call for I-D: Separation of Control = and User Plane for Proxy Mobile IPv6 = . >>=20 >> This I-D is intended to be progressed as a standards track document.=20= >> Please review and post your comments on the mailing list. >> The last call will expire on March 27th, 14.=20 >>=20 >> -Chairs >>=20 >>=20 >>=20 >> _______________________________________________ >> netext mailing list >>=20 >> netext@ietf.orghttps://www.ietf.org/mailman/listinfo/netext >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From nobody Thu Mar 27 04:34: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 8747F1A031B for ; Thu, 27 Mar 2014 04:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 kwBFfYLYgN13 for ; Thu, 27 Mar 2014 04:34:49 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE7E51A0644 for ; Thu, 27 Mar 2014 04:34:48 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 27 Mar 2014 12:34:45 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 27 Mar 2014 12:34:45 +0100 From: To: , Date: Thu, 27 Mar 2014 12:34:44 +0100 Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: Ac9JYRb4KjfzHQFiT2Cwm0kq/FGeZAAQdozg Message-ID: <05C81A773E48DD49B181B04BA21A342A2DE3CBD27B@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Iwr2AYs3jiYB7OKMVPKhyOe0lGk 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: Thu, 27 Mar 2014 11:34:51 -0000 RGVhciBhbGwsDQpJIGFsc28gdGhpbmsgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgZm9yIFJGQyAo ZnJvbSBXRyBwb2ludCBvZiB2aWV3KS4NClNvbWUgbW9yZSBuaXRzIGRldGVjdGVkIHRvIGJlIGNv bnNpZGVyZWQgZm9yIG5leHQgdXBkYXRlOg0KDQpwLjU6DQpHZW5lcmljIFJlY29yZCBFbmNhcHN1 bGF0aW9uID0+IEdlbmVyaWMgUm91dGluZyBFbmNhcHN1bGF0aW9uDQoNCnAuODoNClRoaXMgdmFy aWFibGVzIGluZGljYXRlcyA9PiBUaGlzIHZhcmlhYmxlIGluZGljYXRlcw0KDQpXaGVuIHRoaXMg dmFyaWFibGUgb24gdGhlIE1BRyBpcyBzZXQgdG8gYSB2YWx1ZSBvZiAoMCksIHRoZSBNQUcNCiAg ICAgICAgIG11c3QgZXhwbGljaXRseSBpbmRpY2F0ZSANCj0+IHNob3VsZG4ndCB0aGlzIGJlIGEg bm9ybWF0aXZlIE1VU1Q/DQoNCkZpbmFsbHkgbWlnaHQgaXQgYmUgdXNlZnVsIHRvIGluY2x1ZGUg YSByZWZlcmVuY2UgdG8gb3RoZXIgQy9VIFAgc2VwYXJhdGlvbiB3b3JrIHN1Y2ggYXMgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FraWthd2EtcmVxLW1vYmlsZS1jcC1zZXBhcmF0 aW9uLTAwIG9yIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHN1c2hpbWEtc3Rh dGVsZXNzLXVwbGFuZS12ZXBjLTAyIC0gd2hhdCBkbyB5b3UgdGhpbms/DQoNCkJlc3QgcmVnYXJk cyANCkRpcmsNCg0KPiAoMjAxNC8wMy8xMyAzOjQyKSwgQmFzYXZhcmFqIFBhdGlsIHdyb3RlOg0K Pj4gSGVsbG8sDQo+PiANCj4+IFRoaXMgaXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZv ciBJLUQ6IFNlcGFyYXRpb24gb2YgQ29udHJvbCBhbmQgVXNlciBQbGFuZSBmb3IgUHJveHkgTW9i aWxlIElQdjYgPGRyYWZ0LWlldGYtbmV0ZXh0LXBtaXAtY3AtdXAtc2VwYXJhdGlvbi0wMi50eHQ+ Lg0KPj4gDQo+PiBUaGlzIEktRCBpcyBpbnRlbmRlZCB0byBiZSBwcm9ncmVzc2VkIGFzIGEgc3Rh bmRhcmRzIHRyYWNrIGRvY3VtZW50LiANCj4+IFBsZWFzZSByZXZpZXcgYW5kIHBvc3QgeW91ciBj b21tZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPj4gVGhlIGxhc3QgY2FsbCB3aWxsIGV4cGly ZSBvbiBNYXJjaCAyN3RoLCAxNC4gDQo+PiANCj4+IC1DaGFpcnMNCj4+IA0KPj4gDQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRl eHQgbWFpbGluZyBsaXN0DQo+PiANCj4+IG5ldGV4dEBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+IG5ldGV4 dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4 dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGV4dA0K From nobody Thu Mar 27 04:38: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 C4C3A1A0652 for ; Thu, 27 Mar 2014 04:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 U-U0_XV1jQtt for ; Thu, 27 Mar 2014 04:38:23 -0700 (PDT) Received: from out46-ams.mf.surf.net (out46-ams.mf.surf.net [145.0.1.46]) by ietfa.amsl.com (Postfix) with ESMTP id 179401A0654 for ; Thu, 27 Mar 2014 04:38:22 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s2RBcHYJ013462 for ; Thu, 27 Mar 2014 12:38:18 +0100 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 27 Mar 2014 12:38:24 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Thu, 27 Mar 2014 12:38:17 +0100 From: To: Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPPiLj9cTW/GgAOkSx09Bv3fLbBZr05SQw Date: Thu, 27 Mar 2014 11:38:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F444A27EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vLGzCiKr - f2aa81223a39 - 20140327 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/UYcdxaLDA0J_SdILlJ5GI6zFMXw 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: Thu, 27 Mar 2014 11:38:28 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F444A27EXMBX23adutwent_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read the draft. I think that the draft is in a good shape and I thin= k that we can proceed with the RFC publication process. However, I have som= e comments, which need some attention! Comment_1: : In Section 3, the LMA user plane address mobility option is sp= ecified. Regarding the Length field the following is mentioned: "8-bit unsi= gned integer indicating the length of the option in octets, excluding the t= ype and length fields." This is okay, but why is the Length field does not = exclude in addition to the type and length fields, also the Reserved field.= I think that this will make sense. You may change the description of the L= ength field to: "8-bit unsigned integer indicating the length of the option= in octets, excluding the type, length and Reserved fields." Comment_2: In Section 3, the LMA user plane address mobility option is spec= ified. However, it is not clear what will be the format of this option when= the LMA user plane address is an IPv4 address. You could solve this by adding in the description of the LMA User Plane Add= ress field what will be the value of the Length field when either an IPv4 i= s used or an IPv6 address is used. Note that this is partially done in Sect= ion 4. Note also that in the provided description of the Length field in Se= ction 4, you already assume that the length of the option in octets, is alr= eady excluding the type, length and Reserved fields, while in Section 3, th= e Reserved field is not excluded. Comment_3: In Section 3, the definition of the LMA User Plane Address field= , you probably need to include the term LMA user plane, instead of LMA. Thi= s the description of this field can become: "Contains either the 32-bit IPv= 4 address of the LMA user plane, when the value of the Length field is set = to 4, or the 128-bit IPV6 of the LMA user plane, when the value of the Leng= th field is set to 16. Comment_4: Regarding Figure 1, you might need to use different boxes for MA= G CP and MAG-UP. Comment_5: The IANA section might need more details, regarding what you are= requesting! Comment_6: typo, in Section 6, use Proxy Binding Update instead of Proxy Bi= nding Acknowledgement . Please change from: When this variable on the MAG is set to a value of (0), the MAG must explic= itly indicate its support-capability for this feature by including the LMA = User Plane Address mobility Option in the Proxy Binding Acknowledgement. INTO: When this variable on the MAG is set to a value of (0), the MAG must explic= itly indicate its support-capability for this feature by including the LMA = User Plane Address mobility Option in the Proxy Binding Update. Best regards, Georgios From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj Patil Sent: woensdag 12 maart 2014 19:43 To: netext@ietf.org Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Hello, This is the working group last call for I-D: Separation of Control and User= Plane for Proxy Mobile IPv6 . This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F444A27EXMBX23adutwent_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have read the draft. I think = that the draft is in a good shape and I think that we can proceed with the = RFC publication process. However, I have some comments, which need some att= ention!

 

Comment_1: : In Section 3, the = LMA user plane address mobility option is specified. Regarding the Length f= ield the following is mentioned: “8-bit unsigned integer indicating t= he length of the option in octets, excluding the type and length fields.” This is okay, but why is the Length fie= ld does not exclude in addition to the type and length fields, also the Res= erved field. I think that this will make sense. You may change the descript= ion of the Length field to: “8-bit unsigned integer indicating the length of the option in octets, excluding the type,= length and Reserved fields.”

 

Comment_2: In Section 3, the LM= A user plane address mobility option is specified. However, it is not clear= what will be the format of this option when the LMA user plane address is = an IPv4 address.

You could solve this by adding = in the description of the LMA User Plane Address field what will be the val= ue of the Length field when either an IPv4 is used or an IPv6 address is us= ed. Note that this is partially done in Section 4. Note also that in the provided description of the Length fie= ld in Section 4, you already assume that the length of the option in octets= , is already excluding the type, length and Reserved fields, while in Secti= on 3, the Reserved field is not excluded.

 

Comment_3: In Section 3, the de= finition of the LMA User Plane Address field, you probably need to include = the term LMA user plane, instead of LMA. This the description of this field= can become: “Contains either the 32-bit IPv4 address of the LMA user plane, when the value of the Length field is = set to 4, or the 128-bit IPV6 of the LMA user plane, when the value of the = Length field is set to 16.

 

Comment_4: Regarding Figure 1, = you might need to use different boxes for MAG CP and MAG-UP.

 

Comment_5: The IANA section mig= ht need more details, regarding what you are requesting!<= /p>

 

Comment_6: typo, in Section 6, = use Proxy Binding Update instead of Proxy Binding Acknowledgement .

Please change from:<= /span>

When this variable on the MAG i= s set to a value of (0), the MAG must explicitly indicate its support-capab= ility for this feature by including the LMA User Plane Address mobility Opt= ion in the Proxy Binding Acknowledgement. 

 

INTO:

When this variable on the MAG i= s set to a value of (0), the MAG must explicitly indicate its support-capab= ility for this feature by including the LMA User Plane Address mobility Opt= ion in the Proxy Binding Update. 

 =

Best regards,=

Georgios

 = ;

From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj Patil
Sent: woensdag 12 maart 2014 19:43
To: netext@ietf.org
Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org
Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separat= ion

 

Hello,

 

This is the working group last call for I-D: Separation of Control and User Plane for Proxy Mo= bile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.

 

This I-D is intended to be progressed as a standards= track document. 

Please review and post your comments on the mailing = list.

The last call will expire on March 27th, 14. 

 

-Chairs

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F444A27EXMBX23adutwent_-- From nobody Thu Mar 27 14:42:47 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 22C301A03CC for ; Thu, 27 Mar 2014 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8shyOvbNcNDj for ; Thu, 27 Mar 2014 14:42:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 904ED1A0692 for ; Thu, 27 Mar 2014 14:42:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6FA181071E8; Thu, 27 Mar 2014 22:42:38 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGe0TVWk9nU1; Thu, 27 Mar 2014 22:42:38 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 4D75A107156; Thu, 27 Mar 2014 22:42:23 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.163]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 27 Mar 2014 22:42:23 +0100 From: Marco Liebsch To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPPiLn3T3WEXFlZEKoETZH47PJb5r1jihg Date: Thu, 27 Mar 2014 21:42:23 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D6982C0AB@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D6982C0ABPALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/oomecm8ZehioTNBgt3MrfnQ3DVE Cc: "draft-ietf-netext-pmip-cp-up-separation@tools.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: Thu, 27 Mar 2014 21:42:44 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D6982C0ABPALLENEofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the draft addresses all relevant aspects and specifies the required= option to enable C/U-Plane separation on the LMA. The document is pretty concise, I'd= say. A few notes below for co-authors' consideration: "1. Introduction: Widely deployed mobility management systems for wireless communications require isolation between the path for forwarding data packets (the user plane) and the control plane signaling..." [marco] How can deployed systems require this? I thing deployed systems utilize such split to gain advantage from it, e.g. more flexible deployment. You may change the text to motivate a C-/U-Plane split on the LMA 'to be more flexible in the deployment and placement of Control-= and User-Plane Functions' and that 'deployed systems for mobile communication utilize such split already'. "..require isolation between the path for forwarding data packets (the user plane) and the control plane signaling for mobility management." [marco] 'isolation between paths' may not be clear. What about 'separation = of IP-endpoints for PMIP signaling and forwarding tunnel' ? [marco] Text has no reference to Figure 1 and should be added, e.g. in the = last paragraph of Section 1. Section 6. Protocol Configuration Variables [marco] Let me confirm the use of the configuration variable Domain-wide-LM= A-UPA-Support: If set, no explicit capability discovery is required and a MAG or LMA can include the LMA UPA option if they want to use C/U-Plane separation, or omit it. If cleared, it means some components (MAGs and LMAs) may support the feature, some others may not. So, if a MAG supports it MUST include the option with a value of ALL_ZERO for the address field or omit the address f= ield. If not included, the LMA keeps record of MAGs which do not support the feat= ure. So, the configuration variable, if set, solely helps to reduce signaling me= ssage size by omitting the option. Correct? [marco] Check some editorial nits, e.g. Sect. 2 Terms: MAG User Plane Address (MAG-UP): The IP address on the MAG that is supports user plane tunnels with the LMA. --> The IP address on the MAG that supports user plane tunnels with the LMA= . Section 4. The MAG when including the LMA User Plane Address mobility option in the Proxy Binding Update has to the apply the following considerations: --> The MAG when including the LMA User Plane Address mobility option in the Proxy Binding Update has to apply the following considerations: and.. 'apply the following considerations' --> 'apply the following rules' (?) Hope that helps. Best regards, marco From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj Patil Sent: Mittwoch, 12. M=E4rz 2014 19:43 To: netext@ietf.org Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation Hello, This is the working group last call for I-D: Separation of Control and User= Plane for Proxy Mobile IPv6 . This I-D is intended to be progressed as a standards track document. Please review and post your comments on the mailing list. The last call will expire on March 27th, 14. -Chairs --_000_69756203DDDDE64E987BC4F70B71A26D6982C0ABPALLENEofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think the draft address= es all relevant aspects and specifies the required option to
enable C/U-Plane separation on the LMA. The document is pretty concise, I&#= 8217;d say.
A few notes below for co-authors’ consideration:

 <= /p>

“1. Introduction: Widely deployed mobility management systems for wireless=

communications require isolation between the path for forw= arding data

packets (the user plane) and the control plane signaling&#= 8230;”

 

[marco] How can deployed systems require this? I thing dep= loyed systems
utilize such split to gain advantage from it, e.g. more flexible
deployment. You may change the text to motivate a C-/U-Plane split
on the LMA ‘to be more flexible in the deployment and placement of Co= ntrol- and User-Plane
Functions’ and that ‘deployed systems for mobile communication = utilize such

split already’.

 

 

“..require isolation between the path for forwarding data
   packets (the user plane) and the control plane signaling =
for mobility
   management.”

 

[marco] ‘isolation = between paths’ may not be clear. What about ‘separation of IP-e= ndpoints for PMIP signaling
and forwarding tunnel’ ?

 <= /p>

 <= /p>

[marco] Text has no refer= ence to Figure 1 and should be added, e.g. in the last paragraph of Section= 1.

 <= /p> 

Section 6. Protocol Configuration Va=
riables

 <= /p> 

[marco] Let me confirm the use of the confi=
guration variable Domain-wide-LMA-UPA-Support:
If set, no explicit capability discovery is required and a MAG or LMA =
can
include the LMA UPA option if they want to use C/U-Plane separation,=
 or
omit it.
If cleared, it means some components (MAGs and LMAs) may support thefeature, some others may not. So, if a MAG supports it MUST include theoption with a value of ALL_ZERO for the address field or omit the address=
 field.
If not included, the LMA keeps record of MAGs which do not support the=
 feature.
So, the configuration variable, if set, solely helps to reduce=
 signaling message
size by omitting the option. Correct? 

 <=
/p>

[marco] Check some editorial nits, e.g. Sec=
t. 2 Terms: 
MAG User Plane Address (MAG-UP):


The IP address on the MAG that is supports user plane tunnels with the=
 LMA.


=E0 The IP address on the=
 MAG that supports user plane tunnels with the LMA.


 


Section 4.


The MAG when including the LMA User Plane Address mobility option=



in the Proxy Binding Update has to the apply the following<=
/pre>

considerations:


=E0 The MAG when includin=
g the LMA User Plane Address mobility option


in the Proxy Binding Update has to apply the following

considerations:


 


 


and..


‘apply the following considerations’ =E0 ‘apply the following rules’ (?)


 


 


Hope that helps.


 


Best regards,


marco


 <=
/p>

 <=
/p>







From: netext [=
mailto:netext-bounces@ietf.org]
On Behalf Of Basavaraj Patil

Sent: Mittwoch, 12. M=E4rz 2014 19:43

To: netext@ietf.org

Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org

Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separat=
ion






 




Hello,




 






This is the working group last call for I-D: Separation of Control and User Plane for Proxy Mo=
bile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.






 






This I-D is intended to be progressed as a standards=
 track document. 






Please review and post your comments on the mailing =
list.






The last call will expire on March 27th, 14. 






 






-Chairs






 
--_000_69756203DDDDE64E987BC4F70B71A26D6982C0ABPALLENEofficehd_-- From nobody Fri Mar 28 10:50: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 650731A0969; Fri, 28 Mar 2014 10:50:55 -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 4AgHQuFlCUya; Fri, 28 Mar 2014 10:50:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F29DA1A096A; Fri, 28 Mar 2014 10:50:53 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328175053.19715.7405.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 10:50:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/SZ9zl8yGr0FQaAuHD4jCOiah5a8 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-12.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, 28 Mar 2014 17:50:55 -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 : Quality of Service Option for Proxy Mobile IPv6 Authors : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-12.txt Pages : 68 Date : 2014-03-28 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip6-qos-12 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 Sun Mar 30 18:39:18 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 43D351A090E for ; Sun, 30 Mar 2014 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OGz9Rzd80Uiz for ; Sun, 30 Mar 2014 18:39:14 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7C50A1A03E9 for ; Sun, 30 Mar 2014 18:39:14 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kq14so7516271pab.9 for ; Sun, 30 Mar 2014 18:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlFhDeYzSlBBAEDkZiu6YzMEbjP6tOhyJe4DTpylwnU=; b=pQRst7Q3DLTgU5SIM7jYQYZihHzEdUE6VaVWdVjb8yr+ZS20sNj0VQL/JCgNcO/TgZ +bccvt/bbtHsEzue2trFw0GJfZsGb6wKdnegwSR8xnSfN1s1JXx2B8QJI1yj95NRlWJO 8cN657zci6Qz4Ru9hFdgN+JcySK0F2/kGR0ZYt2Uo3DtEIRLIie9B/wVNtENTziXFJ9F /yynDL2zIm6P3rSSiiMLunLtaCPhP13xhjz6USNJHcOB5xP8jHwcG0wnW96Fn5dGuUbH rbGm1LkN2hNFagOVyR6Mf82OqHZA/QUEv3c0FyubGGuQWnb4oATVMkVH9ASo0bRHsldJ ZmQw== X-Received: by 10.68.100.1 with SMTP id eu1mr21793106pbb.36.1396229950630; Sun, 30 Mar 2014 18:39:10 -0700 (PDT) Received: from [10.201.84.2] ([202.45.12.142]) by mx.google.com with ESMTPSA id v1sm12145834pbl.1.2014.03.30.18.39.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Mar 2014 18:39:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ryuji Wakikawa In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6982C0AB@PALLENE.office.hd> Date: Mon, 31 Mar 2014 10:39:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69756203DDDDE64E987BC4F70B71A26D6982C0AB@PALLENE.office.hd> To: Marco Liebsch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/pD2J9BURcMLBRyP1us8pCxH0NFs Cc: "netext@ietf.org" , Basavaraj Patil , "draft-ietf-netext-pmip-cp-up-separation@tools.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: Mon, 31 Mar 2014 01:39:17 -0000 Hi Marco Thanks for your review and the comments. On 2014/03/28, at =E5=8D=88=E5=89=8D6:42, Marco Liebsch = wrote: > I think the draft addresses all relevant aspects and specifies the = required option to > enable C/U-Plane separation on the LMA. The document is pretty = concise, I=E2=80=99d say. > A few notes below for co-authors=E2=80=99 consideration: > =20 > =E2=80=9C1. Introduction: Widely deployed mobility management systems = for wireless > communications require isolation between the path for forwarding data > packets (the user plane) and the control plane signaling=E2=80=A6=E2=80=9D= > =20 > [marco] How can deployed systems require this? I thing deployed = systems > utilize such split to gain advantage from it, e.g. more flexible > deployment. You may change the text to motivate a C-/U-Plane split > on the LMA =E2=80=98to be more flexible in the deployment and = placement of Control- and User-Plane > Functions=E2=80=99 and that =E2=80=98deployed systems for mobile = communication utilize such > split already=E2=80=99. > =20 > =20 > =E2=80=9C..require isolation between the path for forwarding data > packets (the user plane) and the control plane signaling for = mobility > management.=E2=80=9D > =20 > [marco] =E2=80=98isolation between paths=E2=80=99 may not be clear. = What about =E2=80=98separation of IP-endpoints for PMIP signaling > and forwarding tunnel=E2=80=99 ? How about this? Widely deployed mobility management systems for wireless communications require separation of IP end points for fowarding data packets (the user plane) and the mobility signaling (the control plane). This separation brings more flexible deployment and management of LMA and MAG(s) of Proxy Mobile IP. >=20 > [marco] Text has no reference to Figure 1 and should be added, e.g. in = the last paragraph of Section 1. we will add reference. > =20 > Section 6. Protocol Configuration Variables > =20 > [marco] Let me confirm the use of the configuration variable = Domain-wide-LMA-UPA-Support: > If set, no explicit capability discovery is required and a MAG or LMA = can > include the LMA UPA option if they want to use C/U-Plane separation, = or > omit it. > If cleared, it means some components (MAGs and LMAs) may support the > feature, some others may not. So, if a MAG supports it MUST include = the > option with a value of ALL_ZERO for the address field or omit the = address field. > If not included, the LMA keeps record of MAGs which do not support the = feature. > So, the configuration variable, if set, solely helps to reduce = signaling message > size by omitting the option. Correct?=20 Yes, since PMIP is run in the managed domain, the operator should use = this parameter as you explained above.=20 > [marco] Check some editorial nits, e.g. Sect. 2 Terms:=20 > MAG User Plane Address (MAG-UP): > The IP address on the MAG that is supports user plane tunnels with the = LMA. > =C3=A0 The IP address on the MAG that supports user plane tunnels with = the LMA. > =20 > Section 4. > The MAG when including the LMA User Plane Address mobility option > in the Proxy Binding Update has to the apply the following > considerations: > =C3=A0 The MAG when including the LMA User Plane Address mobility = option > in the Proxy Binding Update has to apply the following > considerations: > =20 > =20 > and.. > =E2=80=98apply the following considerations=E2=80=99 =C3=A0 =E2=80=98app= ly the following rules=E2=80=99 (?) Thanks for finding these errors! really help! regards, ryuji > =20 > =20 > Hope that helps. > =20 > Best regards, > marco > =20 > =20 > From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj = Patil > Sent: Mittwoch, 12. M=C3=A4rz 2014 19:43 > To: netext@ietf.org > Cc: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org > Subject: [netext] WG last call: = draft-ietf-netext-pmip-cp-up-separation > =20 > Hello, > =20 > This is the working group last call for I-D: Separation of Control and = User Plane for Proxy Mobile IPv6 = . > =20 > This I-D is intended to be progressed as a standards track document.=20= > Please review and post your comments on the mailing list. > The last call will expire on March 27th, 14.=20 > =20 > -Chairs > =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From nobody Mon Mar 31 12:30: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 AECE31A6F6C; Mon, 31 Mar 2014 12:30:07 -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 Mh9gpWdKVF8y; Mon, 31 Mar 2014 12:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFB91A6F91; Mon, 31 Mar 2014 12:30:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331193004.31863.20939.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 12:30:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/W3AtFYQDaGfJxvnCcl6FtqVcxwM Cc: netext mailing list , netext chair , RFC Editor Subject: [netext] Protocol Action: 'Quality of Service Option for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-pmip6-qos-12.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: Mon, 31 Mar 2014 19:30:07 -0000 The IESG has approved the following document: - 'Quality of Service Option for Proxy Mobile IPv6' (draft-ietf-netext-pmip6-qos-12.txt) as Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ Technical Summary: 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. Working Group Summary: The WG supports this I-D as it is relevant in the context of the protocols applicability within 3GPP standards. There is strong support to standardize this work. It has been reviewed multiple times by several experts. Document Quality: There is at least one known implementation of the protocol. There is good support for the specification and an interest in utilizing the protocol as a feature by various vendors. All reviewers of the I-D have been acknowledged in the document. Personnel: Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman From nobody Mon Mar 31 17:07:44 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 E892A1A6F79; Mon, 31 Mar 2014 17:07: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 3T01lfZZ7JUN; Mon, 31 Mar 2014 17:07:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B051A08E5; Mon, 31 Mar 2014 17:07:35 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401000735.31254.41694.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 17:07:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/MLi_jeSDPIjxmLshxFcg9zju85U Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-07.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: Tue, 01 Apr 2014 00:07:38 -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 : EAP Attributes for WiFi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-07.txt Pages : 14 Date : 2014-03-31 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-07 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/