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

Dave Michaud <> Mon, 23 February 2015 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B655A1A1AA9 for <>; Mon, 23 Feb 2015 06:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 00kyEedjH4YU for <>; Mon, 23 Feb 2015 06:05:44 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A2921A1A81 for <>; Mon, 23 Feb 2015 06:05:44 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 23 Feb 2015 14:05:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 14:05:23 +0000
From: Dave Michaud <>
To: Mikael Abrahamsson <>, Lorenzo Colitti <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Mon, 23 Feb 2015 14:05:22 +0000
Message-ID: <>
References: <> <> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1068;
x-microsoft-antispam-prvs: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: <>
Cc: V6 Ops List <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 | tel: +1 647.747.9442 | mobile: +1

On 2015-02-23, 09:01, "Mikael Abrahamsson" <> wrote:

>On Mon, 23 Feb 2015, Lorenzo Colitti wrote:
>> On Mon, Feb 23, 2015 at 10:25 PM, Dave Michaud
>> 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
>>> 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
>> 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
>it gets CC52.
>How else should the network signal to the UE that it should bring up a
>second PDP context?
>Mikael Abrahamsson    email:

This communication is confidential. We only send and receive email on the basis of the terms set out at<>

Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à <>