Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt

As a co-author, I'm comfortable with this.
--satoru

On 2012/06/14, at 14:53, <mohamed.boucadair@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.stds@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.boucadair@orange.com wrote:
>>> Re-,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : liu dapeng [mailto:maxpassion@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.boucadair@orange.com<mohamed.boucadair@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-bounces@ietf.org
>>>>>> [mailto:softwires-bounces@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_Lee@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"<maxpassion@gmail.com>  wrote:
>>>>>>> 
>>>>>>>> 2012/6/12, Lee, Yiu<Yiu_Lee@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"<maxpassion@gmail.com>  wrote:
>>>>>>>>> 
>>>>>>>>>> 2012/6/12, Ole Trøan<otroan@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