Re: [Autoconf] new charter

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