Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter

Teco Boot <teco@inf-net.nl> Tue, 24 August 2010 20:16 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 36EDC3A694C for <autoconf@core3.amsl.com>; Tue, 24 Aug 2010 13:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level:
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 nSwghwIM1jV3 for <autoconf@core3.amsl.com>; Tue, 24 Aug 2010 13:15:58 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id AAF3B3A694E for <autoconf@ietf.org>; Tue, 24 Aug 2010 13:15:56 -0700 (PDT)
Received: by ewy22 with SMTP id 22so3987812ewy.31 for <autoconf@ietf.org>; Tue, 24 Aug 2010 13:16:29 -0700 (PDT)
Received: by 10.213.63.142 with SMTP id b14mr5970936ebi.33.1282680989038; Tue, 24 Aug 2010 13:16:29 -0700 (PDT)
Received: from [192.168.2.166] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id u9sm733019eeh.23.2010.08.24.13.16.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 13:16:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-22--568892277
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <FDC5D667-0E9F-4AC6-A114-16BB703183BF@thomasclausen.org>
Date: Tue, 24 Aug 2010 22:16:25 +0200
Message-Id: <8825A5B9-822A-4121-AEA0-9B741A2AEA3A@inf-net.nl>
References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> <FDC5D667-0E9F-4AC6-A114-16BB703183BF@thomasclausen.org>
To: Thomas Heide Clausen <ietf@thomasclausen.org>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF 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: Tue, 24 Aug 2010 20:16:03 -0000

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?
   

Teco


Op 21 aug 2010, om 07:50 heeft Thomas Heide Clausen het volgende geschreven:

> Dear All,
> 
> (sorry, traveling and so only catching up on mails now)
> 
> It appears that this email made it to me, but not onto the 'list - for which we apologize. 
> 
> The original WGLC deadline was set to August 26, in view of the message not making it last time around, the new WGLC deadline is August 30, 2010 (Ryuji, I have edited your email to that effect).
> 
> Kindly provide your feedback, even if it is to express agreement with the proposed charter.
> 
> Sincerely yours,
> 
> Thomas
> 
> Begin forwarded message:
> 
>> From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
>> Date: August 17, 2010 19:05:04 GMT+02:00
>> Subject: WGLC for the AUTOCONF charter
>> 
>> Hi all, 
>> 
>> This is another WGLC for our new charter. 
>> We had good consensus at the meeting, but will confirm the consensus on the list again.
>> 
>> The deadline for this WGLC is going to be Aug 30.
>> 
>> Please give us your opinion.
>> 
>> regards,
>> ryuji
>> 
>> ps. We'll send out the summary of the another WGLC for RFC5889. 
>> 
>> 
>> 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:
>> 
>> -Dec 2010 First working group draft of the "DHCPv6 operation over MANET"
>> -Dec 2010 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