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

[Mark ZZZ Smith <[e-mail]>]

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]>
 To: "<[e-mail]>" <[e-mail]> 
Cc: "[e-mail]" <[e-mail]>; V6 Ops List <[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]> 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]
https://www.ietf.org/mailman/listinfo/v6ops