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

[Teemu Savolainen <[e-mail]>]

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.
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?


> 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.

> 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.


> 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?


> 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).


> 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.


> 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.


> 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.

> 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.