Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hi Dapeng, A state maintained in the endpoint does not make the solution stateful, see this excerpt from RFC1958: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). I didn't considered your last proposed changes for the reason mentioned above. Thank you for your help. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 05:47 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hello Med, Yes, we are almost converged on this final update. As you said here, there still need port translation in the host, that still state in the host. we need clarify that in this document for other readers. Best Regards, Dapeng Liu 2012/6/11, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
2012/6/11, Rémi Després despres.r...@laposte.net: Le 2012-06-11 à 09:32, liu dapeng a écrit : Hello Med, Yes, we are almost converged on this final update. As you said here, there still need port translation in the host, that still state in the host. Note that these states are per-connection, not per customer. Even a host without NAT has to maintain per-connection states for its sockets. The state you mentioned here is for application, but we are talking about state on the network layer, they are different. I don't see why we resist on clarifying and helping reader better understanding. Besides, I guess the state referred in this document is not specific to either per-connection or per customer . AFTR also hold a per-connection state, which is treated as a stateful in the document. Best Regards, Dapeng Liu In this respect, the draft is I think acceptable, and hopefully can now proceed quickly. Regards, RD we need clarify that in this document for other readers. Best Regards, Dapeng Liu 2012/6/11, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hi Yiu, Works for me. Thanks. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : lundi 11 juin 2012 16:54 À : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng Cc : softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med and Dapeng, In order to close the gap, I suggest a slight modification: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that sharing of global IPv4 addresses between Customers is based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note that the stateless solution elaborated in this document focuses on the carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer-premises equipment. Thanks, Yiu On 6/8/12 8:12 AM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
2012/6/7, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers; Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mardi 5 juin 2012 10:49 À : Yong Cui Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hello all, I am not sure this version resolves my concerns regarding the possible misleading by the word stateless. To avoid this misleading, I suggest the following changes: 1. Change the title to Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions. Since this document is mainly about carrier-side stateless, the new title is more precise to reflect the content of this document. Med: Done. I updated my local copy with the proposed title. == Thanks 2. Add a subsection in introduction, clarify that this document is only about carrier side stateless. Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of “stateless” terminology. This document provides elaboration on such need. --- Thanks, Best regards, Dapeng Liu I would like to support it if the document was updated accordingly. Thanks. -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hello all, I am not sure this version resolves my concerns regarding the possible misleading by the word stateless. To avoid this misleading, I suggest the following changes: 1. Change the title to Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions. Since this document is mainly about carrier-side stateless, the new title is more precise to reflect the content of this document. 2. Add a subsection in introduction, clarify that this document is only about carrier side stateless. I would like to support it if the document was updated accordingly. Thanks, Best regards, Dapeng Liu 2012/5/27, Yong Cui cuiy...@tsinghua.edu.cn: Hi folks, This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio n/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong Alain ___ 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] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Support. RD Le 2012-05-27 à 16:28, Yong Cui a écrit : Hi folks, This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio n/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong Alain ___ 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
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
+1 support. On Sun, May 27, 2012 at 10:28 PM, Yong Cui cuiy...@tsinghua.edu.cn wrote: Hi folks, This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio n/http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio%0An/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong Alain ___ 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
