Subject: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 19 Aug 2013 06:52:19 -0700

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices'
  <draft-ietf-v6ops-mobile-device-profile-04.txt> as Informational RFC

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
[email-masked] mailing lists by 2013-09-02. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies an IPv6 profile for 3GPP mobile devices.  It
   lists the set of features a 3GPP mobile device is to be compliant
   with to connect to an IPv6-only or dual-stack wireless network
   (including 3GPP cellular network and IEEE 802.11 network).

   This document defines a different profile than the one for general
   connection to IPv6 cellular networks defined in
   [I-D.ietf-v6ops-rfc3316bis].  In particular, this document identifies
   also features to deliver IPv4 connectivity service over an IPv6-only
   transport.

   Both hosts and devices with capability to share their WAN (Wide Area
   Network) connectivity are in scope.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 20 Aug 2013 09:50:02 +0100

Given we have been discussing 3GPP IPv6 Roaming, I was thinking of any mobile terminal requirements that come from roaming.
There seems to be no specifics regarding roaming in this paper.

One solution appears to be coming into favour to fix one type of operational deficiencies in current roaming: that the terminal can be configured with a home IP profile and a roaming IP profile. This is not so much a compliance requirement, as protecting the subscriber against exceptions when roaming. Should this be included in this paper? Or would this need further debate beyond the scope of this paper?
What are your thoughts?
Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of The IESG
> Sent: 19 August 2013 14:52
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-
> 04.txt>(Internet Protocol Version 6 (IPv6) Profile for 3GPP
> MobileDevices) to Informational RFC
> 
> 
> [email-masked] mailing lists by 2013-09-02. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

Everything Everywhere Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Aug 2013 18:39:18 +0900

>    (including 3GPP cellular network and IEEE 802.11 network).

I object to this document on the grounds that it is little more than a list
of (34!) features with little technical justification. I see this as a
problem because:

1. It is out of the IETF's mandate. It is not the IETF's job to specify
which features or protocols should or should not be implemented in hosts.
Even the hosts requirements RFCs are careful and sparing in their language.
The IETF is certainly not in the business of rubberstamping feature
wishlists without good technical reasons. I would challenge the authors to
find a precedent RFC containing such broad requirements.

2. It is over-broad. The vast majority of the features are in no way
necessary to build a mobile device that works well over IPv6. Today, the
overwhelming majority of mobile device traffic comes from devices that
implement only a handful of these requirements. More specifically,
requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20,
#21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which
cover all applications running on the device - yes, all of them), and #34,
are not necessary to connect to IPv6 mobile networks.

3. It is so daunting as to act as a deterrent to IPv6 deployment. I would
challenge the authors to find a single product today that implements all,
or even a substantial majority, of these requirements. It seems to me that
the sheer length of the list, and the fact that is not prioritized, create
a real risk that implementors will simply write it off as wishful thinking
or even shy away in terror.

4. The document has few technical contributions of its own. Most of the
requirements are simply listed one after another.

I'm all for IPv6 deployment in mobile networks, but making a list of what
seems like all the features that the IETF has ever developed, and then
saying that they all need to be implemented, is not the way to get there.
The way to do it is to document use cases and working scenarios gleaned
from operational experience.

Regards,
Lorenzo

---

From: <[email-masked]>
Date: Tue, 20 Aug 2013 14:53:11 +0200

Hi Nick,

A new version of the draft will be edited at least taking into account comments received during this last call process. 
A requirement to guarantee that the device has some IP connectivity in roaming context, like the one you mention, is likely to be integrated in this upcoming version even if the discussions about roaming will continue and will go beyond device capabilities.  

David

> -----Message d'origine-----
> De : Heatley, Nick [mailto:[email-masked]] 
> Envoyé : mardi 20 août 2013 10:50
> À : [email-masked]; BINET David IMT/OLN; Byrne, Cameron; 
> [email-masked]; Vizdal Ales (TMCZ)
> Cc : [email-masked]
> Objet : RE: [v6ops] Last Call: 
> <draft-ietf-v6ops-mobile-device-profile-04.txt>(Internet 
> Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to 
> Informational RFC
> 
> Given we have been discussing 3GPP IPv6 Roaming, I was 
> thinking of any mobile terminal requirements that come from roaming.
> One solution appears to be coming into favour to fix one type 
> of operational deficiencies in current roaming: that the 
> terminal can be configured with a home IP profile and a 
> roaming IP profile. This is not so much a compliance 
> requirement, as protecting the subscriber against exceptions 
> when roaming. Should this be included in this paper? Or would 
> this need further debate beyond the scope of this paper?
> What are your thoughts?
> Nick
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of The IESG
_________________________________________________________________________________________________________________________

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.

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.

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Aug 2013 16:58:22 -0700

On Aug 20, 2013, at 02:39 , Lorenzo Colitti <[email-masked]> wrote:
> 
> [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...]

My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo.  This draft seems unnecessary to me.

--
james woodyatt <[email-masked]>
core os networking

---

From: Owen DeLong <[email-masked]>
Date: Tue, 20 Aug 2013 17:13:47 -0700

I also agree with James and Lorenzo.

Owen

---

From: Erik Kline <[email-masked]>
Date: Thu, 22 Aug 2013 20:21:38 +0900

REQ 1:
    6434 5.9.1 is already a MUST.  This does not need to be repeated.
    6434 5.8 is already a MUST.  Unless you want to make multipart
ICMP a MUST (why?) as well, this too can be removed.

REQ 6:
    re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST
    frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so
this MUST appears stronger.  Bizarre, though, I never noticed that "ND
SHOULD" before.

REQ 10:
    this reads kind weird.  In REQ 9 you require 6106 support, but in
REQ 10 you say "if 6106 is not supported."  I think you mean something
like "if the network to which the mobile node is attaching does not
support 6016".

---

From: <[email-masked]>
Date: Thu, 22 Aug 2013 14:05:54 +0200

Hi Erik,

Thank you for the review. 

Please see inline.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de
>Erik Kline
>Envoyé : jeudi 22 août 2013 13:22
>À : Owen DeLong
>Cc : [email-masked]; IETF Discussion
>Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-
>04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile
>Devices) to Informational RFC
>
>REQ 1:

[Med] Because some requirements are stronger in this document than what is documented in RFC6434, we had two way to implement this in the document:
(a) Indicate RFC6434 must be supported with the exceptions in the language for some requirements listed in this document.
(b) Call out explicitly the requirements from RFC6434 that are mandatory + indicate which requirements are stronger than rfc6434.
We decided to go for (b) as it provides a comprehensive list of requirements for 3GPP mobile devices grouped in one single document. IMHO, this is just a matter of presentation. 

This rationale is explained in the introduction.

>this MUST appears stronger.  Bizarre, though, I never noticed that "ND

[Med] The language is stronger compared to the SHOULD in Section 5.2 of RFC6434.

>like "if the network to which the mobile node is attaching does not

[Med] Yes, agree. As mentioned in the document,

"   Some of the features listed in this profile document require to
   activate dedicated functions at the network side."

This will be fixed.

---

From: <[email-masked]>
Date: Tue, 27 Aug 2013 09:03:15 +0200

Hi Nick,

I added this new text:

   REQ#19:  Because of potential operational deficiencies to be
        experienced in some roaming situations, the cellular host MUST
        be able to be configured with a home IP profile and a roaming IP
        profile.  The aim of the roaming profile is to limit the PDP
        type(s) requested by the cellular host when out of the home
        network.  Note, distinct PDP type(s) can be configured for home
        and roaming cases.

Please let me know if this text solves your concern. 

Cheers,
Med

>[email-masked]
>Envoyé : mardi 20 août 2013 14:53
>À : Heatley, Nick; [email-masked]; Byrne, Cameron; [email-masked];
>Vizdal Ales (TMCZ)
>04.txt>(Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices)
>to Informational RFC
>
>Hi Nick,
>
>A new version of the draft will be edited at least taking into account
>comments received during this last call process.
>A requirement to guarantee that the device has some IP connectivity in
>roaming context, like the one you mention, is likely to be integrated in
>this upcoming version even if the discussions about roaming will continue
>and will go beyond device capabilities.
>
>David
>
>___________________________________________________________________________
>______________________________________________
>
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 27 Aug 2013 21:05:21 +1000

Reviewer: Abdussalam Baryun
Date: 26.08.2013

As per the IESG request for review dated 19.08.2013
++++++++++++++++++++++++++++++++++++

I support the draft, thanks, below are my comments,

Overall> The draft is about 3GPP Mobile Devices but the draft has no
normative reference to such device. The title of the draft SHOULD mention
that it is general profile or a proposal, where the abstract says
*specifies an IPv6 profile* which means not general, so the title SHOULD
say *An IPv6 profile*. Also the draft does not consider Mobile IP issues
nor RFC5213 into requirements. From the doc the reviewer is not sure does
the draft consider MANET issues or not needed for such devices or such
connections?

Abstract> This document specifies an IPv6 profile for 3GPP mobile devices.

AB> suggest> this document defines an IPv6 profile....

The document is missing an applicability statement section, which may be
found in one paragraph in section 1.1, but the reviewer would like more
details because the document is some how saying it is general requirements.

AB