Subject: decision items for ZEROCONF WG list from IETF 48

From: Erik Guttman <[email-masked]>
Date: Tue, 8 Aug 2000 16:14:24 +0200 (MET DST)

The following is a synopsis of the discusson at IETF 48.  The minutes
are still being prepared (and should appear within a week).  I'm sending
this to the list as soon as possible to generate discussion.

I will surround in '*' marks all decisions, approved only in principal
at the WG meeting, which require approval on the mailing list.

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

The agenda of the meeting was:

  1. Discuss rechartering the WG
  2. Discuss issues with requirements draft 04.

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

1. Rechartering discussion

 . Further Work (on zeroconf protocols)

   Area            Protocol               Status

   Host Autoconf   
                   IP Host Address        Draft Standard
                   Autoconf for IPv6

                   IP Host Address        2 Internet Drafts
                   Autoconf for IPv4      NOT in DHC WG (no WG)

   Name to Address
   Resolution

                   IPv6 Node Information  Internet Draft (IPNG WG)
                   Queries

                   Multicast DNS          Internet Draft (DNSEXT WG)

   Service 
   Discovery
   (both are
   defined for
   IPv4 and IPv6)
                   Service Location       Proposed Standard (SVRLOC WG)
                   Protocol, Version 2
   
                   DNS SRV RR             Proposed Standard (DNSEXT WG)

   Multicast 
   Addresss
   Allocation
   (will be 
   defined for
   IPv4 and IPv6) 
                   Address Allocation     Internet Draft (no WG)
                   Protocol for Zeroconf
                   networks (AAPZ)

   The only two work items which have no home are AAPZ and IPv4 autoconf.
   The concensus at the WG meeting was to take on these work items.

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  Expand the ZEROCONF WG charter with    ***
             ***  the following goals:                   ***
             ***                                         ***
             ***  - Submit Autoconf IPv4 (to Prop. Std.) ***
             ***  - Submit MC Addr Allocation Protocol   ***
             ***    (to Prop. Std.)                      ***
             ***                                         ***
             ***********************************************
             ***********************************************

 . The proposed revised charter goals were the following:

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  New list of ZEROCONF WG milestones:    ***
             ***                                         ***
             ***  09/00 Submit Zeroconf Reqts to IESG    ***
             ***        (to Informational RFC)           ***
             ***  12/00 Submit Autoconf IPv4             ***
             ***        (to Proposed Standard RFC)       ***
             ***  12/00 Submit MC Addr Allocation        ***
             ***        Protocol                         ***
             ***        (to Proposed Standard RFC)       ***
             ***  03/01 Submit Zeroconf Requirements     ***
             ***        (to Informational RFC)           ***
             ***                                         ***
             ***********************************************
             ***********************************************

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

2. Comments on Zeroconf Requirements

 . Currently the Requirements state that a host

     MUST transition to configured operation.

   Shouldn't we instead say that a host

     MAY transition to configured operation.

   Arguments pro:

    + Some hosts may never want to be configured.
    + Allows local connections to persist even if 
      configuration is possible (ie. DHCP comes up).
    + Does not create any arbitrary requirements -
      leave policy up to the implementors.

   Arguments contra:

    + This is more complicated:  It leads to a scoped
      address architecture, as per IPv6:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt

    + This may lead to different host behavior than is 
      implemented now.  Some may not like the new behavior.

  The WG meeting concensus was to expand the charter to allow
  transition and detection of infrastructure to be optional.
  There were only two dissenters, who expressed they thought
  that this would reduce our chances of completing our work 
  in a timely way.

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  Hosts MAY transition to configured     ***
             ***  operation.                             ***
             ***                                         ***
             ***  This change will require a new set     ***
             ***  of requirements to make sure that      ***
             ***  coexistence of zeroconf and non-       ***
             ***  zeroconf configuration will neither    ***
             ***  interfere with existing IP networks    ***
             ***  nor lead to difficulties in the        ***
             ***  implementation and interoperability    ***
             ***  of IP hosts.                           ***
             ***                                         ***
             ***********************************************
             ***********************************************

 . Periodic messages are not the requirement.  Detecting state
   change (and allocation conflicts) is the requirement.

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  Change language in the reqts draft     ***
             ***  requiring periodic messages to a       ***
             ***  requirement to detect and correct      ***
             ***  conflicts and state changes in a       ***
             ***  timely way.                            ***
             ***                                         ***
             ***********************************************
             ***********************************************

   Periodic messages should not be sent by hosts if at all possible.
   Hosts which are not communicating should ideally not be sending
   any messages at all.

 . Once you deploy a server which configures hosts, this is not
   a zeroconf protocol.

   This was widely agreed to at the WG meeting.  This could potentially
   change the requirements document, so let's agree to it on the list.

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  Protocols in which a server configures ***
             ***  hosts (which are clients of that       ***
             ***  protocol) are not zeroconf protocols.  ***
             ***                                         ***
             ***********************************************
             ***********************************************

   It is a separate question whether the servers which are configuring
   other hosts (say mini-DHCP servers) are themselves automatically
   configured.  What we mean by a zeroconf protocol is that it is peer
   to peer (no host is acting as a configuration server).  The act of
   turning on such a configuration server is in effect 'configuring'
   the network.

   The implication is that DHCP, MADCAP and DNS are not zeroconf
   protocols, though they may perhaps automaticly configure their
   server state.

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

There are no doubt other discussion issues which will arise from the
minutes when they are published.  I wanted to start the ball rolling
on these 'decision items' ASAP.  Please send your comments in the next
2 weeks (before 22/08).  

Erik Guttman
ZEROCONF WG cochair

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 8 Aug 2000 10:51:51 -0700

Hi Erik,

I just read all of your decision items (below) and agree
with all of them.  I also read through your previous
message about proposed changes to the ZC Reqts doc and
agree with all of them.

I think defining Autoconf IPv4 is *very* high priority for vendors of
network products and operating systems.

Good work,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Tuesday, August 08, 2000 7:14 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: decision items for ZEROCONF WG list from IETF 48

   Area            Protocol               Status

   Host Autoconf   

   Name to Address
   Resolution

   Service 
   Discovery
   (both are
   defined for
   IPv4 and IPv6)

   Multicast 
   Addresss
   Allocation
   (will be 
   defined for
   IPv4 and IPv6) 

   Arguments pro:

   Arguments contra:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-01.
txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt

Erik Guttman
ZEROCONF WG cochair