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

liu dapeng <maxpassion@gmail.com> Wed, 13 June 2012 03:39 UTC

Return-Path: <maxpassion@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947EC11E8098 for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 20:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level:
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRA2MX70j9Rk for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 20:39:58 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9BF211E808D for <softwires@ietf.org>; Tue, 12 Jun 2012 20:39:57 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so255084obb.31 for <softwires@ietf.org>; Tue, 12 Jun 2012 20:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z5Kgiy6LaykfWxyROLdYJaMqauX1EPtCojKwy9TGHpY=; b=n5HL56u+9lb9kwKBpcp9cVvWOcN5/QB0B5UYqHs16Ls+ehhkbRNGQERnnZ0IprJJhe c3qrtko/igNq8xkMHNKD6kRxyBkT+p13WKt13SQDciXG+9DVWTjmeqokJ2jQGMKwz7fU 06gpNohPtnh0I9XggRQq2wrYxO+bvDbWA6fEwS09urlmIJ2XPMZK3mJ1bRbbV+FksYIS XlowG5rrY8Cuz2o2dCdIKGZ6ZLN+H5LurxQV5OWcpqhjuzqu0diCYa9ACXTv7rK5sBMj oZtFg2rr6OUi/ZqscsICmHg/50CuX6JC/cj/WHO4aqvvyTswVtU4pChYtCsuhJ+ypRrf hjog==
MIME-Version: 1.0
Received: by 10.60.27.6 with SMTP id p6mr22795628oeg.37.1339558797336; Tue, 12 Jun 2012 20:39:57 -0700 (PDT)
Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 20:39:57 -0700 (PDT)
In-Reply-To: <CBFD2344.21E9E%yiu_lee@cable.comcast.com>
References: <CAKcc6AdweW49RP2v+S_F5djGnp5V3ibr2caHB+RCQF+8nXXEkA@mail.gmail.com> <CBFD2344.21E9E%yiu_lee@cable.comcast.com>
Date: Wed, 13 Jun 2012 11:39:57 +0800
Message-ID: <CAKcc6AdBSLD9rCKeS1zhB+yZYXUJRx=Au_zTYV5a8akXmxdW4A@mail.gmail.com>
From: liu dapeng <maxpassion@gmail.com>
To: "Lee, Yiu" <Yiu_Lee@cable.comcast.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2012 03:39:58 -0000

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