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

[joel jaeggli <[e-mail]>]

On 2/9/15 1:14 AM, Heatley, Nick wrote:
> Just a reminder on why I, as an operator, have a need of a document 
> from the IETF. I desire: - an IP profile from IETF - IETF is the home
> of IP and Internet Engineering (but happy to tie up with 3GPP etc.) -
> a profile for mobile devices when the network offers them IPv6-only
> (dualstack will not get us beyond IPv4 exhaustion) - a single
> recommended profile covering all mobile use cases  - handset cellular
> data, handset tethering, mobile broadband; an informational standard
> will suffice - I will use this as a NORM in further discussions with
> terminal vendors. Yes, many operators will have further discussions
> with many terminal vendors, terminal software/configuration on the
> whole is fragmented.
> 
> Contrary to some of the views expressed ("that some IPv6 is out there
> in mobile land, therefore by induction all mobile issues are 
> resolved") there are still some issues and grey areas. As far as I 
> know there are only a few open market device model "families", that 
> may work IPv6-only with full backwards compatibility with IPv4, and 
> provides stable tethering, and implement APN roaming controls. For 
> all other vendor models that are badged as IPv6, you need to request
>  a per operator build. Will the relevant features in the build be the
>  same for all operators, in all regions? How can one operator really
>  say without some global norm to compare this to? If the Google guy 
> says it is all fine, that is great news. I'd feel better if the LG 
> guy, Samsung guy, Apple guy, HTC guy etc. etc. all came on the V6Ops
>  list with the same message. Our devices teams do not normally get 
> involved with such low level requirements as IP protocol versions. We
> have vendors that we haven’t even started talking to yet about IPv6.
> 
> Similarly, find me a mobile network where all IPv6-enabled terminal 
> models are in IPv6-only mode for all use cases (c.f. cellular data, 
> tethering, mobile broadband) using standards build. Those are hard to
> find; as an industry we are not there yet. (No disrespect, this is
> due to business reasons: some operators have gone dualstack APN, some
> have another APN for tethering, some have chosen hardcoding of 
> prefix64, some need a common APN for all  IP connectivity modes....).
> It is important to recognise the operator differences.
> 
> As one of the authors, we were advised by the WG that normative 
> language was not appropriate for this document as it was a feature 
> list /buffet of options/list document rather than a standard. Fine, 
> it is not a standard, it is not a problem to accept that and make 
> that perfectly clear in the paper. But equally I would suspect that 
> as it is not a standard this is why the document has expanded with 
> all the best buffet of features available mandatory/optional/required
> for certain use cases.

Well it essentially started with this list of features, so I don't
accept that it has ballooned as product of non-normative language. If in
total one didn't it like before and the language change didn't mollify,
you probably still don't.

We have a channel for publishing non-consesus documents but it's not the
working group process. I believed, perhaps mistakenly that we could move
this to a more durable consensus on the basis of text changes to take it
away from requirements.

> Now the document appears to be being blasted for exactly this 
> extensive list of non-mandatory features. Is that fair? Has a steer 
> been given here, and is everyone agreed on the steer?
> 
> The question in my mind is this, if we produce a document that 
> focuses only on features for IPv6-only mode of operation (which I may
> support, not sure of other authors' positions), can we use normative
> language and produce an informational standard? Will that be more
> agreeable to the detractors? If it could be done without resetting
> the process too far back and it turned opposition into support, then
> I'd support it. I think the IPv6-only profile is more urgent than the
> equivalent IPv4v6 dual stack profile, based on my viewpoint, again I
> cannot speak for all authors.
> 
> Not having a NORM document, leaves the industry in a hole in my 
> opinion. I hope we can find a timely way forward. Regards, Nick
> 
> 
> -----Original Message----- From: v6ops 
> [mailto:[e-mail]] On Behalf Of Fred Baker (fred) Sent:
>  03 February 2015 19:18 To: [e-mail] Cc: 
> [e-mail]; V6 Ops 
> List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last
> call
> 
> 
>> On Jan 30, 2015, at 4:21 AM, [e-mail] wrote:
>> 
>> With all due respect, I'm afraid we are not discussing whether the
>>  document is needed or not but (as I see it) whether the new
>> version does not break the WG consensus that was declared for the
>> version sent to the IESG. I recall that both the WG and IETF
>> consensus were declared for the version sent to the IESG.
> 
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/history/
>
>
>
>
>
>
>
> 
That’s not quite the way I recall it. In the WG, consensus has
> always been rough. I sent it out when the number of people stating a
>  dissenting position dwindled. In the IETF LC in September 2013, 
> James, Lorenzo, and Owen made comments that caused Joel to withdraw 
> it from the IESG. In the IETF LC in September 2014 and subsequent 
> IESG discussion, comments were raised by several in the IESG and 
> summarized by Brian Haberman to the effect that the document has 
> serious issues. 
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/.
>
>
>
>
>
>
> 
In this round, you have tried to address the issues raised.
> 
> Before I bother the IESG with it a third time, I’d really like to 
> hear a clear consensus, not a rough one. Where it stands right now, 
> that’s not at all obvious.
> 
> 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. 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>