Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

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

Re-,

Can you explicit what do you meant by “harmfully broad”?
(note, the pointer you provided is not valid because several items have been removed from the draft since then.)

Which items are not technically justified?

Cheers,
Med

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

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

What additional changes you would like to see added?

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

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

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

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

---

From: James Woodyatt <[email-masked]>
Date: Wed, 11 Feb 2015 09:51:27 -0800

> Which items are not technically justified?

Others may have other items that bug them, and additional items may spring
to my mind later if I put my mind to it, but I see no technical
justification to recommend a simple firewall by default for tethered hosts
according to RFC 6092. I consider that recommendation to be actively
harmful.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Feb 2015 17:41:13 -0500

On 02/11/2015 12:51 PM, James Woodyatt wrote:
> On Wed, Feb 11, 2015 at 4:09 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> Others may have other items that bug them, and additional items may 
> spring to my mind later if I put my mind to it, but I see no technical 
> justification to recommend a simple firewall by default for tethered 
> hosts according to RFC 6092. I consider that recommendation to be 
> actively harmful.
+1

---

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

Hi James,

Thank you for raising this point as it helps to clarify a confusion.

This document DOES NOT RECOMMENT RFC6092 for tethered hosts.

I guess you are referring to this item:

   L_REC#2:  The cellular CPE must be compliant with the requirements
             specified in [RFC7084<http://tools.ietf.org/html/rfc7084>].

                There are several deployments, particularly in emerging
                countries, that relies on mobile networks to provide
                broadband services (e.g., customers are provided with
                mobile CPEs).

                Note, this profile does not require IPv4 service
                continuity techniques listed in [RFC7084<http://tools.ietf.org/html/rfc7084>] because those
                are specific to fixed networks.  IPv4 service continuity
                techniques specific to the mobile networks are included
                in this profile.

This is about cellular ** CPE ** not tethered devices (You may noticed that this item used explicitly “cellular CPE” while other items in this section uses “cellular device”). RFC7084 is required for this case to ensure a functional parity with fixed CPEs.

BTW, the text you suggested about RFC6092 is in the draft:

   In the case of cellular devices that provide LAN features, compliance

   with L_REC#2 entails compliance with [RFC7084<http://tools.ietf.org/html/rfc7084>], which in turn

   recommends compliance with Recommended Simple Security Capabilities

   in Customer Premises Equipment (CPE) for Providing Residential IPv6

   Internet Service [RFC6092<http://tools.ietf.org/html/rfc6092>].  Therefore, the security considerations

   in Section 6 of [RFC6092]<http://tools.ietf.org/html/rfc6092#section-6> 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.

Are you suggesting that a mobile CPE should not have the same functionalities as the fixed one, and therefore RFC7084 should not be cited in this I-D? Or you are suggesting that RFC7084 is harmful?

Thank you.

Cheers,
Med

De : James Woodyatt [mailto:[email-masked]]
Envoyé : mercredi 11 février 2015 18:51
À : BOUCADAIR Mohamed IMT/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

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

Others may have other items that bug them, and additional items may spring to my mind later if I put my mind to it, but I see no technical justification to recommend a simple firewall by default for tethered hosts according to RFC 6092. I consider that recommendation to be actively harmful.

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

---

From: James Woodyatt <[email-masked]>
Date: Thu, 12 Feb 2015 11:13:52 -0800

Mr. Boucadair—

Yes, there is a problem. The draft seems to conflate the behavior of
residential broadband CPE gateways with 3GPP radios and mobile telephony
handsets with tethering interfaces. I tend not to fight too hard against
RFC 6092 in residential gateway scenarios, but I've always been opposed to
seeing those recommendations applied more widely, especially if it seems—
like it does in this case— that the recommendation is being made out of
rote repetition rather than by careful technical consideration.

Please forgive this digression: I have *never* wavered in my opposition to
any recommendation or specification that calls for unmanaged network layer
gateways to block unsolicited inbound transport layer flows by default. I
have always preferred explicit recommendations to leave RFC 6092 filtering
transparency mode by default, and to require an authorized human to "opt
into" the blocking of inbound flows.

Yes, RFC 6092 contains no such a recommendation. To my everlasting shame.

Because I was the technical editor for RFC 6092, and I was concerned about
conducting myself in that role with equanimity and fairness, I was
grudgingly willing to suspend my objections on this topic when the working
group settled on language that expressly makes no recommendation on whether
transparency should or should not the default. That seemed to reflect
consensus at the time. If I had not been the technical editor for that
document, then I would have more vigorously expressed my personal
objections.

On a personal level, I'm no longer sure it's better to have a document that
carefully describes the behavior of these ubiquitous and harmful firewalls
than to have them go undocumented as was the case with IPv4/NAT firewalls.
I haven't yet come to regret withholding my personal objections to RFC
6092, but I sometimes find that strong beer can dull the pain.

I *was* opposed to RFC 7084 (and its predecessor) because it did not take
the view that RFC 6092 firewall capability SHOULD be set for transparency
by default. I didn't win that argument, and I expect I will lose it again
in the context of this draft— which I oppose for other reasons as well, but
this is the one that animates me before the others.

I'm especially concerned that I-D.ietf-v6ops-mobile-device-profile seems to
be too easily read to recommend the application of RFC 6092 firewalls
inside mobile telephony handsets for tethered users. That's an expansion of
the scope intended for RFC 6092 beyond the usage case of residential
gateways, and I really wouldn't like to see that.

Shorter james:

   - I've got BIG problems recommending RFC 6092 firewalls for mobile
   telephony handsets with tethered hosts.
   - I've got BIG problems whenever it even looks like IETF might be
   recommending RFC 6092 firewalls should be non-transparent by default.
   - I've also got problems with recommending RFC 6092 firewalls without
   expressly cautioning that IETF takes no position on whether they should be
   transparent by default.
   - I'm slightly annoyed whenever RFC 6092 firewalls are even recommended
   at all, but I can get over that with strong enough beer.

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

>              specified in [RFC7084 <http://tools.ietf.org/html/rfc7084>].
>
>
>
>                 continuity techniques listed in [RFC7084
> <http://tools.ietf.org/html/rfc7084>] because those
>
> This is about cellular ** CPE ** not tethered devices (You may noticed
> that this item used explicitly “cellular CPE” while other items in this
> section uses “cellular device”). RFC7084 is required for this case to
> ensure a functional parity with fixed CPEs.
>
>
>
>    with L_REC#2 entails compliance with [RFC7084 <http://tools.ietf.org/html/rfc7084>], which in turn
>
>    Internet Service [RFC6092 <http://tools.ietf.org/html/rfc6092>].  Therefore, the security considerations
>
>    in Section 6 of [RFC6092] <http://tools.ietf.org/html/rfc6092#section-6> are relevant.  In particular, it bears
>
> Are you suggesting that a mobile CPE should not have the same
> functionalities as the fixed one, and therefore RFC7084 should not be cited
> in this I-D? Or you are suggesting that RFC7084 is harmful?
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* James Woodyatt [mailto:[email-masked]]
> *Envoyé :* mercredi 11 février 2015 18:51
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* IPv6 Ops WG
> *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 14:23:36 -0800

> been removed from the draft since then.)

Ok, then. Since you ask, let me copy and paste the text from the pointer,
then, and we can discuss why it is no longer valid.

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

The way I see it, the recent changes made to the document do nothing to
address the substance of those points.

It's true that the document no longer lists 34 features, only 23, but it
looks like the reduction has been mostly effected by removing features that
were already mandatory IETF or 3GPP requirements (e.g., REQ#1, "must
support IPv6 addressing architecture and ICMPv6 node requirements", REQ#6,
"must support IPv6 neighbour discovery") and coalescing multiple features
into one, (e.g., REQ_2 and REQ_3 were merged into C_REC#2).

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 07:21:50 +0000

Hi James,

Please see inline.

Cheers,
Med

De : James Woodyatt [mailto:[email-masked]]
Envoyé : jeudi 12 février 2015 20:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Mr. Boucadair—

Yes, there is a problem. The draft seems to conflate the behavior of residential broadband CPE gateways with 3GPP radios and mobile telephony handsets with tethering interfaces.

[Med] No. The recommendation is about “mobile CPE” used in various deployment to provide broadband services. An example can be found here (http://www.orange.tn/fixe-et-internet/pid382-la-flybox-orange.html). Except the access technology, services offered using these CPE are the same as any fixed CPE. Please let me reiterate the following: this draft does not recommend the support of RFC7084 for every “3GPP radios and mobile telephony handsets with tethering interfaces”. I added a CAUTION text in the latest version to make this clear:

                CAUTION: This recommendation does not apply to any
                cellular device with LAN capabilities; it is specific to
                cellular CPEs in order to ensure the same IPv6
                functional parity for both fixed and cellular CPEs.

I tend not to fight too hard against RFC 6092 in residential gateway scenarios, but I've always been opposed to seeing those recommendations applied more widely, especially if it seems— like it does in this case— that the recommendation is being made out of rote repetition rather than by careful technical consideration.

[Med] It is not about repetition but about a technical strategy that aims to ensure the same functional parity whatever the access technology used to service a customer. This is key for mobile-fixe convergence, mutualizing code, engineering practices, service design and operations, and more important testing and validation resources and effort.

Please forgive this digression: I have *never* wavered in my opposition to any recommendation or specification that calls for unmanaged network layer gateways to block unsolicited inbound transport layer flows by default. I have always preferred explicit recommendations to leave RFC 6092 filtering transparency mode by default, and to require an authorized human to "opt into" the blocking of inbound flows.

[Med] I’m personally with transparent mode set by default. If there is no objection from the working group, this can be added under security section.

Because I was the technical editor for RFC 6092, and I was concerned about conducting myself in that role with equanimity and fairness, I was grudgingly willing to suspend my objections on this topic when the working group settled on language that expressly makes no recommendation on whether transparency should or should not the default. That seemed to reflect consensus at the time. If I had not been the technical editor for that document, then I would have more vigorously expressed my personal objections.

On a personal level, I'm no longer sure it's better to have a document that carefully describes the behavior of these ubiquitous and harmful firewalls than to have them go undocumented as was the case with IPv4/NAT firewalls. I haven't yet come to regret withholding my personal objections to RFC 6092, but I sometimes find that strong beer can dull the pain.

[Med] You can try an orange juice too ;-)

I *was* opposed to RFC 7084 (and its predecessor) because it did not take the view that RFC 6092 firewall capability SHOULD be set for transparency by default. I didn't win that argument, and I expect I will lose it again in the context of this draft— which I oppose for other reasons as well, but this is the one that animates me before the others.

I'm especially concerned that I-D.ietf-v6ops-mobile-device-profile seems to be too easily read to recommend the application of RFC 6092 firewalls inside mobile telephony handsets for tethered users.

[Med] As I explained above this is not the intent. I added a CAUTION for that purpose but if you still think there is still a risk, I can check how better to address your issue.

That's an expansion of the scope intended for RFC 6092 beyond the usage case of residential gateways, and I really wouldn't like to see that.

[Med] There is no expansion of the scope: a cellular CPE is a flavor of residential gateway in part of a country where fixed infrastructure is inexistent or inefficient.

Shorter james:

  *   I've got BIG problems recommending RFC 6092 firewalls for mobile telephony handsets with tethered hosts.
  *   I've got BIG problems whenever it even looks like IETF might be recommending RFC 6092 firewalls should be non-transparent by default.
  *   I've also got problems with recommending RFC 6092 firewalls without expressly cautioning that IETF takes no position on whether they should be transparent by default.
  *   I'm slightly annoyed whenever RFC 6092 firewalls are even recommended at all, but I can get over that with strong enough beer.

On Wed, Feb 11, 2015 at 10:39 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi James,

Thank you.

Cheers,
Med

De : James Woodyatt [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 11 février 2015 18:51
À : BOUCADAIR Mohamed IMT/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 09:52:02 +0000

Hi Lorenzo,

Thank you for copying/pasting the list but I have troubles to map those to the new version because several changes were made since then. It might be more simple if we use the reco # of the latest version of the draft.

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

Some preliminary comments:

·         The document is now built as a superset of existing RFCs: RFC7066 and RFC6434. Several of the items you included in your “broad” list are already cited in RFC7066 and RFC6434  (e.g., #9, #10, etc.).

·         The I-D in ** not ** only about IPv6 connectivity but its scope is as follows:

   This profile is a superset of that of the IPv6 profile for 3GPP

   Cellular Hosts [RFC7066<http://tools.ietf.org/html/rfc7066>], which is in turn a superset of IPv6 Node

   Requirements [RFC6434<http://tools.ietf.org/html/rfc6434>].  It targets cellular nodes, including GPRS,

   EPC (Evolved Packet Core) and IEEE 802.11 networks, that require

   features to ensure IPv4 service delivery over an IPv6-only transport

   in addition to the base IPv6 service.  Moreover, this profile covers

   cellular CPEs that are used in various deployments to offer fixed-

   like services.  Recommendations inspired from real deployment

   experiences (e.g., roaming) are included in this profile.  Also, this

   profile sketches recommendations for the sake of deterministic

   behaviors of cellular devices when the same configuration information

   is received over several channels.

·         A device can be compliant with the profile without supporting all the items listed in it. That’s not specific to this document.

·         Items are listed in a priority order. This is not explicitly mentioned in the draft but we can add a sentence to precise it.

In order to make concrete progress while addressing your concern about the scope, would you be comfortable with the following direction:

·         Exclude WLAN and application-related considerations from the scope of the I-D. This will have the consequence of removing both section 2.1 and Section 5.

·         Add some text in the introduction to remind the importance of AF-independent applications/APIs.

·         Add an explicit sentence to say the support of this profile does not mean that all items MUST be supported.

·         Add a sentence to explicit items under each section are classified in a priority order.

Doing so will lead to a list of 18 items that is almost 1/2 of the initial 34 list ;-)

Thank you.
Cheers,
Med

Envoyé : jeudi 12 février 2015 23:24

Ok, then. Since you ask, let me copy and paste the text from the pointer, then, and we can discuss why it is no longer valid.

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

The way I see it, the recent changes made to the document do nothing to address the substance of those points.

It's true that the document no longer lists 34 features, only 23, but it looks like the reduction has been mostly effected by removing features that were already mandatory IETF or 3GPP requirements (e.g., REQ#1, "must support IPv6 addressing architecture and ICMPv6 node requirements", REQ#6, "must support IPv6 neighbour discovery") and coalescing multiple features into one, (e.g., REQ_2 and REQ_3 were merged into C_REC#2).

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 13:38:04 +0100

Lorenzo,

I wanted to express my oppinion.  I have read your email at the time, 
and now.

When I go through procurements often the vendors ask the RFC list that 
need to be there.  This criterion - the implemented RFC list - primes 
over all others such as software management, dimensions, price tags, 
electrical, temperature and noise features.  If it were not for these 
little RFCs there would be no reasonable procurement.

That said, I also agree with you when you imply that the list of 
features in this draft may be too long, or too hard see coherence.

If so, then maybe we can try to reduce it a bit?

Finally, 'profile' is probably not the right title.  It should qualify 
both the end-user device and the network device.

Alex

Le 12/02/2015 23:23, Lorenzo Colitti a écrit :
>     (note, the pointer you provided is not valid because several items
>     have been removed from the draft since then.)
>
>
> Ok, then. Since you ask, let me copy and paste the text from the
> pointer, then, and we can discuss why it is no longer valid.
>
> =====
> 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:
>
> 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.
>
> 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.
>
> 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.
> ====
>
> looks like the reduction has been mostly effected by removing features
> that were already mandatory IETF or 3GPP requirements (e.g., REQ#1,
> "must support IPv6 addressing architecture and ICMPv6 node
> requirements", REQ#6, "must support IPv6 neighbour discovery") and
> coalescing multiple features into one, (e.g., REQ_2 and REQ_3 were
> merged into C_REC#2).
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 13 Feb 2015 14:05:23 +0000

> need to be there.  This criterion - the implemented RFC list - primes over all
> others such as software management, dimensions, price tags, electrical,
> temperature and noise features.  If it were not for these little RFCs there
> would be no reasonable procurement.
> 
> That said, I also agree with you when you imply that the list of features in this
> draft may be too long, or too hard see coherence.
> 
> Finally, 'profile' is probably not the right title.  It should qualify both the end-
> user device and the network device.

Inside the company I work for, I try to encourage "thoughtful" use of "device profile" RFCs such as this draft may become. That is, read through the entire RFC, and make sure you want everything that's mandated. If you don't, pick and choose what makes sense for the product you are procuring. I would definitely not recommend to anyone (inside or outside my company) that they ask for compliance with this document without fully understanding the implications of what they are asking for. Basically, I see the items listed in the draft as a set of potential items to consider when putting together an RFP.

As it relates to IPv6 "device profile" documents, I would like to mention that CableLabs has been successful with its eRouter spec, BBF successful with its TR-124, and I'm hoping CEA has impact on the CE industry with its new CEA2048 publication (which they're offering for free through Feb 28 -- see http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e8185ea241297a29529). There does seem to be demand for "device profile" documents. I do think the only reason RFC 7084 (which really is a "device profile" RFC) was done in IETF was because of the need to identify requirements for CE routers that could connect to a variety of access network architecture, and IETF was "neutral territory". I admit to finding it odd that IETF would be used to publish a device profile that is only for devices connecting to 3GPP access networks. But I'm not familiar with how 3GPP works, so maybe it wasn't possible to get 3GPP to be willing to create a profile for devices that attach to their access network.

BTW, I'm very concerned about the fact that someone affiliated with a provider of an OS found on many  3GPP devices has so many objections to this particular "device profile". Knowing that, I would very, very strongly recommend to people I work with that they be very, very careful about how they use this particular "device profile" (if at all). I would not suggest including it directly in any RFP.

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 14:22:06 +0000

Barbara, 

FYI as part of the IESF review of this I-D, 3GPP was queried and stated that it had no interest in the document as it categorically doesn't produce documents of the kind. (I understood this from a message from F. Baker).

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de STARK, BARBARA H
Envoyé : vendredi 13 février 2015 15:05
À : Alexandru Petrescu; [email-masked]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

As it relates to IPv6 "device profile" documents, I would like to mention that CableLabs has been successful with its eRouter spec, BBF successful with its TR-124, and I'm hoping CEA has impact on the CE industry with its new CEA2048 publication (which they're offering for free through Feb 28 -- see http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e8185ea241297a29529). There does seem to be demand for "device profile" documents. I do think the only reason RFC 7084 (which really is a "device profile" RFC) was done in IETF was because of the need to identify requirements for CE routers that could connect to a variety of access network architecture, and IETF was "neutral territory". I admit to finding it odd that IETF would be used to publish a device profile that is only for devices connecting to 3GPP access networks. But I'm not familiar with how 3GPP works, so maybe it wasn't possible to get 3GPP to be willing to create a profile for devices that attach to their access
  network
 .

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 13 Feb 2015 15:29:15 +0000

I find your comments very well considered, thank you.

Barbara, ultimately the question remains, will your people be better off having read a document, with all the appropriate contextual warnings (i.e. it is not a standard), than if the paper did not exist? (Do you expect them to read all RFCs?)

To use an analogy  I am not the "specialist surgeon", but a GP* wondering what to vaccinate my patients with.
I don't wish to know, or understand, every new breakthrough in every disease.
I wish the specialists to agree what is ready for patients.
With approaching 10k of RFCs, and given I would hope to fully read 20 a year, I have little chance of keeping up.
My devices team, well, If I can get them to read one paper. (What else can I do, tell them to a RFC search on "mobile"?)
So I'd like the specialists to distill there wisdom into a useable form to take to the front line.
That is why I need a profile paper.
Lorenzo, I feel you are like the specialist surgeon berating the GPs for not knowing every RFC in its pure form.
We have a difficult job dealing with the front line here.
If terminal folks really don't need to know about some of these items, lets remove them.

Perhaps the IETF leads should think about a class of document for exactly this need. 
It is not a pure standards paper, and should not be judged as so.
It could have all the health warnings that Barbara et al would like to see.
Better to have it than not - that is my view.

I only see these becoming more prevalent, we are no longer in an industry where a handful of IP vendors roll out the latest RFCs into code.
Soon every electronic device will have an IP stack, IP features and more. IP Developers will soon be like GPs, not specialists! Help them out.
Nick
* I don't know if GP is an international term - General Practitioner means  local doctor who sees patients in the surgery!

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: 13 February 2015 14:05
To: Alexandru Petrescu; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

> both the end- user device and the network device.

As it relates to IPv6 "device profile" documents, I would like to mention that CableLabs has been successful with its eRouter spec, BBF successful with its TR-124, and I'm hoping CEA has impact on the CE industry with its new CEA2048 publication (which they're offering for free through Feb 28 -- see http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e8185ea241297a29529). There does seem to be demand for "device profile" documents. I do think the only reason RFC 7084 (which really is a "device profile" RFC) was done in IETF was because of the need to identify requirements for CE routers that could connect to a variety of access network architecture, and IETF was "neutral territory". I admit to finding it odd that IETF would be used to publish a device profile that is only for devices connecting to 3GPP access networks. But I'm not familiar with how 3GPP works, so maybe it wasn't possible to get 3GPP to be willing to create a profile for devices that attach to their access network  .

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

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Feb 2015 17:31:32 -0800

> not knowing every RFC in its pure form.

No, I am berating the authors of this draft for writing a document that
makes GPs (=device manufacturers, other network operators) believe that
they have to prepare loads of unnecessary medical machinery (=the many
recommendations that this draft makes) before they can open a small GP
surgery (=deploy IPv6), without bothering to tell them why they need all
that machinery and what they're supposed to do with it.

---

From: Ross Chandler <[email-masked]>
Date: Sat, 14 Feb 2015 12:25:14 +0000

> On 14 Feb 2015, at 01:31, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick <[email-masked] <mailto:[email-masked]>> wrote:
> No, I am berating the authors of this draft for writing a document that makes GPs (=device manufacturers, other network operators) believe that they have to prepare loads of unnecessary medical machinery (=the many recommendations that this draft makes) before they can open a small GP surgery (=deploy IPv6), without bothering to tell them why they need all that machinery and what they’re supposed to do with it.

In this particular analogy I classify the device manufacturers as members of Big Pharma, not as GPs.  The small country GPs are faced with buying equipment/features (dual-stack vaccination) to compensate for deficiencies between network+devices they get from their vendors. Until some paying customer demand arises that gets the GP’s Bank Manager interested in helping to push through the development to production services the GP has little incentive to try to move forward (got a works order for that? no didn’t think so) unless he also happens to be an  IPv6 “ultra-geek”.  

A lot of specific input has been taken on board. The list of recommendations has been paired right back and they are in order of priority and there are explanations in the document. 

Ross

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 15 Feb 2015 22:11:07 -0800

Ok, and to continue the analogy, the proposed solution to convince Big
Pharma to do what the GPs need is to get a medical standards organization
(not even a GP consortium!) to publish an informational document says "this
document is not a standard, and compliance with this document is not
required, but if you haven't yet stopped reading, here's a profile 30
features long that you might want to implement if you feel like it". I
don't see how that will help at all.

The way I see it, the only important issues here are a) absent strong
operator requirements, device manufacturers do not always implement IPv6 in
all products on all regions, and b) iOS does not implement 464xlat.

If you want to effect meaningful change, I'd suggest focusing on those
issues instead.

On Sat, Feb 14, 2015 at 4:25 AM, Ross Chandler <[email-masked]> wrote:

> that machinery and what they’re supposed to do with it.
>
>
> In this particular analogy I classify the device manufacturers as members
> of Big Pharma, not as GPs.  The small country GPs are faced with buying
> equipment/features (dual-stack vaccination) to compensate for deficiencies
> between network+devices they get from their vendors. Until some paying
> customer demand arises that gets the GP’s Bank Manager interested in
> helping to push through the development to production services the GP has
> little incentive to try to move forward (got a works order for that? no
> didn’t think so) unless he also happens to be an  IPv6 “ultra-geek”.
>
> A lot of specific input has been taken on board. The list of
> recommendations has been paired right back and they are in order of
> priority and there are explanations in the document.
>
>
> Ross
>
>
>
>
>
>

---

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

Lorenzo,
Focusing on a) what do you suggest?
Have you another way?

The disappointed for me in the discussion about this common reqts paper is not that there are a few strong voices rejecting this initiative.
It is that there are no voices of support. As I think you have pointed out, there is little support beyond the authors.
(Beyond that the silence is deafening.)
Nick

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: 16 February 2015 06:11
To: Ross Chandler
Cc: Heatley, Nick; IPv6 Ops WG ([email-masked])
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Ok, and to continue the analogy, the proposed solution to convince Big Pharma to do what the GPs need is to get a medical standards organization (not even a GP consortium!) to publish an informational document says "this document is not a standard, and compliance with this document is not required, but if you haven't yet stopped reading, here's a profile 30 features long that you might want to implement if you feel like it". I don't see how that will help at all.

The way I see it, the only important issues here are a) absent strong operator requirements, device manufacturers do not always implement IPv6 in all products on all regions, and b) iOS does not implement 464xlat.

If you want to effect meaningful change, I'd suggest focusing on those issues instead.

On Sat, Feb 14, 2015 at 4:25 AM, Ross Chandler <[email-masked]<mailto:[email-masked]>> wrote:

On 14 Feb 2015, at 01:31, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick <[email-masked]<mailto:[email-masked]>> wrote:
Lorenzo, I feel you are like the specialist surgeon berating the GPs for not knowing every RFC in its pure form.

Ross

NOTICE AND DISCLAIMER

EE Limited

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 10:57:36 +0900

> Focusing on a) what do you suggest?

Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and
give the OEMs a credible signal that from date X onwards, you *will* fail
TA on every device that doesn't implement IPv6, and you *will not* waive
the requirement. That's what Verizon and T-Mobile did, and it worked for
them.

It's true that T-Mobile and Verizon have more market power than some of the
carriers that are behind this draft. However, they definitely do not have
more market power than all the carriers behind this draft taken together.
Also, when they put those requirements down, IPv6 support in mobile devices
was in a much worse state; some devices didn't implement it at all, and
some had pretty severe bugs. Today, any OEM that sells to T-Mobile or
Verizon must have an IPv6 stack that's high-enough quality that tens of
millions of users can use it. So the problem you need to solve is easier
than the one they needed to solve; all you need to do is ask them not to
disable IPv6 in the European firmware, just like it's not disabled in the
US firmware.

If your problem is that you want to go directly from IPv4-only to
IPv6-only, but you feel that you can't do that because iOS doesn't support
464xlat, then you're in the same boat as T-Mobile. And in fact, I believe
that their requirement is something along the lines of "if your device runs
an operating system that supports 464xlat, you MUST configure your device
as IPv6-only with 464xlat" (which is roughly equivalent to saying, "you
must do 464xlat unless you're Apple"). That has a lot of value, because
whatever percentage of your users are on Android or Windows Phone won't
consume IPv4 addresses. The public statistics say T-Mobile is close to 50%
devices running IPv6-only. That's a lot IPv4 addresses saved.

Over time, the more operators take this position, the more will be using
464xlat, and eventually even Apple will read the writing on the wall and
implement it. They're free to use the Android implementation; it's
Apache-licensed.

 The disappointed for me in the discussion about this common reqts paper is
> not that there are a few strong voices rejecting this initiative.
>
> It is that there are no voices of support. As I think you have pointed
> out, there is little support beyond the authors.
>

Personally, I think the resistance/lack of support is mostly due to the
fact that it is not the IETF's job to dictate/influence which technologies
are used in the Internet. The IETF's job is to specify those technologies,
but that's already been done.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 11:41:19 +0900

> the requirement. That's what Verizon and T-Mobile did, and it worked for

Also: if you think that this strategy is not feasible because you do not
have an IPv6 network yet, then yes, that's true - you can't make IPv6 a
device requirement until you have an IPv6 network.

But I think the key point here is that apart from the lack of 464xlat on
iOS, the mobile operating systems are a lot more ready for IPv6 than you
might think they are. Once the network is complete, I think turning on IPv6
in the devices does work. Orange Poland, Telenor, and SK Telecom should be
able to confirm.

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 17 Feb 2015 11:31:29 +0000

This is the game of chicken approach, I have no doubt it works, but is it inclusive to all mobile operators?
For me, it has some limitations:

-          The operator must have top down backing for a terminal policy of “IPv6 or you are out” (now that is a wildcard condition in itself); it may compromise relationships in a valuable ecosystem

-          Where the operator has high major market power helps. Where markets have a number of players ready to play the IPv6 game, there is an advantage. Otherwise the operator is very exposed to divide and conquer

-          Currently it tends to play out as a the simplest set of requirements. Which also means simplest set of network capabilities. Sometimes these simplest set of network capabilities are at odds with the business priorities of the operator (clear examples are: APN strategy, tethering approach, roaming approach, subsidised handset vs “SIM-only”)
(Not having an IPv6 capable network is a myth you are promoting to discredit operator views, it is a red herring – any operator specifying *any* IPv6 requirements will very quickly need this capability to validate terminals whatever the path they choose.)

I can see why you argue for lowest common denominator of v6 requirements.
I think your stance that this can work across the board is “harmfully restrictive”.
The other approach is understanding the differences and trying to set a slightly higher bar that highlights conditional requirements of the collective; what you call  “harmfully broad”.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG ([email-masked])
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and give the OEMs a credible signal that from date X onwards, you *will* fail TA on every device that doesn't implement IPv6, and you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them.

Also: if you think that this strategy is not feasible because you do not have an IPv6 network yet, then yes, that's true - you can't make IPv6 a device requirement until you have an IPv6 network.

But I think the key point here is that apart from the lack of 464xlat on iOS, the mobile operating systems are a lot more ready for IPv6 than you might think they are. Once the network is complete, I think turning on IPv6 in the devices does work. Orange Poland, Telenor, and SK Telecom should be able to confirm.

NOTICE AND DISCLAIMER

EE Limited

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Feb 2015 16:19:53 +0900

I don't understand why you say this is a game of chicken.

All the major device vendors (except Apple, if you need 464xlat) support
IPv6 today - Verizon and T-Mobile have fixed that problem for you. Asking
them to set the APN configuration for your network to IPv6 (or IPv4v6) is
simple, and they are running that code already on other networks. It's not
an unreasonable request. It's not like you're asking them to write off the
national debt or give you all their phones for free or something. It seems
that you are dismissing that approach as unrealistic. Fine.

But what you *are* doing, though, is writing a profile document listing 30+
features, many of which those vendors don't implement today, and some of
which will require substantial work. Then you're asking a technical
standards organization - which is not an operator organization, and which
is not in the business of publishing profile documents or influencing
deployments, but only of defining standards - to publish that document with
"this is not a standard, and compliance is not required" written on the
first page.

To me that sounds a lot less realistic than just asking the vendors to turn
on the code they already have.

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]>
wrote:

> -          The operator must have top down backing for a terminal policy
> of “IPv6 or you are out” (now that is a wildcard condition in itself); it
> may compromise relationships in a valuable ecosystem
>
> -          Where the operator has high major market power helps. Where
> markets have a number of players ready to play the IPv6 game, there is an
> advantage. Otherwise the operator is very exposed to divide and conquer
>
> -          Currently it tends to play out as a the simplest set of
> requirements. Which also means simplest set of network capabilities.
> Sometimes these simplest set of network capabilities are at odds with the
> business priorities of the operator (clear examples are: APN strategy,
> tethering approach, roaming approach, subsidised handset vs “SIM-only”)
>
> (Not having an IPv6 capable network is a myth you are promoting to
> discredit operator views, it is a red herring – any operator specifying *
> *any** IPv6 requirements will very quickly need this capability to
> validate terminals whatever the path they choose.)
>
>
>
> The other approach is understanding the differences and trying to set a
> slightly higher bar that highlights conditional requirements of the
> collective; what you call  “harmfully broad”.
>
>
>
>
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* 17 February 2015 02:41
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG ([email-masked])
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Feb 2015 16:25:43 +0900

> collective; what you call  “harmfully broad”.

What I'm saying is that if your goal is IPv6 deployment in a reasonable
timeframe, then the right strategy is *not* to make a list of all the
features under the sun, wait until they have all been implemented, and
deploy them. A better strategy is to start from the features that are
required, test and deploy those, and then iterate. As the industry evolves
and IPv6 becomes more common, IPv6 features will become higher priority for
vendors and they will get implemented.

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 18 Feb 2015 09:35:16 +0000

Yes, I agree with you, that is a sensible approach.
Working with each vendor in turn.
(You know each vendor who claims IPv6 readiness for their terminal, will never say whether the device will work on the operators IPv6 network.
So it needs to be collaborative.)

So all this document is doing is setting a collective roadmap, rather than expect vendors to do their own thing. Given we agree on the above, this is not harmful.

I think the real disagreement comes from your opinion that this is not IETF.
(By the way, mobile operators have had discussions with the sister org of the Internet Society about what would help mobile operators introduce IPv6.
One of the major major themes has been terminals.)

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: 18 February 2015 07:26
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG ([email-masked])
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]<mailto:[email-masked]>> wrote:
I can see why you argue for lowest common denominator of v6 requirements.
I think your stance that this can work across the board is “harmfully restrictive”.
The other approach is understanding the differences and trying to set a slightly higher bar that highlights conditional requirements of the collective; what you call  “harmfully broad”.

What I'm saying is that if your goal is IPv6 deployment in a reasonable timeframe, then the right strategy is *not* to make a list of all the features under the sun, wait until they have all been implemented, and deploy them. A better strategy is to start from the features that are required, test and deploy those, and then iterate. As the industry evolves and IPv6 becomes more common, IPv6 features will become higher priority for vendors and they will get implemented.

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]<mailto:[email-masked]>> wrote:
This is the game of chicken approach, I have no doubt it works, but is it inclusive to all mobile operators?
For me, it has some limitations:

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

NOTICE AND DISCLAIMER

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

NOTICE AND DISCLAIMER

EE Limited

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 09:49:47 +0000

Lorenzo,

I don’t know who is advocating for “then the right strategy is *not* to make a list of all the features under the sun, wait until they have all been implemented, and deploy them.” !!

I would like to clarify this is not the position of this draft.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : mercredi 18 février 2015 08:26
À : Heatley, Nick
Cc : IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

NOTICE AND DISCLAIMER

EE Limited

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 09:54:22 +0000

Hi Nick,

I fully agree.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Heatley, Nick
Envoyé : mercredi 18 février 2015 10:35
À : Lorenzo Colitti
Cc : IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

NOTICE AND DISCLAIMER

EE Limited

NOTICE AND DISCLAIMER

EE Limited

---

From: Ca By <[email-masked]>
Date: Wed, 18 Feb 2015 07:08:18 -0800

Authors,

I know you said the 3gpp is not interested in this work, what about GSMA ?
They write profiles for mobile networks , right?

CB

On Wednesday, February 18, 2015, <[email-masked]> wrote:

>  Hi Nick,
>
>
>
> I fully agree.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* v6ops [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *De la part de*
> Heatley, Nick
> *Envoyé :* mercredi 18 février 2015 10:35
> *À :* Lorenzo Colitti
> *Cc :* IPv6 Ops WG ([email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>)
> (You know each vendor who claims IPv6 readiness for their terminal, will
> never say whether the device will work on the operators IPv6 network.
>
> So all this document is doing is setting a collective roadmap, rather than
> expect vendors to do their own thing. Given we agree on the above, this is
> not harmful.
>
>
>
> (By the way, mobile operators have had discussions with the sister org of
> the Internet Society about what would help mobile operators introduce IPv6.
>
> *From:* Lorenzo Colitti [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* 18 February 2015 07:26
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG ([email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>)
> On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> *From:* Lorenzo Colitti [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Cc:* Ross Chandler; IPv6 Ops WG ([email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>)
> On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

---

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

Hi Cameron,

It is wasteful to initiate this work in another forum while both the IPv6 expertise and the knowledge of mobile networks is available at the IETF.

FWIW, the IETF produced profile documents (read CPE requirements RFCs) while one can think BBF can be a legitimate forum to produce such documents. This document is not an exception.

I’m sure we will come up to a balanced approach to satisfy the comments received so far.

Cheers,
Med

De : Ca By [mailto:[email-masked]]
Envoyé : mercredi 18 février 2015 16:08
À : BOUCADAIR Mohamed IMT/OLN
Cc : Heatley, Nick; IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Authors,

I know you said the 3gpp is not interested in this work, what about GSMA ?  They write profiles for mobile networks , right?

CB

On Wednesday, February 18, 2015, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nick,

I fully agree.

Cheers,
Med

De : v6ops [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] De la part de Heatley, Nick
Envoyé : mercredi 18 février 2015 10:35
À : Lorenzo Colitti
Cc : IPv6 Ops WG ([email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

From: Lorenzo Colitti [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
Sent: 18 February 2015 07:26
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG ([email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>)
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
I can see why you argue for lowest common denominator of v6 requirements.
I think your stance that this can work across the board is “harmfully restrictive”.
The other approach is understanding the differences and trying to set a slightly higher bar that highlights conditional requirements of the collective; what you call  “harmfully broad”.

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
This is the game of chicken approach, I have no doubt it works, but is it inclusive to all mobile operators?
For me, it has some limitations:

From: Lorenzo Colitti [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG ([email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>)
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and give the OEMs a credible signal that from date X onwards, you *will* fail TA on every device that doesn't implement IPv6, and you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them.

NOTICE AND DISCLAIMER

EE Limited

NOTICE AND DISCLAIMER

EE Limited

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 18 Feb 2015 16:20:07 +0000

> So all this document is doing is setting a collective roadmap, rather than expect vendors to do their own thing. Given we agree on the above, this is not harmful.

It’s not clear to me who this “collective” is. It seems like here the "collective" is the set of authors, but some people fear the outside world might view "collective" as "IETF". That seems to be a major sticking point, and, I think, the perceived potential "harm". It's very clear to me that "collective" is not "IETF" (and informational RFCs should never be seen as "collective" = "IETF", though some on the outside do have difficulty with this concept); nor is "collective" all wireless operators. It's just the authors.

I remember back when DSL was in its infancy, and telcos were struggling to deploy due to the lack of DSLAMs and DSL modems. Several got together, formed a single-purpose "joint procurement group", defined common requirements, and all issued the same RFP.  This was done external to all SDOs or other industry groups. Companies who were not part of this joint procurement group benefited as well, because then they could say "I'll have what they're having." It's very common for the companies who deploy later to use the approach of deploying what the "market leaders" are deploying. This way they don't need to have people who read/understand RFCs and such. They just trust that the "market leaders" have such people and know what they're doing. An added benefit of waiting for "market leader" deployment is that "unrealistic" RFP requirements have been weeded out by that time. As someone who has helped write many RFPs I can say with certainty that there were "must" items in all those RFPs that never made it into the deployed products. Once a timeline or price tag is associated with a "must", it can lose its "must"-ness.

Barbara

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 16:39:56 +0000

Hi,

What I'm saying is that if your goal is IPv6 deployment in a reasonable timeframe, then the right strategy is *not* to make a list of all the features under the sun, wait until they have all been implemented, and deploy them. A better strategy is to start from the features that are required, test and deploy those, and then iterate. As the industry evolves and IPv6 becomes more common, IPv6 features will become higher priority for vendors and they will get implemented.
[DB] Could you be more explicit and indicate which features are not useful in the draft ? As you can mention it, all features are not indicated as mandatory in the draft so I do not clearly understand how this document conflicts with what you say considering that the goal for the operator is to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator.

NOTICE AND DISCLAIMER

EE Limited

_________________________________________________________________________________________________________________________

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: "Heatley, Nick" <[email-masked]>
Date: Thu, 19 Feb 2015 09:14:21 +0000

My observation is around accountability vs responsibility (the RACI matrix).

The issue we seem to have is that the IETF expertise is needed, so we need the IETF community to effectively be the responsible agency for the technical content.
Normally SDOs are both accountable and responsible.
Accountability, well, clearly some find it uneasy that IETF would have accountability for the document.

If another body could be accountable for the document, that it represents the views of a suitable collective (mobile operators), but the technical content was filtered via IETF, that would be ideal, no?
I have no idea how to engineer such an outcome, but if it could be done then this work should not be wasted – could be a “GSMA sponsored RFC”?

This problem of expertise is not going away so I share Meds concerns.

(Barbara’s comment on a group RFP, absolutely not workable due to all the NDAs that reside around terminals.)

From: [email-masked] [mailto:[email-masked]]
Sent: 18 February 2015 15:46
To: Ca By
Cc: Heatley, Nick; IPv6 Ops WG ([email-masked])
Subject: RE: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Hi Cameron,

Cheers,
Med

Cc : Heatley, Nick; IPv6 Ops WG ([email-masked]<mailto:[email-masked]>)

Authors,

CB

I fully agree.

Cheers,
Med

NOTICE AND DISCLAIMER

EE Limited

NOTICE AND DISCLAIMER

EE Limited

NOTICE AND DISCLAIMER

EE Limited

---

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

On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick <[email-masked]>
wrote:

>  If another body could be accountable for the document, that it
> represents the views of a suitable collective (mobile operators), but the
> technical content was filtered via IETF, that would be ideal, no?
>
> I have no idea how to engineer such an outcome, but if it could be done
> then this work should not be wasted – could be a “GSMA sponsored RFC”?
>

You could make it an independent submission, and say that it represents the
recommendations of the authors (see RFC 4846 for a description of the
process, or RFC 6732 for an example of such an independent submission RFC).

If what you're after is IETF expertise, then I think the document has had
plenty of exposure to that already, given it's been in the WG for over a
year and a half.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 19:32:51 +0900

On Thu, Feb 19, 2015 at 1:39 AM, <[email-masked]> wrote:

>
> [DB] Could you be more explicit and indicate which features are not useful
> in the draft ? As you can mention it, all features are not indicated as
> mandatory in the draft so I do not clearly understand how this document
> conflicts with what you say considering that the goal for the operator is
> to provide at least the same service access for users with IPv6
> connectivity than for users with IPv4 connectivity whatever the strategy
> retained by the operator.
>

If the goal of the document is "to provide at least the same service access
for users with IPv6 connectivity than for users with IPv4 connectivity
whatever the strategy retained by the operator" then you can reduce the
document to two requirements:

1. Support both IPv4v6 and IPv6.
2. Support 464xlat.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2015 11:41:18 +0100

Le 19/02/2015 11:19, Lorenzo Colitti a écrit :
> On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> represents the views of a suitable collective (mobile operators), but
> the technical content was filtered via IETF, that would be ideal,
> no?
>
> I have no idea how to engineer such an outcome, but if it could be
> done then this work should not be wasted – could be a “GSMA sponsored
> RFC”?
>
>
> You could make it an independent submission, and say that it
> represents the recommendations of the authors (see RFC 4846 for a
> description of the process, or RFC 6732 for an example of such an
> independent submission RFC).
>
> If what you're after is IETF expertise, then I think the document has
> had plenty of exposure to that already, given it's been in the WG for
> over a year and a half.

As an alternative for more than independent submission, one could (1)
squeeze it into few requirements having more tract than the set, (2) get
software writers to expose running code, (3) get complimentary profiles
other than cellular operators interested, and call it a deal.

For example, squeeze it to recommend only DHCP-PD, tell how OSS
implementations exist, and get an equipment manufacturer on board.

For the 464xlat/nat64/dns64/CLAT recommendation part - I personally
think it is way too strict in its reaches, although I fully agree with a
long-term goal of IPv6-only.  It is strict, because many other IETF RFCs
offer much more solutions to this kind of problem; other new solutions
can be developped as well (Problem Statement first?).  It has wide
reaches because it recommends 'should' a _set_ RFCs.

Finally, if all we have is facing a widely used deployment, with no
means to influence operator's network to end-user needs, tired of
discussions, then this should be an INFORMATIONAL and that's that.
There is much value in it as well.

Alex

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

---

From: <[email-masked]>
Date: Thu, 19 Feb 2015 12:13:21 +0000

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : jeudi 19 février 2015 11:33
À : BINET David IMT/OLN
Cc : IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 1:39 AM, <[email-masked]<mailto:[email-masked]>> wrote:

If the goal of the document is "to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator"

[Med] This is one of the goals of the I-D not the only one. e.g., the I-D lists features that are not covered in RFC7066 and RFC6434: e.g., prefix delegation or prefix sharing.

then you can reduce the document to two requirements:

[Med] I’m afraid compacting the recommendations is not helpful. For example, these two items are covered as follows in the I-D for the sake of deterministic behavior.

[Med] These items cover this 1st point:

   C_REC#1:  In order to allow each operator to select their own
             strategy regarding IPv6 introduction, the cellular host
             must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.23060>].
             IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends
             on the cellular network configuration.

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

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

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

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

   C_REC#3:  The cellular host must support the PCO (Protocol
             Configuration Options) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>] to retrieve the IPv6
             address(es) of the Recursive DNS server(s).

                In-band signaling is a convenient method to inform the
                cellular host about various services, including DNS
                server information.  It does not require any specific
                protocol to be supported and it is already deployed in
                IPv4 cellular networks to convey such DNS information.

   C_REC#4:  The cellular host must support IPv6 aware Traffic Flow
             Templates (TFT) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18#ref-TS.24008>].

                Traffic Flow Templates are employing a packet filter to
                couple an IP traffic with a PDP-Context.  Thus a
                dedicated PDP-Context and radio resources can be
                provided by the cellular network for certain IP traffic.

2. Support 464xlat.
[Med] “464xlat” is meaningless for the device;-) but I got your point. This is covered by the following two items:

   C_REC#8:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, the cellular host should support a

             method to locally construct IPv4-embedded IPv6 addresses

             [RFC6052<http://tools.ietf.org/html/rfc6052>].  A method to learn PREFIX64 should be supported

             by the cellular host.

                This solves the issue when applications use IPv4

                referrals on IPv6-only access networks.

                In PCP-based environments, cellular hosts should follow

                [RFC7225<http://tools.ietf.org/html/rfc7225>] to learn the IPv6 Prefix used by an upstream

                PCP-controlled NAT64 device.  If PCP is not enabled, the

                cellular host should implement the method specified in

                [RFC7050<http://tools.ietf.org/html/rfc7050>] to retrieve the PREFIX64.

   C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only

             deployment context, the cellular host should implement the

             Customer Side Translator (CLAT, [RFC6877<http://tools.ietf.org/html/rfc6877>]) function in

             compliance with [RFC6052<http://tools.ietf.org/html/rfc6052>][RFC6145][RFC6146<http://tools.ietf.org/html/rfc6146>].

                CLAT function in the cellular host allows for IPv4-only

                application and IPv4-referals to work on an IPv6-only

                connectivity.  The more applications are address family

                independent, the less CLAT function is solicited.  CLAT

                function requires a NAT64 capability [RFC6146<http://tools.ietf.org/html/rfc6146>] in the

                network.

                The cellular host should only invoke the CLAT in the

                absence of the IPv4 connectivity on the cellular side,

                i.e., when the network does not assign an IPv4 address

                on the cellular interface.  Note, NAT64 assumes an

                IPv6-only mode [RFC6146<http://tools.ietf.org/html/rfc6146>].

                The IPv4 Service Continuity Prefix used by CLAT is

                defined in [RFC7335<http://tools.ietf.org/html/rfc7335>].

                CLAT and/or NAT64 do not interfere with native IPv6

                communications.

---

From: Dave Michaud <[email-masked]>
Date: Thu, 19 Feb 2015 12:31:07 +0000

I agree with Mohamed. The goal of the document is broader than to ensure same service set in IPv6 than in IPv4 but to provide a base set of practical requirements to actually make it happen.

As an operator, having IPv4v6, IPv6 and 464XLAT is enough to cover the simplest case (user browsing or using an app that connects to an IPv4 endpoint, while on the home network).

When you start considering roaming, tethering, migration strategy, grey market devices and service evolution, the situation becomes slightly more complex. These variables are part of the core offering and must be handled from day one. As an engineer, I will get NO support from my executives if any of the previous item is broken by one of my solutions.

In the mobile world, there are 2 classes of operator, the big ones that can get whatever configuration/personalization they want from their UE vendors and the others. For the others, having a set of common requirements goes a long way in helping immediate transition into the IPv6 world.

This is directly in line with the v6ops charter:

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks,
as well as into new network installations.

The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.

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

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 19, 2015 at 07:13
To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>, BINET IMT/OLN <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : jeudi 19 février 2015 11:33
À : BINET David IMT/OLN
Cc : IPv6 Ops WG ([email-masked]<mailto:[email-masked]>)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

2. Support 464xlat.

             by the cellular host.

                network.

                communications.

________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>

Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

---

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

Re-,

Thank you for the kind suggestion but I’m all optimist the I-D can be published in the IETF stream. If the IETF consensus was declared once, I’d hope this will happen for this version having a restricted scope (https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/)

It is obvious there is a void filled by this draft. It is built on existing RFCs already published in this area. This document is not original in its ambition nor it is different in its structure.

Technical issues can always be fixed (or at worse recorded), disagreements can be acknowledged, compromises can be found, the scope can be adjusted, etc.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 19 février 2015 11:20
À : Heatley, Nick
Cc : BOUCADAIR Mohamed IMT/OLN; Ca By; IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick <[email-masked]<mailto:[email-masked]>> wrote:
If another body could be accountable for the document, that it represents the views of a suitable collective (mobile operators), but the technical content was filtered via IETF, that would be ideal, no?
I have no idea how to engineer such an outcome, but if it could be done then this work should not be wasted – could be a “GSMA sponsored RFC”?

You could make it an independent submission, and say that it represents the recommendations of the authors (see RFC 4846 for a description of the process, or RFC 6732 for an example of such an independent submission RFC).

If what you're after is IETF expertise, then I think the document has had plenty of exposure to that already, given it's been in the WG for over a year and a half.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 21:45:32 +0900

> deployment issues; more advanced stages of deployment and transition
Actually, it isn't, really. The charter is operational guidance for the
IPv4/IPv6 Internet. Not host requirements.

In fact, if you look at the numbered list in the charter, the items are
"identify operational issues and determine solutions", "identify potential
security risks", "identify portions of the specs that can cause operational
concerns", and "analyze solutions for deploying IPv6 within network
environments". None of those cover this document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 21:47:52 +0900

On Thu, Feb 19, 2015 at 9:32 PM, <[email-masked]> wrote:

>  It is obvious there is a void filled by this draft. It is built on
> existing RFCs already published in this area. This document is not original
> in its ambition nor it is different in its structure.
>

Actually, I don't see a void. IPv6 deployment on mobile networks (ok,
perhaps not those of the authors) is happening now. Tens of millions of
mobile devices are running IPv6 today. And a lot of it happened before this
draft was even written.

---

From: <[email-masked]>
Date: Thu, 19 Feb 2015 13:03:34 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 19 février 2015 13:46
À : Dave Michaud
Cc : BOUCADAIR Mohamed IMT/OLN; BINET David IMT/OLN; IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud <[email-masked]<mailto:[email-masked]>> wrote:
This is directly in line with the v6ops charter:

Actually, it isn't, really. The charter is operational guidance for the IPv4/IPv6 Internet. Not host requirements.

[Med] Hummm… I suggest you have a quick look at this page : https://datatracker.ietf.org/wg/v6ops/documents/ (hint: search for ‘host’ or ‘CPE’).

In fact, if you look at the numbered list in the charter, the items are "identify operational issues and determine solutions", "identify potential security risks", "identify portions of the specs that can cause operational concerns", and "analyze solutions for deploying IPv6 within network environments". None of those cover this document.

[Med] Is this a joke? Your assertion is erroneous. I will take one item randomly from the I-D to illustrate the first item in your list:

   C_REC#7:  Because of potential operational deficiencies to be
             experienced in some roaming situations, the cellular host
             must be able to be configured with a home PDP-Context
             type(s) and a roaming PDP-Context type(s).  The purpose of
             the of the roaming profile is to limit the PDP type(s)
             requested by the cellular host when out of the home
             network.  Note that distinct PDP type(s) and APN(s) can be
             configured for home and roaming cases.

---

From: Dave Michaud <[email-masked]>
Date: Thu, 19 Feb 2015 13:10:33 +0000

Does the charter specifically exclude hosts requirements?

Enabling dual-stack on a cellular network serves no mean if it can't be used.

Transitionning to IPv6-only requires further support from the host side to form a complete solution.

The documents published under v6ops should "serve as useful guides to network
operators and users on possible ways how to deploy IPv6 within their
existing IPv4 networks, as well as in new network installations."

This is exactly what this is. As a LAN administrator, it wouldn't cross my mind to look for an RFC for host requirements because I would have little control anyway. As a cellular operator, the hosts are part of my network and I do have a say on how they operate and it forms part of the overall solution (bullet 4 of the charter). Same would apply from a Cable MSO where the CPEs are integral part of the network.

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

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 19, 2015 at 07:45
To: Dave Michaud <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, BINET IMT/OLN <[email-masked]<mailto:[email-masked]>>, IPv6 WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l'avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 22:17:14 +0900

On Thu, Feb 19, 2015 at 10:03 PM, <[email-masked]> wrote:

>
> [Med] Hummm… I suggest you have a quick look at this page :
> https://datatracker.ietf.org/wg/v6ops/documents/ (hint: search for ‘host’
> or ‘CPE’).
>

The search says that a single-digit percentage of the documents contain the
word "host" or "CPE" in the title. What point are you trying to make? That
the charter is inappropriate, because it doesn't mention hosts, but the WG
has published a few documents that talk about hosts?

> [Med] Is this a joke? Your assertion is erroneous. I will take one item
> randomly from the I-D to illustrate the first item in your list:
>
>
>
>              type(s) and a roaming PDP-Context type(s).
>

That's a great example to pick, because the WG is about to produce an RFC
on precisely this topic -
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ .

That document is a good example of what *is* in charter of the WG: an
in-depth, detailed discussion of the operational issues. 8 lines of text
saying "devices must support different PDP types for home and roaming" is
not.

---

From: <[email-masked]>
Date: Thu, 19 Feb 2015 13:20:06 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 19 février 2015 13:48
À : BOUCADAIR Mohamed IMT/OLN
Cc : Heatley, Nick; Ca By; IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 9:32 PM, <[email-masked]<mailto:[email-masked]>> wrote:
It is obvious there is a void filled by this draft. It is built on existing RFCs already published in this area. This document is not original in its ambition nor it is different in its structure.

Actually, I don't see a void.
[Med]

Short answer :

The void is (at least):

·         Existing profile RFC does not cover IPv4 service continuity features, devices with lan capabilities, etc.

·         Existing profile RFCs conflicts with other others.

·         There are still broken IPv6 implementations. Deterministic behaviors is encouraged. Saying a device supports IPv6 is meaningless.

Long version: is documented in the I-D that I suppose you already read:

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

   For conflicting recommendations in [RFC7066] and [RFC6434] (e.g.,
   Neighbor Discovery Protocol), this profile adheres to [RFC7066].
   Indeed, the support of Neighbor Discovery Protocol is mandatory in
   3GPP cellular environment as it is the only way to convey IPv6 prefix
   towards the 3GPP cellular device.  In particular, MTU (Maximum
   Transmission Unit) communication via Router Advertisement must be
   supported since many 3GPP networks do not have a standard MTU
   setting.

   This profile uses a stronger language for the support of Prefix
   Delegation compared to [RFC7066].  The main motivation is that
   cellular networks are more and more perceived as an alternative to
   fixed networks for home IP-based services delivery; especially with
   the advent of smartphones and 3GPP data dongles.  There is a need for
   an efficient mechanism to assign shorter prefix than /64 to cellular
   hosts so that each LAN segment can get its own /64 prefix and multi-
   link subnet issues to be avoided.  The support of this functionality
   in both cellular and fixed networks is key for fixed-mobile
   convergence.

IPv6 deployment on mobile networks (ok, perhaps not those of the authors)

[Med] I thought you already mentioned Orange in one of your answer as an example of those deploying IPv6 (https://www.ietf.org/mail-archive/web/v6ops/current/msg21399.html). Anyway, all the operators co-authoring this draft are active in IPv6 deployment.

is happening now. Tens of millions of mobile devices are running IPv6 today. And a lot of it happened before this draft was even written.

[Med] This draft was edited because operators having IPv6 deployment project are seeking for a reference document for the device part.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 22:22:39 +0900

On Thu, Feb 19, 2015 at 10:10 PM, Dave Michaud <[email-masked]>
wrote:

> existing IPv4 networks, as well as in new network installations.”
>

Guides on how to deploy, yes. Not lists of features.

Example: a document describing a single-stack deployment using IPv6-only
and 464xlat, explaining what is required of the network, what
infrastructural pieces need to be deployed, how things need to work, and
how hosts need to behave - that's a guide on how to deploy.

A list of lots of (some important, some optional) features of mobile
devices is not a guide on how to deploy.

---

From: <[email-masked]>
Date: Thu, 19 Feb 2015 13:27:34 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 19 février 2015 14:17
À : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Michaud; BINET David IMT/OLN; IPv6 Ops WG ([email-masked])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 10:03 PM, <[email-masked]<mailto:[email-masked]>> wrote:

The search says that a single-digit percentage of the documents contain the word "host" or "CPE" in the title. What point are you trying to make? That the charter is inappropriate, because it doesn't mention hosts, but the WG has published a few documents that talk about hosts?

[Med] The answer is obvious : the WG has no problem to publish such documents.

That's a great example to pick, because the WG is about to produce an RFC on precisely this topic - https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ .

[Med] I can inform you this will be published as RFC7445. It happens I’m co-author that document, so I’m not discovering it. Furthermore, this is cited in the mobile profile draft:

                A detailed analysis of roaming failure cases is included
                in [RFC7445].

That document is a good example of what *is* in charter of the WG: an in-depth, detailed discussion of the operational issues. 8 lines of text saying "devices must support different PDP types for home and roaming" is not.

[Med] There is no recommendation in the roaming analysis draft. The profile document includes a clear recommendation on the current plan of most operators to handle the roaming issue. We don’t need hundreds of pages for that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 22:35:53 +0900

On Thu, Feb 19, 2015 at 10:27 PM, <[email-masked]> wrote:

> The search says that a single-digit percentage of the documents contain
> the word "host" or "CPE" in the title. What point are you trying to make?
> That the charter is inappropriate, because it doesn't mention hosts, but
> the WG has published a few documents that talk about hosts?
>
>
>

Not really. If you go and read those documents, you'll see none of them is
on host requirements. And in any case, the discussion was whether this
document is "directly in line with the v6ops charter", as Dave said. Just
because the WG happens to have published a few documents that talk about
hosts doesn't mean that host requirements are directly in line with the
charter.

>  That's a great example to pick, because the WG is about to produce an
> RFC on precisely this topic -
> [Med] I can inform you this will be published as RFC7445. It happens I’m
> co-author that document, so I’m not discovering it.
>

That's why I picked it, yes.

> [Med] There is no recommendation in the roaming analysis draft. The
> profile document includes a clear recommendation on the current plan of
> most operators to handle the roaming issue.
>

But it's not the role of the IETF or of this working group to make
statements about operator plans. It's the IETF's role to discuss technical
standards, and this group's role to provide operational guidance.
"Operators X, Y, and Z are handling the roaming issue like this" is not
operational guidance. An in-depth discussion of the problem, such as
draft-ietf-v6ops-ipv6-roaming-analysis, is.

---

From: <[email-masked]>
Date: Thu, 19 Feb 2015 13:46:29 +0000

Re- ,

Please see inline.

Cheers,
Med

Envoyé : jeudi 19 février 2015 14:36

On Thu, Feb 19, 2015 at 10:27 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Not really. If you go and read those documents, you'll see none of them is on host requirements.

[Med] With all due respect, this is not true. RFC7066 is an example of host requirements.

And in any case, the discussion was whether this document is "directly in line with the v6ops charter", as Dave said. Just because the WG happens to have published a few documents that talk about hosts doesn't mean that host requirements are directly in line with the charter.

[Med] What I know is that this document was adopted by the WG and passed the IETF LC once. The question about the charter was never raised.

[Med] I can inform you this will be published as RFC7445. It happens I’m co-author that document, so I’m not discovering it.

[Med] There is no recommendation in the roaming analysis draft. The profile document includes a clear recommendation on the current plan of most operators to handle the roaming issue.

But it's not the role of the IETF or of this working group to make statements about operator plans.
[Med] Who is asking for this?! This is your assumption, at most.

It's the IETF's role to discuss technical standards, and this group's role to provide operational guidance. "Operators X, Y, and Z are handling the roaming issue like this" is not operational guidance. An in-depth discussion of the problem, such as draft-ietf-v6ops-ipv6-roaming-analysis, is.

[Med] The profile indicate a clear recommendation to solve a problem discussed in more details in another v6ops produced document.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2015 14:58:41 +0100

Le 19/02/2015 14:10, Dave Michaud a écrit :
[...]
> side to form a complete solution.

In this particular respect: no, I think it's very possible to have
transition to an IPv6-only access yet the host acts as a pure IPv4 host
(no CLAT translation on the Host).

I think what you mean is that the cellular operators have a particular
solution for migrating to IPv6-only.  The method 464xlat/clat is good
but not necessarily the best for every context (an IPv4 Host-to-Host app
like Push-to-Talk, to mention something new).

Among those two (IPv6 and CLAT) one would certainly suggest IPv6
implementation in the terminal, but CLAT should be a "MAY".  One
wouldn't want others to think that IPv6 is possible only if CLAT is there.

Alex

>
> The documents published under v6ops should "serve as useful guides
> to network operators and users on possible ways how to deploy IPv6
> within their existing IPv4 networks, as well as in new network
> installations.”
>
> This is exactly what this is. As a LAN administrator, it wouldn’t
> cross my mind to look for an RFC for host requirements because I
> would have little control anyway. As a cellular operator, the hosts
> are part of my network and I do have a say on how they operate and
> it forms part of the overall solution (bullet 4 of the charter).
> Same would apply from a Cable MSO where the CPEs are integral part of
> the network.
>
>
>
> *Dave Michaud* Sr. Architect Mobility – Access Networks & IP Network
> Services Network Technology | Rogers Communications
> [email-masked] <mailto:[email-masked]> |
> tel: +1 647.747.9442 | mobile: +1 416.219.5531
>
>
> From: Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> Date: Thursday, February 19, 2015 at
> 07:45 To: Dave Michaud <[email-masked]
> <mailto:[email-masked]>> Cc:
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>,
> BINET IMT/OLN <[email-masked]
> <mailto:[email-masked]>>, IPv6 WG <[email-masked]
> <mailto:[email-masked]>> Subject: Re: [v6ops]
> draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
>
> On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> guidance on how to deploy IPv6 into existing IPv4-only networks, as
> well as into new network installations.
>
> Actually, it isn't, really. The charter is operational guidance for
> the IPv4/IPv6 Internet. Not host requirements.
>
> In fact, if you look at the numbered list in the charter, the items
> are "identify operational issues and determine solutions", "identify
> potential security risks", "identify portions of the specs that can
> cause operational concerns", and "analyze solutions for deploying
> IPv6 within network environments". None of those cover this
> document.
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
This communication is confidential. We only send and receive email on
> the basis of the terms set out at
> www.rogers.com/web/content/emailnotice
> <http://www.rogers.com/web/content/emailnotice>
>
>
>
> Ce message est confidentiel. Notre transmission et réception de
> courriels se fait strictement suivant les modalités énoncées dans
> l’avis publié à www.rogers.com/aviscourriel
> <http://www.rogers.com/aviscourriel >
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Feb 2015 23:02:48 +0900

On Thu, Feb 19, 2015 at 10:46 PM, <[email-masked]> wrote:

> on host requirements.

The main purpose of RFC 7066 is not to place requirements of its own, but
to clarify the requirements that are posed on hosts by the 3GPP standards.

>   And in any case, the discussion was whether this document is "directly
> in line with the v6ops charter", as Dave said. Just because the WG
> happens to have published a few documents that talk about hosts doesn't
> mean that host requirements are directly in line with the charter.
>
>
>
> [Med] What I know is that this document was adopted by the WG and passed
> the IETF LC once. The question about the charter was never raised.
>

I don't see what WG adoption and IETF LC have got do do with this
discussion. Dave said the document is "directly in line with the v6ops
charter", and I disagreed.

> statements about operator plans.
>

You're the one who wrote the words "the profile document includes a clear
recommendation on the current plan of most operators". All I'm saying is
that that's not the IETF's role.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Feb 2015 08:53:32 +1300

> Normally SDOs are both accountable and responsible.

That isn't clear to me in general.

> Accountability, well, clearly some find it uneasy that IETF would have accountability for the document.

The IETF (and the RFC Editor) is not accountable for anything. Our standards
and recommendations are all voluntary and they all bear a disclaimer (hidden
in the Trust Legal Provisions for recent RFCs) saying something like:
"...DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

The IETF is responsible for the contents in the sense that we require
change control over derivative works of IETF Stream documents.

> If another body could be accountable for the document, that it represents the views of a suitable collective (mobile operators), but the technical content was filtered via IETF, that would be ideal…

Not if the IETF fails to reach rough consensus on the contents.

> I have no idea how to engineer such an outcome, but if it could be done then this work should not be wasted – could be a “GSMA sponsored RFC”?

No. If the IETF fails to reach rough consensus, the authors are free to do
whatever they want. If they believe that the "RFC" label has value, they
are free to submit it as an Independent Stream RFC, and the Independent
Submissions Editor then gets to decide whether to publish it:

http://www.rfc-editor.org/indsubs.html

Disclaimer: I am a member of the Independent Submissions editorial board.

   Brian

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 06:54:35 +0000

Lorenzo,

Items included in the I-D are specified in existing RFCs, 3GGP or GSMA specifications. We are not “inventing” new features!

Actually, I don’t see the point of this discussion that started with a concern about "harmfully broad" but ends now with: this is not within the charter of v6ops!

If the point is to raise an objection then you can find more serious ones but not this one. It is incongruent to discuss this point about the charter at this stage: especially given the document was already accepted by the WG, passed the WGLC twice, and an IETF consensus was declared for it once.

As a reminder, below what we have implemented to address your concerns:

·         We integrated the text change you asked for when the WGLC was immediately initiated,

·         We clarified your concern about non prioritizing the recommendations,

·         We clarified the point that the compliancy with the document does not mean all items must be supported,

·         We reduced the scope of the document and listed items from 34 to 18 (5 of these items are for device with LAN capabilities, while 5 are advanced features).

I still have energy to address any serious concern you would have. If you can provide text this would even be better.

This document is also yours. As editors, we are recording what we hear from the WG.

Thank you.

Cheers,
Med

Envoyé : jeudi 19 février 2015 15:03

On Thu, Feb 19, 2015 at 10:46 PM, <[email-masked]<mailto:[email-masked]>> wrote:

The main purpose of RFC 7066 is not to place requirements of its own, but to clarify the requirements that are posed on hosts by the 3GPP standards.

I don't see what WG adoption and IETF LC have got do do with this discussion. Dave said the document is "directly in line with the v6ops charter", and I disagreed.

You're the one who wrote the words "the profile document includes a clear recommendation on the current plan of most operators". All I'm saying is that that's not the IETF's role.

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 12:39:16 +0000

Hi Alex,

It is obvious that CLAT has nothing to do with native IPv6 communications (i.e., communications between IPv6-enabled nodes over an IPv6-enabled network).

The CLAT recommendation in the profile I-D starts with: "In order to ensure IPv4 service continuity in an IPv6-only deployment context,"

That's IMHO clear enough to avoid "others to think that IPv6 is possible only if CLAT is there.".

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Alexandru
> Petrescu
> Envoyé : jeudi 19 février 2015 14:59
> À : [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 13:57:21 +0100

Le 20/02/2015 13:39, [email-masked] a écrit :
> Hi Alex,
>
> It is obvious that CLAT has nothing to do with native IPv6
> communications (i.e., communications between IPv6-enabled nodes over
> an IPv6-enabled network).
>
> The CLAT recommendation in the profile I-D starts with: "In order to
> ensure IPv4 service continuity in an IPv6-only deployment context,"
>

YEs, I agree.  That text is sufficient.

As a side note, I would be doubtful naming an IPv6-only access network
something that uses IPv4 as well (464xlat, dns64).  I would rather call
it a "mostly" IPv6 access network, with a little of IPv4 however.

This is just a matter of terminology.

Also, since we last discussed we went trying eliminate the IPv4 stack
from a linux kernel.  That is not possible.  So any 'pure' IPv6 machine
that would connect to an IPv6-only access network is just a speculation
at this point, years away from any deployment.

Alex

>
> Cheers, Med
>
>> -----Message d'origine----- De : v6ops
>> [mailto:[email-masked]] De la part de Alexandru Petrescu
>> Envoyé : jeudi 19 février 2015 14:59 À : [email-masked] Objet :
>> Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
>> "harmfully broad"?
>>
>>

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 13:05:08 +0000

Re-,

Please see inline.

> De : Alexandru Petrescu [mailto:[email-masked]]
> Envoyé : vendredi 20 février 2015 13:57
> Cc : [email-masked]

Cool! Thank you.

Cheers,
Med

---

From: joel jaeggli <[email-masked]>
Date: Sun, 22 Feb 2015 10:15:45 -0800

RE: charter

put the charter discussion to bed please. we accepted this as a wg
document in 2013 with full knowledge of the contents.

On 2/19/15 5:10 AM, Dave Michaud wrote:
> Enabling dual-stack on a cellular network serves no mean if it can’t be
> used.
> 
> This is exactly what this is. As a LAN administrator, it wouldn’t cross
> my mind to look for an RFC for host requirements because I would have
> little control anyway. As a cellular operator, the hosts are part of my
> network and I do have a say on how they operate and it forms part of the
> overall solution (bullet 4 of the charter). Same would apply from a
> Cable MSO where the CPEs are integral part of the network.
> 
> 
> 
> *Dave Michaud*
> [email-masked] <mailto:[email-masked]> | tel:
> +1 647.747.9442 | mobile: +1 416.219.5531
> 
> 
> From: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>"
> BINET IMT/OLN <[email-masked] <mailto:[email-masked]>>,
> IPv6 WG <[email-masked] <mailto:[email-masked]>>
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> "identify operational issues and determine solutions", "identify
> cause operational concerns", and "analyze solutions for deploying IPv6
> within network environments". None of those cover this document.
> 
> 
> 
> 
> the basis of the terms set out at www.rogers.com/web/content/emailnotice
> courriels se fait strictement suivant les modalités énoncées dans l’avis
> publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel >

---

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

> document in 2013 with full knowledge of the contents.

I'm not trying to open a debate about that. I was just objecting to the
statement that this document is "directly in line with the charter". As I
see it, at best it's on the fringes.