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. > * focus is on carrier-side stateless solutions ==>Carrier side stateless solution doesn’t mean solution doesn’t cover CPE. We need to clarify definitely. 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 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 >> -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
