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

[<[e-mail]>]

Dear Mark,

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

I would like to make the following comments:


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

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


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


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

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

   Indeed, the support of Neighbor Discovery Protocol is mandatory in

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

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

   Transmission Unit) communication via Router Advertisement must be

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

   setting.


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


   This profile uses a stronger language for the support of Prefix

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

   cellular networks are more and more perceived as an alternative to

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

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

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

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

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

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

   convergence.


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

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


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

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



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



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


Thank you.
Cheers,
Med

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

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

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

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

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

The other thing I wonder about is what is so special about telephones (anymore)? They're fundamentally now nothing more than portable portable computers that just happen to also be used to make phone calls, as well as running many other types of applications. Their 3GPP link-layer interface is the only thing that makes them specifically different from any other portable computer, and I think the only real need to make IPv6 run on them would have been to prepare and update any 3GPP link characteristic specific IPv6 RFCs, that in particular didn't invent new ways of doing what existing non-link specific IPv6 protocols could already do (e.g., PCOs for DNS instead of originally just stateless/stateful DHCPv6 and now (although mostly, in my opinion, unfortunately) RAs).

It seems to me that if smartphone vendors need or needed guidance on what they should implement to support IPv6, they should be or should have been provided with the IPv6 Node Requirements RFC, and an RFC that specifies how to bootstrap IPv6 over an 3GPP link to the point where the non-link type specific standard IPv6 methods could be used, as all of the other IPv6 over Foo-link RFCs do. As major computer companies are now in charge of smartphone development/advancement, that is probably in effect what is mostly happening anyway.

Regards,
Mark.

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


On Tue, Feb 10, 2015 at 11:31 PM, <[e-mail]<mailto:[e-mail]>> 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.

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