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 >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
