Subject: IETF 50 discussion of ZMAAP -> action

From: Erik Guttman Sun Frankfurt Staff Engineer <[email-masked]>
Date: Mon, 23 Apr 2001 14:35:52 +0-100

As a sanity check we asked who would actually implement
the protocol.  Members of ~6 different organizations 
(including vendors) said they would, so there is indeed 
interest.

Those attending the meeting made some choices which need 
to be verified by the working group, on the mailing list.
These will serve to simplify the protocol, if accepted.

1. Only allocate addresses in scopes which are not
   allocated by MADCAP.  

2. Compatibility with AAP does not need to be maintained.

We will decide this on the list - if you have any objections
please raise them by April 6.

- - - - - - - - - - - - -  

Discussion:
   
1. This means that transition mechanisms would not be 
needed.  As with other zeroconf protocols (v4LL, for 
example) transition to 'configured state' is complex, 
has timing issues and ultimately places external servers
in control of what should really be a local feature of
the network.  Removing transition mechanisms simplifies
ZMAAP and stabilizes its operating model.

Addresses from the following scopes available for allocation 
using ZMAAP:

  link-local address-specific (IPv4 & IPv6)
  global, site- & link-local unicast prefix-based addresses
  (IPv6, IPv4???)

2. We have already diverged considerably from AAP.  We
do not want periodic messages, waiting intervals, we 
need lease IDs, we prefer 'time to live' over absolute
times, etc.  If this is really OK, we can drop the last
vestiges of AAP from the header & other elements to make
the protocol as simple as possible.

Erik