Subject: summary of discussion on draft-ietf-zeroconf-reqts-08.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 20 Jul 2001 16:25:06 +0200 (MET DST)

Folks,

This email constitutes a WG action:  It summarizes 
comments and their results.  It is not a call for further
discussion unless it is to take issue with the statements
below or conclude an unresolved point.  This document has
already gone through WG last call _twice_.

Action: 

  Open      = more discussion needed
  No change = no action to be taken, keep text
  Change    = take suggested change

In each case where there is an open topic, I make a suggestion
in order to advance discussion.

Thomas, as you raised most of these issues, please see if you 
are satisfied by the suggestions and actions below.

---------------------------------------------------------------------
08.01.  New title

"Thomas Narten" <[email-masked]> wrote:
> How about a more descriptive title than "zeroconf requirements"

Suggestion: Zeroconf IP Host Requirements

            This makes it clear that we are discussing hosts not
            routers.

Action: Open
---------------------------------------------------------------------
08.02 MAC addr as config info

"Thomas Narten" <[email-masked]> wrote:
> >    A zeroconf protocol is able to operate correctly in the absence
> >    of configured information from either a user or infrastructure
> >    services such as conventional DHCP [RFC 2131] or DNS [RFC 1034,
> >    RFC 1035] servers. Zeroconf protocols may use configured
> >    information, when it is available, but do not rely on it being
> >    present. One possible exception is the use of MAC addresses
> >    (i.e. layer two addresses) as parameters in zeroconf protocols.
>
> I do not consider a MAC address to be configured information. It is
> built-in as far as the end user is concerned.

While this is strictly true, in some cases it is configurable.
(Solaris for instance allows this, as do many PC NIC drivers.)
A second consideration was whether ANY parameters could be used
in zeroconf protocols, built-in or otherwise.  We wanted to
emphasize that MAC addresses were OK for use.

Action: No change.
---------------------------------------------------------------------
08.03 DHCP used as ZC protocol?

"Thomas Narten" <[email-masked]> wrote:
> This may be a minor nit, but it may be worth pointing out that DHCP
> *protocols* could be used in a zeroconf environment, so long as no
> user configuration were needed. One can imagine a DHCP server figuring
> out a lot of things on its own without being configured (and there has
> been talk on the list about this).

Dan Senie <[email-masked]> wrote: 
> There was a lot of debate about this. As I recall, the concern is 
> that Zeroconf can't rely on there being a server. No server means 
> no DHCP.

Stuart Cheshire <[email-masked]> wrote:
> No, the focus of Zeroconf is, "IP should work even if there *isn't* a 
> DHCP server on the network."

"Thomas Narten" <[email-masked]> wrote:
> So I see. :-) I'm OK leaving the text as is then.

Action: No change.
---------------------------------------------------------------------
08.04 terminology 

"Thomas Narten" <[email-masked]> wrote:
> > 1.5 Routable Protocol Requirement
> > 
> >    If a protocol is intended to span multiple IP subnets it SHOULD
> >    NOT use broadcasts or link-local addressing.
> 
> define what link-local addressing is? i.e., self-configured addresses?

Dan Senie <[email-masked]> wrote: 
> yes. See the link local draft...

"Thomas Narten" <[email-masked]> wrote:
> Ah, yes, that makes sense.

Action: No change.
---------------------------------------------------------------------
08.05 why not allow MC and BC for protocols spanning multiple subnets?

"Thomas Narten" <[email-masked]> wrote:
> >    Requirement:
> >    - Protocols intended to span multiple IP subnets SHOULD NOT use
> >      broadcasts or link-local addressing.
> 
> Why not? just stating something should or should not be done without
> context isn't always very convincing.

Dan Senie <[email-masked]> wrote:
> Link local addressing can't be routed per definitions in the 
> other draft.

"Thomas Narten" <[email-masked]> wrote:
> My point was more on the "should not use broadcast". Per the
> definition of link-local addressing, it *can't* be used -- routers
> will drop the traffic, so this would seem to need to be stronger than
> a "SHOULD NOT".

Note that DHCP and a few other protocols use broadcast and span
multiple subnets.  But in order to do this, the protocol requires
special router assist.  In general this is a bad idea as it requires
router software changes.

Action: Change text to "MUST NOT"
---------------------------------------------------------------------
08.06  topology change text problems

"Thomas Narten" <[email-masked]> wrote:
> >    Topology changes or other events such as adding and removing hosts
> >    may cause conflicts and state changes within a protocol. Zeroconf
> >    protocols must be able to resolve conflicts and state changes caused
> >    by topology changes or other events. The scenario in the 2.1.2 Bridge
> >    Installed section is the only scenario that illustrates the need for
> >    this requirement, thus the below requirement is duplicated in section
> >    2.1.2. However, this requirement applies to all protocol areas.
>  
> Suggested rewording of the first part:
> 
>    Topology changes or other events such as adding and removing hosts
>    may cause changes to the overall system state, invalidate
>    assumptions made by some protocols, and lead to incorrect or
>    undesirable operating states.  Zeroconf protocols must be able to
>    detect and resolve conflicts and state changes caused by topology
>    changes or other events in some cases. The scenario in the 2.1.2
>    Bridge Installed section is the only scenario that illustrates the
>    need for this requirement, thus the below requirement is duplicated
>    in section 2.1.2. However, this requirement applies to all protocol
>    areas.

Action:  Change text as suggested.
---------------------------------------------------------------------
08.07 open ended text

"Thomas Narten" <[email-masked]> wrote:
> >    Requirement:
> >    - MUST respond to state changes and resolve conflicts in a timely
> >      manner.
> 
> Note that his is really open ended, so I don't really know what "MUST"
> means specifically. What conflicts need to be resolved? Indeed, what
> is a "conflict"? My suspicion is that having a MUST here in a generic
> sense is not appropriate. What you want is a MUST in specific
> sitations that it is felt should or should not happen.t

Suggestion:   Spell this out for each protocol area:

  address autoconfiguration - detect and eliminate duplicate addresses.
  name resolution - allow resolution of names which could not
     previously be resolved.  In particular, if a host wishes to 
     resolve its own name to determine if it is unique, it will
     be able to detect this conflict and resolve it in a timely
     manner.
  service discovery - allow discovery of previously undiscovered
     services.
  multicast address allocation protocol - detect and eliminate duplicate
     addresses.

Action: Open
---------------------------------------------------------------------
08.08 say some more about routing information

"Thomas Narten" <[email-masked]> wrote:
> >    Requirements:
> >    - MUST configure an appropriate netmask.
> >    - MUST have unique IP addresses within an IP subnet.
> >    - MUST have some routing information
> >      (for the internetwork scenario).
> 
> On the last point, would it be more correct to say, needs the address
> of one or more default routers? Or is there more to this?

Aidan William <[email-masked]> replied:
> I think the wording takes care to avoid the term "default router".
> Routing information may be a default route, but might not be.
> There was even discussion of hosts ARPing for every address and
> having the router do proxy ARP for destinations in different subnets.

"Erik Guttman" <[email-masked]> wrote:
> The background is that any mention of default router configuration
> implies that there are routers in the network, which may not be the
> case.  Consider RFC 1122, section 3.3.1.1:
> 
>             The host IP layer MUST operate correctly in a minimal
>             network environment, and in particular, when there are no
>             gateways.  For example, if the IP layer of a host insists on
>             finding at least one gateway to initialize, the host will be
>             unable to operate on a single isolated broadcast net.
> 
> This clearly indicates that there is no requirement, in the link-local
> communication case, to know of any gateways.  
> 
> What we mean in the above case is that some routing information is
> needed, as stated in RFC 1122, section 3.3.1.2:
> 
>             The IP layer MUST support multiple default gateways.
> 
> The ZEROCONF requirement is that routing state is available in the
> IP layer - which *may or may not* include a list of default gateways.
> In one plausible case, a LL-only device will use the 'arp for everything'
> forwarding policy, discussed by Stuart.  In the case where DHCP configures
> an interface, default gateway(s) will be configured, while still allowing
> for delivery of datagrams to connected networks without the need for a 
> gateway.  
> 
> We aimed at text which supported both possibilities, without requiring
> us to spell them out in detail.

Action: change text to clarify zc may or may not include a list of gateways.
---------------------------------------------------------------------
08.09 scoping

"Thomas Narten" <[email-masked]> wrote:
> >    - MUST have unique IP subnets within an internetwork
> >      (only for the internetwork scenario).
> 
> Do you need to scope this more? I.e., can't an "internetwork" consist
> of the entire Internet (per the earlier definition?)

Aidan William <[email-masked]> replied:
> Perhaps "internetwork" should be a "zeroconf internetwork" in this
> section, where a "zeroconf internetwork" is the bunch of subnets
> connected to exactly one router.

Erik Guttman <[email-masked]> wrote:
> The text above is sufficiently general that it leaves room for multiple
> router zeroconf interface autoconfiguration to be standardized in the 
> future.  
> 
> We did not preclude multiple routers from our charter because we thought 
> it was a bad idea.  Rather, we did not think we could standardize 
> multi-router zeroconf protocols in a timely manner.  The requirements 
> document does not need to echo our charter humility, restricting future 
> (perhaps immanent) standardization efforts. 

Suggestion: clarify that this is currently only specified on a 
            single link or a network with routers whose configuration
            is out of scope for this spec.

Action: Open
---------------------------------------------------------------------
08.10 cannot understand text

"Thomas Narten" <[email-masked]> wrote:
> >    Topology changes from the installation of a bridge or a router may
> >    create the following problems: multiple default routes that cause
> >    dial out lines to be used instead of broadband connections,
> >    duplicate IP addresses within an IP subnet, or duplicate IP
> >    subnets within an internetwork.
> 
> I don't understand the comment (or implication) about multiple default
> routes leading to dial-out lines being used.

Erik Guttman <[email-masked]> wrote:  
> This is supposed to mean that if one indiscriminately dropped  
> routers or bridges into a network, inappropriate topologies may 
> result leading to dumb forwarding paths.  How this could happen, 
> given that routers need to be configured, I don't know. I think 
> this paragraph should be dropped. 

Action: Change - Drop paragraph
--------------------------------------------------------------------- 
08.11 resolve conflicts - should be more specific

"Thomas Narten" <[email-masked]> wrote:
> >    Requirement:
> >    - MUST resolve conflicts and state changes in a timely manner.
> 
> Can the document be more specific and say just what conflicts need to
> be resolved? Or is the assumption that the previously discussed issues
> is what needs to be addressed?

[email-masked] wrote:
> I read this as referring to section 2.1.1, where there are a set of
> uniqueness requirements, etc.  Maybe it could do so explicitly.
> For me, this requirement adds an on-going consistency requirement for
> everything in 2.1.1.

Suggestion: Isn't this addressed by 08.07 above?

Action: Open
---------------------------------------------------------------------
08.12 IPv6 considerations for interface configuration

"Thomas Narten" <[email-masked]> wrote:
> > 2.1.3  IPv6 Considerations
> > 
> >    IPv6 allows a host to select an appropriate IP address, netmask,
> >    and routing information, thus if a host is using IPv6, a zeroconf
> >    IP interface configuration solution already exists.
> 
> 
> Is this fully correct? Do routers automatically (without  user
> configuration) advertise themselves as default routers?
> 
> Indeed, I'm a bit confused about whether this document assumes
> multiple subnets are present. It seems to, but I thought the WG
> decided that a single router was assumed. It would be good to state up
> front what the assumptions are for the enivironment zeroconf is
> operating in. Will there be just one router? Or multiple routers? Or
> no routers?

Suggestion: We have to support 0 routers.  We can support 1+ router.
  Folks want to consider how 1 router can be auto configuring, but
  this is tangential to the requirements in this document.
  We have nothing to say about how routers are configured.  Let's
  make it clear the ZC requirements concern only host configuration 
  not router configuration.

Action: Open
---------------------------------------------------------------------
08.13 bad example

"Thomas Narten" <[email-masked]> wrote:
> > 2.2.1  Web Browsing
> > 
> >    An URL typically contains the name of a Web server. When a user
> >    enters an URL into a Web browser, the name must be translated to
> >    an IP address before any actual Web browsing occurs. Web servers
> >    often record log files of accesses, and wish to map the client's
> >    IP address back to a human-readable name for recording in the log
> >    file. Thus, a mechanism to translate the IP address to a name is
> >    required.
> > 
> >    Requirement:
> >    - MUST translate a name to an IP address.
> >    - MUST translate an IP address to a name.
> 
> This text curiously doesn't mention the DNS. But, for the web server,
> isn't the DNS reverse lookup specifically what is assumed/required?
> Seems like the reqirement is much more specific than just "translate
> name to address" and vice versa, and involves integration with the
> DNS.

Stuart Cheshire <[email-masked]> writes:
> In practice, we believe that Multicast DNS will be the answer. However, 
> from a strict requirements standpoint, the web server calls an OS or 
> library API routine to map an address to a name -- whether that's done 
> using DNS packets, or mDNS, or NetBIOS, is of no concern to the web 
> server software.

"Thomas Narten" <[email-masked]> wrote:
> Is there any sort of requirement that whatever is developed is
> transparent to existing applications? I.e., looks like DNS to (most)
> applications?
>
> I would think that requiring applications to be aware that they are on
> a zeroconf network and then behave differently sets a pretty high bar.

Erik Guttman <[email-masked]> wrote:
> Yes.  What we want to say is that the upper layer support apps relying
> on RFC 1123 DNS interfaces will continue to be supported.  We do not
> have to, nor should we, say in the reqts doc how this support is achieved.

Erik Guttman <[email-masked]> wrote:
> The web server example is motivate and support the listed reqts
> for forward and reverse lookup.  What we should really do, perhaps,
> is require support for RFC 1123, section 6.1.
<snip>
> In summary, I suggest that this text be changed to:
>
>  2.4 Service Discovery Scenarios
> 
>     Service discovery protocols MUST allow users or software to 
>     discover instances and select among available services.  This 
>     removes the requirement that the user or client software know 
>     a server's location in advance and in order for the client 
>     to communicate with the server.

Aidan williams <> wrote:
> I can't off the top of my head think of a protocol which absolutely requires
> reverse lookup of names (if we had one, we should use it as an example).

Erik Guttman <[email-masked]> wrote:
> I think we should insist on requiring continued support for DNS app level
> interfaces, as described in RFC 1123, section 6.1.  

Action: Change text.

---------------------------------------------------------------------
08.14 unclear requirement

"Thomas Narten" <[email-masked]> wrote:
> > 2.3.1  Scope Enumeration
> > 
> >    Applications that leave the choice of scope up to the user require
> >    the ability to enumerate what scopes the host is operating within.
> >    In addition, services that are assigned relative addresses require
> >    the ability to enumerate what scopes the host is within; only then
> >    will a host be able to apply the relative address to a scope.
> > 
> >    Requirements:
> >    - MUST list which of the scopes (local, link-local, or site-local)
> >      are available for hosts.
> >    - MUST list per-scope address ranges that may be allocated.
> 
> I'm not clear what the requirement above is. That is, *who* is
> responsbile for the MUST? The application? How is the application
> supposed to determine this? Is the point that this information must
> somehow be determinable? (General comment: This may all be an artifact
> from the fact that the Requirements bullets are not using full
> sentences.)

Erik Guttman <[email-masked]> wrote: 
> I agree the writing is not clear here.

"Aidan Williams" <[email-masked]> replied:
> Yes, I think the point is that there should be a way for the
> application to find this information out.  Incidentally, this doesn't
> seem to just be a zeroconf requirement, but is probably true of any
> networking with non-trivial multicast applications.

Erik Guttman <[email-masked]> wrote: 
> Yes:  This requirement is derived from MALLOC WG's requirements.
> The requirement here pertains to a zeroconf multicast address allocation
> protocol.  This protocol has to expose its capabilities to applications.
> 
> ZMAAP only works in a subset of the scopes listed above (link-local,
> unicast-prefix based and subnet-local).  The ZMAAP API exposes this
> list to applications.  A future version of ZMAAP capable of interoperation
> with MADCAP servers could support local, site-local or other scopes
> as well.

Suggestion:
  MUST -> Application support software used to autoconfigure
     multicast addresses MUST

Action: Open
---------------------------------------------------------------------
08.15 IPv4 vs IPv6 wrt. multicast address autoconf

"Thomas Narten" <[email-masked]> wrote:
> > 2.3.4  IPv6 Considerations
> > 
> >    To date, no range has been reserved for source-specific addresses
> >    in IPv6.  Hence, until such a range is reserved, dynamic allocation
> >    of source-specific addresses applies only to IPv4.
> > 
> >    To date, no range has been reserved for dynamic allocation of
> >    Link-scoped addresses in IPv4.  Hence, unless such a range is
> >    reserved, dynamic allocation of link-scoped addresses applies only
> >    to IPv6.
> 
> Is there reason to think that the mechanisms in IPv4 and IPv6 might be
> different?

Erik Guttman <[email-masked]> wrote: 
> The difference lies in the current state of IANA reservation and 
> standardization, not in what we think the protocols need to do or
> how they'll do it.

Action: Closed
---------------------------------------------------------------------
08.16 user specific language in service discovery

"Thomas Narten" <[email-masked]> wrote:
> > 2.4 Service Discovery Scenarios
> > 
> >    Service discovery protocols allow users to select services and/or
> >    hosts by a name that is discovered dynamically, rather than requiring
> >    that the user know the name in advance and type it in correctly.
> 
> Can't an application find and select services without the user being
> queried? E.g., isn't DNS a service? Should the user choose the DNS
> server?
>
> Should the user always be prompted, or is there room for the user not
> having to select at all, if there is only one choice?

Dan Senie <[email-masked]> wrote:
> If there's no server serving DNS, it'll be hard to use it.

Erik Guttman <[email-masked]> wrote:
> What we really want to say is that services can be discovered and selected, 
> by users or by a computer program.  That way the location of the server
> does not need to be known in advance for client-server software to function.
> 
> We will quickly get into a rathole about DNS here.
<snip>
> I suggest that this text be changed to:
>   Service discovery protocols allow users or software to discover
>   and select among available services.  This removes the requirement
>   that the user or client software know a server's location in 
>   advance in order for the cleint to communicate with the server.

Action: Change text.
---------------------------------------------------------------------
08.17 explain security requirements text better, for IPv4

"Thomas Narten" <[email-masked]> wrote:
> 
> >    The IPv4 interface configuration protocol MAY omit security
> >    mechanisms if and only if that protocol is not used for IPv6 and
> >    cannot be extended to support IPv6.  It is strongly recommended that
> >    it include security mechanisms, because many protocols are extended
> >    later in ways not anticipated by the original developer(s).
> 
> Explain

This tangled formation came from (a) simple text from me saying
since ARP is insecure, IPv4 autoconf MAY be too, (b) Ran noting that
IPv6 may be implemented over IPv4 so more care would be needed in
the formulation and (c) Stuart's polishing the text for clarity
while trying to preserve as much as possible so as to not force
a new last call (which happened anyway).

What it means is:

IPv4 autoconf MAY be insecure to configure IPv4 interface parameters
(as ARP is insecure).

If the IPv4 autoconf mechanism is used to support IPv6, it had better
be secured (at some level - say the IPv6 in IPv4 packets may include
IPsec AH for the ND messages).

Ran wanted to make sure that even though we may omit security (we
do in IPv4 LL autoconf) there's some text indicating its a Bad Thing.

Suggestion: Leave it alone.

Action: Open
---------------------------------------------------------------------
08.18 broken syntax

"Thomas Narten" <[email-masked]> wrote:
> >   use a printer that doesn't exist, no printed upon paper appears.)
> 
> parsing

Action: Change text.
---------------------------------------------------------------------
08.19

"Aidan Williams" <[email-masked]>
> [ I just noticed a typo too:
> Section 1.  "With respects to hosts, it discusses .." ]

Action: Change text.
---------------------------------------------------------------------

Erik Guttman
ZEROCONF WG cochair

---

From: Aidan Williams <[email-masked]>
Date: Mon, 23 Jul 2001 13:21:06 +1000

Greetings,

I've trimmed out everything that isn't an "Open" issue.

I'm happy with this title.  Three of the remaining Open issues relate
to this, and benifit from a tighter focus.

What is happening to the MUSTs and SHOULDs here?  Even though I would
be comfortable with MUSTs for the first three, it seems like we could
get away with a SHOULD for the last one (multicast).

In general though a SHOULD ought to suffice, and the specific protocols
(e.g. IPv4LL) can specify the MUST behaviour where it makes sense.
I'm wary of pulling up detailed protocol requirements into this
document, although I do think those above are useful and sensible examples.

A different way of stating the requirement is that all protocols MUST
be able to cope with the merging of two zeroconf networks.  I think
that the adding and removal of *hosts* isn't the important thing, nor
is topological change in the network.  The real issues arise from
merging two islands which have each successfully engaged in a zeroconf
protocol to produce consistent addresses/names/whatever.  The act of
merging potentially destroys the consistency that the protocol has
worked to build, and the protocol must be able to cope with this.

I'm happy with a pragmatic focus on a single link.

    >   This makes it clear that we are discussing hosts not

Routers presumably configure themselves as "hosts" for the purposes
of zeroconf protocols covered by this spec.

Yes, probably.  Same comment about coping with merging.

I'm happy with that.  Zeroconf router configuration is future work.
Mini-dhcp is to my way of thinking not strictly zeroconf.

[snip]
>   MUST -> Application support software used to autoconfigure

Looks fine to me.

Perhaps we could use your expanded text on what the paragraph meant?

Can we include an example given for IPv6 over IPv4 which highlighted
the issue?

Of the v6 over v4 mechanisms I am aware of:
  - some are IPv6 tunneled in unicast IPv4 packets (e.g. 6to4)
  - one uses IPv4 multicast as a link layer for IPv6 (6over4).

I cannot see how a tunneling scheme over unicast IPv4 could avoid
being being vulnerable to ARP attacks (DoS in particular), and an
example would clear that up.

6over4 is less problematic from a security point of view because it
does not need to solicit a destination mac address using ARP
(all frames are sent to multicast destinations, and the address is
computed by hashing the v6 destination address).

Reducing our scope to one link could avoid the need to talk about
things like 6to4 entirely.

regards
	aidan
____
:wq!

---

From: Erik Guttman <[email-masked]>
Date: Mon, 23 Jul 2001 09:15:04 +0200 (MET DST)

Aidan,

> get away with a SHOULD for the last one (multicast).

I agree.  One thing we don't consider here or in the ZMAAP spec is the
consequence of a multicast address conflict.  If two applications use
the same MC address at different port #s, there's non-optimal use of
the network (if the MC scope is greater than 1) and the link layer 
(the other app's datagram is filtered at the network instead of by the
NIC).  But this will not lead to the *failure* of either application.
	
> worked to build, and the protocol must be able to cope with this.

I agree this is the issue - which is the point of the section from
which this text comes.  The problem, as Thomas pointed out, is that
it is not specific in what the MUST implies.

The real question before us is - does this section need more text?
Should we list what the undesirable conflicts are which must be
resolved in the case of each protocol area?

Erik

---

From: Aidan Williams <[email-masked]>
Date: Tue, 24 Jul 2001 11:40:25 +1000

> resolved in the case of each protocol area?

I think it could be clearer, perhaps as follows (which is a combination
of more focus on merging, and your suggestions per-protocol).

regards
	aidan
____
:wq!

1.6 Conflicts and State Changes Requirement

   Zeroconf protocols are designed to consistently manage network
   resources (e.g. unicast and multicast addresses, host names).
   Consistency must be maintained when new hosts and networks are
   added or removed.  In addition, consistency must be restored when
   two independant zeroconf networks are connected together, as
   illustrated in Section 2.1.2 Bridge Installed.

   Requirements:
     - Zeroconf protocols MUST detect inconsistencies in a timely
       manner.
     - Zeroconf protocols MUST restore consistency in a timely
       manner.

   These result in the following requirements for each protocol area:

     Address autoconfiguration
         MUST detect and eliminate duplicate addresses.

     Name resolution
         MUST allow resolution of names which could not previously be
         resolved.  In particular, if a host wishes to resolve its own
         name to determine if it is unique, it will be able to detect
         this conflict and resolve it in a timely manner.

     Service discovery
         MUST allow discovery of previously undiscovered services.

     Multicast address allocation protocol
         SHOULD detect and eliminate duplicate addresses.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Jul 2001 08:25:29 -0400

Only commenting where I disagree.

>             This makes it clear that we are discussing hosts not

This is better, but can we do even better?.  My overall concern is
that many (most?) folks (i.e, those not in the WG) won't have any idea
what the term "zeroconf" means. So if that term could be expanded out
somehow...

> (Solaris for instance allows this, as do many PC NIC drivers.)

Yes, but in those cases the need for configuration is necessary for
some other reason. I.e, home users won't be dealing with this. And it
is an option to configure this, not a requirement in most cases.

> emphasize that MAC addresses were OK for use.

The last sentence saying "mac addresses are an exception" I find
misleading. They are not configured (in the sense an end user will
configure them), yet the sentence reads as if their use is an
exception to the rule that configured information can be used when
present, but must not be relied upon.

How about changing the last sentence to:

The use of MAC addresses (i.e. layer two addresses) as parameters in
zeroconf protocols is generally acceptable because they are globally
unique and readily available on most devices of interest.

But this is a minor wording issue in the overall scheme of things.

>   multicast address allocation protocol - detect and eliminate duplicate

This works for me.

> Action: change text to clarify zc may or may not include a list of

Works for me. My intitial reaction came from the terminology "must
have routing information" which seemed open ended to me, and could be
implied to read needs to have more than just a pointer to a default
router. But if one considers the netmask of the attached link to be
part of "rouring information" the statement makes more sense.

>             is out of scope for this spec.

The original wording as can be read to imply IP subnets MUST be
numbered uniquely within an internetwork. If "internetwork" includes
the entire Internet (my read of the definition is that this is true),
then this requirement would appear to be unachievable. 

> Suggestion: Isn't this addressed by 08.07 above?

I think so.

>   not router configuration.

I'm OK with leaving the text as is.

>   MUST -> Application support software used to autoconfigure

Not sure  what the proposal here is.

> Suggestion: Leave it alone.

The current text doesn't (to me) communicate the message you explained.

Thomas