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 <maxpass...@gmail.com>: > 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, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>: >> 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 >>>> >>> > > > -- > > ------ > 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
