Re: [Autoconf] new charter

Teco Boot <teco@inf-net.nl> Wed, 10 November 2010 10:07 UTC

Return-Path: <teco@inf-net.nl>
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 4A92D3A6A18 for <autoconf@core3.amsl.com>; Wed, 10 Nov 2010 02:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 OMqTolkF3FG9 for <autoconf@core3.amsl.com>; Wed, 10 Nov 2010 02:07:17 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 01AF13A6A81 for <autoconf@ietf.org>; Wed, 10 Nov 2010 02:07:16 -0800 (PST)
Received: by yxe1 with SMTP id 1so191079yxe.31 for <autoconf@ietf.org>; Wed, 10 Nov 2010 02:07:43 -0800 (PST)
Received: by 10.100.124.5 with SMTP id w5mr4765067anc.84.1289383662533; Wed, 10 Nov 2010 02:07:42 -0800 (PST)
Received: from dhcp-61f2.meeting.ietf.org (dhcp-61f2.meeting.ietf.org [130.129.97.242]) by mx.google.com with ESMTPS id w3sm664814anw.25.2010.11.10.02.07.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 02:07:41 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <86A2091E-A92B-4485-A7F8-7A9829A39073@gmail.com>
Date: Wed, 10 Nov 2010 11:07:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BA62AD8-1F6D-4B6E-A905-77B031115557@inf-net.nl>
References: <86A2091E-A92B-4485-A7F8-7A9829A39073@gmail.com>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: "Autoconf autoconf@ietf.org" <autoconf@ietf.org>
Subject: Re: [Autoconf] new charter
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, 10 Nov 2010 10:07:18 -0000

Hi Ryuji,

I am happy to repeat my comments.
None is picked up, is it?

Regards, Teco

Op 24 aug 2010, om 22:16 heeft Teco Boot het volgende geschreven:

> I am happy with the dual approach.
> 
> Some remarks on the draft text:
> 
> It says that "other nodes will relay messages to the central node".
> On the list is was discussed the relay function could be co-located on the node itself.
> Is such a method rejected?
> 
> Typo: No new duplicate address detection mechanisms are will be specified
> "are" or  "will be". This is duplicate already :-)
> 
> I have problems with:
>>> it is expected that address uniqueness is
>>> guaranteed by the central node alone.
> 1) DHCPv6 doesn't work this way. Addresses are managed by the requesting node unique token, the DUID.
> 2) I have seen many DHCP implementations that use (link-local) probing for duplicate detection. This is for some guarantee for non-duplicates after a reboot and NV-storage. Quite often, CPE devices don't have volatile storage.
> 3) RFC 3315 specifies usage of DAD by the clients (18.1.8), e.g. for conflict resolving as result of point 2 above. 
> So the expectation is built on quicksand.
> Still, I think it is the right approach. Maybe just remove this sentence?
>    
> 


Op 10 nov 2010, om 08:25 heeft Ryuji Wakikawa het volgende geschreven:

> Hi all,
> 
> Here is the last charter sent to IESG. 
> 
> regards,
> 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. 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. 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.
> 
> - 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
> are will be specified; it is expected that address uniqueness is
> guaranteed by the central node alone.
> 
> 2. Analysis of Problem Space for distributed address configuration and
> service discovery.
> 
> The working group plans to establish design teams for rapidly advancing
> towards initial submissions for these two work items.
> 
> 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
> -Sep 2011 Rechartering or Closing WG
> 
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf