Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
As a co-author, I'm comfortable with this. --satoru On 2012/06/14, at 14:53, mohamed.boucad...@orange.com wrote: Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hello Med and all, I don't agree we move like this way, as yourself said yesterday. (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). It isquite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Please kindly help to let readers understand what is your thought. Thanks a lot for your help. Best Regards, -Dapeng 2012/6/14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hello Dapeng and all, I agreed Med explained three different cases and also understood Dapeng's desire. Trying to clarify cases and converge the discussion, I suggest following words. Hopefully, that could eliminate your concerns. States should be maintained on other equipments, e.g. customer premises equipment or host, in ADDRESS SHARING CONTEXT BRs Gang 2012/6/14, liu dapeng maxpass...@gmail.com: Hello Med and all, I don't agree we move like this way, as yourself said yesterday. (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). It isquite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Please kindly help to let readers understand what is your thought. Thanks a lot for your help. Best Regards, -Dapeng 2012/6/14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hi Gang, This works for me, thanks. Best Regards, Dapeng 2012/6/14, GangChen phdg...@gmail.com: Hello Dapeng and all, I agreed Med explained three different cases and also understood Dapeng's desire. Trying to clarify cases and converge the discussion, I suggest following words. Hopefully, that could eliminate your concerns. States should be maintained on other equipments, e.g. customer premises equipment or host, in ADDRESS SHARING CONTEXT BRs Gang 2012/6/14, liu dapeng maxpass...@gmail.com: Hello Med and all, I don't agree we move like this way, as yourself said yesterday. (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). It isquite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Please kindly help to let readers understand what is your thought. Thanks a lot for your help. Best Regards, -Dapeng 2012/6/14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Great! We will add it. On Jun 14, 2012, at 5:50 PM, liu dapeng maxpass...@gmail.com wrote: Hi Gang, This works for me, thanks. Best Regards, Dapeng 2012/6/14, GangChen phdg...@gmail.com: Hello Dapeng and all, I agreed Med explained three different cases and also understood Dapeng's desire. Trying to clarify cases and converge the discussion, I suggest following words. Hopefully, that could eliminate your concerns. States should be maintained on other equipments, e.g. customer premises equipment or host, in ADDRESS SHARING CONTEXT BRs Gang 2012/6/14, liu dapeng maxpass...@gmail.com: Hello Med and all, I don't agree we move like this way, as yourself said yesterday. (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). It isquite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Please kindly help to let readers understand what is your thought. Thanks a lot for your help. Best Regards, -Dapeng 2012/6/14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Ole Trøan otr...@employees.org: Ok, then we can make this more clear in our document. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I think this is just adding confusion. the NAT44 on the CPE already does this. =First off, we are not only talking about NAT44 here, but port translation and non-shared address. Secondly, NAT44 on the CPE is not doing what today NAT44 does. For example, override ID in ICMP with port information. that reminds me to update the proposed text a bit, States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Ole Trøanotr...@employees.org: Ok, then we can make this more clear in our document. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I think this is just adding confusion. the NAT44 on the CPE already does this. =First off, we are not only talking about NAT44 here, but port translation and non
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
I prefer Tom suggestion. It is typical to have a NAT but not a must or should. On 6/13/12 12:38 PM, liu dapeng maxpass...@gmail.com wrote: I can change may to should to please you but it really does make sense. = thanks smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hi Med, Thanks for posting this new version but I guess it doesn't reflect all the discussion we had. I suggest to make following modifications. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict port numbers within a dedicated range. Please be undestood all the efforts are for precise expression for the readers. Thanks, Best Regards, Dapeng Liu 2012/6/12, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear WG members, The new version includes the comments received during the WG LC (from Dapeng). A diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateless-4v6-motivation-02 Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 12 juin 2012 07:43 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Author(s) : Mohamed Boucadair Satoru Matsushima Yiu Lee Olaf Bonness Isabel Borges Gang Chen Filename: draft-ietf-softwire-stateless-4v6-motivation-02.txt Pages : 16 Date: 2012-06-11 Abstract: IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless- 4v6-motivation There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles s-4v6-motivation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
2012/6/12, Ole Trøan otr...@employees.org: Ok, then we can make this more clear in our document. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I think this is just adding confusion. the NAT44 on the CPE already does this. =First off, we are not only talking about NAT44 here, but port translation and non-shared address. Secondly, NAT44 on the CPE is not doing what today NAT44 does. For example, override ID in ICMP with port information. that reminds me to update the proposed text a bit, States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3 or L4 information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I suggest we instead talk about no _additional_ state in the network. there is no need to mention the CPE, apart from stating that no additional state is required. =I believe the above is clear for reader and designer. I don't see why we resist on clarifying and helping reader better understanding. Regards, Dapeng Liu cheers, Ole -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mardi 12 juin 2012 11:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Ok, then we can make this more clear in our document. States still should be maintained in other equipments, Med: Why should? The NAT is not mandatory and even if port restriction is needed, a host may just restrict its port to be within the range. So, I don't see a reason to change may to should. e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. Med: No need to elaborate what the state is about. You asked to add a sentence to say a state may exist in the LAN side, I updated the text to cover your comment: States may still exist in other equipments such as customer premises equipment. Best Regards, Dapeng Liu 2012/6/12, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Dapeng, I can't add the port restriction because stateless IPv4/IPv6 solutions (e.g., MAP, 4RD) support also the ability to assign a full IP address. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mardi 12 juin 2012 09:14 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Hi Med, Thanks for posting this new version but I guess it doesn't reflect all the discussion we had. I suggest to make following modifications. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict port numbers within a dedicated range. Please be undestood all the efforts are for precise expression for the readers. Thanks, Best Regards, Dapeng Liu 2012/6/12, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear WG members, The new version includes the comments received during the WG LC (from Dapeng). A diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles s-4v6-motivation-02 Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 12 juin 2012 07:43 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Author(s) : Mohamed Boucadair Satoru Matsushima Yiu Lee Olaf Bonness Isabel Borges Gang Chen Filename: draft-ietf-softwire-stateless-4v6-motivation-02.txt Pages : 16 Date: 2012-06-11 Abstract: IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless- 4v6-motivation There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles s-4v6-motivation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Ole Trøan otr...@employees.org: Ok, then we can make this more clear in our document. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I think this is just adding confusion. the NAT44 on the CPE already does this. =First off, we are not only talking about NAT44 here, but port translation and non-shared address. Secondly, NAT44 on the CPE is not doing what today NAT44 does. For example, override ID in ICMP with port information. that reminds me to update the proposed text a bit, States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3 or L4 information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I suggest we instead talk about no _additional_ state in the network. there is no need to mention the CPE, apart from stating that no additional state is required. =I believe the above is clear for reader and designer. I don't see why we resist on clarifying and helping reader better understanding. Regards, Dapeng Liu cheers, Ole -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
