Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/11/13 9:39 PM, Lorenzo Colitti wrote: On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli joe...@bogus.com mailto:joe...@bogus.com wrote: The queue for dicussion of this point is closed. If there needs to be an appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc To clarify - you're talking only about the discussion on whether this draft is in scope? Or are you saying that you consider all discussion of this document in this IETF last call settled? The discussion of whether the IETF, or this working group is a suitable location. It was my opinion that the working group should revist the document itself given what I saw in the last call. joel
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Sep 11, 2013, at 02:40 , Abdussalam Baryun abdussalambar...@gmail.com wrote: On 9/9/13, Owen DeLong o...@delong.com wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. Please define what is the IETF scope? IMHO, IETF is scoped to do with IPv6 devices requirements and implementations. Do you think there is a RFC that considers thoes requirements? From an RFC perspective, I think a cellular device is a host and/or router and those cover it. The media-specific aspects of layering IPv6 onto he peculiarities and vagaries of the underlying cellular specific technologies are, IMHO, best left to the media adaptation efforts of the relevant media standards bodies (as was done with ethernet, FDDI, Firewire, etc.). 2. So watered down in its language as to use many words to say nearly nothing. No, the draft says things, I think if you read nothing that you did not read then. If you read, then what is your definition of saying nothing? The draft says many things most or all of which conflict with things said elsewhere and all of which are fronted by a strong this is advisory only caveat. In fact, it says far too many things with far too little strength. The net result is that the document will, in the long run, become a no-op at best and a quagmire of conflicting and misleading advice at worst. 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. I think this was mentioned clearly in the draft, which readers can understand. I don't doubt that readers can understand it. My point is that once you understand the sum of the caveats and warnings and advisory nature of this document, the sum of all those understandings is that you have to look for the true answer to virtually everything contained here somewhere outside of the IETF anyway. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. IMHO, the LC is not for consensus, but it is for us to send the IESG our comments, and then they decide what is the IETF decision. I suppose everyone is entitled to their opinion. Why is there such a push to do this? Why is there a push to water-down it? I still was not convinced by your argument. However, Lorenzo comments should be considered by the draft as the authors are working on. If you think I am pushing to water it down, you are mistaken. I'd like to see it pared down to a useful document and then given the force of being a standards track document so it can actually provide something useful. Owen
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/9/13, Owen DeLong o...@delong.com wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. Please define what is the IETF scope? IMHO, IETF is scoped to do with IPv6 devices requirements and implementations. Do you think there is a RFC that considers thoes requirements? 2. So watered down in its language as to use many words to say nearly nothing. No, the draft says things, I think if you read nothing that you did not read then. If you read, then what is your definition of saying nothing? 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. I think this was mentioned clearly in the draft, which readers can understand. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. IMHO, the LC is not for consensus, but it is for us to send the IESG our comments, and then they decide what is the IETF decision. Why is there such a push to do this? Why is there a push to water-down it? I still was not convinced by your argument. However, Lorenzo comments should be considered by the draft as the authors are working on. AB
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/11/13 2:40 AM, Abdussalam Baryun wrote: On 9/9/13, Owen DeLong o...@delong.com wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. Please define what is the IETF scope? IMHO, IETF is scoped to do with IPv6 devices requirements and implementations. Do you think there is a RFC that considers thoes requirements? The queue for dicussion of this point is closed. If there needs to be an appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc 2. So watered down in its language as to use many words to say nearly nothing. No, the draft says things, I think if you read nothing that you did not read then. If you read, then what is your definition of saying nothing? 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. I think this was mentioned clearly in the draft, which readers can understand. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. IMHO, the LC is not for consensus, but it is for us to send the IESG our comments, and then they decide what is the IETF decision. Why is there such a push to do this? Why is there a push to water-down it? I still was not convinced by your argument. However, Lorenzo comments should be considered by the draft as the authors are working on. AB ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli joe...@bogus.com wrote: The queue for dicussion of this point is closed. If there needs to be an appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc To clarify - you're talking only about the discussion on whether this draft is in scope? Or are you saying that you consider all discussion of this document in this IETF last call settled?
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Joel, Please see inline. Cheers, Med -Message d'origine- De : joel jaeggli [mailto:joe...@bogus.com] Envoyé : mardi 10 septembre 2013 06:42 À : Lorenzo Colitti; BOUCADAIR Mohamed IMT/OLN Cc : v6...@ietf.org WG; IETF Discussion; BINET David IMT/OLN Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile- 04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On 9/9/13 4:24 AM, Lorenzo Colitti wrote: On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: The document explicitly says This document is not a standard. since version -00. __ __ What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. So this is a problem, and part of the reason I had enough concern about this document to not take it forward. being genereous the consensus on this document is pretty rough. if the outcome doesn't include the consent of implementors it's not very good advice. [Med] Joel, the intent of the document is clear: the goals and scope are unchanged since the individual submission. You can read the following in the introduction: This document specifies an IPv6 profile for mobile devices listing specifications produced by various Standards Developing Organizations (in particular 3GPP and IETF). The objectives of this effort are: 1. List in one single document a comprehensive list of IPv6 features for a mobile device, including both IPv6-only and dual-stack mobile deployment contexts. These features cover various network types such as GPRS (General Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11 network. 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. 3. Vendors to be aware of a set of features to allow for IPv6 connectivity and IPv4 service continuity (over an IPv6-only transport). Operators will use this profile (or some part of it (context-based: ipv6-only, DS, CPE model, etc.)) for further discussion with their vendors. We are not changing that process. This document is a contribution to have non broken IPv6 implementations. For instance, our device partners will see in our 500 pages device requirements document (OGDR) pointers to this profile document. So adding the text suggested by Lorenzo is fine by me. This is the change added to my local copy: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers from vendors who are happy with the content of the document ... but in the meantime I have two reviewers from the same company: one of them suggested to make some edits to enhance the document while the other reviewer have some concerns. The concerns of the second reviewer were addressed and changes were added to my local copy. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformance with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. If not all vendors, then what about some vendors? Is it a goal of this document to have consensus from some implementors? Or is consensus from implementors a non-goal?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.com wrote: * NEW:* * * 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. It uses the normative keywords defined in the** ** previous section only for precision. * * That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead. How about changing is not required in order to claim conformance with IETF standards for IPv6 to is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6?
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re, I have considered that Lorenzo. is not required to deploy IPv6 would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 08:49 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: NEW: 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. It uses the normative keywords defined in the previous section only for precision. That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead. How about changing is not required in order to claim conformance with IETF standards for IPv6 to is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.com wrote: I have considered that Lorenzo. “is not required to deploy IPv6” would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. 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.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers Are reviews still appropriate? I think there are a lot of things left to say about this document beyond the high-order points we're discussing at the moment. If I write them down, will they be considered or will the answer be that it's too late to accept feedback because the document is already in last call?
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
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, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 09:21 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: I have considered that Lorenzo. is not required to deploy IPv6 would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. 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.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.com wrote: 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 need to support IPV4V6 if all you need to do is work on an IPv6-only network. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. you don’t have a means to make work broken applications when IPv6-only is enabled Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? 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 is not about IPv6-only mode. That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. But someone taking this document as a guide to what needs to be implemented to deploy IPv6 would consider them to be incomplete or broken implementations. Such a person might look at the 34 requirements and just give up, when in fact such an implementation is perfectly capable of doing IPv6 today.
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 11:27 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: 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 need to support IPV4V6 if all you need to do is work on an IPv6-only network. [Med] UEs that will provided with IPv6-only or DS is up to the provider. Note also that the requirement is worded to let the decision to each provider. The document explicitly says: This allows each operator to select their own strategy regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP- Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends on the cellular network configuration. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff [Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features. , without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. [Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That's not fair. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. [Med] This document is not a standard. This document does not ambition to have the same level as RFC1122. you don't have a means to make work broken applications when IPv6-only is enabled Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). [Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode. The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. [Med] Are you saying this is a MUST? if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? [Med] How many device support IPv6 today? We can play that game endlessly... 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 is not about IPv6-only mode. [Med] What is wrong in that text? Can we focus on the exact text change? That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. [Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones...while this is not true. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. [Med] I'm sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 8:12 PM, mohamed.boucad...@orange.com wrote: *[Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features.* Sorry - what I meant is: most of the text in the document says that devices MUST support this, SHOULD support that, SHOULD support the other, but not much time saying why. ** *[Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That’s not fair.* Isn't it? For example, look at RFC1122 and compare it to this document. Compare the percentage of text used to state requirements and the percentage of text used for rationale. If anything, an informational document should have fewer requirements and more rationale than a standard, not the other way around. Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). *[Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode.* Then change the requirement to say vendor applications must not be IPv4-only. At least it's a reasonable request (though one that's unlikely to happen before IPv6 is widely deployed). All apps is not a reasonable request. * * The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. ** *[Med] Are you saying this is a MUST?* I don't think this document should be a bunch of MUST this, SHOULD that, MUST the other. As regards 464xlat, I think that shipping an IPv6-only phone without 464xlat or something equivalent equals shipping a phone that's not useful, and that doesn't happen in the real world. So if you want to ship IPv6-only, you need something like 464xlat. Does it follow that a phone MUST implement 464xlat? No, it does not. ** *[Med] How many device support IPv6 today? We can play that game endlessly...* Not really, because upwards of 30 million mobile devices are using IPv6 every day on Verizon Wireless alone. See: http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13462152832-2.pdf http://www.worldipv6launch.org/measurements/ Those phones do not meet the requirements of this draft. They violate at least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs. According to the text in -05, that means they cannot connect to an IPv6-only or dual-stack wireless network including 3GPP cellular network and IEEE 802.11 network). I know that text won't be there in the next version, but the point I'm trying to make is that the document made it all the way to IETF last call while claiming that largest deployment of IPv6 in a mobile network was not possible. I don't want that to be the message coming out of this document. 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 is not about IPv6-only mode. *[Med] What is wrong in that text? Can we focus on the exact text change?* The operators proposing this profile believe that the support of a subset of the features included in this protocol may lead to degraded level of service. * * Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. ** *[Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones…while this is not true.* Per the document, if you implement IPv6 tethering you MUST implement a full RFC 6204 router in the device (req#28). * * ** I don't consider these to be degraded service, I consider them to be a lot better than what we have today. *[Med] I’m sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode. * I stand by my opinion that IPv6 tethering without a full RFC6204 implementation and that 464xlat without a local DNS64 implementation are not degraded.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/9/13 1:06 PM, Owen DeLong wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1.Out of scope for the IETF. AD here... let's put this one to bed. there are existance proof(s) of previous work in this area and others that covers similar ground. I don't believe that this is out of scope for the WG or the IETF, Neither did the previous AD. So... Focus on the contents. 2.So watered down in its language as to use many words to say nearly nothing. 3.Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. Why is there such a push to do this? Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med *De :* Lorenzo Colitti [mailto:lore...@google.com http://google.com/] *Envoyé :* lundi 9 septembre 2013 13:24 *À :* BOUCADAIR Mohamed IMT/OLN *Cc :* Dave Cridland; v6...@ietf.org mailto:v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion *Objet :* Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. */[Med] I made this change:/* */ /* */OLD:/* */ /* This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). */ /* */New:/* */ /* This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). */ /* 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? */[Med] I used the same wording as in RFC6092. The change is as follows:/* */ /* */OLD:/* */ /* This document is not a standard. It uses the normative keywords only for precision. */ /* */NEW:/* */ /* 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. It uses the normative keywords defined in the previous section only for precision. */ /* ___ v6ops mailing list v6...@ietf.org mailto:v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
From: Owen DeLong o...@delong.com To: Vízdal Aleš ales.viz...@t-mobile.cz Cc: v6...@ietf.org WG v6...@ietf.org; IETF Discussion ietf@ietf.org; Dave Cridland d...@cridland.net Sent: Tuesday, 10 September 2013 7:04 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt(InternetProtocol Version 6 (IPv6) Profile for 3GPP MobileDevices) toInformational RFC snip Why is there such a push to do this? [av] Because the Operators are currently missing such a document, so they went to the IETF to work on one. As written in the document the number of well behaving IPv6 capable mobile devices is not very high at the moment. This initiative is intended to help the developers. Is there any reason a cellphone shouldn't just meet the standard requirements like any other router? I agree with this view. I don't think there is anything that special about portable computers that that can make phone calls (mobile multihomed hosts*). It seems to me the only thing special here is that one of the links the MMHH has is a 3G/4G etc. one, and the operators of those networks have certain views on how those networks should operate. That would seem to me to give them the ability to select what parameters are chosen for IPv6 operation over their networks e.g., stateful DHCPv6 only, prefix lifetimes of 2/1 hours etc., but to extend that to listing IPv6 protocol implementation requirements across the whole MMHH seems excessive and unnecessary. Surely the existing IPv6 node requirements RFC is enough for that? Regards, Mark. *The Rapid Rise of the Mobile Multihomed Host, and what it might mean to the network http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. 2. So watered down in its language as to use many words to say nearly nothing. 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. Why is there such a push to do this? Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:24 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document is not a standard. It uses the normative keywords only for precision. NEW: 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. It uses the normative keywords defined in the previous section only for precision. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Sep 9, 2013, at 13:36 , Vízdal Aleš ales.viz...@t-mobile.cz wrote: Please see inline. Ales From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, September 09, 2013 10:07 PM To: mohamed.boucad...@orange.com Cc: v6...@ietf.org WG; Dave Cridland; IETF Discussion Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. [av] Strongly disagree. The IETF as the IPv6 owner is the right place to define what qualifies a device to be IPv6 compliant. (a mobile one in this case) This is intended as informational, not a standards track document, so it does not do that. 2. So watered down in its language as to use many words to say nearly nothing. [av] Hints on how the text shall be changed are always welcome. If you don't leave it watered down, it becomes a standards track document. There appears to be even greater resistance to that, so I don't see such a document as being likely to achieve any greater degree of consensus. 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. [av] The reader will learn what must/should/may be implemented in a mobile device to support IPv6. Except that this document is clearly marked as informational and not standards track and there fore the application of must/should/may to it is seemingly rather absurd. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. [av] Med has posted an answer on this one earlier in the thread. I was not entirely satisfied with his answer. Why is there such a push to do this? [av] Because the Operators are currently missing such a document, so they went to the IETF to work on one. As written in the document the number of well behaving IPv6 capable mobile devices is not very high at the moment. This initiative is intended to help the developers. Is there any reason a cellphone shouldn't just meet the standard requirements like any other router? Owen Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:24 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Ray, Please see inline. Cheers, Med -Message d'origine- De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Ray Hunter Envoyé : vendredi 6 septembre 2013 16:33 À : Gert Doering Cc : v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile- 04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Gert Doering wrote: Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster I know I'm formally a couple of days late on the WGLC (work!). [Med] This was an IETF LC not WGLC... I agree with Lorenzo. And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and REQ#34 be enforced by a manufacturer (during compliance testing)? [Med] This can be part of the test campaigns to assess the behavior of applications shipped with the device. This is in particular important for the applications made available by the device vendor itself. For example, our teams tested a device which can get IPv6 connectivity...but the user cannot use the store from that vendor to get applications in IPv6-mode. There are other applications which make use of IPv4 address literals, etc. The requirements is valid for applications dev'ed by the vendor or a third-party.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti lore...@google.com wrote: I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 §4.2.2] But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. No, the IETF has published profile documents in a number of cases. One could argue that RFC 1122 and RFC 1123 are both profile documents, actually, but there are other specific examples, like the Lemonade profile, for example. I suspect, however, that this document is actually a standard, or intended as one. There's discussion about conformance, about testing for conformance, and so on, which suggests that an operator (in particular) might treat any resultant RFC as a standard without regard for its IETF status. That's a concern, though in practise, if this is to be a document detailing what operators want, I'd be happier that it's published through the IETF as Informational than not published at all - and in any case, no amount of pretence will alter the fact that people will treat any RFC as a standard if it suits them anyway. What may be more useful, though, would be to get more stakeholders involved in a commonly agreed profile, and supercede this. Dave.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Browsing through the document I am not sure how much weight is carries when an IETF working group defines what 3GPP networks should be doing, particularly when talking about protocols the 3GPP has not really expressed an opinion about. From the document it is unclear to me what requirements are directly taken from 3GPP specifications and what additional requirements the authors have added. On 09.09.2013 13:19, Dave Cridland wrote: On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti lore...@google.com mailto:lore...@google.com wrote: I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: AnInformational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 §4.2.2] But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. No, the IETF has published profile documents in a number of cases. One could argue that RFC 1122 and RFC 1123 are both profile documents, actually, but there are other specific examples, like the Lemonade profile, for example. I suspect, however, that this document is actually a standard, or intended as one. There's discussion about conformance, about testing for conformance, and so on, which suggests that an operator (in particular) might treat any resultant RFC as a standard without regard for its IETF status. That's a concern, though in practise, if this is to be a document detailing what operators want, I'd be happier that it's published through the IETF as Informational than not published at all - and in any case, no amount of pretence will alter the fact that people will treat any RFC as a standard if it suits them anyway. What may be more useful, though, would be to get more stakeholders involved in a commonly agreed profile, and supercede this. Dave.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland d...@cridland.net wrote: I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 §4.2.2] Fair enough. But the document then proceeds to use RFC2119 normative language, which is not appropriate because it's not a standards track document. Normative language is not appropriate for informational documents; there was a big discussion over that for RFC6092, and that ended up being published with a note well saying, this document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. You may note that no such conformance is not required text is present here. This is at best confusing and at worst misleading. If this document were to plainly state that it simply represents the set of features that a particular set of operators feels is necessary for IPv6 deployment on mobile networks, but that it is not an IETF standard, and compliance with it is not necessary to deploy IPv6 on mobile networks or to claim conformance with IETF standards, I would have no objection to it. But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. No, the IETF has published profile documents in a number of cases. One could argue that RFC 1122 and RFC 1123 are both profile documents, actually, but there are other specific examples, like the Lemonade profile, for example. I had written a few paragraphs explaining why this document and RFC 1122 / 1123 are not even remotely comparable, but I think that's beside the point of this discussion. I think the main point is that RFC 1122/1123 are standards and this document is not intended to be one. I suspect, however, that this document is actually a standard, or intended as one. There's discussion about conformance, about testing for conformance, and so on, which suggests that an operator (in particular) might treat any resultant RFC as a standard without regard for its IETF status. Absolutely. Such an operator might well decide to say that the requirements for all devices on their network are captured in this standard, and the IETF would have nothing to say about it. But the point is that it would be the operator setting the requirements, not the IETF. The IETF cannot set requirements in an informational document. That's a concern, though in practise, if this is to be a document detailing what operators want, I'd be happier that it's published through the IETF as Informational than not published at all - and in any case, no amount of pretence will alter the fact that people will treat any RFC as a standard if it suits them anyway. Sure, but if said document said this is not a standard in so many words, then that would be a difficult position to convince others of.
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Lorenzo, The document explicitly says This document is not a standard. since version -00. What additional statement you would like to see added? Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:01 À : Dave Cridland Cc : BOUCADAIR Mohamed IMT/OLN; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland d...@cridland.netmailto:d...@cridland.net wrote: I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 §4.2.2] Fair enough. But the document then proceeds to use RFC2119 normative language, which is not appropriate because it's not a standards track document. Normative language is not appropriate for informational documents; there was a big discussion over that for RFC6092, and that ended up being published with a note well saying, this document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. You may note that no such conformance is not required text is present here. This is at best confusing and at worst misleading. If this document were to plainly state that it simply represents the set of features that a particular set of operators feels is necessary for IPv6 deployment on mobile networks, but that it is not an IETF standard, and compliance with it is not necessary to deploy IPv6 on mobile networks or to claim conformance with IETF standards, I would have no objection to it.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. ** ** What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformance with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:24 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: The document explicitly says This document is not a standard. since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document is not a standard. It uses the normative keywords only for precision. NEW: 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. It uses the normative keywords defined in the previous section only for precision.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Owen, do you have any technical objection to raise about this document, or are you just replying because you like the sound the keys make as you type? The working group adopted the document, so it's too late to object that the working group shouldn't be working on it. You can object by pointing out that it doesn't do what it says it's going to do, but if so you'd need to actually make the case that it doesn't do that, not just assert that it doesn't do that. Your point about RFC 2119 language has been addressed, so there's no sense in re-raising it unless you have some specific objection to state about the way in which it was addressed (I'm not satisfied is not a specific objection). Etc.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
It has been pointed out to me that I went overboard in my response to you. I will state what was obvious to me as I wrote my response, but may not have been obvious to other readers: I am not the responsible AD for v6ops. My response was that of a participant in v6ops. I didn't find what you wrote helpful, but what I like isn't particularly important in this case, unless you decide it is. I did not intend to suggest that you should not criticize this document. I would like to see more substance to the criticism. But the way I expressed that desire was (a) overly sarcastic and (b) not constructive, and I apologize for that.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/9/13 4:24 AM, Lorenzo Colitti wrote: On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. __ __ What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. So this is a problem, and part of the reason I had enough concern about this document to not take it forward. being genereous the consensus on this document is pretty rough. if the outcome doesn't include the consent of implementors it's not very good advice. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformance with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo
Re: Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Gert Doering wrote: Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster I know I'm formally a couple of days late on the WGLC (work!). I agree with Lorenzo. And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and REQ#34 be enforced by a manufacturer (during compliance testing)? -- Regards, RayH
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Lorenzo Answers below David De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Lorenzo Colitti Envoyé : mercredi 4 septembre 2013 10:04 À : BOUCADAIR Mohamed IMT/OLN Cc : v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network. This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. [[david]] Do you mean that the current status regarding IPv6 support in devices is fine and that there is no need for other features in mobile devices ? Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. [[david]] OK Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.com wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network. This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.com wrote: ** But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.com wrote: Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? ** *[Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.* Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That’s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. *[Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear.* True. The document does define cellular device as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than device here? It's confusing, because device usually refers to any engineered object. Maybe use the word sharing or tethering in the name? *[Med] There is running code for several features listed in this document. Because we don’t have “decent” implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!* But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works.
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Lorenzo, We already answered to several of the points in previous discussions (during the call for adoption and also during the WGLC). We also made some changes in the last version to make the language clear (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05): it is about ** a ** profile for mobile devices. The scope covers mobile hosts, hosts with wan sharing capabilities (e.g., mobile CPE) and the also those with wi-fi interfaces. The motivations for this effort and scope are explained in the introduction. Cheers, Med De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Lorenzo Colitti Envoyé : mardi 20 août 2013 11:39 À : IETF Discussion Cc : v6...@ietf.org WG Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.orgmailto:iesg-secret...@ietf.org wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, See inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mercredi 4 septembre 2013 10:51 À : BINET David IMT/OLN Cc : BOUCADAIR Mohamed IMT/OLN; v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.commailto:david.bi...@orange.com wrote: But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. [Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all. Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? [Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear. There are plenty deployments relying on the mobile networks to provide broadband services. Device vendors people involved in discussion with operators in this field are quite aware of this model. You can check for instance: http://www.orange.tn/fixe-et-internet/pid382-la-flybox-orange.html Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document? [Med] There is running code for several features listed in this document. Because we don't have decent implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mercredi 4 septembre 2013 11:25 À : BOUCADAIR Mohamed IMT/OLN Cc : BINET David IMT/OLN; v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. [Med] What statement you would like to see added? Thanks. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. [Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all. I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. [Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear. True. The document does define cellular device as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than device here? It's confusing, because device usually refers to any engineered object. Maybe use the word sharing or tethering in the name? [Med] The use of cellular device is governed by the definition included in the document: o 3GPP cellular host (or cellular host for short) denotes a 3GPP device which can be connected to 3GPP mobile networks or IEEE 802.11 networks. o 3GPP cellular device (or cellular device for short) refers to a cellular host which supports the capability to share its WAN (Wide Area Network) connectivity. and ... This section focuses on cellular devices (e.g., CPE, smartphones or dongles with tethering features) which provide IP connectivity to other devices connected to them. In such case, all connected devices are sharing the same 2G, 3G or LTE connection. In addition to the generic requirements listed in Section 2http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#section-2, these cellular devices have to meet the requirements listed below. Because I'm naively assuming the reader interprets this term according to the definition provided in the document, I don't see what is confusing in such wording. [Med] There is running code for several features listed in this document. Because we don't have decent implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!! But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. [Med] This document is not a standard. This is explicitly mentioned in the document.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Dear Abdussalam, Many thanks for your review and suggestions. The changes you proposed have been integrated in -05 (see http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-05). As for your question about IP mobility, this is not relevant in the context of this document. Mobility is managed following 3GGP specific procedures. Cheers, Med De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Abdussalam Baryun Envoyé : mardi 27 août 2013 13:05 À : ietf Cc : v6...@ietf.org; i...@ietf.org Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 I support the draft, thanks, below are my comments, Overall The draft is about 3GPP Mobile Devices but the draft has no normative reference to such device. The title of the draft SHOULD mention that it is general profile or a proposal, where the abstract says *specifies an IPv6 profile* which means not general, so the title SHOULD say *An IPv6 profile*. Also the draft does not consider Mobile IP issues nor RFC5213 into requirements. From the doc the reviewer is not sure does the draft consider MANET issues or not needed for such devices or such connections? Abstract This document specifies an IPv6 profile for 3GPP mobile devices. AB suggest this document defines an IPv6 profile The document is missing an applicability statement section, which may be found in one paragraph in section 1.1, but the reviewer would like more details because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG iesg-secret...@ietf.orgmailto:iesg-secret...@ietf.org wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' draft-ietf-v6ops-mobile-device-profile-04.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.orgmailto:ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to i...@ietf.orgmailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D.
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
At 02:43 04-09-2013, mohamed.boucad...@orange.com wrote: [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. There aren't any minutes for that WG session. Is there a formal request for guidance from the working group and is it possible to verify that there wasn't any comment at that time? I took a quick look at the draft. I note that, for the telechat, Spencer Dawkins and Pete Resnick are paid by the document. :-) It would be interesting to have an approximate page count of the number of pages to review. In the Introduction Section: One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices. I read the above sentence several times. My understanding is that having non-broken IPv6 implementations is a hurdle. The way to fix that would be for mobile operators to have broken IPv6 implementations. :-) In Section 1.2: It uses the normative keywords only for precision. My reading of the word precision is that it is the ability of a measurement to be consistently reproduced. I don't see how special language fits that. My guess is that the intent of that sentence got lost in translation ( http://www.youtube.com/watch?v=pCB7cxv-Ey8 ). In Section 2: REQ#3: The cellular host MUST comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-Context type. Is the above in accordance with RFC Editor guidelines? REQ#6: The device MUST support the Neighbor Discovery Protocol ([RFC4861] and [RFC5942]). In which RFCs are the Neighbor Discovery Protocol defined? I am asking this question as the above does not match the information provided by the RFC Editor. REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host. How would the capitalized should be read in the above? The guidance in RFC 2119 does not look applicable here. In Section 5: REQ#34: Applications using URIs MUST follow [RFC3986]. For example, SIP applications MUST follow the correction defined in [RFC5954]. The above says that applications must follow RFC 3986 and then provides an example with a capitalized must for RFC 5954. The Security Considerations Section references draft-ietf-v6ops-rfc3316bis-04. That draft contains exhaustive security considerations. This draft doesn't say much about security considerations. Regards, -sm
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Erik, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Erik Kline Envoyé : jeudi 22 août 2013 13:22 À : Owen DeLong Cc : v6...@ietf.org; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile- 04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC REQ 1: 6434 5.9.1 is already a MUST. This does not need to be repeated. [Med] Because some requirements are stronger in this document than what is documented in RFC6434, we had two way to implement this in the document: (a) Indicate RFC6434 must be supported with the exceptions in the language for some requirements listed in this document. (b) Call out explicitly the requirements from RFC6434 that are mandatory + indicate which requirements are stronger than rfc6434. We decided to go for (b) as it provides a comprehensive list of requirements for 3GPP mobile devices grouped in one single document. IMHO, this is just a matter of presentation. This rationale is explained in the introduction. 6434 5.8 is already a MUST. Unless you want to make multipart ICMP a MUST (why?) as well, this too can be removed. REQ 6: re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so this MUST appears stronger. Bizarre, though, I never noticed that ND SHOULD before. [Med] The language is stronger compared to the SHOULD in Section 5.2 of RFC6434. REQ 10: this reads kind weird. In REQ 9 you require 6106 support, but in REQ 10 you say if 6106 is not supported. I think you mean something like if the network to which the mobile node is attaching does not support 6016. [Med] Yes, agree. As mentioned in the document, Some of the features listed in this profile document require to activate dedicated functions at the network side. This will be fixed.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
REQ 1: 6434 5.9.1 is already a MUST. This does not need to be repeated. 6434 5.8 is already a MUST. Unless you want to make multipart ICMP a MUST (why?) as well, this too can be removed. REQ 6: re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so this MUST appears stronger. Bizarre, though, I never noticed that ND SHOULD before. REQ 10: this reads kind weird. In REQ 9 you require 6106 support, but in REQ 10 you say if 6106 is not supported. I think you mean something like if the network to which the mobile node is attaching does not support 6016.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
I also agree with James and Lorenzo. Owen On Aug 20, 2013, at 4:58 PM, james woodyatt j...@apple.com wrote: On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote: [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt j...@apple.com core os networking ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.org wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote: [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt j...@apple.com core os networking
