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

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 28 Jan 2015 16:57:44 +0000

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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 29 Jan 2015 20:53:16 +0900

On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <[email-masked]> wrote:

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

Ok, off we go again then.

I have objected to this document already, and was found to be in the rough.
Therefore, I must assume that rough WG consensus is that we need a document
that looks something like this, and I will accordingly refrain from making
any general statements on the scope, utility, and general content of the
document, with which I continue to disagree.

However, I would be remiss if I did not at least draw attention to the
following factual errors and/or inappropriate statements.

1. The wording "required features to connect 3GPP mobile devices to an
IPv6-only or dual-stack wireless network" is factually incorrect. The vast
majority of these recommendations are not required to connect to such
networks, and are many are not even implemented by many popular mobile
operating systems - which manage to connect just fine. After long
discussions, that text was removed in -06. Why was it readded?

2. Previous versions of the document, including the version that passed
IETF last call, contained the text:

   This document is not a standard, and conformance with it is not
   required in order to claim conformance with IETF standards for IPv6.
   The support of the full set of features may not be required in some
   deployment contexts.  The authors believe that the support of a
   subset of the features included in this protocol may lead to degraded
   level of service in some deployment contexts.

That text remains accurate and that statement is still necessary. Why was
it removed? It has been in the document since -06, and the words "this
document is not a standard" have been in this document since -01.

3. I object to the statement "One of the major hurdles encountered by
mobile operators is the availability of non-broken IPv6 implementation in
mobile devices." I submit that if it were true, then we would observe no
IPv6 deployment in mobile networks... but publicly-available data - e.g.,
http://www.worldipv6launch.org/measurements/ - shows that multiple
operators have deployed IPv6 to up to 30-65% of their footprint, using the
same commercially-available devices that are used by customers of other
operators. So claiming that "broken IPv6 implementations in mobile devices"
are a major hurdle is at best incomplete and at worst incorrect.

At the risk of sounding like a broken record, I am going yet again to say
that that operational documents should be based on operational experience.
I am not aware of any of the authors' employers having a substantial IPv6
deployment (though I would be happy to see any data that the authors could
provide to the contrary). On the other hand, the IPv6 lead on one of the
operators that *has* deployed IPv6 no longer appears in the list of authors.

Regards,
Lorenzo

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Jan 2015 13:15:04 +0100

> On 28 Jan 2015, at 17:57 , Fred Baker (fred) <[email-masked]> wrote:
> 

+1 to Lorenzo's comments.

in addition.

   C_REC#11:  If the cellular host receives the DNS information in
              several channels for the same interface, the following
              preference order must be followed:

                 1.  PCO

                 2.  RA

                 3.  DHCPv6

in the other areas this issue has come up. then the conclusion has been that the host uses all the information received. I think it would be quite unfortunate that the host stack much behave differently depending on the link-layer. I would suggest either to drop the requirement, or to say that the implementation must use all DNS servers learnt.

same comment applies to W_REC#4.
I can't see a good reason why hosts that also have cellular interfaces should work differently on a WLAN as opposed to those that don't have cellular interfaces.

why does e.g. A_REC#3 refer to NATs?

"Tracking a host is still possible based on the first 64
 bits of the IPv6 address.  Means to prevent against such
 tracking issues may be enabled in the network side."

what does this allude to?

---

From: James Woodyatt <[email-masked]>
Date: Thu, 29 Jan 2015 12:07:13 -0800

Additionally—

Editorial: the section for Security Considerations currently says this:

Security-related considerations that apply when the cellular
> device provides LAN features are specified in [RFC6092
> <https://tools.ietf.org/html/rfc6092>].

This sentence is a bit awkward— but more importantly, RFC 6092 is not a
specification, and the chain of citation that lead to its reference here is
far from clear.  I suggest the following wordier but more helpful
replacement:

In the case of cellular devices that provide LAN features, compliance with
> L_REC#2 entails compliance with RFC 6204, which in turn recommends
> compliance with Recommended Simple Security Capabilities in Customer
> Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [
> RFC6092 <https://tools.ietf.org/html/rfc6092>]. Therefore, the security
> considerations in section 6 of that document are relevant. In particular,
> it bears repeating here that the true impact of stateful filtering may be a
> reduction in security, and that IETF make no statement, expressed or
> implied, as to whether using the capabilities described in any of these
> documents ultimately improves security for any individual users or for the
> Internet community as a whole.

p.s. I also share all of Lorenzo's other specific concerns about this
draft, as well as his broad general objections.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Jan 2015 21:12:51 +0100

Hi,

> +1 to Lorenzo's comments.

Another +1 - I can't see this reflecting WG consensus, more "everybody
besides Lorenzo has given up".

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: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jan 2015 09:39:19 +1300

To be honest I stopped tracking this draft a long time ago,
so didn't speak up during the first WGLC. But I think I'm
in the rough with Lorenzo. The document reads like somebody's
procurement spec, not like a set of recommendations for
generic interoperability. And the devil is in the details.
For example, I noticed a point where I have a little skin
in the game:

   APP_REC#3:  Applications provided by the mobile device vendor that
               use Uniform Resource Identifiers (URIs) must follow
               [RFC3986].  For example, SIP applications must follow the
               correction defined in [RFC5954].

So, does that requirement include the updates to RFC 3986 (i.e. RFC 6874
and 7320)? And how is applying a correction to RFC 3261 an "example"
of following RFC 3986? And anyway, shouldn't this be in a SIP profile,
not here?

That's an illustration of why this document positioned as an IETF work
product makes me uncomfortable. I imagine there are many other similar
hidden issues.

    Brian

On 30/01/2015 00:53, Lorenzo Colitti wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 07:13:44 +0000

Hi Fred,

Thank you for initiating the call. 

>From my editor window, the recommendations as included in this version have all been listed in the version that passed the WGLC and IETF LC. The main change is that we removed all the reco that are present in RFC7066/RFC6436 + remove the "special language" as per the IESG's request. 

Saying that, we are open to tweak the text to record the feedback from this call.

Cheers,
Med   

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Fred Baker (fred)
Envoyé : mercredi 28 janvier 2015 17:58
À : V6 Ops List
Cc : [email-masked]
Objet : [v6ops] draft-ietf-v6ops-mobile-device-profile last call

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 07:35:17 +0000

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 29 janvier 2015 12:53
À : Fred Baker (fred)
Cc : V6 Ops List; [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:
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.

I have objected to this document already, and was found to be in the rough. Therefore, I must assume that rough WG consensus is that we need a document that looks something like this, and I will accordingly refrain from making any general statements on the scope, utility, and general content of the document, with which I continue to disagree.

However, I would be remiss if I did not at least draw attention to the following factual errors and/or inappropriate statements.

1. The wording "required features to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network" is factually incorrect. The vast majority of these recommendations are not required to connect to such networks, and are many are not even implemented by many popular mobile operating systems - which manage to connect just fine. After long discussions, that text was removed in -06. Why was it readded?

[Med] This text was redited as a side effect of implementing the request from the IESG to position this document as a superset of existing RFCs.  The recommendations are not only about IPv6 but also, as indicated in the same sentence you quoted, “features to deliver IPv4 connectivity service over an IPv6-only transport”.

2. Previous versions of the document, including the version that passed IETF last call, contained the text:

That text remains accurate and that statement is still necessary. Why was it removed? It has been in the document since -06, and the words "this document is not a standard" have been in this document since -01.

[Med] It was removed as per a request from the IESG (A. Farrel).

3. I object to the statement "One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices." I submit that if it were true, then we would observe no IPv6 deployment in mobile networks... but publicly-available data - e.g., http://www.worldipv6launch.org/measurements/ - shows that multiple operators have deployed IPv6 to up to 30-65% of their footprint, using the same commercially-available devices that are used by customers of other operators. So claiming that "broken IPv6 implementations in mobile devices" are a major hurdle is at best incomplete and at worst incorrect.

[Med] That sentence was there since we edited the individual version of the document. Of course, current implementations perform better that when we edited the -00 of the document. Still, the feedback we had from our device team is that there are still a lot to be done.

At the risk of sounding like a broken record, I am going yet again to say that that operational documents should be based on operational experience. I am not aware of any of the authors' employers having a substantial IPv6 deployment (though I would be happy to see any data that the authors could provide to the contrary). On the other hand, the IPv6 lead on one of the operators that *has* deployed IPv6 no longer appears in the list of authors.

[Med] I can give you the example of Orange in Poland, for one. You can also check the Orange Groud Device requirements (IPv6 Chapter): https://www.ogdr-online.com/ogdr/index.php/component/extendedreg/login. I hope we can focus on technical comment rather than diverting. Thanks.

Regards,
Lorenzo

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 08:04:53 +0000

Hi Ole,

Thank you for the comments.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Ole Troan [mailto:[email-masked]] 
Envoyé : jeudi 29 janvier 2015 13:15
À : Fred Baker (fred)
Cc : V6 Ops List; [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

in addition.

                 1.  PCO

                 2.  RA

                 3.  DHCPv6

[Med] FWIW, this was added to have a more deterministic behavior at the cellular side. I may lost the context since early stages of the draft, but I recall there was a discussion in the list asking to make the ordering more strict: see for instance: http://www.ietf.org/mail-archive/web/v6ops/current/msg14375.html. Using all the information or follow the selection modes are two ways to achieve the same objective: determinist behavior at the terminal side. The draft recorded the feedback we received at that time.

same comment applies to W_REC#4.
[Med] There is no W_REC# in the current version. I think you are referring to W_REC#2. Same as above.

I can't see a good reason why hosts that also have cellular interfaces should work differently on a WLAN as opposed to those that don't have cellular interfaces.
[Med] The main motivation for this section was the test we have conducted on some IPv6-enabled devices that do not behave correctly when IPv6-only mode (you can see for instance what we reported here: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-3.3). This is an example of implementation brokenness to be avoided.

why does e.g. A_REC#3 refer to NATs?
[Med] A_REC#3 is when IPv4 service continuity is provided over IPv6. 

what does this allude to?
[Med] All what it says is that if a host doesn't want to be tracked, changing the last 64 bits may not be sufficient.

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 08:07:48 +0000

Dear James,

Your proposed wording is OK with me.

I implemented it in my local copy, thanks.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de James Woodyatt
Envoyé : jeudi 29 janvier 2015 21:07
À : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Additionally—

Security-related considerations that apply when the cellular device provides LAN features are specified in [RFC6092<https://tools.ietf.org/html/rfc6092>].

This sentence is a bit awkward— but more importantly, RFC 6092 is not a specification, and the chain of citation that lead to its reference here is far from clear.  I suggest the following wordier but more helpful replacement:

In the case of cellular devices that provide LAN features, compliance with L_REC#2 entails compliance with RFC 6204, which in turn recommends compliance with Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [RFC6092<https://tools.ietf.org/html/rfc6092>]. Therefore, the security considerations in section 6 of that document are relevant. In particular, it bears repeating here that the true impact of stateful filtering may be a reduction in security, and that IETF make no statement, expressed or implied, as to whether using the capabilities described in any of these documents ultimately improves security for any individual users or for the Internet community as a whole.

p.s. I also share all of Lorenzo's other specific concerns about this draft, as well as his broad general objections.

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
Nest Labs, Communications Engineering

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 08:20:45 +0000

Hi Brian,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Brian E Carpenter [mailto:[email-masked]] 
Envoyé : jeudi 29 janvier 2015 21:39
À : Lorenzo Colitti; Fred Baker (fred)
Cc : [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

and 7320)?

[Med] The main entry is RFC3986; updates to that RFC can be added.  

 And how is applying a correction to RFC 3261 an "example"
of following RFC 3986? And anyway, shouldn't this be in a SIP profile,
not here?

[Med] SIP is an example of application for which the initial specification included a broken IPv6 ABNF + broken URI comparison rules. We provided the SIP example to illustrate which rules must be followed.  

[Med] It would be helpful if those were called out, no?

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 Jan 2015 17:27:08 +0900

On Fri, Jan 30, 2015 at 4:35 PM, <[email-masked]> wrote:

> IPv6-only or dual-stack wireless network" is factually incorrect. The
> vast majority of these recommendations are not required to connect to such
> *[Med] *This text was redited as a side effect of implementing the
> request from the IESG to position this document as a superset of existing
> RFCs.  The recommendations are not only about IPv6 but also, as indicated
> in the same sentence you quoted, “features to deliver IPv4 connectivity
> service over an IPv6-only transport”.
>

But that doesn't change the fact that the statement is incorrect. The vast
majority of those features are not "required to connect". As for the
feature required to deliver IPv4 connectivity service over IPv6-only
transport, only one feature (out of the dozes in this draft) is required
for that - 464xlat.

If you want to turn this into a document of features that are required to
connect, I support that... but that would mean that the majority of
recommendations should be removed, because they're not required.

Also - this document passed WG and IETF last call with the understanding
that it explicitly did *not* define an IETF-approved device profile, but
only a profile "that a number of operators recommend". That text was in the
document as recently as -14, but it was removed.

Making this documean IETF-approved device profile is a substantial change
and has much broader implications than what the WG and IETF had consensus
on. Adding that text was essential to overcome the objections of those in
the WG that felt that it is not the place of an operational WG, or indeed
of the IETF, to place the RFC seal of approval on a device profile document
(or, as Brian puts it, "on somebody's procurement spec").

That text should be restored.

> [Med] It was removed as per a request from the IESG (A. Farrel).

Adrian, why did you request that this text be removed?

The text that passed last call went out of its way to state it was not a
standard, and that compliance with it was not required.  This text helped
defuse substantial objections within the WG and the IETF that pointed out
that only a fraction of these features are actually necessary to deploy,
and called attention to the harm to IPv6 deployment that would occur if
mobile operators and device manufacturers believed that all these features
needed to be implemented before deployment could occur.

> [Med] That sentence was there since we edited the individual version of
> the document. Of course, current implementations perform better that when
> we edited the -00 of the document. Still, the feedback we had from our
> device team is that there are still a lot to be done.
>

But you see, the problem with that is that it's just the opinion of your
device team. For example, if instead you asked the device teams of Verizon
Wireless and T-Mobile, they might well say that the features that are
necessary to deploy IPv6 are already supported just fine (with the possible
exception of 464xlat on iOS) - and that's why they deployed IPv6 to 30-65%
of their devices.

The IETF should not document matters of opinion. It should make technical
statements that are supported by evidence. The available evidence does not
support the statement that "IPv6 deployment is blocked because mobile
device implementations are broken"; in fact, the existence of large mobile
deployments proves that statement wrong.

>   I am not aware of any of the authors' employers having a substantial
> IPv6 deployment (though I would be happy to see any data that the authors
> could provide to the contrary). On the other hand, the IPv6 lead on one of
> the operators that *has* deployed IPv6 no longer appears in the list of
> authors.
>
> [Med] I can give you the example of Orange in Poland, for one.
>
http://www.worldipv6launch.org/measurements/ says 1.81% , yes. What about
the others?

> You can also check the Orange Groud Device requirements (IPv6 Chapter):
> https://www.ogdr-online.com/ogdr/index.php/component/extendedreg/login. I
> hope we can focus on technical comment rather than diverting. Thanks.
>
The problem with that is that there is very little technical content in
this document. Most of the document is just a laundry list of desired
features.

Regards,
Lorenzo

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 09:12:16 +0000

Dear Gert,

Can you please help us identifying technical flaws that you think need to be fixed in the document?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Gert Doering [mailto:[email-masked]] 
Envoyé : jeudi 29 janvier 2015 21:13
À : Ole Troan
Cc : Fred Baker (fred); [email-masked]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Hi,

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 09:39:33 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : vendredi 30 janvier 2015 09:27
À : BOUCADAIR Mohamed IMT/OLN
Cc : Fred Baker (fred); V6 Ops List; [email-masked]; [email-masked]; joel jaeggli
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Fri, Jan 30, 2015 at 4:35 PM, <[email-masked]<mailto:[email-masked]>> wrote:
1. The wording "required features to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network" is factually incorrect. The vast majority of these recommendations are not required to connect to such networks, and are many are not even implemented by many popular mobile operating systems - which manage to connect just fine. After long discussions, that text was removed in -06. Why was it readded?

But that doesn't change the fact that the statement is incorrect. The vast majority of those features are not "required to connect". As for the feature required to deliver IPv4 connectivity service over IPv6-only transport, only one feature (out of the dozes in this draft) is required for that - 464xlat.

If you want to turn this into a document of features that are required to connect, I support that... but that would mean that the majority of recommendations should be removed, because they're not required.

[Med] We already discussed this point several times. No need to repeat this discussion once again.

Also - this document passed WG and IETF last call with the understanding that it explicitly did *not* define an IETF-approved device profile, but only a profile "that a number of operators recommend". That text was in the document as recently as -14, but it was removed.

Making this documean IETF-approved device profile is a substantial change and has much broader implications than what the WG and IETF had consensus on. Adding that text was essential to overcome the objections of those in the WG that felt that it is not the place of an operational WG, or indeed of the IETF, to place the RFC seal of approval on a device profile document (or, as Brian puts it, "on somebody's procurement spec").

[Med] Your point about the process is fair. I have no problem to restore that text if this is what the WG wants. This is really the kind fo feedback I’m looking for.  Unless I heard any objection from the WG, that text will be restored.

The text that passed last call went out of its way to state it was not a standard, and that compliance with it was not required.  This text helped defuse substantial objections within the WG and the IETF that pointed out that only a fraction of these features are actually necessary to deploy, and called attention to the harm to IPv6 deployment that would occur if mobile operators and device manufacturers believed that all these features needed to be implemented before deployment could occur.

[Med] Lorenzo, the document does not states ALL features MUST be implemented. Just like any other recommendation document, there are several support levels. As far as I’m concerned, I have no objection to include that text if the IESG is OK with it.

But you see, the problem with that is that it's just the opinion of your device team. For example, if instead you asked the device teams of Verizon Wireless and T-Mobile, they might well say that the features that are necessary to deploy IPv6 are already supported just fine (with the possible exception of 464xlat on iOS) - and that's why they deployed IPv6 to 30-65% of their devices.
[Med] This is US-centric, but anyway you already raised this point several times: some answers are provided here https://www.ietf.org/mail-archive/web/v6ops/current/msg14769.html or https://www.ietf.org/mail-archive/web/v6ops/current/msg20086.html. I can add that in the Europe for instance, operators do not control the device used by  the customer, hence the need to have a profile.

The IETF should not document matters of opinion.
[Med] Agree.

It should make technical statements that are supported by evidence.
[Med] ISOC organized several IPv6 mobile workshops that revealed that operators participated a those workshop agree devices are a hurdle for their IPv6 deployments. I don’t have public pointers for the prez mad during the workshop but you can get in touch with ISOC if you need so.

The available evidence does not support the statement that "IPv6 deployment is blocked because mobile device implementations are broken"; in fact, the existence of large mobile deployments proves that statement wrong.
[Med] Not sure to understand the causality effect here.

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Jan 2015 11:39:24 +0100

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.

For the specifics, everything that Lorenzo said.

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 12:21:13 +0000

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.

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,

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jan 2015 07:52:37 -0500

> [Med] It was removed as per a request from the IESG (A. Farrel).

It is well within the rights of the working group to say no to Adrian on this point.   He may not have been aware of the reason the working group put it in the document.   It may be that there's a better way to serve the intent of the working group than this text, which could be negotiated with Adrian, but the point is that the fact that Adrian put it in a DISCUSS doesn't mean that the DISCUSsion is over.   This is why we bring documents back to working groups after addressing DISCUSses that produce significant changes.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 30 Jan 2015 15:17:41 +0000

Proposed text from James:
> In the case of cellular devices that provide LAN features, compliance with L_REC#2 entails compliance with RFC 6204, which in turn recommends compliance with Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [RFC6092]. Therefore, the security considerations in section 6 of that document are relevant. In particular, it bears repeating here that the true impact of stateful filtering may be a reduction in security, and that IETF make no statement, expressed or implied, as to whether using the capabilities described in any of these documents ultimately improves security for any individual users or for the Internet community as a whole.
--

FYI. RFC 6204 (in James’ proposed text above) was obsoleted by RFC 7084. If this text is to be included, that should be changed.

I would also like to see some of the removed text (referring to discussion around some of Lorenzo's comments) put back.
Barbara

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 15:25:02 +0000

Hi Barbara,

Thank you for the comment.

I'm planning to put back that text if there is no objection from the WG. 

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

Thank you.

Cheers,
Med

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

--

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 31 Jan 2015 00:32:05 +0900

On Fri, Jan 30, 2015 at 9:21 PM, <[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.

Er, wait. Are you're saying that if the WG re-reads this document and there
is no longer consensus in the WG that it should be published, it gets
published anyway?

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 16:48:09 +0100

Lorenzo, do you want to start another WGLC for this document? Why do you assume that WG position has changed since the last WGLC?

-ob

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Freitag, 30. Januar 2015 16:32
To: <[email-masked]>
Cc: [email-masked]; V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Fri, Jan 30, 2015 at 9:21 PM, <[email-masked]<mailto:[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.

Er, wait. Are you're saying that if the WG re-reads this document and there is no longer consensus in the WG that it should be published, it gets published anyway?

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 Jan 2015 16:35:07 +0000

On 30/01/2015 15:48, [email-masked] wrote:
> Lorenzo, do you want to start another WGLC for this document? Why do you
> assume that WG position has changed since the last WGLC?

the WG position hasn't materially changed; the document has.

Nick

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Jan 2015 17:41:26 +0100

Hi,

> 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

---

From: <[email-masked]>
Date: Fri, 30 Jan 2015 16:57:28 +0000

Hi,

> 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.
[DB] Whatever the IPv6 deployment status in a given country, we can't say that IPv6 deployment is ready everywhere. In some countries lack of IPv6 support in some mobile devices is still an issue. 
> 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.
[DB] The document does not mandate some support of every feature present in the document as it is the case for RFC 7084 (CPE can be connected to IPv6 networks without any 6rd or DS-Lite features).
The document does not mandate CLAT feature but in some situations, mobile devices should implement this feature. 

David
>         -- NetMaster

_________________________________________________________________________________________________________________________

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: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 30 Jan 2015 17:44:54 +0000

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

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. 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. I'm not convinced that this reference to an obsoleted RFC will be understood in the manner you intend.
Barbara

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Jan 2015 19:04:56 +0100

Hi,

> [DB] Whatever the IPv6 deployment status in a given country, we can't say that IPv6 deployment is ready everywhere. In some countries lack of IPv6 support in some mobile devices is still an issue. 

This is a global world, and (maybe except for the chinese market), handset
vendors ship globally - so I bet that an Android handset that works well
in T-Mobile USA's and Verizon Wireless' network has enough IPv6 support
to work on your network as well...

OTOH, I have a number of Telco-branded devices here that can *not* do
IPv6, even if the original vendor firmware *does* IPv6.  So this is really
a matter of the Telcos telling their handset / USB / router vendors to
enable IPv6 in the build shipped to them.  So that wishlist makes sense
to have as a Telco, but I'm not convinced it's a useful IETF document
(I don't see Telcos following IETF or 3GPP recommendations in other 
fields either if they don't want to.  Like, implementing IPv6, which is
mandatory in the 3GPP specs since ever...).

Gert Doering
        -- NetMaster

---

From: Ross Chandler <[email-masked]>
Date: Fri, 30 Jan 2015 19:50:22 +0000

> On 30 Jan 2015, at 18:04, Gert Doering <[email-masked]> wrote:
> 
> vendors ship globally -

I know of one Android based vendor that isn’t shipping IPv6 support in Europe yet (they plan to) for devices known to work with IPv6.
We take a regional image from them at present.

> so I bet that an Android handset that works well
> to work on your network as well…

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.

> IPv6, even if the original vendor firmware *does* IPv6.  

There’s an original vendor that lets APN protocol be edited to IPv6 but the devices don’t include the necessary support.

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

BR
Ross

---

From: joel jaeggli <[email-masked]>
Date: Sat, 31 Jan 2015 12:48:55 -0800

On 1/30/15 4:21 AM, [email-masked] wrote:
> 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,
> 
> 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.
> 
> Gert Doering -- NetMaster
>