Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt

[<[e-mail]>]

Hi Teemu,

Many thanks for your detailed review.

Please see inline.
Cheers,
Med

De : Teemu Savolainen [mailto:[e-mail]]
Envoyé : jeudi 18 avril 2013 13:55
À : BOUCADAIR Mohamed OLNC/OLN
Cc : [e-mail]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt

Med, all,

I gave this document a full read with following comments:
1) I think "mobile devices" is perhaps too wide a name - should this explicitly say "3gpp mobile devices" or "cellular hosts".
[Med] 3GPP Mobile Devices would be OK.

2) In my opinion all references to 3316 should be changed to draft-ietf-v6ops-rfc3316bis,
[Med] Will see how to update the text.

and there is no need to compare RFC3316 with 3316bis draft in here (in section 1), as the 3316bis will obsolete the 3316.
[Med] Are you referring to this text?

   [RFC3316] lists a set of features to be supported by cellular hosts
   to connect to 3GPP cellular networks.  Since the publication of that
   document, new functions have been specified within the 3GPP and the
   IETF whilst others have been updated.  Moreover, in the light of
   recent IPv6 production deployments, additional features to facilitate
   IPv6-only deployments while accessing IPv4-only service are to be
   considered.

Are you suggesting this text is to be removed?

3) The abstract talks about "device with LAN" capabilities. That is ambiguous, as I think you mean LAN on "downlink" of the device? I mean a device with WiFi connection has "LAN capability" even if it does not have tethering capabilities:) "Both hosts and devices with capability to share their WAN connectivity to LAN" or something?
[Med] I got your point. Will tweak the text.

3) Why some of the requirements of RFC6434 are duplicated herein with same keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would suppose a profile document could say that mobile device MUST follow RFC6434, except when <exceptions> ?
[Med] Isn't this covered by this text:


   Pointers to some requirements listed in [RFC6434<http://tools.ietf.org/html/rfc6434>] are included in

   this profile.  The justification for using a stronger language

   compared to what is specified in [RFC6434<http://tools.ietf.org/html/rfc6434>] is provided for some

   requirements.

If you think this is not clear, we can update the text to better clarify the logic.

4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also required, or is IPv4 PDP optional? Needs clarification.
[Med] The title focuses only on the IPv6-related PDP contexts. I don't think there is a value to use the normative language for IPv4 PDP.

5) Is it required to be able to support different PDP types in parallel, e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but do you wish to write it down?
[Med] IMHO, this is not specific to IPv6. I don't think there is a value to explicit this for IPv6-related PDP contexts.

6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack. Well, this is how 3GPP writes it as well... but in reality all this depends on provisioning. So you should say that this is the way, unless provisioned to do otherwise..
[Med] Would you be OK if the text is changed as follows:

OLD:
the cellular host MUST request ...

NEW:
the cellular host MUST request by default ...

7) REQ#3 bullet 1, I don't follow. It says that if network does not have IPv4v6, but "IPv4 and IPv6", then the network will configure IPv4 address and IPv6 prefix. This is does not tell really much, IPv4 address and IPv6 prefix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed in parallel. Maybe this gets fixed if you change "and/or" to just "or". Because if network gives only IPv4 or IPv6, then the device can ask for parallel bearer.
[Med] Fixed.

8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to SHOULD or MUST. This is because device is dual-stack capable, has requested IPv4v6, but only gotten IPv4 or IPv6. If the network does not indicate "single bearer only", then IMHO the device MUST ask for parallel PDP - which the network can reject. I.e. dual-stack host should ask for IPv4v6, then IPv4 and IPv6 in parallel. Exceptions are provisioning or error codes available at and after release-8.
[Med] The text will be fixed.

9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in addition to MUST for PCO option support.
[Med] This is discussed in REQ#9. No?

10) REQ#6: should you clarify that MTU option really needs to be received and acted upon?
[Med] Can you explicit what change you want to see added to the text?

11) REQ#9 says in title "must" but in text "SHOULD". Which way do you intend? I could go for MUST in order to allow more flexibility in the future, but SHOULD is ok as well
[Med] "must comply" with Section 7.3 means it needs to follow what is described in that section: i.e., SHOULD support 6106. This is indicated explicitly in the text.

12) REQ#10 says in title "must", but why? What if device just does not need anything via stateless DHCPv6? SHOULD would be better?
[Med] Idem as above.

13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is the only that says preference order (with PCP, should probably be PCO instead). Could these REQs be combined? Should the preference order be a separate requirement ?
[Med] Fixed the typo with PCP. OK to have a separate requirement for the preference order.

14) REQ#11 do you have requirement
[Med] See the justification text and also the DNSSEC case.

15) REQ#13 could have pointer/dependency to REQ#11? I take DNSSEC support goes off-scope - but nevertheless REQ#13 is needed only if device supports DNSSEC, or 464XLAT?
[Med] Added a pointer to REQ#11.

16) REQ#15 refers to MIF - I would probably simply drop the MIF reference out, as if MIF is included also other problems start creeping in (specific routes, DNS selection, provisioning domains...) - i.e. better exclude MIF problematics from this document. You could explicitly state whether you prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something currently more or less random.
[Med] No problem to remove the MIF reference. For the DNS case, are you suggesting to add a sentence such as:
"When both IPv4 and IPv6 DNS servers are configured, a dual-stack host MUST contact first its IPv6 DNS server."

17) Section 2.1 I would like clarification whether this applies to "downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but please spell it out.
[Med] What difference do you make between those two?

18) WiFi is a trademark owned by WiFi Alliance. Based on prior feedback to me, I would rather talk about IEEE 802.11, or WLAN here as well.
[Med] Fixed. Thanks.

19) REQ#19 I would remove the background text about "some recent tests revealed" on some OS - it just does not suit well for profile document living for a looong time. Alternatively you could have Appendix that includes some of the real-world experiences of particular implementations?
[Med] We put that text there to record the encountered issue with some implementations. If the requirement is supported, this wouldn't be an issue. I will discuss with my co-author how to handle this comment. Thanks.

20) REQ#22 why this is advanced requirement? I would call it basic.. and I would like to emphasize capability to receive MTU option via RA.
[Med] Would moving this REQ to be called out just after REQ#6 be OK with you?

21) REQ#23 - I am not convinced full RFC4941 is always required. Enough private  addresses could be obtained by simpler ways as well, I believe. Hence I would rephrase that hosts MUST have RFC4941 or other means for providing privacy addressing. I.e. the requirement should be about privacy addresses, not RFC4941.
[Med] Makes sense. What about this change?

OLD:


The cellular host must comply with Section 5.9.3 of<http://tools.ietf.org/html/rfc6434#section-5.9.3>

          [RFC6434]<http://tools.ietf.org/html/rfc6434#section-5.9.3> for the support of the Privacy Extensions for

          Stateless Address Autoconfiguration in IPv6.


             The activation of privacy extension makes it more difficult

             to track a host over time when compared to using a

             permanent interface identifier.  [RFC4941<http://tools.ietf.org/html/rfc4941>] does not require

             any DAD mechanism to be activated as the GGSN (or PDN-GW)

             MUST NOT configure any global address based on the prefix

             allocated to the cellular host.

NEW:


The cellular host MUST be able able to generate IPv6 addresses which preserve privacy.


             The activation of privacy extension (e.g., using [RFC4941<http://tools.ietf.org/html/rfc4941>]) makes it more difficult

             to track a host over time when compared to using a

             permanent interface identifier. Note, [RFC4941<http://tools.ietf.org/html/rfc4941>] does not require

             any DAD mechanism to be activated as the GGSN (or PDN-GW)

             MUST NOT configure any global address based on the prefix

             allocated to the cellular host.


22) REQ#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE requires RTP/UDP/IP, but nobody is requiring TCP profile (because for (Voice)/RTP/UDP/IP the savings in compressed headers are significant, but for TCP bulk download the savings are insignificant and when compared to overall costs (cost of compressing/decompressing) probably close to negative).
[Med] This is a very good point. I do personally agree with you. Let see what there other think, if no objection is raised, we will adopt your suggestion.

23) Section 4 title - please clarify this is downlink LAN
24) REQ#27 makes 3GPP-wise sense only on Release-10 based networks. Do you intent this requirement to cover all IPv6 hosts from 3GPP Release-99 onwards (cherry picking)? Please clarify in either case.
[Med] Just like REQ#29, the tone has been softened to not mention any 3GPP release as discussed here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html.

25) REQ#33 this is something handset vendors have only so much control over.. but maybe this document can also be given for application writers?-)
[Med] I was aware of applications developed by the same mobile device vendor but are not IPv6-compatible. The requirement as currently worded is valid for all applications.


Best regards,

Teemu



2013/3/27 <[e-mail]<mailto:[e-mail]>>
Dear all,

The changes in the new version are as follows:

(1) Tweak the text in the Abstract and Introduction to answer to the comment raised by F. Baker here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15672.html
(2) Soften the tone for REQ#29 as discussed with Mickael here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html
(3) Add a disclaimer some features require activating some functions at the network side as suggested by Jouni
(4) Add an explicit reference to RFC6434 + whenever needed, indicate whether the new language form is stronger + Justification.

The new version integrates all the comments received so far.

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] De
>la part de [e-mail]<mailto:[e-mail]>
>Envoyé : mercredi 27 mars 2013 10:33
>À : [e-mail]<mailto:[e-mail]>
>Cc : [e-mail]<mailto:[e-mail]>
>Objet : [v6ops] I-D Action:
>draft-ietf-v6ops-mobile-device-profile-01.txt
>
>
>A New Internet-Draft is available from the on-line
>Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working
>Group of the IETF.
>
>       Title           : Internet Protocol Version 6 (IPv6)
>Profile for Mobile Devices
>       Author(s)       : David Binet
>                          Mohamed Boucadair
>                          Ales Vizdal
>                          Cameron Byrne
>                          Gang Chen
>       Filename        : draft-ietf-v6ops-mobile-device-profile-01.txt
>       Pages           : 16
>       Date            : 2013-03-27
>
>Abstract:
>   This document specifies an IPv6 profile for mobile devices.
> It lists
>   the set of features a mobile device is to be compliant with to
>   connect to an IPv6-only or dual-stack mobile network.
>
>   This document defines a different profile than the one for general
>   connection to IPv6 mobile networks defined in [RFC3316].  In
>   particular, this document identifies also features to ensure IPv4
>   service continuity over an IPv6-only transport.
>
>   Both Hosts and devices with LAN capabilities are in scope.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device
>-profile-01
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>v6ops mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops