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

[<[e-mail]>]

Hi Teemu,

Please see inline.
Cheers,
Med

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

Hi Med,

Thank you for your prompt reply, further comments inline for some points (rest cut):

Cheers,

Teemu

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?

What I'm saying is that RFC3316bis will obsolete RFC3316, hence this document should not be referring to obsolete RFC - assuming both these complete roughly at the same time. Hence you should replace the RFC3316 with RFC3316bis and modify the text accordingly. I.e. describe what this document brings in addition. Maybe something like:

   [RFC3316bis] lists a set of features to be supported by cellular hosts
   to connect to 3GPP cellular networks.  In the light of
   recent IPv6 production deployments, additional features to facilitate
   IPv6-only deployments while accessing IPv4-only service are to be
   considered.
[Med] OK with your proposed wording.
or something?
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.
Well I just don't see why to point to some requirements in RFC6434, except to use stronger (or weaker) language for the requirements explicitly pointed at.

Could the document perhaps state that RFC6434 is required but with exceptions and additions listed in this document?
[Med] We want to call out explicitly the requirements which are of interest and therefore have a comprehensive list of requirements. A justification text is added when the normative language is stronger.

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.
I was asking because the "Both IPv6 and IPv4v6 PDP contexts MUST be supported in addition to the IPv4 PDP." sounds like normative text.  I was thinking whether  this document allows a device with just IPv6 and IPv4v6 PDP context support. Probably no use for such device in near future, but I was nevertheless wondering if IPv4 is explicitly required.
[Med] I see your point. I removed "in addition to the IPv4 PDP". The text is silent about IPv4 PDP-Context support.
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.
True, ok for me not to talk about this here.
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 ...
Yes, that would be fine.
[Med] Done.

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?
True, probably by the time I hit REQ#9 I had forgotten this comment already:)

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?
MTU communication via RA from SHOULD to MUST?
[Med] Agree with MUST

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.
What does it mean when one "must comply" with "SHOULD"?-) If the normative text says SHOULD, why the title could not be "The cellular host should comply with.."

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.
And same as above, "must comply" with "SHOULD" is confusing.

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

This was a typo from me, I thought of something, checked it out, and then forgot to delete the text I had started writing...
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."
Yes, that would suit me, but I wanted to check whether you wish it that way, or if "random" is ok (or e.g. happy eyeballs style approach).
 [Med] I changed the text as proposed above.
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?
Never mind, I was thinking perhaps a bit too far. It talks already about hotspots anyway.
[Med] ;-)
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.
I'm fine with the requirement, but if you need to keep it for a while still that's ok.
 [Med] 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?
Yes.
[Med] Done.
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.

Would work for me.
[Med] Done. Thanks.