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
