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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Ryuji, all,

I have some comments:

- Why are we assuming a DHCP-based solution? or a more general question:
why are we pushing for a centralized solution? I'm neutral on this at
this point, but I think it'd be good to analyze the different pros and
cons before taking such an important decision.

- Related with the former, I strongly believe that analyzing the
existing solution space is a step that would help a lot in designing a
solution. We have been working in the past on solutions surveys and
problem space analysis:

http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-05
http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02

I think it is worth adding an item in the charter for an informational
document that analyzes the solution space. What do people think? do you
think it is worth adding an item in the charter for this? we have
already some documents that could serve as starting point and their
authors are willing to work on this to make it progress. Would do other
people contribute to that effort (e.g., suggesting updates, reviewing
it)?

Thanks,

Carlos

On Mon, 2010-06-28 at 21:20 -0700, Ryuji Wakikawa 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 <[e-mail]>
> Thomas Clausen <[e-mail]>
> 
> Internet Area Directors:
> Ralph Droms <[e-mail]>
> Jari Arkko <[e-mail]>
> 
> Internet Area Advisor:
> Jari Arkko <[e-mail]>
> 
> Mailing Lists:
> General Discussion: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67