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

[<[e-mail]>]

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

De : Lorenzo Colitti [mailto:[e-mail]]
Envoyé : jeudi 12 février 2015 23:24
À : BOUCADAIR Mohamed IMT/OLN
Cc : Heatley, Nick; Fred Baker (fred); [e-mail]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Wed, Feb 11, 2015 at 4:09 AM, <[e-mail]<mailto:[e-mail]>> wrote:
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.)

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