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

From: <[email-masked]>
Date: Wed, 4 Sep 2013 10:29:09 +0200

Hi Lorenzo

Answers below

David

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : mercredi 4 septembre 2013 10:04
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked] WG; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Wed, Sep 4, 2013 at 3:31 PM, <[email-masked]<mailto:[email-masked]>> wrote:

it is about ** a ** profile for mobile devices.

But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it.
[[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs.

I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons).
[[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors.
 The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document "lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network". This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document.
[[david]] Do you mean that the current status regarding IPv6 support in devices is fine and that there is no need for other features in mobile devices ? Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document.

I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus.
[[david]] OK

Oh, and I know it's a bit out of fashion, but: what happened to "running code"? Are there *any* implementations of all this?
[[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some.

_________________________________________________________________________________________________________________________

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 Sep 2013 11:31:05 +0200

Hi,

On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote:
> > Sure, but the majority are mandatory, and don't forget that some of them
> > are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the
> > IETF's role to produce vendor requirements documents. The considerations
> > that the IETF deals with are primarily technical, and "we want this stuff
> > from our vendors" is not a technical issue.****
> >
> > *[Med] With all due respect, you are keeping the same argument since the
> > initial call for adoption and you seem ignore we are not in that stage.
> > That?s not fair at all.*
> >
> I'm just saying it here so that everyone in the community can see it. If
> it's an IETF document it has to have IETF consensus, and since I feel that
> the arguments were not properly taken into account in the WG (read:
> ignored), I think it's important that the community see them before we
> publish this document.

+1

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 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2013 17:04:24 +0900

> it is about ** a ** profile for mobile devices.
But wait... if it's just *a* profile, then why is the IETF publishing this
particular profile, and not any other profile? Is this an IETF recommended
profile? If, so then the document should state why. If not, then the
document should state that this is just one possible profile, and that the
IETF does not recommend for or against it.

I think the fundamental problem with this document is that it does not
provide solid reasons for why all 34 requirements need to be implemented
(and personally, I think that's because it just can't - there *are* no
solid reasons). The draft seems implies that all these requirements must be
met to deploy IPv6 on mobile devices, but that's not true. A great example
is the statement in the abstract which says that this document "lists the
set of features a 3GPP mobile device is to be compliant with to connect to
an IPv6-only or dual-stack wireless network". This statement is false:
there are tens of millions of mobile devices using IPv6 every day, and none
of them meet more than a minority of the requirements in this document.

I know we've already gone over this in the WG, but since this is IETF last
call, I think the rest of the community should see this discussion so that
we collectively know what the arguments for and against this proposal and
can reach informed consensus.

Oh, and I know it's a bit out of fashion, but: what happened to "running
code"? Are there *any* implementations of all this?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2013 17:50:32 +0900

On Wed, Sep 4, 2013 at 5:29 PM, <[email-masked]> wrote:

> **
> [[david]] It is a profile proposed by several operators and supported by
> other ones. Maybe you have some other proposition for mobile profile but as
> operators, this list of requirements fits our needs.
>
> Ok. So maybe you can put in the draft that this profile is a profile
supported by several operators, but not necessarily endorsed by the IETF?

> solid reasons).
> [[david]] Did you mention that not all requirements are mandatory ? It
> gives flexibility to operators to define what they are expecting from
> vendors.
>
are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the
IETF's role to produce vendor requirements documents. The considerations
that the IETF deals with are primarily technical, and "we want this stuff
from our vendors" is not a technical issue.

>   Some devices have been connected to IP networks for tens of years now
> and it does not mean we should not add new features to these devices to
> enable new services. We are considering, as operators, that current IPv6
> features in mobile devices do not satisfy all our needs as mentioned in the
> document.
>
> And how is it that you as an operator need all devices to meet requirement
#28 (a cellphone MUST also be a CPE router)? How can you say that it's
necessary to facilitate deployment?

> [[david]] We expect some implementations and we are thinking that such
> kind of document may be useful to get some.
>
> Remember, the IETF is supposed to be about rough consensus and running
code. Can we wait until there is at least one implementation that does all
this before we publish the document?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2013 18:25:17 +0900

On Wed, Sep 4, 2013 at 6:07 PM, <[email-masked]> wrote:

> *[Med] The document followed the IETF procedures and was benefited from
> the inputs and review of IETF participants; and as such it is an IETF
> document. We included text to precise this is not a standard but an
> informational document. FWIW, we formally asked for guidance from the wg in
> Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9)
> but no comment was made at that time.*
>
Then state in the document that this profile is recommended by the IETF,
and if you get consensus on that, great. But the document should say
*something* about this.

> That’s not fair at all.*

> *[Med] This is not for all mobile hosts but for those acting as mobile
> CPEs. The text is clear.*
>
True. The document does define "cellular device" as something that's
capable of sharing WAN connectivity. I don't suppose you could pick another
word than "device" here? It's confusing, because "device" usually refers to
any engineered object. Maybe use the word "sharing" or tethering" in the
name?

> *[Med] There is running code for several features listed in this
> document. Because we don’t have “decent” implementations which meet the
> minimal set of requirements from operators, a group of these operators
> decided to carry on this effort to define a common profile. Saying that, it
> seems to me you want to impose specific rules only for this document!!*
>
But the IETF doesn't define profile documents. The IETF defines technical
standards on the basis of rough consensus and running code. What you're
saying is "since we don't have running code that does what we want, we're
trying to define a profile in the hope that someone will write the code".
That's not the way it works.

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 08:31:55 +0200

Hi Lorenzo,

We already answered to several of the points in previous discussions (during the call for adoption and also during the WGLC). We also made some changes in the last version to make the language clear (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05): it is about ** a ** profile for mobile devices. The scope covers mobile hosts, hosts with wan sharing capabilities (e.g., mobile CPE) and the also those with wi-fi interfaces. The motivations for this effort and scope are explained in the introduction.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : mardi 20 août 2013 11:39
À : IETF Discussion
Cc : [email-masked] WG
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Mon, Aug 19, 2013 at 10:52 PM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:
   This document specifies an IPv6 profile for 3GPP mobile devices.  It
   lists the set of features a 3GPP mobile device is to be compliant
   with to connect to an IPv6-only or dual-stack wireless network
   (including 3GPP cellular network and IEEE 802.11 network).

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

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

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

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

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

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

Regards,
Lorenzo

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 11:07:30 +0200

Re-,

See inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 10:51
À : BINET David IMT/OLN
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked] WG; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Wed, Sep 4, 2013 at 5:29 PM, <[email-masked]<mailto:[email-masked]>> wrote:
But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it.
[[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs.
Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF?
[Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.
I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons).
[[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors.
Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and "we want this stuff from our vendors" is not a technical issue.
[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all.
 Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document.
And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment?
[Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear. There are plenty deployments relying on the mobile networks to provide broadband services. Device vendors people involved in discussion with operators in this field are quite aware of this model. You can check for instance: http://www.orange.tn/fixe-et-internet/pid382-la-flybox-orange.html
Oh, and I know it's a bit out of fashion, but: what happened to "running code"? Are there *any* implementations of all this?
[[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some.
Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document?
[Med] There is running code for several features listed in this document. Because we don't have "decent" implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 11:43:29 +0200

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 11:25
À : BOUCADAIR Mohamed IMT/OLN
Cc : BINET David IMT/OLN; [email-masked] WG; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Wed, Sep 4, 2013 at 6:07 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF?
[Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.
Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this.
[Med] What statement you would like to see added? Thanks.
Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and "we want this stuff from our vendors" is not a technical issue.
[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all.
I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document.
[Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear.
True. The document does define "cellular device" as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than "device" here? It's confusing, because "device" usually refers to any engineered object. Maybe use the word "sharing" or tethering" in the name?
[Med] The use of "cellular device" is governed by the definition included in the document:

   o  "3GPP cellular host" (or cellular host for short) denotes a 3GPP
      device which can be connected to 3GPP mobile networks or IEEE
      802.11 networks.

   o  "3GPP cellular device" (or cellular device for short) refers to a
      cellular host which supports the capability to share its WAN (Wide
      Area Network) connectivity.

and ...

   This section focuses on cellular devices (e.g., CPE, smartphones or

   dongles with tethering features) which provide IP connectivity to

   other devices connected to them.  In such case, all connected devices

   are sharing the same 2G, 3G or LTE connection.  In addition to the

   generic requirements listed in Section 2<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#section-2>, these cellular devices have

   to meet the requirements listed below.

 Because I'm naively assuming the reader interprets this term according to the definition provided in the document, I don't see what is confusing in such wording.
[Med] There is running code for several features listed in this document. Because we don't have "decent" implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!
But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is "since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code". That's not the way it works.
[Med] This document is not a standard. This is explicitly mentioned in the document.

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 13:05:21 +0200

Dear Abdussalam,

Many thanks for your review and suggestions.
The changes you proposed have been integrated in -05 (see http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-05).

As for your question about IP mobility, this is not relevant in the context of this document. Mobility is managed following 3GGP specific procedures.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Abdussalam Baryun
Envoyé : mardi 27 août 2013 13:05
À : ietf
Cc : [email-masked]; [email-masked]
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

Reviewer: Abdussalam Baryun
Date: 26.08.2013

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

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

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

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

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

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

AB

On Mon, Aug 19, 2013 at 11:52 PM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2013-09-02. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

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

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

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

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

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

---

From: SM <[email-masked]>
Date: Wed, 04 Sep 2013 11:21:44 -0700

At 02:43 04-09-2013, [email-masked] wrote:
>[Med] The document followed the IETF procedures and was benefited 
>from the inputs and review of IETF participants; and as such it is 
>an IETF document. We included text to precise this is not a standard 
>but an informational document. FWIW, we formally asked for guidance 
>from the wg in Orlando (see 
>http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no 
>comment was made at that time.

There aren't any minutes for that WG session.  Is there a formal 
request for guidance from the working group and is it possible to 
verify that there wasn't any comment at that time?

I took a quick look at the draft.  I note that, for the telechat, 
Spencer Dawkins and Pete Resnick are paid by the document. :-)  It 
would be interesting to have an approximate page count of the number 
of pages to review.

In the Introduction Section:

  "One of the major hurdles encountered by mobile operators is the
   availability of non-broken IPv6 implementation in mobile devices."

I read the above sentence several times.  My understanding is that 
having non-broken IPv6 implementations is a hurdle.  The way to fix 
that would be for mobile operators to have broken IPv6 implementations.  :-)

In Section 1.2:

  "It uses the normative keywords only for precision."

My reading of the word "precision" is that it is the ability of a 
measurement to be consistently reproduced.  I don't see how special 
language fits that.  My guess is that the intent of that sentence got 
lost in translation ( http://www.youtube.com/watch?v=pCB7cxv-Ey8 ).

In Section 2:

   "REQ#3:  The cellular host MUST comply with the behavior defined in
         [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-Context
         type."

Is the above in accordance with RFC Editor guidelines?

   "REQ#6:  The device MUST support the Neighbor Discovery Protocol
         ([RFC4861] and [RFC5942])."

In which RFCs are the Neighbor Discovery Protocol defined?  I am 
asking this question as the above does not match the information 
provided by the RFC Editor.

  "REQ#12:  The cellular host SHOULD support a method to locally
         construct IPv4-embedded IPv6 addresses [RFC6052].  A method to
         learn PREFIX64 SHOULD be supported by the cellular host."

How would the capitalized "should" be read in the above?  The 
guidance in RFC 2119 does not look applicable here.

In Section 5:

   "REQ#34:  Applications using URIs MUST follow [RFC3986].  For example,
           SIP applications MUST follow the correction defined in
           [RFC5954]."

The above says that applications must follow RFC 3986 and then 
provides an example with a capitalized "must" for RFC 5954.

The Security Considerations Section references 
draft-ietf-v6ops-rfc3316bis-04.  That draft contains exhaustive 
security considerations.   This draft doesn't say much about security 
considerations.

Regards,
-sm

---

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Sep 2013 16:32:40 +0200

>> ignored), I think it's important that the community see them before we

I know I'm formally a couple of days late on the WGLC (work!).

I agree with Lorenzo.

And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and
REQ#34 be enforced by a manufacturer (during compliance testing)?

-- 
Regards,
RayH

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 08:59:08 +0200

Hi Ray,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Ray Hunter
>Envoyé : vendredi 6 septembre 2013 16:33
>À : Gert Doering
>Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-
>04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile
>Devices) to Informational RFC
>
>
>Gert Doering wrote:
>> Hi,
>>
[Med] This was an IETF LC not WGLC... 

>REQ#34 be enforced by a manufacturer (during compliance testing)?

[Med] This can be part of the test campaigns to assess the behavior of applications shipped with the device. This is in particular important for the applications made available by the device vendor itself. For example, our teams tested a device which can get IPv6 connectivity...but the user cannot use the store from that vendor to get applications in IPv6-mode. There are other applications which make use of IPv4 address literals, etc. The requirements is valid for applications dev'ed by the vendor or a third-party.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Sep 2013 11:19:42 +0100

> ignored), I think it's important that the community see them before we

I'm not sure the consensus requirement you're suggesting actually exists.
This is aiming at Informational, and as such:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational

[RFC 2026 §4.2.2]

> That's not the way it works.

No, the IETF has published profile documents in a number of cases. One
could argue that RFC 1122 and RFC 1123 are both profile documents,
actually, but there are other specific examples, like the Lemonade profile,
for example.

I suspect, however, that this document is actually a standard, or intended
as one. There's discussion about conformance, about testing for
conformance, and so on, which suggests that an operator (in particular)
might treat any resultant RFC as a standard without regard for its IETF
status. That's a concern, though in practise, if this is to be a document
detailing "what operators want", I'd be happier that it's published through
the IETF as Informational than not published at all - and in any case, no
amount of pretence will alter the fact that people will treat any RFC as a
standard if it suits them anyway.

What may be more useful, though, would be to get more stakeholders involved
in a commonly agreed profile, and supercede this.

Dave.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Sep 2013 13:56:55 +0300

Browsing through the document I am not sure how much weight is carries 
when an IETF working group defines what 3GPP networks should be doing, 
particularly when talking about protocols the 3GPP has not really 
expressed an opinion about.

 From the document it is unclear to me what requirements are directly 
taken from 3GPP specifications and what additional requirements the 
authors have added.

On 09.09.2013 13:19, Dave Cridland wrote:
>
>
>
> On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I'm just saying it here so that everyone in the community can see
>     it. If it's an IETF document it has to have IETF consensus, and
>     since I feel that the arguments were not properly taken into account
>     in the WG (read: ignored), I think it's important that the community
>     see them before we publish this document.
>
>
> I'm not sure the consensus requirement you're suggesting actually
> exists. This is aiming at Informational, and as such:
>
>     An"Informational"  specification is published for the general
>     But the IETF doesn't define profile documents. The IETF defines
>     technical standards on the basis of rough consensus and running
>     code. What you're saying is "since we don't have running code that
>     does what we want, we're trying to define a profile in the hope that
>     someone will write the code". That's not the way it works.
>
>
> actually, but there are other specific examples, like the Lemonade
> profile, for example.
>
> I suspect, however, that this document is actually a standard, or
> intended as one. There's discussion about conformance, about testing for
> status. That's a concern, though in practise, if this is to be a
> document detailing "what operators want", I'd be happier that it's
> published through the IETF as Informational than not published at all -
> and in any case, no amount of pretence will alter the fact that people
> will treat any RFC as a standard if it suits them anyway.
>
> What may be more useful, though, would be to get more stakeholders
> involved in a commonly agreed profile, and supercede this.
>
> Dave.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Sep 2013 20:01:14 +0900

>    Internet community consensus or recommendation.  The Informational

Fair enough. But the document then proceeds to use RFC2119 normative
language, which is not appropriate because it's not a standards track
document. Normative language is not appropriate for informational
documents; there was a big discussion over that for RFC6092, and that ended
up being published with a note well saying, "this document is not a
standard, and conformance with it is not required in order to claim
conformance with IETF standards for IPv6." You may note that no such
"conformance is not required" text is present here. This is at best
confusing and at worst misleading.

If this document were to plainly state that it simply represents the set of
features that a particular set of operators feels is necessary for IPv6
deployment on mobile networks, but that it is not an IETF standard, and
compliance with it is not necessary to deploy IPv6 on mobile networks or to
claim conformance with IETF standards, I would have no objection to it.

> actually, but there are other specific examples, like the Lemonade profile,

I had written a few paragraphs explaining why this document and RFC 1122 /
1123 are not even remotely comparable, but I think that's beside the point
of this discussion. I think the main point is that RFC 1122/1123 are
standards and this document is not intended to be one.

> status.

Absolutely. Such an operator might well decide to say that the requirements
for all devices on their network are captured in this standard, and the
IETF would have nothing to say about it. But the point is that it would be
the operator setting the requirements, not the IETF. The IETF cannot set
requirements in an informational document.

That's a concern, though in practise, if this is to be a document detailing
> "what operators want", I'd be happier that it's published through the IETF
> as Informational than not published at all - and in any case, no amount of
> pretence will alter the fact that people will treat any RFC as a standard
> if it suits them anyway.
>

Sure, but if said document said "this is not a standard" in so many words,
then that would be a difficult position to convince others of.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 13:06:51 +0200

Lorenzo,

The document explicitly says "This document is not a standard." since version -00.

What additional statement you would like to see added?

Cheers,

Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : lundi 9 septembre 2013 13:01
À : Dave Cridland
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked] WG; BINET David IMT/OLN; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland <[email-masked]<mailto:[email-masked]>> wrote:
I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such:

Fair enough. But the document then proceeds to use RFC2119 normative language, which is not appropriate because it's not a standards track document. Normative language is not appropriate for informational documents; there was a big discussion over that for RFC6092, and that ended up being published with a note well saying, "this document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6." You may note that no such "conformance is not required" text is present here. This is at best confusing and at worst misleading.

If this document were to plainly state that it simply represents the set of features that a particular set of operators feels is necessary for IPv6 deployment on mobile networks, but that it is not an IETF standard, and compliance with it is not necessary to deploy IPv6 on mobile networks or to claim conformance with IETF standards, I would have no objection to it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Sep 2013 20:24:14 +0900

On Mon, Sep 9, 2013 at 8:06 PM, <[email-masked]> wrote:

> The document explicitly says “This document is not a standard.” since
> version -00.
>
> ** **
>
I think the high-order points are:

1. The text "This document defines an IPv6 profile for 3GPP mobile devices.
It lists the set of features a 3GPP mobile device is to be compliant with
to connect to an IPv6-only or dual-stack wireless network" should be
replaced with "This document defines an IPv6 profile for 3GPP mobile
devices that a number of operators believe is necessary to deploy IPv6 on
an IPv6-only or dual-stack wireless network (including 3GPP cellular
network and IEEE 802.11 network)."

In place of "a number of operators believe is necessary to deploy" you
could have "intend to deploy" or "require". I'd guess that as long as it's
clear that the requirements don't come from the IETF but from a number of
operators (not all of them, or a majority of them), it doesn't matter
exactly what you say.

2. In the normative language section, I'd like to see a statement similar
to what's in RFC 6092. Perhaps something like this?

1.3.  Use of Normative Keywords

      NOTE WELL: This document is not a standard. Conformance with it is
      not required to deploy IPv6 in mobile networks or to claim conformance
      with IETFstandards for IPv6.  It uses the normative keywords defined
in the
      previous section only for precision.

Regards,
Lorenzo

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 14:16:54 +0200

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : lundi 9 septembre 2013 13:24
À : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Cridland; [email-masked] WG; BINET David IMT/OLN; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Mon, Sep 9, 2013 at 8:06 PM, <[email-masked]<mailto:[email-masked]>> wrote:
The document explicitly says "This document is not a standard." since version -00.

1. The text "This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network" should be replaced with "This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network)."

In place of "a number of operators believe is necessary to deploy" you could have "intend to deploy" or "require". I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say.
[Med] I made this change:

OLD:

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

New:

   This document defines an IPv6 profile that a number of operators
   require in order to connect 3GPP mobile devices to an IPv6-only or
   dual-stack wireless network (including 3GPP cellular network and IEEE
   802.11 network).

2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this?
[Med] I used the same wording as in RFC6092. The change is as follows:

OLD:

   This document is not a standard.  It uses the normative keywords only
   for precision.

NEW:

      NOTE WELL: This document is not a standard, and conformance with
      it is not required in order to claim conformance with IETF
      standards for IPv6.  It uses the normative keywords defined in the
      previous section only for precision.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 21:19:46 +0000

Owen, do you have any technical objection to raise about this document, or are you just replying because you like the sound the keys make as you type?

The working group adopted the document, so it's too late to object that the working group shouldn't be working on it.   You can object by pointing out that it doesn't do what it says it's going to do, but if so you'd need to actually make the case that it doesn't do that, not just assert that it doesn't do that.

Your point about RFC 2119 language has been addressed, so there's no sense in re-raising it unless you have some specific objection to state about the way in which it was addressed ("I'm not satisfied" is not a specific objection).

Etc.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Sep 2013 01:25:58 +0000

It has been pointed out to me that I went overboard in my response to you.   I will state what was obvious to me as I wrote my response, but may not have been obvious to other readers: I am not the responsible AD for v6ops.   My response was that of a participant in v6ops.

I didn't find what you wrote helpful, but what I like isn't particularly important in this case, unless you decide it is.   I did not intend to suggest that you should not criticize this document.   I would like to see more substance to the criticism.

But the way I expressed that desire was (a) overly sarcastic and (b) not constructive, and I apologize for that.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 09 Sep 2013 21:41:42 -0700

On 9/9/13 4:24 AM, Lorenzo Colitti wrote:
> On Mon, Sep 9, 2013 at 8:06 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     The document explicitly says “This document is not a standard.”
>     since version -00.
> 
>     __ __
> 
> 1. The text "This document defines an IPv6 profile for 3GPP mobile
> devices. It lists the set of features a 3GPP mobile device is to be
> compliant with to connect to an IPv6-only or dual-stack wireless
> network" should be replaced with "This document defines an IPv6 profile
> for 3GPP mobile devices that a number of operators believe is necessary
> to deploy IPv6 on an IPv6-only or dual-stack wireless network (including
> 3GPP cellular network and IEEE 802.11 network)."
> 
> could have "intend to deploy" or "require". I'd guess that as long as
> it's clear that the requirements don't come from the IETF but from a
> number of operators (not all of them, or a majority of them), it doesn't
> matter exactly what you say.

So this is a problem, and part of the reason I had enough concern about
this document to not take it forward. being genereous the consensus on
this document is pretty rough. if the outcome doesn't include the
consent of implementors it's not very good advice.

> 2. In the normative language section, I'd like to see a statement
> similar to what's in RFC 6092. Perhaps something like this?
> 
>       with IETFstandards for IPv6.  It uses the normative keywords
> defined in the

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 08:27:09 +0200

Hi Joel,

Please see inline.

Cheers,
Med

>De : joel jaeggli [mailto:[email-masked]]
>Envoyé : mardi 10 septembre 2013 06:42
>À : Lorenzo Colitti; BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked] WG; IETF Discussion; BINET David IMT/OLN

[Med] Joel, the intent of the document is clear: the goals and scope are unchanged since the individual submission.  You can read the following in the introduction: 

"   This document specifies an IPv6 profile for mobile devices listing
   specifications produced by various Standards Developing Organizations
   (in particular 3GPP and IETF).  The objectives of this effort are:

   1.  List in one single document a comprehensive list of IPv6 features
       for a mobile device, including both IPv6-only and dual-stack
       mobile deployment contexts.  These features cover various network
       types such as GPRS (General Packet Radio Service), EPC (Evolved
       Packet Core) or IEEE 802.11 network.

   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.

   3.  Vendors to be aware of a set of features to allow for IPv6
       connectivity and IPv4 service continuity (over an IPv6-only
       transport)."

Operators will use this profile  (or some part of it (context-based: ipv6-only, DS, CPE model, etc.)) for further discussion with their vendors. We are not changing that process. This document is a contribution to have non broken IPv6 implementations. 

For instance, our device partners will see in our 500 pages device requirements document (OGDR) pointers to this profile document. So adding the text suggested by Lorenzo is fine by me. This is the change added to my local copy:

Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. 

How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers from vendors who are happy with the content of the document ... but in the meantime I have two reviewers from the same company: one of them suggested to make some edits to enhance the document while the other reviewer have some concerns. The concerns of the second reviewer were addressed and changes were added to my local copy.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 15:42:46 +0900

> Having consent form all vendors is valuable but I'm afraid this is not the

If not "all vendors", then what about "some vendors"? Is it a goal of this
document to have consensus from some implementors? Or is consensus from
implementors a non-goal?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 15:48:31 +0900

On Mon, Sep 9, 2013 at 9:16 PM, <[email-masked]> wrote:

> *
> NEW:*
>
> * *
>
>       NOTE WELL: This document is not a standard, and conformance with****
>
>       it is not required in order to claim conformance with IETF****
>
>       standards for IPv6.  It uses the normative keywords defined in the**
> **
>
>       previous section only for precision.****
>
> * *
>

That's better, thanks. I still think it's important for the document to say
that it's not necessary to do all mountain of work to deploy IPv6, because
otherwise there's the risk that product managers/implementors will say,
"Wait, are you're saying that to deploy IPv6 we have to do all that work?
We can't do all that. Let's focus on something else instead."

How about changing "is not required in order to claim conformance with IETF
standards for IPv6" to "is not required to deploy IPv6 on other networks or
to claim conformance with IETF standards for IPv6"?

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 08:57:52 +0200

Re,

I have considered that Lorenzo. "is not required to deploy IPv6" would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model.

Cheers,
Med

Envoyé : mardi 10 septembre 2013 08:49

On Mon, Sep 9, 2013 at 9:16 PM, <[email-masked]<mailto:[email-masked]>> wrote:

NEW:

That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, "Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead."

How about changing "is not required in order to claim conformance with IETF standards for IPv6" to "is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6"?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 16:20:37 +0900

On Tue, Sep 10, 2013 at 3:57 PM, <[email-masked]> wrote:

> I have considered that Lorenzo. “is not required to deploy IPv6” would be
> accurate if this document is dealing only with dual-stack, but this is not
> true for the IPv6-only mode. The set of SHOULD recommendations are
> targeting that deployment model.
>

I disagree. By my reading, you can make a phone that works perfectly well
on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11,
#12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36.
Some of those are MUSTs in this document.

If you want to do IPv6-only on wifi you need either #9 and #10 (or both
plus #11 as well), and either #20 or #21 (or both plus #23). But the other
ones are not necessary to deploy an IPv6-only phone. One of your co-authors
will be able to confirm this: I'm told there are multiple IPv6-only phones
on T-Mobile USA today, and I'm sure none of them implement all the
requirements in this document (or even all the MUSTs).

[*] How did #18 even make it in? What use is a MAY in a requirements
document? Of course implementors MAY do anything they want, unless they
SHOULD NOT or MUST NOT.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 16:23:09 +0900

On Tue, Sep 10, 2013 at 3:27 PM, <[email-masked]> wrote:

> How can we ensure every implementers will agree with this list? For
> instance we have two detailed technical reviewers

Are reviews still appropriate? I think there are a lot of things left to
say about this document beyond the high-order points we're discussing at
the moment.

If I write them down, will they be considered or will the answer be that
it's too late to accept feedback because the document is already in last
call?

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 10:18:49 +0200

Re-,

I really don't see how you can have a phone that "make a phone that works perfectly well on an IPv6-only" if you don't support IPv6/IPv4v6 PDP context, you don't have a means to make work broken applications when IPv6-only is enabled, if the phone does not follow the procedure for requesting the PDP context, how you can be compatible with DNSSEC, etc.

If what you mean by "perfect" is a degraded level of service, then you are right.

I update the text to reflect this:

      standards for IPv6.  The support of the full set of features may

      not be required in some contexts (e.g. dual-stack).  The support

      of a subset of the features included in this profile may lead to

      degraded level of service (e.g., IPv6-only mode).

      This document uses the normative keywords defined in the previous

      section only for precision.

Is this better?

Cheers,

Med

Envoyé : mardi 10 septembre 2013 09:21

On Tue, Sep 10, 2013 at 3:57 PM, <[email-masked]<mailto:[email-masked]>> wrote:
I have considered that Lorenzo. "is not required to deploy IPv6" would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model.

I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document.

If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs).

[*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 18:26:53 +0900

On Tue, Sep 10, 2013 at 5:18 PM, <[email-masked]> wrote:

> I really don’t see how you can have a phone that “make a phone that works
> perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP
> context
>
You don't need to support IPV4V6 if all you need to do is work on an
IPv6-only network. That might seem like a stupid answer, but the point I'm
trying to make is that while you and I know that supporting only IPV6 will
result in the phone being incompatible with some networks *the document
doesn't say that*. The document says you MUST support all this stuff,
without saying why, and without giving any information to operators,
implementers, or anyone else on why this particular laundry list of
features was selected. That's not a good way to specify things. Look at
RFC1122, for example: every requirement is carefully articulated, with
rationale and everything else.

> you don’t have a means to make work broken applications when IPv6-only is
> enabled
>
Nobody can control third party-applications, not even the phone
manufacturer (which is why REQ#33 doesn't make sense). The manufacturer can
provide something like 464xlat, which I agree is necessary for IPv6-only
operation.

> if the phone does not follow the procedure for requesting the PDP context,
>
You don't need to do that if you have an APN database that's configured
with what the operator supports, or if you don't support IPV4V6. (Straying
back into technical discussion for a bit - from a technical point of view,
having seen the wide variety of behaviours and result codes that basebands
typically exhibit when you ask them to do something that they or the
network doesn't support, I think relying on this fallback is a terrible
idea.)

> how you can be compatible with DNSSEC, etc.
>
How many phones today support DNSSEC?

>       standards for IPv6.  The support of the full set of features may****
>
>       not be required in some contexts (e.g. dual-stack).  The support****
>
>       of a subset of the features included in this profile may lead to****
>
This is not about IPv6-only mode. That's a useful feature, and as I'm sure
you know, it's been implemented by a number of manufacturers.

Consider an implementation that implements IPv6 tethering without including
a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful
DHCPv6 and all the bells and whistles built in. Or consider a 464xlat
implementation without a local DNS64 implementation.

I don't consider these to be degraded service, I consider them to be a lot
better than what we have today. But someone taking this document as a guide
to what needs to be implemented to deploy IPv6 would consider them to be
incomplete or broken implementations. Such a person might look at the 34
requirements and just give up, when in fact such an implementation is
perfectly capable of doing IPv6 today.

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 13:12:35 +0200

Re-,

Please see inline.

Cheers,
Med

Envoyé : mardi 10 septembre 2013 11:27

On Tue, Sep 10, 2013 at 5:18 PM, <[email-masked]<mailto:[email-masked]>> wrote:
I really don't see how you can have a phone that "make a phone that works perfectly well on an IPv6-only" if you don't support IPv6/IPv4v6 PDP context
You don't need to support IPV4V6 if all you need to do is work on an IPv6-only network.
[Med] UEs that will provided with IPv6-only or DS is up to the provider. Note also that the requirement is worded to let the decision to each provider. The document explicitly says:

           This allows each operator to select their own strategy
           regarding IPv6 introduction.  Both IPv6 and IPv4v6 PDP-
           Contexts MUST be supported.  IPv4, IPv6 or IPv4v6 PDP-Context
           request acceptance depends on the cellular network
           configuration.

That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff
[Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features.

, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected.
[Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That's not fair.

That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else.
[Med] This document is not a standard. This document does not ambition to have the same level as RFC1122.
you don't have a means to make work broken applications when IPv6-only is enabled
Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense).
[Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode.

The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation.
[Med] Are you saying this  is a MUST?
if the phone does not follow the procedure for requesting the PDP context,
You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.)
how you can be compatible with DNSSEC, etc.
How many phones today support DNSSEC?
[Med] How many device support IPv6 today? We can play that game endlessly...

This is not about IPv6-only mode.
[Med] What is wrong in that text? Can we focus on the exact text change?

That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers.

Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation.
[Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones...while this is not true.

I don't consider these to be degraded service, I consider them to be a lot better than what we have today.
[Med] I'm sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 20:54:44 +0900

On Tue, Sep 10, 2013 at 8:12 PM, <[email-masked]> wrote:

> *[Med] No. no, no the document indicates the language for each feature:
> there are MUST, SHOULD, etc. This is not the first time a document makes
> such classification of the features.*
>
Sorry - what I meant is: "most of the text in the document says that
devices MUST support this, SHOULD support that, SHOULD support the other",
but not much time saying why.

**
>
> *[Med] There is already motivations text for most of features, rationale
> and scope of the overall effort in the draft. You are continuing ignore it.
> That’s not fair.*
>
Isn't it? For example, look at RFC1122 and compare it to this document.
Compare the percentage of text used to state requirements and the
percentage of text used for rationale. If anything, an informational
document should have fewer requirements and more rationale than a standard,
not the other way around.

> manufacturer (which is why REQ#33 doesn't make sense).****
>
> *[Med] There are API, there applications shipped by device vendors
> themselves, etc. Our teams already tested applications provided by vendors
> devices which are broken when IPv6-only mode.*
>
Then change the requirement to say vendor applications must not be
IPv4-only. At least it's a reasonable request (though one that's unlikely
to happen before IPv6 is widely deployed). "All apps" is not a reasonable
request.

* *
> *[Med] Are you saying this  is a MUST?*
>
I don't think this document should be a bunch of "MUST this", "SHOULD
that", "MUST the other". As regards 464xlat, I think that shipping an
IPv6-only phone without 464xlat or something equivalent equals shipping a
phone that's not useful, and that doesn't happen in the real world. So if
you want to ship IPv6-only, you need something like 464xlat. Does it follow
that a phone MUST implement 464xlat? No, it does not.

> **
>
> *[Med] How many device support IPv6 today? We can play that game
> endlessly...*
>

Not really, because upwards of 30 million mobile devices are using IPv6
every day on Verizon Wireless alone. See:

http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13462152832-2.pdf
http://www.worldipv6launch.org/measurements/

Those phones do not meet the requirements of this draft. They violate at
least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs.

According to the text in -05, that means they cannot "connect to an
IPv6-only or dual-stack wireless network including 3GPP cellular network
and IEEE 802.11 network)." I know that text won't be there in the next
version, but the point I'm trying to make is that the document made it all
the way to IETF last call while claiming that largest deployment of IPv6 in
a mobile network was not possible. I don't want that to be the message
coming out of this document.

> This is not about IPv6-only mode.****
>
> *[Med] What is wrong in that text? Can we focus on the exact text change?*
>
"The operators proposing this profile believe that the support of a subset
of the features included in this protocol may lead to degraded level of
service."

 * *
>
> Consider an implementation that implements IPv6 tethering without
> including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD,
> stateful DHCPv6 and all the bells and whistles built in. Or consider a
> 464xlat implementation without a local DNS64 implementation.
>
> **
>
> *[Med] You still do that. These features are not MUST in this document.
> It is your right to ignore them but you need to be aware this may have some
> negative impact. It seems you understand the list as MUST ones…while this
> is not true.*
>
Per the document, if you implement IPv6 tethering you MUST implement a full
RFC 6204 router in the device (req#28).

* *****
>
> ** I don't consider these to be degraded service, I consider them to be a
> lot better than what we have today.
>
> *[Med] I’m sorry to say that a customer with IPv6-only connectivity that
> cannot use some applications available for an IPv4 customer is a degraded
> service. This is seen by some operators as a barrier for that mode.  *****
>
I stand by my opinion that IPv6 tethering without a full RFC6204
implementation and that 464xlat without a local DNS64 implementation are
not degraded.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 9 Sep 2013 14:25:49 -0700 (PDT)

> From: Owen DeLong <[email-masked]>
>To: Vízdal Aleš <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]>; IETF Discussion <[email-masked]>; Dave Cridland <[email-masked]> 
>Sent: Tuesday, 10 September 2013 7:04 AM
>Subject: Re: [v6ops] Last Call:    <draft-ietf-v6ops-mobile-device-profile-04.txt>    (Internet    Protocol Version 6 (IPv6) Profile for 3GPP Mobile    Devices) to    Informational RFC
> 
>
>

<snip>

>
>Why is there such a push to do this?
>>[av] Because the Operators are currently missing such a document, so they went to the IETF to work on one.
>>As written in the document the number of well behaving IPv6 capable mobile devices is not very high at the moment.
>>This initiative is intended to help the developers.
>
>Is there any reason a cellphone shouldn't just meet the standard requirements like any other router?
>

I agree with this view. I don't think there is anything that special about portable computers that  that can make phone calls ("mobile multihomed hosts"*).

It seems to me the only thing special here is that one of the links the MMHH has is a 3G/4G etc. one, and the operators of those networks have certain views on how those networks should operate. That would seem to me to give them the ability to select what parameters are chosen for IPv6 operation over their networks e.g., stateful DHCPv6 only, prefix lifetimes of 2/1 hours etc., but to extend that to listing IPv6 protocol implementation requirements across the whole MMHH seems excessive and unnecessary. Surely the existing IPv6 node requirements RFC is enough for that?

Regards,
Mark.

*"The Rapid Rise of the Mobile Multihomed Host, and what it might mean to the network"
http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf

---

From: Owen DeLong <[email-masked]>
Date: Mon, 9 Sep 2013 13:06:48 -0700

I have to agree with Lorenzo here again.

This document seems to me to be:

	1.	Out of scope for the IETF.
	2.	So watered down in its language as to use many words to say nearly nothing.
	3.	Claims to be informational, but with so many caveats about the nature of that
		information that it's hard to imagine what meaningful information an independent
		reader could glean from the document.

Finally, given the spirited debate that has extended into this last call (which I honestly wonder
how this ever saw last call over the sustained objections) definitely does not appear to have
even rough consensus, nor does it appear to have running code.

Owen

On Sep 9, 2013, at 05:16 , <[email-masked]> wrote:

> The document explicitly says “This document is not a standard.” since version -00.
>  
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Mon, 9 Sep 2013 14:04:57 -0700

On Sep 9, 2013, at 13:36 , Vízdal Aleš <[email-masked]> wrote:

> Please see inline.
>  
> Ales
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Owen DeLong
> Sent: Monday, September 09, 2013 10:07 PM
> To: [email-masked]
> Cc: [email-masked] WG; Dave Cridland; IETF Discussion
> [av] Strongly disagree. The IETF as the IPv6 owner is the right place to define what qualifies a device to be IPv6 compliant. (a mobile one in this case)
>  

This is intended as "informational", not a standards track document, so it does not do that.

> [av] Hints on how the text shall be changed are always welcome.

If you don't leave it watered down, it becomes a standards track document. There appears to be even greater resistance to that, so I don't see such a document as being likely to achieve any greater degree of consensus.

>                   [av] The reader will learn what must/should/may be implemented in a mobile device to support IPv6.

Except that this document is clearly marked as informational and not standards track and there fore the application of must/should/may to it is seemingly rather absurd.

> [av] Med has posted an answer on this one earlier in the thread.
>  

I was not entirely satisfied with his answer.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Tue, 10 Sep 2013 09:52:24 -0700

On 9/9/13 1:06 PM, Owen DeLong wrote:
> 1.Out of scope for the IETF.

AD here... let's put this one to bed. there are existance proof(s) of
previous work in this area and others that covers similar ground.

I don't believe that this is out of scope for the WG or the IETF,
Neither did the previous AD.

So... Focus on the contents.

> 2.So watered down in its language as to use many words to say nearly
> nothing.
> 3.Claims to be informational, but with so many caveats about the nature
> of that
> On Sep 9, 2013, at 05:16 , <[email-masked]
>> *De :* Lorenzo Colitti [mailto:[email-masked] <http://google.com/>] 
>> *Envoyé :* lundi 9 septembre 2013 13:24
>> *À :* BOUCADAIR Mohamed IMT/OLN
>> *Cc :* Dave Cridland; [email-masked] <mailto:[email-masked]> WG; BINET
>> David IMT/OLN; IETF Discussion
>> *Objet :* Re: [v6ops] Last Call:
>> <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol
>> Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
>>  
>> network" should be replaced with "This document defines an IPv6
>> profile for 3GPP mobile devices that a number of operators believe is
>> necessary to deploy IPv6 on an IPv6-only or dual-stack wireless
>> network (including 3GPP cellular network and IEEE 802.11 network)."
>>  
>> number of operators (not all of them, or a majority of them), it
>> doesn't matter exactly what you say.
>> */[Med] I made this change:/*
>> */ /*
>> */OLD:/*
>> */ /*
>> */ /*
>> */New:/*
>> */ /*
>> */
>> /*
>> */[Med] I used the same wording as in RFC6092. The change is as follows:/*
>> */ /*
>> */OLD:/*
>> */ /*
>> */ /*
>> */NEW:/*
>> */ /*
>> */ /*
>> [email-masked] <mailto:[email-masked]>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 11 Sep 2013 11:40:38 +0200

> 	1.	Out of scope for the IETF.

Please define what is the IETF scope? IMHO, IETF is scoped to do with
IPv6 devices requirements and implementations. Do you think there is a
RFC that considers thoes requirements?

> 	2.	So watered down in its language as to use many words to say nearly

No, the draft says things, I think if you read nothing that you did
not read then. If you read, then what is your definition of saying
nothing?

> 		reader could glean from the document.

I think this was mentioned clearly in the draft, which readers can understand.

> even rough consensus, nor does it appear to have running code.

IMHO, the LC is not for consensus, but it is for us to send the IESG
our comments, and then they decide what is the IETF decision.
> Why is there such a push to do this?

Why is there a push to water-down it? I still was not convinced by
your argument. However, Lorenzo comments should be considered by the
draft as the authors are working on.

AB

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Sep 2013 14:45:18 -0700

> RFC that considers thoes requirements?

The queue for dicussion of this point is closed. If there needs to be an
appeal on this point now or in the future, then I'll be happy to help
someone write it, but I consider that dicussion settled for the purposes
of a draft that has already been tested for wg acceptance/wglc/ietf-lc

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Sep 2013 13:39:23 +0900

> of a draft that has already been tested for wg acceptance/wglc/ietf-lc

To clarify - you're talking only about the discussion on whether this draft
is in scope? Or are you saying that you consider all discussion of this
document in this IETF last call settled?

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Sep 2013 23:08:25 -0700

On 9/11/13 9:39 PM, Lorenzo Colitti wrote:
> On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> To clarify - you're talking only about the discussion on whether this
> draft is in scope? Or are you saying that you consider all discussion of
> this document in this IETF last call settled?

The discussion of whether the IETF, or this working group is a suitable
location.

It was my opinion that the working group should revist the document
itself given what I saw in the last call.

joel

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Sep 2013 23:21:22 -0700

> RFC that considers thoes requirements?

From an RFC perspective, I think a cellular device is a host and/or router
and those cover it.

The media-specific aspects of layering IPv6 onto he peculiarities and vagaries
of the underlying cellular specific technologies are, IMHO, best left to the media
adaptation efforts of the relevant media standards bodies (as was done with
ethernet, FDDI, Firewire, etc.).

> not read then. If you read, then what is your definition of saying

The draft says many things most or all of which conflict with things said elsewhere and
all of which are fronted by a strong "this is advisory only" caveat. In fact, it says far
too many things with far too little strength. The net result is that the document will,
in the long run, become a no-op at best and a quagmire of conflicting and misleading
advice at worst.

> I think this was mentioned clearly in the draft, which readers can understand.

I don't doubt that readers can understand it. My point is that once you understand
the sum of the caveats and warnings and advisory nature of this document, the sum
of all those understandings is that you have to look for the true answer to virtually
everything contained here somewhere outside of the IETF anyway.

> our comments, and then they decide what is the IETF decision.

I suppose everyone is entitled to their opinion.

> draft as the authors are working on.

If you think I am pushing to water it down, you are mistaken. I'd like to see it
pared down to a useful document and then given the force of being a standards
track document so it can actually provide something useful.

Owen