[Autoconf] Fwd: WG Action: RECHARTER: Ad-Hoc Network Autoconfiguration (autoconf)

Ryuji Wakikawa <ryuji.wakikawa@gmail.com> Tue, 11 January 2011 04:38 UTC

Return-Path: <ryuji.wakikawa@gmail.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4528C25D for <autoconf@core3.amsl.com>; Mon, 10 Jan 2011 20:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx5vzuXcq4iA for <autoconf@core3.amsl.com>; Mon, 10 Jan 2011 20:38:32 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8588B28C25A for <autoconf@ietf.org>; Mon, 10 Jan 2011 20:38:32 -0800 (PST)
Received: by iwn40 with SMTP id 40so21146669iwn.31 for <autoconf@ietf.org>; Mon, 10 Jan 2011 20:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version:x-mailer; bh=db4JDy8yfgXvKi05OvVEcIc37CtzLJprOK1/aQLQAkA=; b=UzwmKZFpMGGdEpRBiZ7zAn5sfwKiWuU5QXIQaszLQCvl1BYs6PzSlqtUnbtSTTinst HojoZPFyfcv2oO2kNl1xHlag+us+bYeP9deg/Gd4JaqkAkwO/CHVgQLBPI1SvnrEjP6F uaKe6Bi4CwoOj+YFjTMubHRu0wXpTaANJHTas=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=qgO7oDZbNDurRlm28j9BAQ6MlkxdEA8I51fyVDL9thVMXjuBufiN4lkrio0f2VR/iq ZcVeggnoYANMSDYiOUMQ3JUtYYFDZLDwsVD7hxw9VNJceov1WmiA9XYnmjvU43GdsldG M62lO5kDuY/aVZl2Ahkxn4C7XZTxRxaQk7U0A=
Received: by 10.42.230.137 with SMTP id jm9mr5205751icb.282.1294720847823; Mon, 10 Jan 2011 20:40:47 -0800 (PST)
Received: from [10.0.1.5] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id ca7sm4176091icb.0.2011.01.10.20.40.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 20:40:44 -0800 (PST)
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Jan 2011 20:40:41 -0800
References: <20101221175017.212DD3A6B45@core3.amsl.com>
To: "Autoconf autoconf@ietf.org" <autoconf@ietf.org>
Message-Id: <A134CDC5-70B2-402C-B714-8C6F8E35D820@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [Autoconf] Fwd: WG Action: RECHARTER: Ad-Hoc Network Autoconfiguration (autoconf)
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2011 04:38:33 -0000

Hi all,

After rechartering, we are ready for discussions. 
Does anybody plan to submit IDs related to AUTOCONF WG charter items?

If you plan to submit ID, can you contact to chairs (thomas and I) even before submission.
We need to know the number of related IDs before requesting a slot in Prague meeting.

thanks,
ryuji


Begin forwarded message:

> From: IESG Secretary <iesg-secretary@ietf.org>
> Date: 2010/12/21 09:50:17GMT-08:00
> To: IETF Announcement list <ietf-announce@ietf.org>
> Cc: ryuji.wakikawa@gmail.com, T.Clausen@computer.org, autoconf@ietf.org
> Subject: WG Action: RECHARTER: Ad-Hoc Network Autoconfiguration (autoconf) 
> 
> The Ad-Hoc Network Autoconfiguration (autoconf) working group in the
> Internet Area of the IETF has been rechartered.  For additional
> information, please contact the Area Directors or the working group
> Chairs.
> 
> Ad-Hoc Network Autoconfiguration (autoconf)
> ---------------------------------------------------
> Current Status: Active Working Group
> 
> Chairs:
>  Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
>  Thomas Clausen <T.Clausen@computer.org>
> 
> Internet Area Directors:
>  Ralph Droms <rdroms.ietf@gmail.com>
>  Jari Arkko <jari.arkko@piuha.net>
> 
> Internet Area Advisor:
>  Jari Arkko <jari.arkko@piuha.net>
> 
> Mailing Lists:
>  General Discussion: autoconf@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
>  Archive:
> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html
> 
> Description of Working Group:
> 
> RFC 5889 presents one possible IPv6 addressing model for ad hoc
> nodes. In this model the ad hoc routers need to configure their
> network interface(s) with addresses valid in the ad hoc network, and
> may configure additional prefixes for use by attached nodes.
> 
> After completing the work on RFC 5889, the main purpose of the
> AUTOCONF WG is to standardize how existing IPv6 address configuration
> tools can be used for address configuration.
> 
> 1. DHCPv6 operation over MANET, including:
> 
> - A DHCPv6-based mechanism for configuring required interface
> addresses for the routers in the ad hoc network. This mechanism
> is expected to produce addresses with properties outlined in RFC
> 5889. This mechanism uses the existing DHCPv6 protocol unchanged,
> and assumes a central node that can allocate addresses on a
> first-come-first-served basis. Nodes in the ad hoc network
> will relay messages to the central node in order to help a new
> node get an address for itself. This mechanism is only suitable
> for deployments were a central node can be set up. It should be
> noted that many existing deployments employ Internet gateways
> that can act as such a central node as well. Future extensions
> such as central node election may make this mechanism suitable
> for also for stand-alone ad hoc networks.
> 
> - A DHCPv6-based mechanism for delegating a prefix(es) to each
> router for use by applications running on the routers themselves,
> or for configuration of attached hosts/networks. This mechanism
> works in a similar manner to the one above, but allocates
> prefixes instead of addresses.
> 
> Both mechanisms should be independent from operation of any specific
> MANET routing protocol, although may exploit information maintained by
> such a routing protocol, if available.
> 
> The working group will adapt and/or reuse existing protocols whenever
> reasonable and possible. No new duplicate address detection mechanisms
> will be specified.
> 
> 2. Analysis of Problem Space for distributed address configuration and
> service discovery. This analysis is necessary in order to understand
> what type of distributed solution(s) can be standardized. There is
> already quite a lot of material about possible solutions in the
> literature.
> 
> The working group plans to establish design teams for rapidly advancing
> towards initial submissions for these two work items. The group shall
> also work with the 6LOWPAN and ROLL working group to ensure that
> the results from AUTOCONF working group are useful for the larger
> community and do not overlap with work already in progress in these
> other working groups.
> 
> Goals and Milestones:
> 
> - Jan 2011 First working group draft of the "DHCPv6 operation over
>           MANET"
> - Jan 2011 First working group draft of the "Analysis of Problem Space"
> - Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG
>           for publication as BCP
> - Sep 2011 Submission of the "Analysis of Problem Space" the IESG for
>           publication as Informational RFC
> - Oct 2011 First working group draft of the "Distributed Solution"
> - Jun 2012 Submission of the "Distributed Solution" to the IESG for
>           publication as an Proposed Standard RFC
> - Jun 2012 Rechartering or Closing WG