As a co-author, I'm comfortable with this. --satoru On 2012/06/14, at 14:53, <mohamed.boucad...@orange.com> wrote:
> 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:tom.taylor.s...@gmail.com] >> Envoyé : mercredi 13 juin 2012 17:44 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : liu dapeng; softwires@ietf.org >> 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, mohamed.boucad...@orange.com wrote: >>> Re-, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : liu dapeng [mailto:maxpass...@gmail.com] >>>> Envoyé : mercredi 13 juin 2012 12:09 >>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : softwires@ietf.org >>>> Objet : Re: [Softwires] I-D Action: >>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>> 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. >>>> >>> >>> 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 : 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 >>> >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
