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

<mohamed.boucadair@orange.com> Mon, 23 February 2015 07:59 UTC

Return-Path: <mohamed.boucadair@orange.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 55AFE1A0275 for <v6ops@ietfa.amsl.com>; Sun, 22 Feb 2015 23:59:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yYUteLNbjzHe for <v6ops@ietfa.amsl.com>; Sun, 22 Feb 2015 23:59:26 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5801A026F for <v6ops@ietf.org>; Sun, 22 Feb 2015 23:59:26 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 85C522AC0F6; Mon, 23 Feb 2015 08:59:24 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 368B0180073; Mon, 23 Feb 2015 08:59:24 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%35]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 08:59:24 +0100
From: <mohamed.boucadair@orange.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQTTthIBd3RGtSR02IrTMsDHyUSpz93h0g
Date: Mon, 23 Feb 2015 07:59:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <alpine.DEB.2.02.1502201513320.4007@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1502201513320.4007@uplift.swm.pp.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/phY62ytgC42m18lKX6d0cM6kux8>
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 07:59:28 -0000

Hi Mikael,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Mikael
> Abrahamsson
> Envoyé : vendredi 20 février 2015 19:30
> À : V6 Ops List
> Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
> 
> On Wed, 28 Jan 2015, Fred Baker (fred) wrote:
> 
> > Please read it now, and comment. This WGLC will run until 15 February.
> 
> I have re-read the latest incarnation just now. I am going to treat it as
> if I never read it before:
> 
> 1.2.
> 
> I know what a "shorter prefix than /64" is. A lot of readers might not, so
> I would like to insert at "(larger)" in there, or similar text.

[Med] Fixed in 2 occurrences in the I-D: s/shorter prefix than /64/larger prefixes.

> 
> C_REC#2:
> 
> Second paragraph, suggest text to clarify that adding the second PDP
> context is to achieve dual stack connectivity by means of these two PDP
> contexts.

[Med] I made this change:

OLD:
             *  If the requested IPv4v6 PDP-Context is not supported by
                the network, but IPv4 and IPv6 PDP types are allowed,
                then the cellular host will be configured with an IPv4
                address or an IPv6 prefix by the network.  It must
                initiate another PDP-Context activation in addition to
                the one already activated for a given APN (Access Point
                Name).  

NEW:

             *  If the requested IPv4v6 PDP-Context is not supported by
                the network, but IPv4 and IPv6 PDP types are allowed,
                then the cellular host will be configured with an IPv4
                address or an IPv6 prefix by the network.  It must
                initiate another PDP-Context activation in addition to
                the one already activated for a given APN (Access Point
                Name).  The purpose of initiating a second PDP-Context
                is to achieve dual-stack connectivity by means of two
                PDP-Contexts.
> 
> C_REC#6:
> 
> "restarts the ongoing applications". I don't like this wording, "will
> interrupt existing network connections" or similar text would be better.

[Med] I made this change:

OLD:

                Note, a cellular host changing its connection between an
                IPv6-specific APN and an IPv4-specific APN restarts the
                ongoing applications.  This may be considered as a
                brokenness situation.

NEW:
                Note, a cellular host changing its connection between an
                IPv6-specific APN and an IPv4-specific APN will
                interrupt associated network connections.  This may be
                considered as a brokenness situation for some
                applications.

To Alex: Can you please review this text (because you are the one who asked to have the OLD version)

> 
> C_REC#7:
> 
> typo:
> 
> "The purpose of the of the roaming profile is"

[Med] Fixed. Thank you.

> 
> C_REC#8:
> 
> I don't understand the reference to 6052. Is this a referral to networks
> with NAT64 and/or 464XLAT? Then I think this should be clearer.

[Med] This feature is for NAT64 context in general, but without requiring any packet translation feature.

OLD:
                This solves the issue when applications use IPv4
                referrals on IPv6-only access networks.

NEW:

                In the context of NAT64, applications relying on address
                referrals will fail because an IPv6-only client won't be
                able to make use of an IPv4 address received in a
                referral.  This feature allows to solve this referral
                problem and, also, to distinguish between IPv4-converted
                IPv6 addresses [RFC6052] and native IPv6 addresses. 

Better?

> 
> L_REC#4: Isn't this a duplication of one of the C_RECs?

[Med] This one is for IPv4 devices connected via the cellular device through an IPv6-only network. The one in C_REC#8 is about local applications running on the cellular host.  

> 
> Summary:
> 
> I think this kind of document is valuable. Many operators do not have
> staff with right skill level to put in the requirements towards equipment
> manufacturers, and in some markets, the equipment manufacturers are
> selling directly to consumers without discussing details with operators. I
> also feel that the vendors of mobile equipment would benefit from having a
> more unified set of requirements from the operators.
> 
> Either these requirements can be gathered within the IETF for IP related
> matters, or operators can try to do it in another venue. I don't see why
> the IETF can't be the venue for this.
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops