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

[<[e-mail]>]

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:[e-mail]] 
>Envoyé : mercredi 13 juin 2012 17:44
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : liu dapeng; [e-mail]
>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, [e-mail] wrote:
>> Re-,
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : liu dapeng [mailto:[e-mail]]
>>> Envoyé : mercredi 13 juin 2012 12:09
>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>> Cc : [e-mail]
>>> Objet : Re: [Softwires] I-D Action:
>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt
>>>
>>> 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.
>>>
>>
>> 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 : [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
>>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>