Re-, I really don’t see how you can have a phone that “make a phone that works perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP context, you don’t have a means to make work broken applications when IPv6-only is enabled, if the phone does not follow the procedure for requesting the PDP context, how you can be compatible with DNSSEC, etc. If what you mean by “perfect” is a degraded level of service, then you are right. I update the text to reflect this: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This document uses the normative keywords defined in the previous section only for precision.Is this better?Cheers,MedDe : Lorenzo Colitti [mailto:lorenzo@xxxxxxxxxx] On Tue, Sep 10, 2013 at 3:57 PM, <mohamed.boucadair@xxxxxxxxxx> wrote:
I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT. |