Hi Gang, This works for me, thanks.
Best Regards, Dapeng 2012/6/14, GangChen <[email protected]>: > 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 <[email protected]>: >> 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, [email protected] <[email protected]>: >>> 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:[email protected]] >>>>Envoyé : mercredi 13 juin 2012 17:44 >>>>À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>Cc : liu dapeng; [email protected] >>>>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, [email protected] wrote: >>>>> Re-, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : liu dapeng [mailto:[email protected]] >>>>>> Envoyé : mercredi 13 juin 2012 12:09 >>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>> Cc : [email protected] >>>>>> Objet : Re: [Softwires] I-D Action: >>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> >>>>>> Dear Med: >>>>>> >>>>>> >>>>>> 2012/6/13, >>>>[email protected]<[email protected]>: >>>>>>> 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 : [email protected] >>>>>>>> [mailto:[email protected]] De la part de liu dapeng >>>>>>>> Envoyé : mercredi 13 juin 2012 05:40 >>>>>>>> À : Lee, Yiu >>>>>>>> Cc : [email protected] >>>>>>>> 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<[email protected]>: >>>>>>>>> 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"<[email protected]> wrote: >>>>>>>>> >>>>>>>>>> 2012/6/12, Lee, Yiu<[email protected]>: >>>>>>>>>>> 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"<[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> 2012/6/12, Ole Trøan<[email protected]>: >>>>>>>>>>>>>> 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 >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> ------ >>>>>>>>>> Best Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> ------ >>>>>>>> Best Regards, >>>>>>>> Dapeng Liu >>>>>>>> _______________________________________________ >>>>>>>> Softwires mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> > -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
