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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 23 February 2015 14:01 UTC

Return-Path: <swmike@swm.pp.se>
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 91F031A1A9E for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:01:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 syRLzvkCij0J for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:01:45 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B7D1A1AA0 for <v6ops@ietf.org>; Mon, 23 Feb 2015 06:01:45 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 85DC4A2; Mon, 23 Feb 2015 15:01:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424700103; bh=Yr4gHusFv8iIH+Q/QDY7uHozeKqYNRyNoe3WasAeJ1M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mrNrjZw39H/XMFpJd0LLRsS0oZzg3ykxlWnQ8nTdm1srEJpTj4BOqL2q8Rxhizhp0 J2drxDxY0GguvpAlVGL3HvmeT4uVRVlBF1k6MPhoOTcszgnGu3FDnQsPOApGf8CuDL zLyLsErc44KxOdYibFQLlFxA1HStjXZlV2CquxcQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7E7BFA1; Mon, 23 Feb 2015 15:01:43 +0100 (CET)
Date: Mon, 23 Feb 2015 15:01:43 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lorenzo Colitti <lorenzo@google.com>
In-Reply-To: <CAKD1Yr1ZG_rOZLCXtOjeNwAHbKzcnuRzUhitznp-5J0RP4CV9w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1502231459150.4007@uplift.swm.pp.se>
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>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/62PCLp-IS9wqCSx-C9xWmZ4x8vo>
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:01:48 -0000

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