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.boucad...@orange.com wrote:
Re-,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : liu dapeng [mailto:maxpass...@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.boucad...@orange.com<mohamed.boucad...@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-boun...@ietf.org
[mailto:softwires-boun...@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_...@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"<maxpass...@gmail.com> wrote:
2012/6/12, Lee, Yiu<yiu_...@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"<maxpass...@gmail.com> wrote:
2012/6/12, Ole Trøan<otr...@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
