Subject: ZEROCONF WG actions

From: Erik Guttman <[email-masked]>
Date: Mon, 2 Sep 2002 13:58:44 +0200 (MEST)

The following drafts have been submitted to the IESG for consideration
as RFCs.

  draft-ietf-zeroconf-reqts-11.txt to Informational
  draft-ietf-zeroconf-ipv4-linklocal-07.txt to Proposed Standard

The latter document is currently in IETF last call for a final round.
Both documents have been through Working Group last call in prior
versions and have changed only very little since, in response to 
last call comments.

Please see the current charter at
  www.ietf.org/html.charters/zeroconf-charter.html

As previously discussed on the list, I propose changing the text as
follows.

From:

   This WG will produce two documents. The first describes the
   requirements for the configuration (and security) services,
   defaults, and mechanisms a node needs to fully participate on
   ZEROCONF networks and/or configured networks. The second, 
   which follows the first, will detail a 'profile' specifying
   which standards specifically satisfy ZEROCONF requirements. 

   The WG will also produce two protocol specifications. First, 
   the WG will develop a document describing automatic generation
   and assignment of link-local IPv4 addresses in environments 
   lacking host configuration (static or using DHCP). The
   document will describe existing practice as well as define
   recommendations for future implementations. Second, the WG
   will develop a profile of the Address Allocation Protocol (AAP) to
   provide Zero Configuration Multicast Address Allocation
   support for IPv4 and IPv6. 

To:

   This WG will produce two documents. The first describes the
   requirements for the configuration (and security) services,
   defaults, and mechanisms a node needs to fully participate on
   ZEROCONF networks and/or configured networks.

   The WG will also produce one protocol specification. 
   The WG will develop a document describing automatic generation
   and assignment of link-local IPv4 addresses in environments 
   lacking host configuration (static or using DHCP). The
   document will describe existing practice as well as define
   recommendations for future implementations. 

The goals should be changed from:

  Done        Submit internet-draft to be considered as an
              Informational RFC on Requirements for Zero Configuration 
              Networking. 
  Done        Submit Automatic Address Configuration for IPv4 to be
              considered as a Standards Track RFC. 
  AUG 01      Submit Multicast Address Allocation Protocol for Zeroconf
              Networks to be considered as a Standards Track RFC. 
  AUG 01      Submit internet-draft to be considered as an Informational
              RFC on Host Profile for Zero Configuration Networking. 

To:

  Done        Submit internet-draft to be considered as an
              Informational RFC on Requirements for Zero Configuration 
              Networking. 
  Done        Submit Automatic Address Configuration for IPv4 to be
              considered as a Standards Track RFC. 

According to this, we wait till our two active documents advance and do
additional work on them if necessary.  This accurately reflects the 
actual output of this working group.  No discussion or activity on 
ZMAAP or the host profile has been undertaken for over 18 months.

Comments?

Best regards,

Erik Guttman
ZEROCONF cochair

---

From: Erik Guttman <[email-masked]>
Date: Mon, 2 Sep 2002 15:05:19 +0200 (MEST)

On Mon, 2 Sep 2002 [email-masked] wrote:

> Quoting Erik Guttman <[email-masked]>:
> <snip>
> I am not sure what this means.
> 
> Do we not believe that some form of multicast address assignment is 
> needed in a zeroconf environment?

There has been no active interest on the working group to work on 
this topic for some time.

The disincentive for work here is that collisions on use of the same
multicast address can be disambiguated by different applications use
of distinct UDP port numbers.  Even if there are collisions on the 
same port #, multicast apps are supposed to be able to survive such
collisions.  Dave Thaler or Steve Hanna can point us to the right 
doc citing this guideline.  So the only real incentive for this 
protocol is optimization - to minimize collisions.  This is not a 
very strong argument.  In a larger multicast network one could 
deploy madcap to hand out non-colliding addresses.

> Do we not believe in that vendors will need guidance for implementing 
> zeroconf for hosts?

We have not distinguished ourselves in this working group as being able
to reach a concensus on which protocols are best suited for the tasks
described in the requirements document.

address allocation
  IPv6 includes stateless addrconf
  IPv4 address autoconfiguration will be specified by this WG

name resolution
  This is a charter item of the DNSEXT working group

multicast address allocation
  Discussed above

service discovery
  We have disagreement here that we have not been able to overcome.

> I have done a bit of work (on paper) for the host profile, and think that it will 
> be needed if there is any hope for interoperability.

We will get interoperability in each of the areas above as the IETF
standardizes protocol.  It is just that this working group is not 
the place to define how this works as a total 'bill of goods.'  The
IETF doesn't generally write profiles anyway.  Its not clear that we
could get one published as an RFC, even if we had the will to do so.

Best regards,

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n            Short email (<140 characters) to 
 Solaris Installation and Deployment       [email-masked] 
 Sun Microsystems                             cell: +49 172 865 5497