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

From: Erik Guttman <[email-masked]>
Date: Wed, 1 Aug 2001 16:00:26 +0200 (MET DST)

Thomas,

I make another attempt to wrap this up - responding only to those
points where aggreement hasn't yet been reached.

> > > 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.
> 
> 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...

How about "Requirements for Hosts with Zero Configuration Networking Support"
 
Its a bit wordy, but it makes it clear that these are not 'host requirements,'
and that the requirements are only for certain hosts (not every host, routers,
etc.)

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.)
> 
> 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.
> 
> > 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.
> 
> 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.

Let's adopt your text.
 
Action: Open.
   
> > ---------------------------------------------------------------------
> > 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.
> 
> 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. 

So how about:

   - MUST have unique IP subnets within an internetwork
     (This is only for the case when there is one or more router attached
     in the network where autoconfigured hosts.  How routers obtain
     their configuration is beyond of the scope of this document.)
     
Action: Open.

> > ---------------------------------------------------------------------
> > 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
> 
> Not sure  what the proposal here is.

Change the text:

    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.

to:

    Requirements: 
    Application support software used to autoconfigure multicast addresses
    - 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.

Action: Open
> 
> > ---------------------------------------------------------------------
> > 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.
> 
> The current text doesn't (to me) communicate the message you explained.

How about my text instead?  Or does someone have some better text?

Action: Open.