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

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 1 Feb 2015 22:38:13 +0900

On Sat, Jan 31, 2015 at 4:50 AM, Ross Chandler <[email-masked]> wrote:

> I just tested bug fixes from another vendor to make 464xlat work with IPv4
> tethering when a shared handset data & tethering APN is used.
>
The software developed I assume to meet the requirements of T-Mobile US
> didn’t work  for the above case although that case works in stock android.
>

There is no text in the document that would have prevented this.

> Another vendor hasn’t said that they’ll support 464xlat and it doesn’t
> look like they’ve any plans to.
>

If you mean Apple, then I doubt that an IETF document will make them change
their mind.

---

From: <[email-masked]>
Date: Mon, 2 Feb 2015 06:32:47 +0000

Hi Barbara,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : STARK, BARBARA H [mailto:[email-masked]] 
Envoyé : vendredi 30 janvier 2015 18:45
À : BOUCADAIR Mohamed IMT/OLN; James Woodyatt
Cc : IPv6 Ops WG
Objet : RE: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

> As per RFC7084, we didn't included it because it included some IPv4
> continuity service features that are not valid for the mobile context. The
> document already mentions the following:
> 
>                 "Note, even if RFC7084 obsoletes [RFC6204], this profile
>                 does not require RFC7084 because IPv4 service continuity
>                 techniques used in mobile networks are not the same as
>                 in fixed networks."

Requiring compliance to an obsoleted RFC (6204) is...um...unusual. Especially since RFC 7084 fixed several items in 6204 that needed fixing. I, personally, would not recommend anything be compliant with RFC 6204.

Also note that DS-Lite and 6rd are "SHOULD" requirements in RFC 7084. It is totally possible for a device to be 100% compliant with RFC 7084 and not do either DS-Lite or 6rd. 

[Med] I fully agree ... but, unfortunately,  this interpretation is not shared. It seems that some think that ALL items mentioned in a document (whatever the language used for individual items) must be supported which is not true. 

Surely mobile device manufacturers are intelligent enough to recognize that there is a very good reason for them not to do DS-Lite or 6rd (because these aren't used in 3GPP networks)? It would also be possible to explicitly note that these technologies are not used or needed for connecting to 3GPP networks.

It's my understanding that when an RFC is obsoleted by another RFC, readers are supposed to consider the new RFC as a replacement for the obsoleted RFC, every time they see a reference to the obsoleted RFC. So a brand new reference to an obsoleted RFC, for me, is rather bizarre. It's boggling my mind.

[Med] I hear you. I will remove the obsolete reference + add a sentence to exclude IPv4 service continuity features mentioned in RFC7084. 

 I'm not convinced that this reference to an obsoleted RFC will be understood in the manner you intend.

[Med] I will follow your suggestion. 

Barbara

---

From: <[email-masked]>
Date: Mon, 2 Feb 2015 06:40:50 +0000

Hi Joel,

Which consensus are your talking about?: The one for adopting the document as a WG item?, the first one declared by the WG before sending it to the IESG? the second one declared by the WG to send the document to the IESG?, or the IETF consensus that was declared before the IESG starts its review?

Cheers,
Med

-----Message d'origine-----
De : joel jaeggli [mailto:[email-masked]] 
Envoyé : samedi 31 janvier 2015 21:49
À : BOUCADAIR Mohamed IMT/OLN; Gert Doering
Cc : [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On 1/30/15 4:21 AM, [email-masked] wrote:
> Re-,
> 
> With all due respect, I'm afraid we are not discussing whether the
> document is needed or not but (as I see it) whether the new version
> does not break the WG consensus that was declared for the version
> sent to the IESG. I recall that both the WG and IETF consensus were
> declared for the version sent to the IESG.

One point on that. Part of the reason we are engaged canvasing, is that
Brian's discussed questioned my interpretation of the consensus call.
Given that I conceded from the outset that the call is somewhat narrow,
one of the questions before us as a w.g. and the ietf community is, is
that consensus more unequivocal?  Brian I believe is willing to extended
the benefit of the doubt. So am I, but it's the working groups document...

thanks

joel

> Thank you.
> 
> Cheers, Med
> 
> -----Message d'origine----- De : Gert Doering [mailto:[email-masked]]
>  Envoyé : vendredi 30 janvier 2015 11:39 À : BOUCADAIR Mohamed
> IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred);
> [email-masked]; V6 Ops
> List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last
> call
> 
> Hi,
> 
> On Fri, Jan 30, 2015 at 09:12:16AM +0000,
> [email-masked] wrote:
>> Can you please help us identifying technical flaws that you think
>> need to be fixed in the document?
> 
> I don't think there is a need for this document, and I can't truly
> see it reflecting WG consensus.  So it's more fundamental than just
> individual technical issues.
> 
> For the specifics, everything that Lorenzo said.
> 
> Gert Doering -- NetMaster
>

---

From: <[email-masked]>
Date: Mon, 2 Feb 2015 07:01:36 +0000

Gert,

The point about successful deployment is not a valid argument. It is about rhetoric, not technical. If we adopt that position, every RFC is useless !!

Please let me clarify the following points:

* This profile is a superset of RFC6434 and RFC7066. For example, the profile lists items to fix some problem for IPv6 deployments (e.g., roaming)
* This profile also covers IPv4 service continuity features over an IPv6 connectivity
* This profile also lists items related to devices with LAN capabilities (there are deployments relying on mobile CPEs)
* The profile includes items related to the delivery of advanced services over IPv6 (e.g., VoLTE profile).
* THE PROFILE DOES NOT REQUIRE IMPLEMENTING ALL THE FEATURES IT LISTS! 
* All these items were present in the draft when both the WG and IETF consensus were declared.

I really recommend you read Section 1.2.

Cheers,
Med

-----Message d'origine-----
De : Gert Doering [mailto:[email-masked]] 
Envoyé : vendredi 30 janvier 2015 17:41
À : Nick Hilliard
Cc : [email-masked]; [email-masked]; BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Hi,

On Fri, Jan 30, 2015 at 04:35:07PM +0000, Nick Hilliard wrote:
> the WG position hasn't materially changed; the document has.

To some extent, reality has changed.  There are a number of large scale
production wireless 3G/4G deployments out there, so the claim "it cannot 
be done because handsets sucks" is most definitely no longer true.

And, as Lorenzo stated, none of these handsets (that work well in 
practice!) fulfills the shopping list in this draft...  which gives that 
the requirements are not needed for successful deployment, and *that*
makes the whole document slightly... superfluous.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: <[email-masked]>
Date: Mon, 2 Feb 2015 12:38:01 +0000

Barbara, 

Your proposed change has been integrated in the new version: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-16 

Please let me know if this solves your concern. Thank you.

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 2 février 2015 07:33
À : STARK, BARBARA H; James Woodyatt
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Hi Barbara,

Please see inline.

Cheers,
Med

-----Message d'origine-----

Barbara
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 3 Feb 2015 19:17:59 +0000

> On Jan 30, 2015, at 4:21 AM, [email-masked] wrote:
> 
> With all due respect, I'm afraid we are not discussing whether the document is needed or not but (as I see it) whether the new version does not break the WG consensus that was declared for the version sent to the IESG. I recall that both the WG and IETF consensus were declared for the version sent to the IESG.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/history/

That’s not quite the way I recall it. In the WG, consensus has always been rough. I sent it out when the number of people stating a dissenting position dwindled. In the IETF LC in September 2013, James, Lorenzo, and Owen made comments that caused Joel to withdraw it from the IESG. In the IETF LC in September 2014 and subsequent IESG discussion, comments were raised by several in the IESG and summarized by Brian Haberman to the effect that the document has serious issues. https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/. In this round, you have tried to address the issues raised.

Before I bother the IESG with it a third time, I’d really like to hear a clear consensus, not a rough one. Where it stands right now, that’s not at all obvious.

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 08:10:54 +0000

Hi,

> > With all due respect, I'm afraid we are not discussing whether the document is
> needed or not but (as I see it) whether the new version does not break the WG
> consensus that was declared for the version sent to the IESG. I recall that both the
> WG and IETF consensus were declared for the version sent to the IESG.
> 
> That's not quite the way I recall it. In the WG, consensus has always been rough. I
> sent it out when the number of people stating a dissenting position dwindled. In
> the IETF LC in September 2013, James, Lorenzo, and Owen made comments that
> caused Joel to withdraw it from the IESG. In the IETF LC in September 2014 and
> subsequent IESG discussion, comments were raised by several in the IESG and
> summarized by Brian Haberman to the effect that the document has serious
> issues. https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-
> profile/ballot/. In this round, you have tried to address the issues raised.
[DB] Based on discussions we had regarding Brian's comments, we did not only try to address these comments. We published a new version taking into consideration these comments and the main comment about 3GPP liaison has been closed because 3GPP has no interest and does not edit such kind of document. 
> 
> Before I bother the IESG with it a third time, I'd really like to hear a clear
> consensus, not a rough one. Where it stands right now, that's not at all obvious.
[DB] Do not you think we are in a loop regarding the process ? There were some WG and IETF consensus, then some final comments we have taken into consideration, and now a new WG last call where no technical comments are raised but only the same arguments we had during the first last call process. And I do not speak about the fact that we may not have, as operators, some legitimacy to edit such document or that some people think that IPv6 deployment is done if 3% of the world population can benefit of some IPv6 connectivity. 

_________________________________________________________________________________________________________________________

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: Gert Doering <[email-masked]>
Date: Wed, 4 Feb 2015 09:31:38 +0100

Hi,

On Wed, Feb 04, 2015 at 08:10:54AM +0000, [email-masked] wrote:
> some people think that IPv6 deployment is done if 3% of the world population can benefit of some IPv6 connectivity. 

I notice that those that actually do deploy IPv6 are not those that complain
about non-deployment.

So, how's Orange's IPv6 deployment coming on?

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 08:45:27 +0000

> Envoyé : mercredi 4 février 2015 09:32
> À : BINET David IMT/OLN
> Cc : Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN; draft-ietf-v6ops-mobile-
> [email-masked]; V6 Ops List
> I notice that those that actually do deploy IPv6 are not those that complain about
> non-deployment.
[DB] It is a "litote" in French language, doesn't it ?
> So, how's Orange's IPv6 deployment coming on?
[DB] Why do you think we are editing with other operators the document we are talking about.?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Feb 2015 17:52:23 +0900

> [DB] Why do you think we are editing with other operators the document we
are talking about.?

Well, but on the other hand, there's an expression in English my mother
always used to use. "Those who can, do. Those who can't, teach". :-)

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Feb 2015 10:03:31 +0100

Hi,

> [DB] Why do you think we are editing with other operators the document we are talking about.?

No idea, TBH.  I look at other operators that have successfully deployed
IPv6 in mobile networks, and fail to see the correspondence to your
document.

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 10:58:40 +0000

> IPv6 in mobile networks, and fail to see the correspondence to your document.
[DB] Operators you are talking about have done a great job regarding IPv6 deployment but you also have to understand that other operators may not have the same strength and the same workforce to get IPv6 support from devices vendors. As Ross said in a previous mail, we still have some specificities regarding devices capabilities and we should try to reach a state where IPv6 support in devices is not a specific feature anymore, whatever the regions or the way consumers purchase their devices. 
Such document can certainly help to progress on such issue but I agree it will not solve everything and operators have to think about their IPv6 introduction strategy and to deploy it effectively.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2015 13:11:41 +0100

I support this draft.

I support it for a particular reason: its stance with respect to
DHCPv6-PD.  It mandates the DHCPv6-PD feature (where other
documents like RFC7066 IPv6/cell are very diffuse about this
requirement).  This is needed, because ongoing IPv6-over-foo documents,
and RFC 7278 "tethering", tell the best way is DHCPv6-PD, despite
deployments missing it.

But I am aware of a risk: it is possible to put up an RFC and its
technique to never get deployed, however strong the language is.

Alex

Le 28/01/2015 17:57, Fred Baker (fred) a écrit :
> draft-ietf-v6ops-mobile-device-profile has been through Quite a bit
> of change in the IESG. The ADs would like to see the working group
> read it again and comment - working group last call - before they
> proceed. To summarize, it provides requirements for handsets that
> would work in a specific business model. As such, it builds on RFC
> 6434 and 7066, strengthening some of those requirements, and going
> on to add requirements related to 464xlat and other technologies.
>
> Please read it now, and comment. This WGLC will run until 15
> February.
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Feb 2015 06:20:24 -0700

On Feb 4, 2015, at 1:52 AM, Lorenzo Colitti <[email-masked]> wrote:
> Well, but on the other hand, there's an expression in English my mother always used to use. "Those who can, do. Those who can't, teach". :-)

It would not be unwelcome if we were to avoid casting aspersions on the practitioners of various important, difficult and often thankless professions as we continue the discussion about this document.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 04 Feb 2015 18:13:43 -0800

> So, how's Orange's IPv6 deployment coming on?

I think this out of line. disagreement on implementation one thing,
individual business  decissions may be influenced by things outside this
document.

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 9 Feb 2015 09:14:50 +0000

Just a reminder on why I, as an operator, have a need of a document from the IETF. 
I desire:
- an IP profile from IETF - IETF is the home of IP and Internet Engineering (but happy to tie up with 3GPP etc.)
- a profile for mobile devices when the network offers them IPv6-only (dualstack will not get us beyond IPv4 exhaustion)
- a single recommended profile covering all mobile use cases  - handset cellular data, handset tethering, mobile broadband; an informational standard will suffice
- I will use this as a NORM in further discussions with terminal vendors. Yes, many operators will have further discussions with many terminal vendors, terminal software/configuration on the whole is fragmented.

Contrary to some of the views expressed ("that some IPv6 is out there in mobile land, therefore by induction all mobile issues are resolved") there are still some issues and grey areas.
As far as I know there are only a few open market device model "families", that may work IPv6-only with full backwards compatibility with IPv4, and provides stable tethering, and implement APN roaming controls.
For all other vendor models that are badged as IPv6, you need to request a per operator build. Will the relevant features in the build be the same for all operators, in all regions? How can one operator really say without some global norm to compare this to?
If the Google guy says it is all fine, that is great news. 
I'd feel better if the LG guy, Samsung guy, Apple guy, HTC guy etc. etc. all came on the V6Ops list with the same message.
Our devices teams do not normally get involved with such low level requirements as IP protocol versions. We have vendors that we haven’t even started talking to yet about IPv6.

Similarly, find me a mobile network where all IPv6-enabled terminal models are in IPv6-only mode for all use cases (c.f. cellular data, tethering, mobile broadband) using standards build.
Those are hard to find; as an industry we are not there yet. (No disrespect, this is due to business reasons: some operators have gone dualstack APN, some have another APN for tethering, some have chosen hardcoding of prefix64, some need a common APN for all  IP connectivity modes....). It is important to recognise the operator differences.

As one of the authors, we were advised by the WG that normative language was not appropriate for this document as it was a feature list /buffet of options/list document rather than a standard.
Fine, it is not a standard, it is not a problem to accept that and make that perfectly clear in the paper. 
But equally I would suspect that as it is not a standard this is why the document has expanded with all the best buffet of features available mandatory/optional/required for certain use cases. 
Now the document appears to be being blasted for exactly this extensive list of non-mandatory features. Is that fair? Has a steer been given here, and is everyone agreed on the steer?

The question in my mind is this, if we produce a document that focuses only on features for IPv6-only mode of operation (which I may support, not sure of other authors' positions), can we use normative language and produce an informational standard? Will that be more agreeable to the detractors?
If it could be done without resetting the process too far back and it turned opposition into support, then I'd support it.
I think the IPv6-only profile is more urgent than the equivalent IPv4v6 dual stack profile, based on my viewpoint, again I cannot speak for all authors.

Not having a NORM document, leaves the industry in a hole in my opinion. 
I hope we can find a timely way forward.
Regards,
Nick

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: 03 February 2015 19:18
To: [email-masked]
Cc: [email-masked]; V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

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. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 02 Feb 2015 08:10:42 -0600

On 2/2/15 12:40 AM, [email-masked] wrote:
> Hi Joel,
> 
> Which consensus are your talking about?: The one for adopting the
> document as a WG item?, the first one declared by the WG before
> sending it to the IESG? the second one declared by the WG to send
> the document to the IESG?, or the IETF consensus that was declared
> before the IESG starts its review?

IETF last call.

> Cheers, Med
> 
> -----Message d'origine----- De : joel jaeggli
> [mailto:[email-masked]] Envoyé : samedi 31 janvier 2015 21:49 À :
> BOUCADAIR Mohamed IMT/OLN; Gert Doering Cc :
> List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile
> last call
> 
>> With all due respect, I'm afraid we are not discussing whether
>> the document is needed or not but (as I see it) whether the new
>> version does not break the WG consensus that was declared for the
>> version sent to the IESG. I recall that both the WG and IETF
>> consensus were declared for the version sent to the IESG.
> 
> One point on that. Part of the reason we are engaged canvasing, is
> that Brian's discussed questioned my interpretation of the
> consensus call. Given that I conceded from the outset that the call
> is somewhat narrow, one of the questions before us as a w.g. and
> the ietf community is, is that consensus more unequivocal?  Brian I
> believe is willing to extended the benefit of the doubt. So am I,
> but it's the working groups document...
> 
> thanks
> 
> joel
> 
>> Thank you.
>> 
>> Cheers, Med
>> 
>> -----Message d'origine----- De : Gert Doering
>> [mailto:[email-masked]] Envoyé : vendredi 30 janvier 2015 11:39 À
>> : BOUCADAIR Mohamed IMT/OLN Cc : Gert Doering; Ole Troan; Fred
>> Baker (fred); 
>> [email-masked]; V6
>> Ops List Objet : Re: [v6ops]
>> draft-ietf-v6ops-mobile-device-profile last call
>> 
>> Hi,
>> 
>>> Can you please help us identifying technical flaws that you
>>> think need to be fixed in the document?
>> 
>> I don't think there is a need for this document, and I can't
>> truly see it reflecting WG consensus.  So it's more fundamental
>> than just individual technical issues.
>>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 09 Feb 2015 09:40:14 -0800

On 2/9/15 1:14 AM, Heatley, Nick wrote:
> Just a reminder on why I, as an operator, have a need of a document 
> from the IETF. I desire: - an IP profile from IETF - IETF is the home
> of IP and Internet Engineering (but happy to tie up with 3GPP etc.) -
> a profile for mobile devices when the network offers them IPv6-only
> (dualstack will not get us beyond IPv4 exhaustion) - a single
> recommended profile covering all mobile use cases  - handset cellular
> data, handset tethering, mobile broadband; an informational standard
> will suffice - I will use this as a NORM in further discussions with
> terminal vendors. Yes, many operators will have further discussions
> with many terminal vendors, terminal software/configuration on the
> whole is fragmented.
> 
> Contrary to some of the views expressed ("that some IPv6 is out there
> in mobile land, therefore by induction all mobile issues are 
> resolved") there are still some issues and grey areas. As far as I 
> know there are only a few open market device model "families", that 
> may work IPv6-only with full backwards compatibility with IPv4, and 
> provides stable tethering, and implement APN roaming controls. For 
> all other vendor models that are badged as IPv6, you need to request
>  a per operator build. Will the relevant features in the build be the
>  same for all operators, in all regions? How can one operator really
>  say without some global norm to compare this to? If the Google guy 
> says it is all fine, that is great news. I'd feel better if the LG 
> guy, Samsung guy, Apple guy, HTC guy etc. etc. all came on the V6Ops
>  list with the same message. Our devices teams do not normally get 
> involved with such low level requirements as IP protocol versions. We
> have vendors that we haven’t even started talking to yet about IPv6.
> 
> Similarly, find me a mobile network where all IPv6-enabled terminal 
> models are in IPv6-only mode for all use cases (c.f. cellular data, 
> tethering, mobile broadband) using standards build. Those are hard to
> find; as an industry we are not there yet. (No disrespect, this is
> due to business reasons: some operators have gone dualstack APN, some
> have another APN for tethering, some have chosen hardcoding of 
> prefix64, some need a common APN for all  IP connectivity modes....).
> It is important to recognise the operator differences.
> 
> As one of the authors, we were advised by the WG that normative 
> language was not appropriate for this document as it was a feature 
> list /buffet of options/list document rather than a standard. Fine, 
> it is not a standard, it is not a problem to accept that and make 
> that perfectly clear in the paper. But equally I would suspect that 
> as it is not a standard this is why the document has expanded with 
> all the best buffet of features available mandatory/optional/required
> for certain use cases.

Well it essentially started with this list of features, so I don't
accept that it has ballooned as product of non-normative language. If in
total one didn't it like before and the language change didn't mollify,
you probably still don't.

We have a channel for publishing non-consesus documents but it's not the
working group process. I believed, perhaps mistakenly that we could move
this to a more durable consensus on the basis of text changes to take it
away from requirements.

> Now the document appears to be being blasted for exactly this 
> extensive list of non-mandatory features. Is that fair? Has a steer 
> been given here, and is everyone agreed on the steer?
> 
> The question in my mind is this, if we produce a document that 
> focuses only on features for IPv6-only mode of operation (which I may
> support, not sure of other authors' positions), can we use normative
> language and produce an informational standard? Will that be more
> agreeable to the detractors? If it could be done without resetting
> the process too far back and it turned opposition into support, then
> I'd support it. I think the IPv6-only profile is more urgent than the
> equivalent IPv4v6 dual stack profile, based on my viewpoint, again I
> cannot speak for all authors.
> 
> Not having a NORM document, leaves the industry in a hole in my 
> opinion. I hope we can find a timely way forward. Regards, Nick
> 
> 
> -----Original Message----- From: v6ops 
> [mailto:[email-masked]] On Behalf Of Fred Baker (fred) Sent:
>  03 February 2015 19:18 To: [email-masked] Cc: 
> List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last
> call
> 
> 
>>  document is needed or not but (as I see it) whether the new
That’s not quite the way I recall it. In the WG, consensus has
> always been rough. I sent it out when the number of people stating a
>  dissenting position dwindled. In the IETF LC in September 2013, 
> James, Lorenzo, and Owen made comments that caused Joel to withdraw 
> it from the IESG. In the IETF LC in September 2014 and subsequent 
> IESG discussion, comments were raised by several in the IESG and 
> summarized by Brian Haberman to the effect that the document has 
> serious issues. 
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/.
>
>
>
>
>
>
> 
In this round, you have tried to address the issues raised.
> 
> Before I bother the IESG with it a third time, I’d really like to 
> hear a clear consensus, not a rough one. Where it stands right now, 
> that’s not at all obvious.
> 
> 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.
> 
> EE Limited Registered in England and Wales Company Registered Number:
> 02382161 Registered Office Address: Trident Place, Mosquito Way,
> Hatfield, Hertfordshire, AL10 9BW.

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 07:00:16 +0000

Hi Nick,

Thank you for sharing your thoughts. 

This is exactly the motivations for which we edited the first version of the cellular requirements draft. We wanted a document that gathers features shared by a group of operators. This scope and objectives have been explicitly called out since the initial version of the draft. The draft was adopted with that scope unchanged. 

As an editor of the draft, I'm open to address technical comments that would enhance the document. We already released an updated version that integrated the changes requested during this ongoing call. (BTW, I would like to publically thank F. Baker for his effort and guidance to solve one of the key issues raised during the IESG review.)

If there are other technical concerns or clarifications that need to be added to the draft, we are open to discuss how to address those.

Cheers,
Med

-----Message d'origine-----
De : Heatley, Nick [mailto:[email-masked]] 
Envoyé : lundi 9 février 2015 10:15
À : Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; V6 Ops List; Ross Chandler ([email-masked])
Objet : RE: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: 03 February 2015 19:18
To: [email-masked]
Cc: [email-masked]; V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

NOTICE AND DISCLAIMER

EE Limited

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Feb 2015 23:13:09 -0800

On Tue, Feb 10, 2015 at 11:00 PM, <[email-masked]> wrote:

> This is exactly the motivations for which we edited the first version of
> the cellular requirements draft.

Just in case it might have escaped someone's attention, I'd like to point
out that David, Mohamed, Nick and Ross are listed as the authors of this
draft, and that if you're an author of the document, you're probably likely
to agree with the other authors on its content.

As Joel says, it's not my role to declare consensus. But I think that on
this thread I have seen only one statement in support of this document that
was not from an author, and several statements expressing reservations and
lack of support.

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 07:31:31 +0000

Lorenzo,

In case you missed the latest version (see the diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16), we addressed the changes YOU asked for and also those from James and Barbara (many thanks to them).

What additional changes you would like to see added?

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : mercredi 11 février 2015 08:13
À : BOUCADAIR Mohamed IMT/OLN
Cc : Heatley, Nick; Fred Baker (fred); [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Tue, Feb 10, 2015 at 11:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nick,

This is exactly the motivations for which we edited the first version of the cellular requirements draft.

Just in case it might have escaped someone's attention, I'd like to point out that David, Mohamed, Nick and Ross are listed as the authors of this draft, and that if you're an author of the document, you're probably likely to agree with the other authors on its content.

As Joel says, it's not my role to declare consensus. But I think that on this thread I have seen only one statement in support of this document that was not from an author, and several statements expressing reservations and lack of support.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Feb 2015 00:09:51 -0800

On Tue, Feb 10, 2015 at 11:31 PM, <[email-masked]> wrote:

>  In case you missed the latest version (see the diff:
> http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16),
> we addressed the changes YOU asked for and also those from James and
> Barbara (many thanks to them).
>
>
>

I don't think minor changes to the document would cause me to support it.

I have expressed my concerns about this document in the past. For example,
I think the document is too broad (in fact, harmfully broad); places too
much focus on what features to support and not enough focus on why; reads
like a procurement spec and not a technical document. Pretty much what I
said already at IETF last call -
https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - and what
I have been saying since we started discussing this document.

The good news for this document is that it does not need my support to
advance - one objection is not sufficient. IIRC the chairs/ADs have stated
that they want to see "clear consensus" to support it, and if I were the
only one objecting, then I suppose that would be clear consensus. After
all, clear consensus does not mean unanimity.

My observation of this thread, however, is that it's not just me objecting.
Most clearly, Brian wrote that this reads like a procurement spec and not
an IETF document. Gert wrote that he doesn't see a need for this document.
James said he shares my general objections. And so on. You can't address
that sort of objection with minor edits. And there doesn't seem to be lots
of support for this document, either. I see one statement of support from
someone who is not an author, and very little else from the rest of the WG.

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 08:51:50 +0000

Re-,

I hear the point from Brian. FWIW, this point is mentioned explicitly in the introduction:

   2.  Help Operators with the detailed device requirement list

       preparation (to be exchanged with device suppliers).  This is

       also a contribution to harmonize Operators' requirements towards

       device vendors.

This point was part of the draft since we submitted the first individual submission.

The document was adopted by the WG and passed both the WG and IETF LCs with that scope. I naively assumed that this point is not anymore an issue given that the draft passed major milestones (several WGLCs, IETF LC) and the IETF consensus declared for it means this is not an issue to advance the document.

BTW, any requirement document (CPE requirement RFCs, for example) can be turned into a "procurement specification". It is a matter of presentation not a question of technical foundations. We could opted for a similar format, but we decided to be direct to the point.

The draft is currently presented as a superset of existing RFCs, enriched with features required for IPv4 service continuity, LAN capabilities, etc.

Cheers,
Med

Envoyé : mercredi 11 février 2015 09:10

On Tue, Feb 10, 2015 at 11:31 PM, <[email-masked]<mailto:[email-masked]>> wrote:
In case you missed the latest version (see the diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16), we addressed the changes YOU asked for and also those from James and Barbara (many thanks to them).

I have expressed my concerns about this document in the past. For example, I think the document is too broad (in fact, harmfully broad); places too much focus on what features to support and not enough focus on why; reads like a procurement spec and not a technical document. Pretty much what I said already at IETF last call - https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - and what I have been saying since we started discussing this document.

The good news for this document is that it does not need my support to advance - one objection is not sufficient. IIRC the chairs/ADs have stated that they want to see "clear consensus" to support it, and if I were the only one objecting, then I suppose that would be clear consensus. After all, clear consensus does not mean unanimity.

My observation of this thread, however, is that it's not just me objecting. Most clearly, Brian wrote that this reads like a procurement spec and not an IETF document. Gert wrote that he doesn't see a need for this document. James said he shares my general objections. And so on. You can't address that sort of objection with minor edits. And there doesn't seem to be lots of support for this document, either. I see one statement of support from someone who is not an author, and very little else from the rest of the WG.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Feb 2015 01:43:56 -0800

On Wed, Feb 11, 2015 at 12:51 AM, <[email-masked]> wrote:
>
> The document was adopted by the WG and passed both the WG and IETF LCs
> with that scope. I naively assumed that this point is not anymore an issue
> given that the draft passed major milestones (several WGLCs, IETF LC) and
> the IETF consensus declared for it means this is not an issue to advance
> the document.
>
I think that assumption is incorrect, given Fred's explicit statement on
this thread, "Before I bother the IESG with it a third time, I’d really
like to hear a clear consensus, not a rough one."

https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 10:08:09 +0000 (UTC)

I agree with Lorenzo and others, and this has made me wonder about perhaps what might be different philosophies between e.g. the ITU and the IETF regarding how to handle devices that have different versions or feature revisions of protocols.
In the IETF, major and very significant differences are handled by using a different protocol version, where as for less significant differences, mandatory absolute minimums and supported option negotiation is used to cope with those  differences. This allows different versions or feature revisions of different protocols to co-exist on a IPv6 node, to the point where an individual node may have a unique combination of protocol versions and protocol feature revisions that no other node has.
Reading through this draft and having looked a bit at the telephone standards world, it seems the traditional telephony world has more of an approach of 'profiles', which specify a snapshot of features across many protocols at a particular time. This draft is stating them as recommendations, perhaps to be more in line with the less prescriptive approach of the IETF. In effect, I think profiles are like having major version numbers, and therefore mandatory maximums, with no or very little option negotiation.
The concern I have about this 'profiles' approach is that I think it probably slows down deployment of new capabilities in the protocols to a device, because doing so now stops it being "Profile XYZ.ABC" compliant. Perhaps it stops a phone vendor from deploying new capabilities because they have to wait until there is a profile that allows it. Perhaps they can't deploy some more limited new capabilities because doing so would cause them to have to try to comply with a later and newer profile, and that then creates an obligation to support all of the newer profile's capabilities, and the phone's hardware just can't support all of them.
The other thing I wonder about is what is so special about telephones (anymore)? They're fundamentally now nothing more than portable portable computers that just happen to also be used to make phone calls, as well as running many other types of applications. Their 3GPP link-layer interface is the only thing that makes them specifically different from any other portable computer, and I think the only real need to make IPv6 run on them would have been to prepare and update any 3GPP link characteristic specific IPv6 RFCs, that in particular didn't invent new ways of doing what existing non-link specific IPv6 protocols could already do (e.g., PCOs for DNS instead of originally just stateless/stateful DHCPv6 and now (although mostly, in my opinion, unfortunately) RAs).
It seems to me that if smartphone vendors need or needed guidance on what they should implement to support IPv6, they should be or should have been provided with the IPv6 Node Requirements RFC, and an RFC that specifies how to bootstrap IPv6 over an 3GPP link to the point where the non-link type specific standard IPv6 methods could be used, as all of the other IPv6 over Foo-link RFCs do. As major computer companies are now in charge of smartphone development/advancement, that is probably in effect what is mostly happening anyway.

Regards,Mark.
      From: Lorenzo Colitti <[email-masked]>
 To: "<[email-masked]>" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; V6 Ops List <[email-masked]> 
 Sent: Wednesday, 11 February 2015, 19:09
 Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

In case you missed the latest version (see the diff:http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16), we addressed the changes YOU asked for and also those from James and Barbara (many thanks to them).
 What additional changes you would like to see added?

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 10:22:20 +0000

Re-,

I really trust and defer to the chairs to decide whether the document is ready to be sent to the IESG, to be withdrawn, to be sent to ISE, or whatever action they judge appropriate to reflect the wg position.

My concern as an editor of the document is to understand why the document is harmful to IPv6 deployment, whether it contains technical flaws, understand what is meant by “harmfully abroad”, which aspects can be removed/tweaked so that it cannot be seen anymore “harmfully abroad”, etc. I’m in that stand, not somewhere else.

I would like to remind that the IETF is always asking to associate operators. This draft tries to have common voice from a group of operators who think there is a void in existing RFCs and a document is still needed. Note, the items listed in the document are all RFCs or specifications from 3GPP or GSMA.

Cheers,
Med

Envoyé : mercredi 11 février 2015 10:44

On Wed, Feb 11, 2015 at 12:51 AM, <[email-masked]<mailto:[email-masked]>> wrote:

The document was adopted by the WG and passed both the WG and IETF LCs with that scope. I naively assumed that this point is not anymore an issue given that the draft passed major milestones (several WGLCs, IETF LC) and the IETF consensus declared for it means this is not an issue to advance the document.
I think that assumption is incorrect, given Fred's explicit statement on this thread, "Before I bother the IESG with it a third time, I’d really like to hear a clear consensus, not a rough one."

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 10:43:38 +0000

Dear Mark,

Thank you very much for sharing your thoughts. I do share several of your points.

I would like to make the following comments:

·         The document is no more than a superset of existing RFCs that are defining “profiles” without calling them as such. “IPv6 node requirements” or RFC7066 are profiles! This is mentioned in Section 1.2:

   This profile is a superset of that of the IPv6 profile for 3GPP
   Cellular Hosts [RFC7066<http://tools.ietf.org/html/rfc7066>], which is in turn a superset of IPv6 Node
   Requirements [RFC6434<http://tools.ietf.org/html/rfc6434>].  It targets cellular nodes, including GPRS,
   EPC (Evolved Packet Core) and IEEE 802.11 networks, that require
   features to ensure IPv4 service delivery over an IPv6-only transport
   in addition to the base IPv6 service.  Moreover, this profile covers
   cellular CPEs that are used in various deployments to offer fixed-
   like services.  Recommendations inspired from real deployment
   experiences (e.g., roaming) are included in this profile.  Also, this
   profile sketches recommendations for the sake of deterministic
   behaviors of cellular devices when the same configuration information
   is received over several channels.

·         There are conflicts between RFC7066 and RFC6434 (IPv6 node requirements): This document specifies which one should win.

   For conflicting recommendations in [RFC7066<http://tools.ietf.org/html/rfc7066>] and [RFC6434<http://tools.ietf.org/html/rfc6434>] (e.g.,

   Neighbor Discovery Protocol), this profile adheres to [RFC7066<http://tools.ietf.org/html/rfc7066>].

   Indeed, the support of Neighbor Discovery Protocol is mandatory in

   3GPP cellular environment as it is the only way to convey IPv6 prefix

   towards the 3GPP cellular device.  In particular, MTU (Maximum

   Transmission Unit) communication via Router Advertisement must be

   supported since many 3GPP networks do not have a standard MTU

   setting.

·         Access to mobile networks should be harmonized with the fixed one: this is for instance the reason why this document advocates for the following:

   This profile uses a stronger language for the support of Prefix

   Delegation compared to [RFC7066<http://tools.ietf.org/html/rfc7066>].  The main motivation is that

   cellular networks are more and more perceived as an alternative to

   fixed networks for home IP-based services delivery; especially with

   the advent of smartphones and 3GPP data dongles.  There is a need for

   an efficient mechanism to assign shorter prefix than /64 to cellular

   hosts so that each LAN segment can get its own /64 prefix and multi-

   link subnet issues to be avoided.  The support of this functionality

   in both cellular and fixed networks is key for fixed-mobile

   convergence.

·         There are (still) some specificities for mobile devices: PDP creation, roaming aspects, etc. Having a “standard” why to address those issue is key.

·         IPv4 continuity mechanisms defined for fixed devices does not apply for the mobile network: the counterpart of this profile for the fixed case can be for instance found in the profile defined in RFC7084. Those mechanisms are deployed in the mobile networks.

·         Because we are aware about the versioning issues, this document lists the features without referring the 3GPP release. Features can be supported without be “complexified” with the release considerations. This is why we included this sentence in the draft:

“The recommendations do not include 3GPP release details. “

·         The document is not a standard. The document can be seen as a “helper”.

·         A coordination between vendors and operators is encouraged as some of the functions in the terminal side require functions to be enabled in the network and vice versa. This document ambitions to ease that collaboration.

Thank you.
Cheers,
Med

De : Mark ZZZ Smith [mailto:[email-masked]]
Envoyé : mercredi 11 février 2015 11:08
À : Lorenzo Colitti; BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Regards,
Mark.

________________________________
From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; V6 Ops List <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 11 February 2015, 19:09
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2015 11:51:34 +0100

Le 11/02/2015 11:08, Mark ZZZ Smith a écrit :
[...]

> The other thing I wonder about is what is so special about
> telephones (anymore)?

In principle yes - a smartphone is now as open as an IBM PC on a desk.
The end-user independently makes any software that s/he wants to run,
provided enough skill is present.

> They're fundamentally now nothing more than portable portable
> computers that just happen to also be used to make phone calls, as
> well as running many other types of applications. Their 3GPP
> link-layer interface is the only thing that makes them specifically
> different from any other portable computer, and I think the only
> real need to make IPv6 run on them would have been to prepare and
> update any 3GPP link characteristic specific IPv6 RFCs,

This draft is more than just making IPv6 work on it.  IPv6 already works
on many cell links and there are a couple IPv6-over-cellular RFCs present.

This draft makes some new requirements about additional matters of this
"IPv6" to work on these links.  These requirements are not so clear in
the older IPv6-over-cellular RFCs, although they are assumed true by
much protocol design happening in IETF.  They're just not stated anywhere.

And, regardless of these new requirements being clear in this draft,
there are still unknowns happening on 3GPP links - they are are maybe
left for future specifications (if ever the 3GPP links become open
standards).

> that in particular didn't invent new ways of doing what existing
> non-link specific IPv6 protocols could already do (e.g., PCOs for DNS
> instead of originally just stateless/stateful DHCPv6 and now
> (although mostly, in my opinion, unfortunately) RAs).
>
> It seems to me that if smartphone vendors need or needed guidance on
> what they should implement to support IPv6, they should be or should
> have been provided with the IPv6 Node Requirements RFC, and an RFC
> that specifies how to bootstrap IPv6 over an 3GPP link to the point
> where the non-link type specific standard IPv6 methods could be
> used, as all of the other IPv6 over Foo-link RFCs do. As major
> computer companies are now in charge of smartphone
> development/advancement, that is probably in effect what is mostly
> happening anyway.

Mark - there is a host of kinds of smartphone vendors: operators selling 
them, but also hw manufacturers and B2B resellers, integrators; their 
interests vary from pure IETF stds to pure 3GPP stds.

Even if this draft is titled "mobile device profile",
its reqs may well apply to a Machine which is not mobile at all (home 
automation) or provides mobility for others (trains).  Or apply to LTE 
USB keys connecting specialized platforms, very different than smartphones.

For me the important aspect, among its other contents, is that it puts 
DHCPv6 PD forward - I hope it will lead operators to support it.

Alex

>
> Regards, Mark.
>
> ------------------------------------------------------------------------
>
>
>
*From:* Lorenzo Colitti <[email-masked]>
> *To:* "<[email-masked]>" <[email-masked]>
> *Cc:* "[email-masked]"
> <[email-masked]>; V6 Ops
> List <[email-masked]> *Sent:* Wednesday, 11 February 2015, 19:09
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last
> call
>
>
>
> On Tue, Feb 10, 2015 at 11:31 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Barbara (many thanks to them). __ __ What additional changes you
> would like to see added?
>
>
> I have expressed my concerns about this document in the past. For
> example, I think the document is too broad (in fact, harmfully
> broad); places too much focus on what features to support and not
> enough focus on why; reads like a procurement spec and not a
> technical document. Pretty much what I said already at IETF last
> call -
> https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html -
> and what I have been saying since we started discussing this
> document.
>
> The good news for this document is that it does not need my support
> to advance - one objection is not sufficient. IIRC the chairs/ADs
> have stated that they want to see "clear consensus" to support it,
> and if I were the only one objecting, then I suppose that would be
> clear consensus. After all, clear consensus does not mean unanimity.
>
> My observation of this thread, however, is that it's not just me
> objecting. Most clearly, Brian wrote that this reads like a
> procurement spec and not an IETF document. Gert wrote that he
> doesn't see a need for this document. James said he shares my
> general objections. And so on. You can't address that sort of
> objection with minor edits. And there doesn't seem to be lots of
> support for this document, either. I see one statement of support
> from someone who is not an author, and very little else from the rest
> of the WG.
>
> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2015 12:02:36 +0100

Le 11/02/2015 10:43, Lorenzo Colitti a écrit :
> On Wed, Feb 11, 2015 at 12:51 AM, <[email-masked]
>     The document was adopted by the WG and passed both the WG and IETF
>     LCs with that scope. I naively assumed that this point is not
>     anymore an issue given that the draft passed major milestones
>     (several WGLCs, IETF LC) and the IETF consensus declared for it
>     means this is not an issue to advance the document.
>

LEt me try to understand - are we trying to identify consensus?  Or can 
we still discuss the requirements per se?

To me, the latter has its importance as well.

For example:
>    C_REC#1:  In order to allow each operator to select their own
>              strategy regarding IPv6 introduction, the cellular host
>              must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060].
>              Both IPv6 and IPv4v6 PDP-Contexts must be supported.  IPv4,
>              IPv6 or IPv4v6 PDP-Context request acceptance depends on
>              the cellular network configuration.

I would like this requirement to state that _if_ the smartphone sold by 
that operator supports IPv4 PDP-context, IPv6 PDP-context and IPv4v6 
PDP-context then the operator SHOULD support at least IPv4v6 
PDP-context, and ideally the 3 for the same APN; in all cases, the 
operator SHOULD NOT support only IPv6 PDP-Context or only IPv4 
PDP-Context per one APN.

As surprising it might seem, some operators take an approach of 
supporting only IPv6 PDP-Context on one APN, and the other two on other 
two APNs, regardless of the end-user preference; they have their 
particular reasons which may not be technical.  It is very stimulating 
in some sense (IPv6-only), or too daring for some customers which see 
their IPv6 flows interupted if switching to other APN.

Alex

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 13:30:01 +0000

Hi Alex,

The draft includes this text: 

   Some of the features listed in this profile document require to
   activate dedicated functions at the network side.  It is out of scope
   of this document to list these network-side functions.

This I-D cannot mandate the behavior of the network side as it is up to the taste of each operator.

Saying that, if you believe there is a service/application brokenness risk due to some kind of policy enforced at the network side with regards to the management of PDP contexts and APNs, I see a value in adding a "note" to record it.

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Alexandru Petrescu
Envoyé : mercredi 11 février 2015 12:03
À : [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs

Le 11/02/2015 10:43, Lorenzo Colitti a écrit :
> this thread, "Before I bother the IESG with it a third time, I'd really

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2015 15:15:04 +0100

Le 11/02/2015 14:30, [email-masked] a écrit :
> activate dedicated functions at the network side.  It is out of
> scope of this document to list these network-side functions.
>
> Saying that, if you believe there is a service/application brokenness
> risk due to some kind of policy enforced at the network side with
> regards to the management of PDP contexts and APNs, I see a value in
> adding a "note" to record it.

Note: a smartphone changing its connection between an APN-v6 and an 
APN-v4 block-restarts the ongoing applications.  This is a brokenness 
situation.

Alex

>
> Cheers, Med
>
> -----Message d'origine----- De : v6ops
> [mailto:[email-masked]] De la part de Alexandru Petrescu
> Envoyé : mercredi 11 février 2015 12:03 À : [email-masked] Objet :
> Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6
> PDP-contexts and APNs
>
>> I think that assumption is incorrect, given Fred's explicit
>> statement on this thread, "Before I bother the IESG with it a third
>> time, I'd really like to hear a clear consensus, not a rough one."
>>
> LEt me try to understand - are we trying to identify consensus?  Or
> can we still discuss the requirements per se?
>
>> strategy regarding IPv6 introduction, the cellular host must
>> support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. Both IPv6 and
>> IPv4v6 PDP-Contexts must be supported.  IPv4, IPv6 or IPv4v6
>> PDP-Context request acceptance depends on the cellular network
>> configuration.
>
> I would like this requirement to state that _if_ the smartphone sold
> by that operator supports IPv4 PDP-context, IPv6 PDP-context and
> IPv4v6 PDP-context then the operator SHOULD support at least IPv4v6
> supporting only IPv6 PDP-Context on one APN, and the other two on
> other two APNs, regardless of the end-user preference; they have
> their particular reasons which may not be technical.  It is very
> stimulating in some sense (IPv6-only), or too daring for some
> customers which see their IPv6 flows interupted if switching to other
> APN.
>
> Alex
>
>>
>>

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 15:00:46 +0000

Gert,

You can check slide 13 of this prez http://www.ipv6observatory.eu/wp-content/uploads/2012/11/01-05-Christian-Jacquenet.pdf to see examples of IPv6 services offered by our group.

I hope we can focus on technical aspects of the document rather than discussing specific business matters. 

Thank you.

Cheers,
Med  

-----Message d'origine-----
De : Gert Doering [mailto:[email-masked]] 
Envoyé : mercredi 4 février 2015 09:32
À : BINET David IMT/OLN
Cc : Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN; [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Hi,

Gert Doering
        -- NetMaster

---

From: t.petch <[email-masked]>
Date: Wed, 11 Feb 2015 17:46:03 +0000

----- Original Message -----
From: "Mark ZZZ Smith" <[email-masked]>
Sent: Wednesday, February 11, 2015 10:08 AM

I agree with Lorenzo and others, and this has made me wonder about
perhaps what might be different philosophies between e.g. the ITU and
the IETF regarding how to handle devices that have different versions or
feature revisions of protocols.

In the IETF, major and very significant differences are handled by using
a different protocol version, where as for less significant differences,
mandatory absolute minimums and supported option negotiation is used to
cope with those differences. This allows different versions or feature
revisions of different protocols to co-exist on a IPv6 node, to the
point where an individual node may have a unique combination of protocol
versions and protocol feature revisions that no other node has.

Reading through this draft and having looked a bit at the telephone
standards world, it seems the traditional telephony world has more of an
approach of 'profiles', which specify a snapshot of features across many
protocols at a particular time. This draft is stating them as
recommendations, perhaps to be more in line with the less prescriptive
approach of the IETF. In effect, I think profiles are like having major
version numbers, and therefore mandatory maximums, with no or very
little option negotiation.

The concern I have about this 'profiles' approach is that I think it
probably slows down deployment of new capabilities in the protocols to a
device, because doing so now stops it being "Profile XYZ.ABC" compliant.
Perhaps it stops a phone vendor from deploying new capabilities because
they have to wait until there is a profile that allows it. Perhaps they
can't deploy some more limited new capabilities because doing so would
cause them to have to try to comply with a later and newer profile, and
that then creates an obligation to support all of the newer profile's
capabilities, and the phone's hardware just can't support all of them.

<tp>

I think that you make a good point but that there is another one
alongside it, that ITU-T Recommendations, at least in aggregate, are
much, much more complex than IETF RFC and so the idea of profiling them,
to produce something that can be implemented and interwork, is
desirable, if not necessary.

IETF RFC are, for the most part, much simpler and do not require such an
action.  MPLS-TP, perhaps not surprisingly, has a strong flavour of
ITU-T about it and does include profiles - it needed them.

IPv6?  Probably the most complex protocol, or family thereof, that the
IETF has produced, which, for me, is why the take up is so poor
(nonexistent around me, on a small offshore island:-).  So the idea of a
profile seems to be not just right, quite likely essential, to make IPv6
get deployed.

Tom Petch

The other thing I wonder about is what is so special about telephones
(anymore)? They're fundamentally now nothing more than portable portable
computers that just happen to also be used to make phone calls, as well
as running many other types of applications. Their 3GPP link-layer
interface is the only thing that makes them specifically different from
any other portable computer, and I think the only real need to make IPv6
run on them would have been to prepare and update any 3GPP link
characteristic specific IPv6 RFCs, that in particular didn't invent new
ways of doing what existing non-link specific IPv6 protocols could
already do (e.g., PCOs for DNS instead of originally just
stateless/stateful DHCPv6 and now (although mostly, in my opinion,
unfortunately) RAs).
It seems to me that if smartphone vendors need or needed guidance on
what they should implement to support IPv6, they should be or should
have been provided with the IPv6 Node Requirements RFC, and an RFC that
specifies how to bootstrap IPv6 over an 3GPP link to the point where the
non-link type specific standard IPv6 methods could be used, as all of
the other IPv6 over Foo-link RFCs do. As major computer companies are
now in charge of smartphone development/advancement, that is probably in
effect what is mostly happening anyway.

Regards,Mark.

In case you missed the latest version (see the
diff:http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-pro
file-15&url2=draft-ietf-v6ops-mobile-device-profile-16), we addressed
the changes YOU asked for and also those from James and Barbara (many
thanks to them).
What additional changes you would like to see added?

I don't think minor changes to the document would cause me to support
it.
I have expressed my concerns about this document in the past. For
example, I think the document is too broad (in fact, harmfully broad);
places too much focus on what features to support and not enough focus
on why; reads like a procurement spec and not a technical document.
Pretty much what I said already at IETF last call -
https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - and
what I have been saying since we started discussing this document.
The good news for this document is that it does not need my support to
advance - one objection is not sufficient. IIRC the chairs/ADs have
stated that they want to see "clear consensus" to support it, and if I
were the only one objecting, then I suppose that would be clear
consensus. After all, clear consensus does not mean unanimity.
My observation of this thread, however, is that it's not just me
objecting. Most clearly, Brian wrote that this reads like a procurement
spec and not an IETF document. Gert wrote that he doesn't see a need for
this document. James said he shares my general objections. And so on.
You can't address that sort of objection with minor edits. And there
doesn't seem to be lots of support for this document, either. I see one
statement of support from someone who is not an author, and very little
else from the rest of the WG.
_______________________________________________

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 09:36:01 +0000

Hi Alex,

I think this note can be added to C_REC#6 not C_REC#1. I made this change in my local copy:

OLD: 
   C_REC#6:  The cellular host must be able to be configured to limit
             PDP type(s) for a given APN.  The default mode is to allow
             all supported PDP types.  Note, C_REC#2 discusses the
             default behavior for requesting PDP-Context type(s).

                This feature is useful to drive the behavior of the UE
                to be aligned with: (1) service-specific constraints
                such as the use of IPv6-only for VoLTE (Voice over LTE),
                (2) network conditions with regards to the support of
                specific PDP types (e.g., IPv4v6 PDP-Context is not
                supported), (3) IPv4 sunset objectives, (4) subscription
                data, etc.

NEW:

   C_REC#6:  The cellular host must be able to be configured to limit
             PDP type(s) for a given APN.  The default mode is to allow
             all supported PDP types.  Note, C_REC#2 discusses the
             default behavior for requesting PDP-Context type(s).

                This feature is useful to drive the behavior of the UE
                to be aligned with: (1) service-specific constraints
                such as the use of IPv6-only for VoLTE (Voice over LTE),
                (2) network conditions with regards to the support of
                specific PDP types (e.g., IPv4v6 PDP-Context is not
                supported), (3) IPv4 sunset objectives, (4) subscription
                data, etc.

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

Please let me know if this is OK. Thank you.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : mercredi 11 février 2015 15:15
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Feb 2015 10:40:33 +0100

> Please let me know if this is OK. Thank you.

YEs, this note is OK, thanks.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 10:03:44 +0900

On Wed, Feb 4, 2015 at 4:17 AM, Fred Baker (fred) <[email-masked]> wrote:

> Before I bother the IESG with it a third time, I’d really like to hear a
> clear consensus, not a rough one. Where it stands right now, that’s not at
> all obvious.
>

So did we have clear consensus? The WLGC was supposed to go until February
15.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Feb 2015 19:30:17 +0100 (CET)

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.

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.

C_REC#6:

"restarts the ongoing applications". I don't like this wording, "will 
interrupt existing network connections" or similar text would be better.

C_REC#7:

typo:

"The purpose of the of the roaming profile is"

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.

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

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: [email-masked]

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 07:59:23 +0000

Hi Mikael,

Thank you for the review. 

Please see inline.

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Mikael
> Abrahamsson
> Envoyé : vendredi 20 février 2015 19:30
> À : V6 Ops List

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

> context is to achieve dual stack connectivity by means of these two PDP

[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.
> 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)

> "The purpose of the of the roaming profile is"

[Med] Fixed. Thank you.

> 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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 17:09:29 +0900

>                 is to achieve dual-stack connectivity by means of two

Operators who have deployed IPv6 report that running dual-stack over two
PDP contexts is a very bad idea because it consumes 2x the network
resources. Please don't recommend this unless you have evidence that this
works well in production (not in testing).

>                 considered as a brokenness situation for some

What is the purpose of this text? Mobile nodes change IP addresses all the
time (e.g., when switching from 4G to wifi). How is this different?

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 08:39:02 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : lundi 23 février 2015 09:09
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mikael Abrahamsson; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Mon, Feb 23, 2015 at 4:59 PM, <[email-masked]<mailto:[email-masked]>> wrote:
NEW:

Operators who have deployed IPv6 report that running dual-stack over two PDP contexts is a very bad idea because it consumes 2x the network resources. Please don't recommend this unless you have evidence that this works well in production (not in testing).

[Med] We are not recommending establishing systematically two PDP contexts. Please check the full recommendation provided below for your convenience.

   C_REC#2:  The cellular host must comply with the behavior defined in
             [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-
             Context type.  In particular, the cellular host must
             request by default an IPv6 PDP-Context if the cellular host
             is IPv6-only and request an IPv4v6 PDP-Context if the
             cellular host is dual-stack or when the cellular host is
             not aware of connectivity types requested by devices
             connected to it (e.g., cellular host with LAN capabilities
             as discussed in Section 3):

                is to achieve dual- stack connectivity by means of two
                PDP-Contexts.

             *  If the subscription data or network configuration allows
                only one IP address family (IPv4 or IPv6), the cellular
                host must not request a second PDP-Context to the same
                APN for the other IP address family.

             The text above focuses on the specification part which
             explains the behavior for requesting IPv6-related PDP-
             Context(s).  Understanding this behavior is important to
             avoid having broken IPv6 implementations in cellular
             devices.

NEW:

What is the purpose of this text? Mobile nodes change IP addresses all the time (e.g., when switching from 4G to wifi). How is this different?

[Med] This text was added to address a comment from Alex. I will let him further clarify, but Alex is asking for APNs that are not specific to a given address family, hence this note.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 19:49:07 +0900

On Mon, Feb 23, 2015 at 5:39 PM, <[email-masked]> wrote:

> [Med] We are not recommending establishing systematically two PDP
> contexts. Please check the full recommendation provided below for your
> convenience.
>
>
>

How are you "not recommending" this behaviour, if the text says that the
device "must initiate another PDP-Context activation"?

>              avoid having broken IPv6 implementations in cellular

I find this last paragraph meaningless. What is it intended to convey?

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 12:58:05 +0100

Le 23/02/2015 08:59, [email-masked] a écrit :
[...]

>> C_REC#6:
>>
>> "restarts the ongoing applications". I don't like this wording,
>> "will interrupt existing network connections" or similar text
>> would be better.
>
> IPv6-specific APN and an IPv4-specific APN restarts the ongoing
> applications.  This may be considered as a brokenness situation.
>
> NEW:
>
> IPv6-specific APN and an IPv4-specific APN will interrupt associated
> network connections.  This may be considered as a brokenness
> situation for some applications.
>

Yes, thanks for asking.  It looks good, except it would be better to say 
"by some applications" instead of "for some applications".

And "bound" or "ongoing" or "related" would be better than "associated" 
(because this latter may make think of WiFi).

Alex

>> 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?
>
>>
> [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: [email-masked]
>>

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 12:10:18 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : lundi 23 février 2015 11:49

On Mon, Feb 23, 2015 at 5:39 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Operators who have deployed IPv6 report that running dual-stack over two PDP contexts is a very bad idea because it consumes 2x the network resources. Please don't recommend this unless you have evidence that this works well in production (not in testing).

How are you "not recommending" this behaviour, if the text says that the device "must initiate another PDP-Context activation"?

[Med] It seems you skipped “systematically” in my answer ;-). So, I confirm “we are not recommending establishing systematically two PDP contexts”. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 PDP types are allowed, two PDP contexts can be requested. The network is free to accept those or not. As you can see there are “if”s in this behavior. So to be accurate, this text does not recommend requesting two separate PDP contexts as default behavior, but it does not forbid it either.

[Med] FWIW, the last paragraph was added as per a comment received from the mailing list: https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. The point is that the set of cited specifications contains more details about how PDP contexts are to be handled compared to what is described in here (that is IPv6-sepcific).

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 13:16:58 +0100

Le 23/02/2015 09:09, Lorenzo Colitti a écrit :
> On Mon, Feb 23, 2015 at 4:59 PM, <[email-masked]
> *  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.
>
>

> Operators who have deployed IPv6 report that running dual-stack over
>  two PDP contexts is a very bad idea because it consumes 2x the
> network resources.

So this means it would be good to rather recommend one PDP context with
two types on at the same time?  (v4v6).  If so, I would agree.

> Please don't recommend this unless you have evidence that this works
> well in production (not in testing).

I don't think it is possible to have two PDP connections with two APNs 
up at the same time, in the same smartphone.  I have never seen it, is 
it there somewhere?

> NEW: Note, a cellular host changing its connection between an
> What is the purpose of this text? Mobile nodes change IP addresses
> all the time (e.g., when switching from 4G to wifi). How is this
> different?

The switching between two interfaces (4G and wifi) is smoother than
switching a single interface from one APN to another.

For the former, there are many operations taking place simultaneously
(associate, set up PDP, acquire address, establish def route).  Because
of this simultaneity, and because overlapping coverage of 4G/wifi
deployments, very often the end user does not notice any interruption in
the ongoing applications; especially those buffered, or relying on brief
http requests, or restartable TCP sessions, or those perioridally
heartbeating: a youtube session will advance on green line (buffer)
instead of red (live), HTTP HTML pages will display more or less, FTP
transfers will restart by themselves somehow, and the skype check will
re-green.  On another hand, a skype ongoing call _will_ be interrupted.

For the latter, the switching is more brutal: the smartphone must put
interface down and delete routes before putting it up again, new
address, new routes.  There is no simultaneity.  In this case the
socket data structures proper often vanish, and lead to popping up
messages like "you have been disconnected, try again".

Switching between APNs is more brutal even than 'roaming' between two
networks.

Beside this app continuity factor, there are more reasons to _not_
recommend switching between APNs, that we could discuss separately.

Alex

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 12:19:47 +0000

Hi Alex, 

Please see inline.

Cheers,
Med

> Envoyé : lundi 23 février 2015 12:58
> À : [email-masked]

[Med] Works for me. The NEW text is now:

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

---

From: Dave Michaud <[email-masked]>
Date: Mon, 23 Feb 2015 13:25:51 +0000

To further clarify the comment below, this is not a recommendation but it is the expected behaviour as per the 3GPP spec.

Upon receiving a request for a dual-stack PDP, the network operator can return one of the following cause codes (there are a lot more options but these are the relevant ones for discussion):

Cause code 50: PDP Type IPv4 only allowed
Cause code 51: PDP Type IPv6 only allowed
Cause code 52: Single address bearers only allowed

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.

"If the requested IPv4v6 PDP-Context is not supported by
the network, but IPv4 and IPv6 PDP types are allowed…” —> This is signalled with cause code 52.

Dave Michaud
Sr. Architect Mobility – Access Networks & IP Network Services
Network Technology | Rogers Communications
[email-masked]<mailto:[email-masked]> | tel: +1 647.747.9442 | mobile: +1 416.219.5531

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 23, 2015 at 07:10
To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Re-,

Please see inline.

Cheers,
Med

________________________________
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>
________________________________

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 22:48:56 +0900

On Mon, Feb 23, 2015 at 9:10 PM, <[email-masked]> wrote:

>  [Med] It seems you skipped “systematically” in my answer ;-). So, I
> confirm “we are not recommending establishing systematically two PDP
> contexts”. The default behavior is to ask for a IPv4v6 PDP-Context, but
> (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6
> PDP types are allowed, two PDP contexts can be requested. The network is
> free to accept those or not. As you can see there are “if”s in this
> behavior. So to be accurate, this text does not recommend requesting two
> separate PDP contexts as default behavior, but it does not forbid it
> either.
>

Ok, so you're saying that in this case, the recommendation is that the
device establishes two PDP contexts? If so, then as I said before: "Please
don't recommend this unless you have evidence that this works well in
production (not in testing)."

To make myself more clear: please either provide evidence that this works
well in production, or please remove the mention of two parallel PDP
contexts.

> [Med] FWIW, the last paragraph was added as per a comment received from
> the mailing list:
> https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. The
> point is that the set of cited specifications contains more details about
> how PDP contexts are to be handled compared to what is described in here
> (that is IPv6-sepcific).
>

Let me try again. You say "The text above focuses on the specification
part". What is the "specification part"? Part of what?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 22:57:48 +0900

On Mon, Feb 23, 2015 at 10:25 PM, Dave Michaud <[email-masked]>
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?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Feb 2015 15:01:43 +0100 (CET)

> In any case, I think we agree that this is not something that we want to

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?

---

From: Dave Michaud <[email-masked]>
Date: Mon, 23 Feb 2015 14:05:22 +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
[email-masked] | tel: +1 647.747.9442 | mobile: +1
416.219.5531

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 23:05:59 +0900

> definitely want (and expect) the UE to set up a second PDP context in case

Then you should read TS 23.060 release 8, which says "may".

> How else should the network signal to the UE that it should bring up a

Why would you ever want to do this? It has terrible scaling properties and
no fate sharing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 23:10:04 +0900

> If the operator does not want this behavior, CC50 and CC51 are available

But this group is in the business of providing operational guidance. It's
not in the business of rubberstamping operator requirements. And it's not
in the business of re-specifying behaviour that is already specified in
standards written by other standards bodies.

---

From: Gert Doering <[email-masked]>
Date: Mon, 23 Feb 2015 15:12:04 +0100

Hi,

> How else should the network signal to the UE that it should bring up a 

Actually I read CC52 as "no, we do not have IPv4IPv6, but you are free
to bring up either IPv4 or IPv6 PDP!" (as opposed to CC50 and CC51 that
are telling specifically which one to use).  Is that not what is intended?

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Feb 2015 15:16:29 +0100 (CET)

> Why would you ever want to do this? It has terrible scaling properties and

Because that's the way MMS is commonly done as well, as well as VoLTE. 
It's the basic model how QoS is supposed to work in 3GPP networks.

The fact that historically vendors have charged on a per-PDP-context basis 
doesn't mean it doesn't work.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 23:27:36 +0900

> It's the basic model how QoS is supposed to work in 3GPP networks.

Sure, but even if you already have another PDN up for VoLTE, using 2 PDNs
for Internet access is still a 50% increase in load. Again - do we have
evidence from operators that using IPv4 / IPv6 on two separate APNs works
well in production?

The only operators I have heard using it said that it was very much
something they wanted to avoid.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Feb 2015 15:42:11 +0100 (CET)

On Mon, 23 Feb 2015, Lorenzo Colitti wrote:

> Sure, but even if you already have another PDN up for VoLTE, using 2 
> PDNs for Internet access is still a 50% increase in load. Again - do we 
> have evidence from operators that using IPv4 / IPv6 on two separate APNs 
> works well in production?

>From 23.401 version 12.6.0:

"If the requested PDN type is IPv4v6, and both IPv4 and IPv6 PDN types are 
allowed by subscription but not IPv4v6, the MME shall set the PDN type to 
IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation 
specific. The UE should then initiate the UE requested PDN connectivity 
procedure to this APN in order to activate a second PDN connection with 
the other single address PDN type which was not allocated by the network."

"should". So as far as I can tell, the current document we're discussion 
is saying the same thing as 3GPP 23.401. The behaviour is also what I have 
seen from "all" UEs I did testing with, so I'd say the baseband vendors 
are doing just this.

> something they wanted to avoid.

Well, because of paying per PDP context (licensing fee). This is a 
negotiation between them and their equipment vendor.

If they do not want the UE to do this, then they have provisioning tools 
to make this happen (return CC50 or CC51).

Even if there is a "may" in release 8, in later versions of 3GPP 
architecture this seems to have been replaced by a "should". It's my 
opinion that this "should" makes a lot of sense and that's what I would 
like to see in the mobile-device-profile document.

---

From: Dave Michaud <[email-masked]>
Date: Mon, 23 Feb 2015 14:45:01 +0000

The technicality here is that CC50, CC51 and CC52 are returned not as a
failure but as a success with an IP address allocated.

So CC52 is returned with either an IPv4 or an IPv6 address allocated by
the network with the onus on the UE to proceed with a subsequent request
to establish the alternate PDP type.

For CC50 and CC51, they are also returned with the selected PDP type (and
allocated IP address) and it tells the UE that the alternate PDP type will
be rejected by the network (so the UE is not to proceed further).

Dave Michaud

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Feb 2015 23:54:38 +0900

On Mon, Feb 23, 2015 at 11:42 PM, Mikael Abrahamsson <[email-masked]>
wrote:

>> seen from "all" UEs I did testing with, so I'd say the baseband vendors are
>> doing just this.
>>
>
I stand by my earlier questions. Do we have evidence that people do this in
production? It's not just the money - Dual-PDP is either a 100% increase or
a 50% increase in state and signaling load over single-PDP. It also has
worse fate-sharing properties (e.g., IPv4 can fail but IPv6 can be working,
and vice versa). Is that something we want to recommend?

I get it that if you're an operator, the ideal situation is that you have a
knob to control every possible aspect of device behaviour, even if you
never use it. But forget about that for a moment. Remember, this group is
about providing *operational guidance*. Is this really something you would
recommend operationally? If so, why?

Saying "establishing a second PDP context after code 52 is what the 3GPP
standards say the device should do" is all very well. But it's not really
very useful for the IETF to say that, first because those standards are
already written down in other organizations' documents, and second because
(as you yourself point out) the terminals *do* respect the standards and
already behave this way.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 15:57:09 +0100

Le 23/02/2015 14:25, Dave Michaud a écrit :
> To further clarify the comment below, this is not a recommendation but
> it is the expected behaviour as per the 3GPP spec.
>
> Upon receiving a request for a dual-stack PDP, the network operator can
> return one of the following cause codes (there are a lot more options
> but these are the relevant ones for discussion):

And what is the Cause code number for "PDP Type IPv4IPv6 allowed"?

If there is no such Cause code then it would make sense to add it.

Alex

> 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
> the network, *but IPv4 and IPv6 PDP types are allowed**…*” —> This is
> signalled with cause code 52.
>
>
>
> *
> *
> *Dave Michaud*
> [email-masked] <mailto:[email-masked]> | tel:
> +1 647.747.9442 | mobile: +1 416.219.5531
>
>
> From: "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> To: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> Cc: IPv6 WG <[email-masked] <mailto:[email-masked]>>
> *De :*Lorenzo Colitti [mailto:[email-masked]]
> *Envoyé :* lundi 23 février 2015 11:49
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Mikael Abrahamsson; V6 Ops List
> *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
>
> On Mon, Feb 23, 2015 at 5:39 PM, <[email-masked]
> resources. Please don't recommend this unless you have evidence that
> this works well in production (not in testing).
>
> point is that the set of cited specifications contains more details
> about how PDP contexts are to be handled compared to what is described
> in here (that is IPv6-sepcific).
>
>
>
>
>
> 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 >

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Feb 2015 16:04:09 +0100 (CET)

On Mon, 23 Feb 2015, Lorenzo Colitti wrote:

> I stand by my earlier questions. Do we have evidence that people do this 
> in production? It's not just the money - Dual-PDP is either a 100% 
> increase or a 50% increase in state and signaling load over single-PDP. 
> It also has worse fate-sharing properties (e.g., IPv4 can fail but IPv6 
> can be working, and vice versa). Is that something we want to recommend?
>

My opinion is the following:

We should recommend to run IPv4v6 whereever possible to operators, for the 
reasons you provide.
We should recommend device manufacturers to follow the 3GPP standards and 
set up a second PDP context when it receives CC#52.

---

From: Ca By <[email-masked]>
Date: Mon, 23 Feb 2015 07:57:36 -0800

On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson <[email-masked]>
wrote:

>> in production? It's not just the money - Dual-PDP is either a 100% increase
>> or a 50% increase in state and signaling load over single-PDP. It also has

i don't see how we, v6ops,  can recommend operators deploy ipv4 addresses
that are not available.

Should we include an appendix listing ipv4 brokers they can contact?

Oh, and don't forget the v6ops is also publishing this

https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07

Quoting:

"In the network attachment stage, PDP/PDN type IPv4v6 is the major

   concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
   PDN type IPv4v6 in the earlier releases.  That PDP/PDN type is
   supported in new-built EPS network, but isn't supported well in the
   third generation network."

CB

---

From: Gert Doering <[email-masked]>
Date: Mon, 23 Feb 2015 17:01:18 +0100

Hi,

> And what is the Cause code number for "PDP Type IPv4IPv6 allowed"?

"Success!".

If the device is capable of doing IPv4IPv6, it is supposed to try it first
(if permitted by policy).

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Feb 2015 17:02:25 +0100 (CET)

> i don't see how we, v6ops,  can recommend operators deploy ipv4 addresses

You're right, I will be more specific.

If the operator wants the UEs to have simultaneous IPv4 and IPv6 access to 
the device, this should be done by means of a single IPv4v6 bearer and not 
one IPv4 and one IPv6 bearer.

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 23 Feb 2015 16:03:07 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 23 February 2015 15:04
To: Lorenzo Colitti
Cc: V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

We should recommend to run IPv4v6 whereever possible to operators, for the reasons you provide.
[Heatley, Nick] If we want to recommend, then I would suggest we should recommend that the operator's APN design promotes the use of a single PDP/PDN type per subscriber, for the reasons you provide.
The problem for me is that this is design in the operator network and losing focus on the mobile device profile.

We should recommend device manufacturers to follow the 3GPP standards and set up a second PDP context when it receives CC#52.
[Heatley, Nick] I would not be comfortable doing anything but working within the 3GPP standards.

The background is that parallel address version PDPs may exist per subscriber due to:
1.	Legacy handsets (pre-release8 devices on dualstack networks)
2.	OR Roaming situations, e.g. dualstack APN home networks on legacy visited networks
3.	OR Due to an individual operator's APN design.
So even with a recommendation then 2. could exist and result in CC#52.
IMHO the original text just acknowledges the existence of such an outcome.

NOTICE AND DISCLAIMER

EE Limited

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 17:25:12 +0100

Le 23/02/2015 16:57, Ca By a écrit :
>
>
> On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         I stand by my earlier questions. Do we have evidence that people
>         do this in production? It's not just the money - Dual-PDP is
>         either a 100% increase or a 50% increase in state and signaling
>         load over single-PDP. It also has worse fate-sharing properties
>         (e.g., IPv4 can fail but IPv6 can be working, and vice versa).
>         Is that something we want to recommend?
>
> i don't see how we, v6ops,  can recommend operators deploy ipv4
> addresses that are not available.

Cameron - these addresses _are_ available, they're NATted anyways.

I know the IPv4 exhaustion problem, but it does not apply here: that
problem is a _publicly_ routable IPv4 address problem, not a private
routable address problem. One can have larger than 2^32 networks
entirely on IPv4 with multiple NATs and/or traffic engineering.

One would appreciate an IPv4 private address with IPv4IPv6-type rather
than an IPv6-only type.

> Should we include an appendix listing ipv4 brokers they can contact?

YEs, it is good to have such a list in one place. Do they do this
automatically or does one have to fill in forms?

>     third generation network."

So the network should be updated to support IPv4IPv6 type.

Alex

>
>
> CB
>
>     We should recommend device manufacturers to follow the 3GPP
>     standards and set up a second PDP context when it receives CC#52.
>
>
>     --
>     Mikael Abrahamsson    email: [email-masked] <mailto:[email-masked]>
>
>     _________________________________________________
>     v6ops mailing list
>     https://www.ietf.org/mailman/__listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>
>

---

From: Ca By <[email-masked]>
Date: Mon, 23 Feb 2015 08:33:37 -0800

> entirely on IPv4 with multiple NATs and/or traffic engineering.
I don't think the IETF is willing to recommend what you have described
above.

> One would appreciate an IPv4 private address with IPv4IPv6-type rather

Not this "one".  But, you can run your network how you like.

> So the network should be updated to support IPv4IPv6 type.
This advice you provide has not been deployed in production.

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 17:45:38 +0100

Le 23/02/2015 17:33, Ca By a écrit :
>
>
> On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  I get it that if you're an operator, the ideal
>         situation is that
>                  you have a
>                  knob to control every possible aspect of device
>         behaviour, even
>                  if you
>                  never use it. But forget about that for a moment.
>         Remember, this
>                  group is
>                  about providing *operational guidance*. Is this really
>         something
>                  you would
>              We should recommend to run IPv4v6 whereever possible to
>         operators,
>              for the reasons you provide.
>
>

I dont think IETF wants to recommend many things, I agree.

I dont think anybody says IPv4 does not exist either.

And I dont think anybody will refuse an offer of a publicly routable 
IPv6 address and an IPv4 address be it private.

I sense the lack of IPv4 address (even a private one) as lack of 
connectivity.

> Not this "one".  But, you can run your network how you like.

:-) ok

You seem to favor IPv6-only PDP type, right?

You do agree that CLAT has some problems, including with IPv4-only 
devices behind a tethering smartphone, no?

>         https://tools.ietf.org/html/__draft-ietf-v6ops-ipv6-roaming-__analysis-07
>         <https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07>
>
>         Quoting:
>

In some places many things can be tried prior to converging.  That's an 
enviable situation.

In other places there is less chance to try many things, one should be
best at the first trial.

Alex

>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>              ___________________________________________________
>              v6ops mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>              <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>
>
>

---

From: Tore Anderson <[email-masked]>
Date: Mon, 23 Feb 2015 17:50:58 +0100

* Ca By

> This advice you provide has not been deployed in production.

Telenor Norway and Tele2 Sweden both have APNs that support IPv4v6 in
production, AFAIK. Telenor defaults to this for new handsets.

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Feb 2015 08:10:24 +0100 (CET)

> production, AFAIK. Telenor defaults to this for new handsets.

I can confirm that there is to my direct knowledge at least one network in 
the world with millions of customers, that supports IPv4v6 PDP context and 
proper handover of this between 2G/3G/4G, and this is also supported by 
devices from at least 3 different UE manufacturers.