IETF Logo Mail Archive

Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01

Leaf yeh <leaf.y.yeh@huawei.com> Mon, 08 October 2012 04:12 UTC

Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9841521F8762 for <dhcwg@ietfa.amsl.com>; Sun, 7 Oct 2012 21:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+lAknxU-GtI for <dhcwg@ietfa.amsl.com>; Sun, 7 Oct 2012 21:12:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE421F875E for <dhcwg@ietf.org>; Sun, 7 Oct 2012 21:12:00 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ72459; Mon, 08 Oct 2012 04:11:59 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 05:11:35 +0100
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 05:11:58 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 12:11:50 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01
Thread-Index: AQHNoy/3x07iyqI+M0+SYXbfMix6M5eusfZw
Date: Mon, 08 Oct 2012 04:11:50 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3CE36E96@szxeml546-mbx.china.huawei.com>
References: <EDE04BE3-EF07-4CD2-B8D9-D82A570E8C19@nominum.com> <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com>
In-Reply-To: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dhcwg WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2012 04:12:01 -0000

a. Schedule question: draft-mrugalski-softwire-dhcpv4-over-v6-option sounds work for the draft-cui-softwire-b4-translated-ds-lite per the section 2 of introduction, but draft-cui (LW4o6) is still in the status of individual draft. Is it suitable to adopt this draft after the (softwire) adoption of draft-cui?

<quote>In a typical deployment as [I-D.cui-softwire-b4-translated-ds-lite]..., CRA functionality will be a part of a Lightweight B4 element (Basic Bridging BroadBand element) implementation.</quote>
<quote>...the typical envisaged use would be the Lightweight 4over6 architecture, where TSV or TRA could be part of Lightweight AFTR implementation.</quote>

The above is quoted as the reference.

b. A naive question on the network scenario: why do we need call the client (LW4o6 initiator) to be CRA, not the *client* directly?
c. One more naive question on the network scenario: Could the dhcp4ov6 endpoint (called TSV or TRA) be the different one with the LW4o6 tunnel endpoint (called LW4o6 concentrator)? If yes, not sure it have been mentioned in draft-cui.

d. Technical question: Section 5 - DHCPv6 Client Behavior - <quote>It SHOULD warn its operator about such condition.</quote>. How?


Best Regards,
Leaf


-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Saturday, October 06, 2012 3:31 AM
To: dhcwg WG
Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01

On Sep 26, 2012, at 1:27 PM, Ted Lemon <ted.lemon@nominum.com> wrote:
> The authors have requested that the working group adopt draft-mrugalski-softwire-dhcpv4-over-v6-option as a working group work item.   The document is within the scope of the current charter.   It describes a DHCPv6 option that is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-ipv6).

Just a reminder: we have only seen two responses on this draft, and I know that there are more than two working group participants who are interested in it.   The call for adoption expires on October 10.

FTR, with my wg chair hat off, I'm in favor of adopting.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email