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

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Tue, 12 June 2012 20:51 UTC

Return-Path: <yiu_lee@cable.comcast.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 4677711E8073 for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 13:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.231
X-Spam-Level:
X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 WtajoMAwb+uv for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 13:51:28 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF221F86B1 for <softwires@ietf.org>; Tue, 12 Jun 2012 13:51:28 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20970738; Tue, 12 Jun 2012 14:34:58 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 16:51:23 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: liu dapeng <maxpassion@gmail.com>
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Thread-Index: AQHNSN0gFHJFO2o5GU2LzTg9ZchidQ==
Date: Tue, 12 Jun 2012 20:51:23 +0000
Message-ID: <CBFD2344.21E9E%yiu_lee@cable.comcast.com>
In-Reply-To: <CAKcc6AdweW49RP2v+S_F5djGnp5V3ibr2caHB+RCQF+8nXXEkA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.2.120421
x-originating-ip: [24.40.55.70]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3422364682_1368046"
MIME-Version: 1.0
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: Tue, 12 Jun 2012 20:51:29 -0000

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