Great! We will add it. On Jun 14, 2012, at 5:50 PM, "liu dapeng" <[email protected]> wrote:
> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
