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

[<[e-mail]>]

Hi Brian,

Thank you for the comments.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Brian E Carpenter [mailto:[e-mail]] 
Envoyé : jeudi 29 janvier 2015 21:39
À : Lorenzo Colitti; Fred Baker (fred)
Cc : [e-mail]; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

To be honest I stopped tracking this draft a long time ago,
so didn't speak up during the first WGLC. But I think I'm
in the rough with Lorenzo. The document reads like somebody's
procurement spec, not like a set of recommendations for
generic interoperability. And the devil is in the details.
For example, I noticed a point where I have a little skin
in the game:

   APP_REC#3:  Applications provided by the mobile device vendor that
               use Uniform Resource Identifiers (URIs) must follow
               [RFC3986].  For example, SIP applications must follow the
               correction defined in [RFC5954].

So, does that requirement include the updates to RFC 3986 (i.e. RFC 6874
and 7320)?

[Med] The main entry is RFC3986; updates to that RFC can be added.  

 And how is applying a correction to RFC 3261 an "example"
of following RFC 3986? And anyway, shouldn't this be in a SIP profile,
not here?

[Med] SIP is an example of application for which the initial specification included a broken IPv6 ABNF + broken URI comparison rules. We provided the SIP example to illustrate which rules must be followed.  


That's an illustration of why this document positioned as an IETF work
product makes me uncomfortable. I imagine there are many other similar
hidden issues.

[Med] It would be helpful if those were called out, no?

    Brian

On 30/01/2015 00:53, Lorenzo Colitti wrote:
> On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <[e-mail]> wrote:
> 
>> draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of
>> change in the IESG. The ADs would like to see the working group read it
>> again and comment - working group last call - before they proceed.
> 
> 
> Ok, off we go again then.
> 
> I have objected to this document already, and was found to be in the rough.
> Therefore, I must assume that rough WG consensus is that we need a document
> that looks something like this, and I will accordingly refrain from making
> any general statements on the scope, utility, and general content of the
> document, with which I continue to disagree.
> 
> However, I would be remiss if I did not at least draw attention to the
> following factual errors and/or inappropriate statements.
> 
> 
> 1. The wording "required features to connect 3GPP mobile devices to an
> IPv6-only or dual-stack wireless network" is factually incorrect. The vast
> majority of these recommendations are not required to connect to such
> networks, and are many are not even implemented by many popular mobile
> operating systems - which manage to connect just fine. After long
> discussions, that text was removed in -06. Why was it readded?
> 
> 
> 2. Previous versions of the document, including the version that passed
> IETF last call, contained the text:
> 
>    This document is not a standard, and conformance with it is not
>    required in order to claim conformance with IETF standards for IPv6.
>    The support of the full set of features may not be required in some
>    deployment contexts.  The authors believe that the support of a
>    subset of the features included in this protocol may lead to degraded
>    level of service in some deployment contexts.
> 
> That text remains accurate and that statement is still necessary. Why was
> it removed? It has been in the document since -06, and the words "this
> document is not a standard" have been in this document since -01.
> 
> 
> 3. I object to the statement "One of the major hurdles encountered by
> mobile operators is the availability of non-broken IPv6 implementation in
> mobile devices." I submit that if it were true, then we would observe no
> IPv6 deployment in mobile networks... but publicly-available data - e.g.,
> http://www.worldipv6launch.org/measurements/ - shows that multiple
> operators have deployed IPv6 to up to 30-65% of their footprint, using the
> same commercially-available devices that are used by customers of other
> operators. So claiming that "broken IPv6 implementations in mobile devices"
> are a major hurdle is at best incomplete and at worst incorrect.
> 
> 
> At the risk of sounding like a broken record, I am going yet again to say
> that that operational documents should be based on operational experience.
> I am not aware of any of the authors' employers having a substantial IPv6
> deployment (though I would be happy to see any data that the authors could
> provide to the contrary). On the other hand, the IPv6 lead on one of the
> operators that *has* deployed IPv6 no longer appears in the list of authors.
> 
> 
> Regards,
> Lorenzo
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>