Hi Yiu,
+1. Cheers, Med >-----Message d'origine----- >De : [email protected] >[mailto:[email protected]] De la part de Lee, Yiu >Envoyé : mardi 12 juin 2012 14:46 >À : [email protected] >Objet : Re: [Softwires] I-D Action: >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >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. 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. >Adding more text only causes confusion. > >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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
