Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "Lack of Justification"?

[<[e-mail]>]

Hi Lorenzo,

(I changed the subject because the point raised by Lorenzo is not the same as the one initially in this thread)

I have three comments here :

(1)

Saying there is no justification in the document is WRONG. I can understand that the justification can be weak from your standpoint, but saying there is no justification is not fair at all. Some examples are provides below:

====
   C_REC#3:  The cellular host must support the PCO (Protocol
             Configuration Options) [TS.24008<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17#ref-TS.24008>] to retrieve the IPv6
             address(es) of the Recursive DNS server(s).

                In-band signaling is a convenient method to inform the
                cellular host about various services, including DNS
                server information.  It does not require any specific
                protocol to be supported and it is already deployed in
                IPv4 cellular networks to convey such DNS information.

   C_REC#6:  The cellular host must be able to be configured to limit
             PDP type(s) for a given APN.  The default mode is to allow
             all supported PDP types.  Note, C_REC#2 discusses the
             default behavior for requesting PDP-Context type(s).


                This feature is useful to drive the behavior of the UE
                to be aligned with: (1) service-specific constraints
                such as the use of IPv6-only for VoLTE (Voice over LTE),
                (2) network conditions with regards to the support of
                specific PDP types (e.g., IPv4v6 PDP-Context is not
                supported), (3) IPv4 sunset objectives, (4) subscription
                data, etc.

                Note, a cellular host changing its connection between an
                IPv6-specific APN and an IPv4-specific APN restarts the
                ongoing applications.  This is a brokenness situation.

   C_REC#7:  Because of potential operational deficiencies to be
             experienced in some roaming situations, the cellular host
             must be able to be configured with a home IP profile and a
             roaming IP profile.  The aim of the roaming profile is to
             limit the PDP type(s) requested by the cellular host when
             out of the home network.  Note that distinct PDP type(s)
             and APN(s) can be configured for home and roaming cases.

   C_REC#8:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular host should support a
             method to locally construct IPv4-embedded IPv6 addresses
             [RFC6052<http://tools.ietf.org/html/rfc6052>].  A method to learn PREFIX64 should be supported
             by the cellular host.

                This solves the issue when applications use IPv4
                referrals on IPv6-only access networks.

                In PCP-based environments, cellular hosts should follow
                [RFC7225<http://tools.ietf.org/html/rfc7225>] to learn the IPv6 Prefix used by an upstream
                PCP-controlled NAT64 device.  If PCP is not enabled, the
                cellular host should implement the method specified in
                [RFC7050<http://tools.ietf.org/html/rfc7050>] to retrieve the PREFIX64.

   C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular host should implement the
             Customer Side Translator (CLAT, [RFC6877<http://tools.ietf.org/html/rfc6877>]) function which
             is compliant with [RFC6052<http://tools.ietf.org/html/rfc6052>][RFC6145][RFC6146<http://tools.ietf.org/html/rfc6146>].

                CLAT function in the cellular host allows for IPv4-only
                application and IPv4-referals to work on an IPv6-only
                connectivity.  CLAT function requires a NAT64 capability
                [RFC6146<http://tools.ietf.org/html/rfc6146>] in the core network.

                The IPv4 Service Continuity Prefix used by CLAT is
                defined in [RFC7335<http://tools.ietf.org/html/rfc7335>].
=====

(2) I checked RFC7084 and RFC7066 out of curiosity, I didn’t found those documents provide more elaborated justifications that what we are doing here.

(3) You still continue assuming all items included in this I-D are mandatory, this is not true. A device can support this profile without supporting all the items listed in this profile.

Thank you.

Cheers,
Med

De : v6ops [mailto:[e-mail]] De la part de Lorenzo Colitti
Envoyé : samedi 14 février 2015 02:32
À : Heatley, Nick
Cc : IPv6 Ops WG ([e-mail])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick <[e-mail]<mailto:[e-mail]>> wrote:
Lorenzo, I feel you are like the specialist surgeon berating the GPs for not knowing every RFC in its pure form.

No, I am berating the authors of this draft for writing a document that makes GPs (=device manufacturers, other network operators) believe that they have to prepare loads of unnecessary medical machinery (=the many recommendations that this draft makes) before they can open a small GP surgery (=deploy IPv6), without bothering to tell them why they need all that machinery and what they're supposed to do with it.