Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Stephen, Please see inline. Cheers, Med -Message d'origine- De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Envoyé : vendredi 6 juin 2014 17:59 À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Hi Med, On 06/06/14 12:41, mohamed.boucad...@orange.com wrote: [Med] I'm not sure about this Ted. There are other initiatives that try to solve the issue for particular use cases, see for instance this effort for HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The rationale of the host identifier scenarios document is to group all use cases suffering from the same problem instead of focusing on one single case. This allows having a big picture view of the problem space. I think XFF is actually a good example of why we ought not adopt this work. [Med] I provided Forward as an example to illustrate there is a need to have a big picture view rather than focusing on specific use case. This draft does not suggest to adopt XFF or Forward at all. There is a need to understand the problem space and identify deployment scenarios where encountering complications. XFF is widely deployed already but somewhat flakey in terms of interop so the authors of the above draft aimed to produce a spec that just addressed interop. (*) That was adopted by an area WG without (IMO) ever really considering the privacy implications, and definitely without any effort having been made to develop a more privacy-friendly mechanism (which could have been done, again IMO) to solve what were the claimed use-cases. [Med] Wouldn't be this effort an opportunity to promote those solutions you are advocating for? The proxy use case (not limited to HTTP) is listed as a typical scenario. If there are other better solutions that solves your privacy concerns, why not documenting them? By the time it got to the IESG that was in practice unfixable and after some fairly painful discussions it ended up with 4 abstain ballots, including mine. [1] (For those who quite reasonably don't need to care about IESG balloting, an abstain means approximately yuk.:-) Of course that all also pre-dated BCP188 and the last year's shenanigans so I'd hope we have learned to not keep doing that. I'd be delighted if those who could get a better solution implemented/deployed were to attempt to try to address the privacy issues with XFF but it seems that at least in that case relevant folks don't care (sufficiently;-) deeply about our privacy to go do that. S. [1] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ (*) To be clear: I think the authors were genuinely just trying to fix what they saw as an interop problem. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Re-, Please see inline. Cheers, Med -Message d'origine- De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc : ietf-privacy@ietf.org; Internet Area; Joe Touch Objet : Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) [Med] FWIW, this draft does not hint solutions but it aims to describe scenarios with problems. I understand you have concerns with privacy but this is not an excuse to abuse and characterize this effort as stupid. Privacy implications should be assess on a per use case basis (see for example cases where all involved entities belong to same administrative entity). Furthermore, the document (including -04) says the following : the document does not elaborate whether explicit authentication is enabled or not. Adding new identifiers with privacy impact, as proposed here, is quite different. [Med] I have already clarified this point: the scenario draft does not propose any identifier! S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Ted, As far as this document is concerned, we are open to address technical concerns. It will be helpful if these concerns are specific enough and hopefully in reference to http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05. Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3. Cheers, Med -Message d'origine- De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Ted Lemon Envoyé : jeudi 5 juin 2014 23:27 À : Brian E Carpenter Cc : ietf-privacy@ietf.org; int-a...@ietf.org; Stephen Farrell Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Re-, Please see inline. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : vendredi 6 juin 2014 12:48 À : BOUCADAIR Mohamed IMT/OLN Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org; Stephen Farrell Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On Jun 6, 2014, at 4:11 AM, mohamed.boucad...@orange.com wrote: Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3. The document hasn't been adopted yet, so we can avoid security issues simply by not adopting it. [Med] I'm not sure about this Ted. There are other initiatives that try to solve the issue for particular use cases, see for instance this effort for HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The rationale of the host identifier scenarios document is to group all use cases suffering from the same problem instead of focusing on one single case. This allows having a big picture view of the problem space. Talking about what the security considerations section might do to ameliorate the harm isn't in scope yet. First we need to decide whether there is more harm than good done by adopting and publishing the document! [Med] Fair enough. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] NAT Reveal / Host Identifiers
Dear all, FWIW, the latest version is http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05. There is a section about privacy that basically refers to http://tools.ietf.org/html/rfc6967#section-3. Identifying other privacy-related concerns that are not discussed in RFC6967 will be helpful. Comments are more than welcome. Cheers, Med -Message d'origine- De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de Hannes Tschofenig Envoyé : jeudi 5 juin 2014 09:06 À : ietf-privacy@ietf.org Objet : [ietf-privacy] NAT Reveal / Host Identifiers If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with draft-boucadair-intarea-host-identifier-scenarios-04 currently in a call for adoption). I had raised my concerns several times now on the mailing list and during the meetings. Ciao Hannes Original Message Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Date: Thu, 5 Jun 2014 04:20:56 + From: Suresh Krishnan suresh.krish...@ericsson.com To:Internet Area int-a...@ietf.org Hi all, This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- scenarios-04 This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19. Regards Suresh Juan Carlos ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] NAT Reveal / Host Identifiers
Re-, I have two comments: (1) If one missed the following sentences in -04 Below is listed as set of requirements to be used to characterize each use case (discussed in Section 3): and Once this list is stabilized, each use case will be checked against these requirements., then the requirements list can be seen as odd. I agree the wording is not so that clear. The initial intent was to identify the ones from the list that apply for each use case. That effort was abandoned in -05 to focus on the description of the use cases where problems are encountered. (2) Privacy concerns are not ignored. A section is present in the draft to recall some privacy-related issues: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05#section-15. If there are other concerns not already covered, it will be relay helpful to explicit them. The document does not include any solution discussion but focuses only on the description of deployment use cases where problems are encountered. Cheers, Med -Message d'origine- De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Envoyé : jeudi 5 juin 2014 15:24 À : BOUCADAIR Mohamed IMT/OLN; Hannes Tschofenig; int-a...@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers Hi Med, On 05/06/14 14:11, mohamed.boucad...@orange.com wrote: Hi Stephen, You referred in your message to an old version. That was the one for which the adoption call was issued. I guess just a typo. I looked quickly at the diff between 04 and 05 and my conclusion remains the same and most of my comment I think still apply, despite the removal of the odd requirements section. S. The latest version of the document does not include any requirement, it is only an inventory of use cases when problems are encountered. The latest version is available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- scenarios-05. Some of these use cases are restricted to a single administrative domain while others span multiple domain. Privacy concerns are really important; these are discussed in RFC6967. The use cases are not theoretical ones, but are those where complications arise. Explicitly calling out security risks (including privacy ones) will benefit to this work. It is really helpful to understand the use cases and call out any potential risks rather than speculating without actual understanding of what the problem is. This document is the opportunity to record security and privacy concerns that apply to these use cases. The content of the document is not frozen. Adopting it as a WG document will undoubtedly enrich it and benefit from other perspectives that those of the authors. Cheers, Med -Message d'origine- De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig; int-a...@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with draft-boucadair-intarea-host-identifier-scenarios-04 currently in a call for adoption). I had raised my concerns several times now on the mailing list and during the meetings. I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. For something like this, the onus ought IMO be on the proposers to have done that work before asking for adoption. Based on the draft, they clearly have not done that. We could also ask to add more use-cases: use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell data that's even more fine-grained than clickstreams use-case#14: expose your n/w internals to help on path attackers use-case#15: track hosts from which people emit dangerous utterances use-case#16: block hosts from which people emit dangerous utterances use-case#17: charge me more for using two of my computers in my house The set of use-cases presented very much contradicts the explicit claim in the draft that no position is being taken as to the merits of this. IMO that argues strongly to not adopt this. One could also comment on the requirements that seem to require new laws of physics or are otherwise pretty odd: REQ#1: seems to require knowing from packets passing by that a device is a trusted device (and REQ#15 says that can be done with 16 bits;-) Hmm... are those qubits maybe? REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without a flag day. Hmm... REQ#6: says this is a transport thing. Eh, why ask INT-AREA? REQ#10+REQ#11: MUST be intradomain only but MUST also be inter domain. Hmm... REQ#18: receiver MUST enforce policies like
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
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
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
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
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
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
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
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
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
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: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Dear Robert, I updated the document to cover the comments you raised. You can check the diff available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06 Cheers, Med De : dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] De la part de Robert Sparks Envoyé : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Nits/editorial comments:
RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? Med: I'm not aware of any; but if there is one we can cite it. If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Med: Will consider that option if you think this is really needed. Nits/editorial comments:
RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Robert, Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: (1) OLD: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? Cheers, Med -Message d'origine- De : Bernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 Robert: The reason to allow this is that otherwise client A will be unnecessarily reconfigured many times. (It is also possible that a client might Renew on its own just as this is happening and thus it can also be removed from the Reconfigure.) I think the text should be cleaned up to indicate that allowing removal of already reconfigured clients is recommended (to prevent unnecessary reconfigures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a new message (new XID). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucad...@orange.com Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools .ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). If I understand you correctly, you need more than just changing a parenthetical e.g.. I think you're saying that you are constraining the message changes to be such that if anything earlier in the retransmission sequence succeeded, the request in the retransmission would also have succeeded. But why do you need that much complexity? Do you have it already with any other request? Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? Med: I'm not aware of
RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Dear Peter, The new version is now available online. A diff is available here: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-upnp-igd-interworking-08. Thank you again for the review. Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : mercredi 10 avril 2013 18:47 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-pcp-upnp-igd- interworking@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Med, That looks great. Thanks for accommodating my concern. Kind regards, -Peter -Original Message- From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] Sent: Wednesday, April 10, 2013 12:49 AM To: Peter Yee; draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Dear Peter, I changed the text as follows: OLD: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response. If a short lifetime error is returned, the IGD-PCP IWF MAY re-send the same request to the PCP Server after 30 seconds. If a PCP error response is received, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. NEW: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response: 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend the same request to the PCP Server after 30 seconds without relaying the error to the UPnP Control Point. The IGD-PCP IWF MAY repeat this process until a positive answer is received or some maximum retry limit is reached. When the maximum retry limit is reached, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. 2. If a long lifetime error is returned, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. Better? Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : mardi 9 avril 2013 20:58 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-pcp-upnp-igd- interworking@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Med, Thanks for the swift response to my review. See my one reply inline. Kind regards, -Peter Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. [Med] The basic behavior is to relay the received error to the UPnP CP. For the short-lifetime errors, the IWF may decide to resend the request and not relay those errors immediately to the UPnP CP. The number of repeats is not specified here as it can be implementation-specific. Your explanation is fine. I just found the wording If a PCP error response is received to sound ambiguously as if the short-lifetime errors were not a subset of PCP errors.
RE: Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06
Dear Peter, The two OLD nits are already fixed in my local copy. As for the new one, I'm generating the references automatically. The RFC Editor can fix this if needed. Thanks. Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : samedi 6 avril 2013 01:56 À : draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen- ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-intarea-nat-reveal-analysis-06 Reviewer: Peter Yee Review Date: Apr-5-2013 IETF LC End Date: Mar-8-2013 IESG Telechat date: Apr-11-2013 This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits] It addresses most of the issues raised in my review of the -05 version. Two items from that review that I'm revisiting are noted below with text from the original review and responses from one of the authors (Med). We agreed that those two revisited items could be addressed in a subsequent revision; they are just recorded here for ease of reference. Major issues: Minor issues: Nits: [Old] Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Med: The point is: when several layers are used to inject a host_id, the device should check the same subset of information is revealed. For instance, there should not be conflict, etc. Then perhaps you could reword so that should reveal subsets of the same information becomes should reveal the same subsets of information at each layer? Section 4.9.2, 4th bullet item, 2nd sentence: Delete heavy and unless you want to explain what heavy means. Med: Establishing agreements with the owner of the address sharing function and owners of servers is heavy. This is already mentioned in the text. Perhaps you could replace heavy with burdensome. [New] In the references, there seem to be an excess of commas in a couple of places. Look for the string , , (comma space comma) and you'll see what I mean. The document titles start with an extra comma and end with one. Also in the references, for RFC 1413, put a space between the M. and the C. in Mike St. Johns' initials.
RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Dear Peter, I changed the text as follows: OLD: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response. If a short lifetime error is returned, the IGD-PCP IWF MAY re-send the same request to the PCP Server after 30 seconds. If a PCP error response is received, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. NEW: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response: 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend the same request to the PCP Server after 30 seconds without relaying the error to the UPnP Control Point. The IGD-PCP IWF MAY repeat this process until a positive answer is received or some maximum retry limit is reached. When the maximum retry limit is reached, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. 2. If a long lifetime error is returned, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. Better? Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : mardi 9 avril 2013 20:58 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-pcp-upnp-igd- interworking@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Med, Thanks for the swift response to my review. See my one reply inline. Kind regards, -Peter Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. [Med] The basic behavior is to relay the received error to the UPnP CP. For the short-lifetime errors, the IWF may decide to resend the request and not relay those errors immediately to the UPnP CP. The number of repeats is not specified here as it can be implementation-specific. Your explanation is fine. I just found the wording If a PCP error response is received to sound ambiguously as if the short-lifetime errors were not a subset of PCP errors.
RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Dear Peter, Thanks for the review. Please see inline. Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : mardi 9 avril 2013 10:13 À : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcp-upnp-igd-interworking-07 Reviewer: Peter Yee Review Date: Apr-08-2013 IETF LC End Date: Apr-08-2013 IESG Telechat date: Unknown Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues] This is a well-written draft describing how Universal Plug-and-Play Internet Gateway Devices interwork with NAT devices that use the Port Control Protocol. My review is mostly nits with otherwise minor issues. I have no problems with the general concept and enjoyed reading a clearly articulated concept. [Med] Thanks. Major Issues: None. Minor Issues: Section 4.1: is the mapping of the state variables between the UPnP IGD function and the PCP Client function really straightforward such that it does not need further description? I'm asking if an implementor would naturally gravitate to the correct use of the mapping without further instructions. Similar questions arise for Sections 4.2 and 4.3, although I believe those are more straightforward mappings. [Med] I don't think further explanation is needed. Pointers to the appropriate sections is included in Section 4.2 and Section 4.3. FWIW, there are already existing implementations of the IWF and no complaint was received from these implementers. Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. [Med] The basic behavior is to relay the received error to the UPnP CP. For the short-lifetime errors, the IWF may decide to resend the request and not relay those errors immediately to the UPnP CP. The number of repeats is not specified here as it can be implementation-specific. Nits: [Med] Fixed. General: replace re-send with resend. Page 3, 1st paragraph, 2nd sentence: insert a before each occurrence of UPnP. Page 4, section 3, 4th bullet: consider changing in to on or over. Page 4, 1st paragraph after the bullet items: bracket for instance with commas. Page 5, Figure 3: perhaps the LAN Side label could move a bit to the left to give it better delineation from the External Side label? Page 5, 1st paragraph after Figure 4, 2nd sentence: add a comma after [I-D.ietf-pcp-base]. Page 5, 2nd paragraph after Figure 4: change can not to cannot. Page 9, section 5, 3rd paragraph: insert the same way or the same before as any PCP Client. Page 9, section 5.1, 2nd paragraph: insert whether before it should. Page 9, section 5.1, 3rd paragraph: insert the before requesting UPnP Control Point. Page 10, Section 5.3, 2nd paragraph, 1st sentence: consider changing retrieve to extract. Page 11, 1st paragraph after bullet items, 2nd sentence: change to to than. Page 11, Section 5.6: swap the order of AddPortMapping() and AddAnyPortMapping() to match the order of the subsequent subsections. Page 11, Section 5.6.1, 2nd paragraph, 2nd sentence: change 30s to 30 seconds. Page 13, 1st paragraph, 4th sentence: change re-issue to issue; change new requested to different requested. Page 14, last paragraph: delete the comma after 4 times). Page 15, Section 5.7, 1st paragraph: append a comma after GetSpecificPortMappingEntry(). Page 15, Section 5.7, 3rd paragraph, 3rd sentence: replace 60s with 60 seconds. Page 15, Section 5.7, 3rd paragraph, last sentence: insert the before error code; change enquried to queried. Page 15, Section 5.8, 1st paragraph: insert , respectively before the period. Page 15, Section 5.8, 2nd paragraph, 2nd sentence: insert the before '606 Action Not'. Page 16, last paragraph, 2nd sentence: insert the before'731 PortMappingNotFound'. Page 19, 1st continuation paragraph, 1st sentence fragment: change of to in. Page 19, 1st continuation paragraph, 1st full sentence: consider swapping the positions of renew and periodically for readability. Page 19, Section 5.10, 1st paragraph, 2nd sentence: I prefer In particular to Particularly here. Page 19, Section 5.10, 3rd paragraph, 3rd sentence: replace signalled with signaled.
RE: Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
Dear Peter, Many thanks for the review. A new version with your suggested changes is now online. See the diff available here: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06. This version includes also the comments raised by SM here: http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html. Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : samedi 9 mars 2013 09:14 À : draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Cc : ietf@ietf.org; gen-...@ietf.org Objet : Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Document: draft-ietf-intarea-nat-reveal-analysis-05 Reviewer: Peter Yee Review Date: Mar-08-2013 IETF LC End Date: Mar-08-2013 IESG Telechat date: TBD Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues.] This draft catalogs and analyzes various means of supplying a host identifier to a remote server when Carrier Grade NAT or similar host obscuring technology is in use. General: There were sentences in the draft that I could not parse even in the context of surrounding text. That's primarily why I'm marking this draft as Ready with issues. These sentences are supplied below. Mostly, the document has a fair number of nits. The general concept is fine. General: hyphenate uses of address sharing when it used as an adjective. For example, address-sharing device. General: expand acronyms on first use except if they are really well known in our community (e.g., TCP/IP) or where they appear in the abstract. Examples of acronyms in need of expansion are HIP, XFF, Š. General: You will probably want to resolve Internet Draft references to something more permanent. General: The term broken should be replaced with something more specific or useful. I've made some suggestions below. Section 1, 2nd paragraph, last sentence: delete an before information. Section 1, 3rd paragraph: change are to include. Section 1, 3rd paragraph: change customers unsatisfaction to and customers' dissatisfaction. Section 2, 1st paragraph, 2nd sentence: delete an before extra. Change than to beyond. Section 2, 1st paragraph, 3rd sentence: replace this sentence with We call this information the HOST_ID. Section 2, 2nd paragraph: add a serial comma after subscriber. Serial comma use in the draft was inconsistent. Section 2, 3rd paragraph, 3rd sentence: I'm not sure why the HOST_ID and public IP address would be relatively unique. Assuming that HOST_IDs are unique amongst the hosts hidden behind the public IP address and the public IP address is unique, I would have thought that the combination was globally unique. My confusion may arise from the 4th sentence which is incomplete. Perhaps those two sentences could be rewritten for clarity. Section 2, 4th paragraph, 1st sentence: change put to conveyed. Section 2, 4th paragraph, 2nd sentence: change put to conveyed. Section 3, 2nd paragraph, 1st sentence: considering using identifiability instead of uniqueness. Section 3, 2nd paragraph, 2nd sentence: replace which with what. Section 3,1, 4th paragraph: add a comma after re-write. Change re-write to rewrite. Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Section 4.1.1, 1st paragraph, 1st sentence: delete an before information. Section 4.1.1, 1st paragraph, 3rd sentence: insert , there are after hence. Section 4.1.1, 4th paragraph, consider replacing with: Address-sharing devices using this solution would be required to indicate that out of band, possibly using a special DNS record. Section 4.1.2, 3rd paragraph, 2nd sentence: add a comma after scenario. Change broken to ill-advised. Section 4.2.1, 1st paragraph, 2nd sentence: add A at the beginning of the sentence. Section 4.2.1, 1st paragraph, 4th sentence: rewrite as This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a GRE key, an IPv6 Flow Label, etc. Section 4.2.1, 2nd paragraph: insert an before IP. Section 4.2.2, 1st paragraph, 1st sentence: change for to to. Section 4.2.2, 1st paragraph, 2nd sentence: use of the term filter in this sentence is not clear. Do you mean that that routes and middleboxes remove the IP options? Or that they remove packets with IP options? Or that they take other actions based on the presence of IP options? Please clarify. Section 4.2.2, 2nd paragraph: replace As a with In. Define host-hint somewhere. Is it meant to be equivalent to HOST_ID? Section 4.3.1, 3rd sentence: change their to its both places
RE: Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC
Dear Suresh, Having the warnings in the draft is good but having a pointer to a document including a fair and detailed risk analysis is also valuable and worth to be acknowledged. Having that pointer is an invitation to people who will deploy this mechanism (I know some of them who are planning to) to assess the validity of the claimed threats (and also to consider the alternatives listed in Section 3 of draft-dec-*). This is even encouraged given the intended track: experimental. Thanks. Cheers, Med -Message d'origine- De : Suresh Krishnan [mailto:suresh.krish...@ericsson.com] Envoyé : vendredi 8 juin 2012 22:14 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : ietf@ietf.org; i...@ietf.org; DUREL Sophie OLNC/NAD/TIP Objet : Re: Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC Hi Med, On 06/06/2012 08:04 AM, mohamed.boucad...@orange.com wrote: Dear Suresh, all, Even if the document includes several warnings about the unreliability of an RS-based mechanism, I suggest to add a pointer to the following document: http://tools.ietf.org/html/draft-dec-6man-rs-access-harmful-00. Is there something in particular that you think is missing from the lineid draft? The current warning text in lineid (and the reclassification to experimental) was arrived at after consultations with the the 6man chairs and the author of draft-dec. Thanks Suresh
RE: Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC
Dear Suresh, all, Even if the document includes several warnings about the unreliability of an RS-based mechanism, I suggest to add a pointer to the following document: http://tools.ietf.org/html/draft-dec-6man-rs-access-harmful-00. The document can be cited as an informative reference. Thanks. Cheers, Med -Message d'origine- De : ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] De la part de The IESG Envoyé : lundi 4 juin 2012 16:19 À : IETF-Announce Cc : i...@ietf.org Objet : Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'The Line Identification Destination Option' draft-ietf-6man-lineid-05.txt as Experimental 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.org mailing lists by 2012-06-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ballot/ No IPR declarations have been submitted directly on this I-D.
RE: [MBONED] Last Call: draft-ietf-mboned-64-multicast-address-format-01.txt (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard
Dear SM, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : mboned-boun...@ietf.org [mailto:mboned-boun...@ietf.org] De la part de SM Envoyé : dimanche 22 avril 2012 01:26 À : ietf@ietf.org Cc : mbo...@ietf.org Objet : Re: [MBONED] Last Call: draft-ietf-mboned-64-multicast-address-format-01.txt (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard At 15:33 18-04-2012, The IESG wrote: The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'IPv4-Embedded IPv6 Multicast Address Format' draft-ietf-mboned-64-multicast-address-format-01.txt as a Proposed Standard 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.org mailing lists by 2012-05-02. Exceptionally, comments may be Is there a write-up for this proposal? In Section 2: The format to build such addresses is defined in Section 3 for ASM mode and Section 4 for SSM mode. I suggest expanding ASM and SSM on first use. Med: Ok. Done in my local copy. Thanks. In Section 3: To meet the requirements listed in Appendix A.2 Wouldn't it be better to reference RFC 4291? Med: Do you mean, cite RFC4291 in addition to the ref to Appendix A.2? This field must follow the recommendations specified in [RFC3306] if unicast-based prefix is used or the recommendations specified in [RFC3956] if embedded-RP is used. Shouldn't that be a MUST? Med: Done. In Section 4: Flags must be set to 0011. Is that a requirement? Med: Yes, because as listed in Appendix A.2, we wanted to have an a prefix in the ff3x::/32 range. The embedded IPv4 address SHOULD be in the 232/8 range [RFC4607]. 232.0.0.1-232.0.0.255 range is being reserved to IANA. Why is this a SHOULD? Med: We first considered a MUST but we relaxed that required to SHOULD for any future use case which may need to map IPv4 ASM to IPv6 SSM. Does this makes sense to you? What does being reserved to IANA mean? Med: It should be for IANA allocation instead of to IANA. Better? Although the proposal appears simple, I would suggest further review as it updates RFC 4291. Med: Reviews are more than welcome. FWIW, a call for review has been issued in 6man and 6vops for 2 weeks: * http://www.ietf.org/mail-archive/web/ipv6/current/msg15488.html * http://www.ietf.org/mail-archive/web/v6ops/current/msg12174.html Regards, -sm ___ MBONED mailing list mbo...@ietf.org https://www.ietf.org/mailman/listinfo/mboned
RE: [Int-area] Last Call: draft-ietf-intarea-server-logging-recommendations-02.txt (Logging recommendations for Internet facing servers) to BCP
Hi Francis, Please see inline. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : jeudi 17 mars 2011 16:41 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : ietf@ietf.org; IETF-Announce; int-a...@ietf.org Objet : Re: [Int-area] Last Call: draft-ietf-intarea-server-logging-recommendations-02.txt (Logging recommendations for Internet facing servers) to BCP In your previous mail you wrote: This is a late comment but I think it is worth raising it. = as the gen-art reviewer of the document I'd like to understand the comment. Med: To understand the issue, I recommend you the following reading: http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt This I-D recommends to log the source port number for internet-facing servers. But due to the presence of load-balancers in the path, the original source port may be lost. The source port number that will be passed to the target server may not be accurate and hence does not meet the initial requirment. = where are these load-balancers and as they perform a NAT function why they don't log mappings they create? Or if they are placed in front of servers why they are not integrated in the logging system? Med: You can make a quick search on the XFF practices in load-balances/proxies to see how it is used for logging purposes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Int-area] Last Call: draft-ietf-intarea-server-logging-recommendations-02.txt (Logging recommendations for Internet facing servers) to BCP
Dear all, This is a late comment but I think it is worth raising it. This I-D recommends to log the source port number for internet-facing servers. But due to the presence of load-balancers in the path, the original source port may be lost. The source port number that will be passed to the target server may not be accurate and hence does not meet the initial requirement. Of course, the same issue applies for the source IP address. The only difference is that there are tool to convey the source IP address in application headers for instance. There is nothing equivalent at the IP/transport/application level for the source port. You don't think it would be valuable to record the issue in the draft? FWIW, below a text describing this issue. 2.1. Preserve Source Port Number In order to implement the recommendation documented in [I-D.ietf-intarea-server-logging-recommendations], extensions are required to preserve the source port number and to avoid this information to be lost when load-balancers are involved in the path. Examples of mitigation solutions are provided below: 1. Extend XFF to convey the port in addition to the IP address 2. Define a header similar to XFF to convey the source port 3. Extend the TCP Option to convey the source port 4. Enable the Proxy Protocol [Proxy]. Cheers, Med -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de The IESG Envoyé : vendredi 25 février 2011 16:04 À : IETF-Announce Cc : int-a...@ietf.org Objet : [Int-area] Last Call: draft-ietf-intarea-server-logging-recommendations-02.txt (Logging recommendations for Internet facing servers) to BCP The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Logging recommendations for Internet facing servers' draft-ietf-intarea-server-logging-recommendations-02.txt as a BCP 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.org mailing lists by 2011-03-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ No IPR declarations have been submitted directly on this I-D. ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-ipv6-transition-guidelines-08.txt (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC
Dear all, Please find below some comments about this I-D. (1) * Precise in the introduction section the type of networks which are concerned with the IPv6 deployment models listed in the I-D; in particular mention that both corporate networks and providers networks are concerned. * Fixed and mobile networks may adopt distinct IPv6 deployment strategies because of the differences between the two networks (e.g., controlled CPE vs. non controlled handsets). * It seems services infrastructures (e.g., VoIP, IP TV) are out of scope. This should be mentioned. Note that some service-related discussed is covered in Section 4.4. (2) Page 5/6, the I-D says: o The ability to offer a valuable service. In the case of the Internet, connectivity has been this service. o The ability to deploy the solution in an incremental fashion. o Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols. o Openly available implementations. These make it easier for researchers, start-ups and others to build on or improve existing components. o The ability to scale. The IPv4 Internet grew far larger than its original designers had anticipated, and scaling limits only became apparent 20-30 years later. o The design supports robust interoperability rather than mere correctness. This is important in order to ensure that the solution works in different circumstances and in an imperfectly controlled world. and in Page 6: These factors are also important when choosing IPv6 migration tools., but: * The I-D does not show how these factors are applied for the tools listed in the I-D; a table with a set of criteria would be useful; * The first criterion is IMHO meaningless for IPv6 deployment because IPv6 does not offer a new service compared to IPv4. * I'm not sure that having an open source for a given tool can be an argument to RECOMMEND or NOT a given tool; * How scalability is defined (5th bullet)?? All the solutions listed in the I-D need a NAT (l2-nat, ds-lite nat44, nat44, nat64), to what extent a CGN is considered as a scalable solution? * The last bullet is not clear: Do you consider that DS-Lite satisfies this factor? FWIW, DS-Lite has been rejected by the 3GPP because it requires specific functions on the UE. (3) From the perspective of transitioning networks to IPv6, I don't see the rationale behind including techniques such as those listed in 4.2. Crossing IPv4 Islands as a candidate solutions for IPv6 deployment. This section can be removed to an appendix. (4) (a) I have an issue with the following statements in the I-D: On page 6, the ID states: The third scenario is more advanced and looks at a service provider network that runs only on IPv6 but which is still capable of providing both IPv6 and IPv4 services. and in page 11, the ID mentions: The recommended tool for this model is Dual Stack Lite [I-D.ietf-softwire-dual-stack-litehttp://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines-13#ref-I-D.ietf-softwire-dual-stack-lite]. Dual Stack Lite provides both relief for IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6. Given this IPv6 connectivity, as a side-effect it becomes easy to provide IPv6 connectivity all the way to the end users. Taking into account the current DS-Lite specification, this recommendation is not justified for the following reasons: * For Ds-Lite technique to be deployed in a IPv6-only realm, and as currently specified in DS-Lite specification, this would mean that DS-Lite AFTR(s) are to be located at the boundaries of the IPv6-only domain. * This design choice would lead to non optimal intra-domain paths to place communications between two DS-Lite serviced customers. * This centralised model is not suitable for service providers who want to deploy DS-Lite AFTRs closer to the customers. (b) The I-D states in page 11: Given this IPv6 connectivity, as a side-effect it becomes easy to provide IPv6 connectivity all the way to the end users. This wording is not accurate; IPv6 connectivity is not a side-effect of DS-lite but rather a pre-requisite for DS-Lite (e.g., DHCPv6 is required to configure for instance the AFTR NAME option, dual-stack CPE, etc.). (5) * In Section 4.4. IPv6-only Deployment, add a sentence to precise that the issues listed in [I-D.ietf-intarea-shared-addressing-issueshttp://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines-13#ref-I-D.ietf-intarea-shared-addressing-issues] are still valid when NAT64 is deployed. * Page 13, change SIP (Session Identity Protocol) to SIP (Session Initiation Protocol); * Page 13: One might position a web proxy, a mail server, or a SIP (Session Identity Protocol) back-to-back user agent across the boundary between IPv4 and IPv6
