I would prefer IETF more strict about what accurate terminology we are using other than favorite. At this moment this document go through working group last call which I have reviewed, and believe it should be Revised for not misleading other people. Thanks for your suggestion.
Regards, Dapeng Liu 2012/6/11, Rajiv Asati (rajiva) <raj...@cisco.com>: > I am not fond of the proposed change. > > After all, most of the other documents refer to stateful without taking a > "side" (e.g. carrier-side), and so this document should state stateless in > the same regard. > > Of course, where it makes sense to clarify, it must be clarified that > stateless is in the carrier-side, with or without stateful NAT44 in the > customer-side. We must not make the assumption that stateless and stateful > go together, though they will likely. > > Cheers, > Rajiv > > >> -----Original Message----- >> From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On >> Behalf Of liu dapeng >> Sent: Sunday, June 10, 2012 11:47 PM >> To: mohamed.boucad...@orange.com >> Cc: softwires@ietf.org; Yong Cui >> Subject: Re: [Softwires] WG last call >> ondraft-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 > -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
