Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Wed, 30 June 2010 13:42 UTC

Return-Path: <emmanuel.baccelli@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 28BC328C103 for <autoconf@core3.amsl.com>; Wed, 30 Jun 2010 06:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 1qOu3WeGJECA for <autoconf@core3.amsl.com>; Wed, 30 Jun 2010 06:42:56 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 6096A28C0CF for <autoconf@ietf.org>; Wed, 30 Jun 2010 06:42:55 -0700 (PDT)
Received: by gxk5 with SMTP id 5so416513gxk.31 for <autoconf@ietf.org>; Wed, 30 Jun 2010 06:43:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=DgGWeH/fJ0XTxjH1YzAo6oRUm9ZCiTIL+/q78jwFMvo=; b=mCYqv3/hXWh6FnB+06svbfJUDo06d4NGtUkhr/G25wGQvnRXCD0hz5+v9Dy2JV9DQ9 JMUtHP3QL5DWRXziwAp/ZoZZcsS8UMMzIVsqNI4KYRoMnpoYIFf6+FVO1uQU9Fcw5WlM /tXLvspbixiXGHeb23uolUywGEj3kAZmUd2u8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=BPqMLoPhY6kTCR1LL3AfrOA+pU9IUZl/BMUnbzpljBzW8Vuix05xM0F5VbK2rA5HKx ekaXbG0eru0K2q2P6g+zMgthm/6uEgfuE2VNGbJiBwDyDvtX2NOMSSk4WZhHrrG5G2Do 0GAtislf7+NL+x9okHK3UUyxHf0xoiqlX60CQ=
Received: by 10.213.10.195 with SMTP id q3mr427610ebq.59.1277905380227; Wed, 30 Jun 2010 06:43:00 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by 10.216.173.198 with HTTP; Wed, 30 Jun 2010 06:42:40 -0700 (PDT)
In-Reply-To: <BFD8FF22-FD36-436E-9985-7BFA2E234081@gmail.com>
References: <BFD8FF22-FD36-436E-9985-7BFA2E234081@gmail.com>
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Wed, 30 Jun 2010 15:42:40 +0200
X-Google-Sender-Auth: 74gkGK2TbTaZOYh2CXdoS2g0hwY
Message-ID: <AANLkTin7UpwkLuSD-6IgI_NjKf2jsYg7nZyS3KmGiwYM@mail.gmail.com>
To: "autoconf@ietf.org autoconf@ietf.org" <autoconf@ietf.org>
Content-Type: multipart/alternative; boundary="0015174c11e03ebd2f048a3f8817"
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.
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: Wed, 30 Jun 2010 13:42:58 -0000

Hi all,


I also support a "walk-before-run" approach. To focus on the specific case
where a DHCP server is reachable somewhere in the MANET is somewhat
restrictive, but to me, it makes sense to solve this particular "simple"
case before tackling "hairy" cases.

I want however to point out that an informational RFC documenting the
observed weird characteristics of ad hoc wireless communications would be a
useful companion document for the solution to be designed for AUTOCONF (as
well as for other mechanisms currently being designed in other working
groups, including 6lowpan, ROLL). In that respect, the draft we have worked
on with Charlie is a candidate to consider:

http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt

Regards,

Emmanuel





On Tue, Jun 29, 2010 at 6:20 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail.com>wrote:

> Hi all,
>
> Please find a proposal of a new AUTOCONF charter attached below.
> We need to define our new charter carefully to avoid yet-another 5 years
> discussion.
> Jari and chairs agreed to narrow down the charter items and go straight to
> solution space.
>
> This charter is not the final version. Please review it and provide us your
> comments.
> The discussion before the coming IETF is very important to set our charter
> ready soon.
>
> Please give us your feedback before July 9th.
>
> thanks,
> ryuji
>
> Ad-Hoc Network Autoconfiguration (autoconf)
> -------------------------------------------
>
> Current Status: Active
>
> 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. 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. Other 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.
>
> 2. 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 on 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 are
> will be specified as a part of the first item; it is expected that address
> uniqueness is guaranteed by the central node alone.
>
> Goals and Milestones:
>
> Dec 2010 First working group draft of the address configuration mechanism
> Apr 2011 First working group draft of the prefix configuration mechanism
> Sep 2011 Submission of the address configuration mechanism to the IESG for
> publication as a Proposed Standard
> Sep 2011 Submission of the prefix configuration mechanism to the IESG for
> publication as a Proposed Standard
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>