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

[Teemu Savolainen <[e-mail]>]

It seems all my comments are now addressed - I'll give a reread for the
next revision and try to see if I can come up with further comments.

Thank you,

Teemu


2013/4/23 <[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.****
>