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

[<[e-mail]>]

Dear Dapeng,

The current text says:

* no state in the (provider) network side
* state may exist in the customer premises side
* focus is on carrier-side stateless solutions

As an editor of the document, I believe the new version solves your concerns. 

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] 
>[mailto:[e-mail]] De la part de liu dapeng
>Envoyé : mercredi 13 juin 2012 05:40
>À : Lee, Yiu
>Cc : [e-mail]
>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 <[e-mail]>:
>> 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" <[e-mail]> wrote:
>>
>>>2012/6/12, Lee, Yiu <[e-mail]>:
>>>> 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" <[e-mail]> wrote:
>>>>
>>>>>2012/6/12, Ole Trøan <[e-mail]>:
>>>>>>> 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
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>>
>>>
>>>
>>>--
>>>
>>>------
>>>Best Regards,
>>>Dapeng Liu
>>
>
>
>-- 
>
>------
>Best Regards,
>Dapeng Liu
>_______________________________________________
>Softwires mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires
>