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

[liu dapeng <[e-mail]>]

Dear Med:


2012/6/13, [e-mail] <[e-mail]>:
> 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.


> * focus is on carrier-side stateless solutions

==>Carrier side stateless solution doesn’t mean solution doesn’t cover
CPE. We need to clarify definitely.

Regards,
Dapeng

> 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
>>


-- 

------
Best Regards,
Dapeng Liu