IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Dave Michaud <Dave.Michaud@rci.rogers.com> Mon, 23 February 2015 14:05 UTC

Return-Path: <Dave.Michaud@rci.rogers.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B655A1A1AA9 for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 00kyEedjH4YU for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:05:44 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2921A1A81 for <v6ops@ietf.org>; Mon, 23 Feb 2015 06:05:44 -0800 (PST)
Received: from CY1PR0401MB1065.namprd04.prod.outlook.com (25.160.161.145) by CY1PR0401MB1068.namprd04.prod.outlook.com (25.160.161.148) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 14:05:23 +0000
Received: from CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) by CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 14:05:23 +0000
From: Dave Michaud <Dave.Michaud@rci.rogers.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZz6AFWAgAQGuYCAAALSgIAACEIAgAAkWICAABavAP//wUeAgABcwgCAAAEYgP//rS8A
Date: Mon, 23 Feb 2015 14:05:22 +0000
Message-ID: <D1109D5C.1AD8C%dave.michaud@rci.rogers.com>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <alpine.DEB.2.02.1502201513320.4007@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr3A6fzgTauLz+Yxe-xOLeDLZ5bzKBo-XyWU4i9LBSAM9Q@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr1c74gbnR51caf_WTKi7FFTbJP0KhwwXtabsvNhiE2Lgw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <D11092F8.1AD6E%dave.michaud@rci.rogers.com> <CAKD1Yr1ZG_rOZLCXtOjeNwAHbKzcnuRzUhitznp-5J0RP4CV9w@mail.gmail.com> <alpine.DEB.2.02.1502231459150.4007@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1502231459150.4007@uplift.swm.pp.se>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [162.208.80.3]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1068;
x-microsoft-antispam-prvs: <CY1PR0401MB10689BD8A447D1BC6805F9A1C4290@CY1PR0401MB1068.namprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1068;
x-forefront-prvs: 0496DF6962
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(377424004)(51704005)(377454003)(189002)(199003)(2656002)(106116001)(19580405001)(68736005)(2950100001)(2900100001)(87936001)(105586002)(66066001)(99286002)(106356001)(15975445007)(77156002)(62966003)(101416001)(54356999)(83506001)(46102003)(50986999)(76176999)(93886004)(97736003)(15974865002)(64706001)(19580395003)(40100003)(122556002)(92566002)(102836002)(86362001)(74826001)(19273905006)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1068; H:CY1PR0401MB1065.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-ID: <54F564DA4173714EBCA0D899BF6BD5EA@namprd04.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rci.rogers.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 14:05:22.8254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1068
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/jrxkvIgwMuedmXmDQfodswYKwhw>
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 14:05:46 -0000

I am of the same opinion.

I am not saying that operators should or should not do that (it¹s up to
them to decide) but if they send a CC52, I expect the UEs to request
another primary PDP.

If the operator does not want this behavior, CC50 and CC51 are available
for that purpose.


Dave Michaud
Sr. Architect Mobility ­ Access Networks & IP Network Services
Network Technology | Rogers Communications
dave.michaud@rci.rogers.com | tel: +1 647.747.9442 | mobile: +1
416.219.5531






On 2015-02-23, 09:01, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

>On Mon, 23 Feb 2015, Lorenzo Colitti wrote:
>
>> On Mon, Feb 23, 2015 at 10:25 PM, Dave Michaud
>><Dave.Michaud@rci.rogers.com>
>> wrote:
>>
>>>  In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type
>>> selected by the network (IPv4 or IPv6) and not proceed further. Cause
>>>code
>>> 52 is the mean by which the network signals that it will allow two
>>> distincts PDP of different address type. In that case only is the UE
>>> suppose to go back and request a second PDP with the alternate type not
>>> offered by the network at the same time cause code 52 was returned.
>>
>> Actually the behaviour depends on the release. Release 8 says the MS
>>"MAY
>> request another PDP context for the other PDP type".
>>
>> In any case, I think we agree that this is not something that we want to
>> recommend?
>
>I don't agree. I agree with the above description of the CC52 code, and I
>definitely want (and expect) the UE to set up a second PDP context in
>case
>it gets CC52.
>
>How else should the network signal to the UE that it should bring up a
>second PDP context?
>
>--
>Mikael Abrahamsson    email: swmike@swm.pp.se





________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>



Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

v2.23.0 | Report a Bug | By Email