Subject: RE: comments on requirements draft 04

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 8 Aug 2000 16:05:48 -0700

It's great to have this level of feedback and comments!! I look forward to
more discussion following.

Just to let people know, I've started on a version 5 and have already made
some changes based on the comments. I'll post 
version 5 when Stuart and Erik think the discussion and the text have
settled enough to make a version 5 worth posting.

> The highest impact issues effect the direction of document,
> and could fundamentally change the focus of the working group.
> 
>  1. The definition of a zeroconf protocol is too narrow.  We need
>     to broaden it.

I disagree. I'll follow up with additional email.

>  2. Is reconfiguration required when infrastructure detected?

Agree 100% that this should be MAY instead of MUST. This is changed in
version 5. Does anyone disagree with this?

>  3. Host name (not domain name) to IP Address Resolution

This change seems worth trying. Opinions?
 
>  3. IP Host configuration is defined in terms of default routers,
>     IP subnets, and subnet masks.  This is inappropriate.

I agree with some of the below comments, but not all of them.

True, a default route is not a required configuration parameter for
communication on the local IP subnet - this is true for link local or
non-link local addressing.

The text in the draft was meant to clearup previous confusing discussions.
I'll remove the text that describes sending a packet, but we still need to
walk through the issues because the comments below show that we're still not
on the same page. I'll bring this up in another mail with a focus on this
comment:
> That is, the host must know with
>     which interface and with which method to forward IP 
> datagrams.  One such implementation is to use subnet masks as discussed 
> in section 2.1.1.  Another is to maintain a routing table with 
> network numbers.
>     Another still is to only use link local addresses and to 
> always use ARP (or neighbor discovery). 

>  5. Several places in the document discuss periodic messages.  This is
>     *not* the requirement - in fact it is a highly 
> undesirable protocol
>     feature.

Where is the requirement for a periodic message. Periodic actions ARE
required. I agree with the comments: 

>     In each case there are protocol design alternatives.  For 
> instance,
>     if ARP, mDNS, AAP replies were multicast instead of unicast, then
>     hosts could detect collisions through the normal use of 
> the protocol.
>     Note these protocols either don't exist yet or do not support this
>     operation today, but they could be enhanced to do so.  

The statement:
   > The requirement is detection of conflicts after allocation, not that 
   > periodic messages be sent.  
is not accurate. There are no requirements for periodic messages.

I'll let someone else pick up this thread if further discussion is needed.

>  6. Service discovery protocol requirements include notification that
>     a service is going off line.

The excerpts from the draft below say SHOULD, not MUST. NBP, SLP, etc. don't
include "going-off-line" notifications, but is this a reason that a protocol
should not do this. (IGMP did not have the concept of leaving a group,
IGMPv2 does.) To me, a "going-off-line" notification seems like a fine and
reasonable thing for a service discovery protocol. 

>  7. As discussed on the mailing list, we will be silent with 
> respect to
>     secure IP Host Configuration (ARP, IPv6 neighbor discovery, DHCP,
>     etc.)
...
> For this reason, section 3.1 should be dropped.

Agreed and apply this to entire security section - the section should change
significantly. See version 5.
 
> These comments are important, but aren't likely to require 
> much discussion.
> 
> a. Add to the Introduction Stuart's suggested motivating text
> 
>    Zero configuration networking is not intended to replace or compete
>    with existing mechanisms deployed in today's large-scale 
> IP networks
>    such as the Internet.  Instead, zero configuration networking is
>    aimed at small scale isolated networks that are poorly served by
>    today's IP mechanisms, beginning with the extreme case of just two
>    devices and scaling up as far as is reasonable.

This has semantic problems similar to earlier versions of the text.
Specifically, everyone had their own favorite definition of zero
configuration networking which included some network topologies and excluded
others. I don't remember who it was, but someone clearly pointed out (and
garnered support from others on the list) that we should focus on protocols
- not on networking and not on network topologies. 
   
> b. Replace some text for clarity
> 
>    I like Stuart's formulation more.

I like Stuart's text better also. It is in version 5. 

> c. Scalability is not the primary concern, but it is still a 
> concern for
>    zeroconf network protocols.

I'll work on this section. See version 5.

> d. The following text makes it sound as if a boundary router 
> is required
>    for networks which use Zeroconf protocols:

Good catch. Text will change.

> e. Unclear text
> 
>    What does this mean?
> 
>   section 2.1.2, p 9
>     This creates two problems. First, hosts may have duplicate IP 
>     addresses. Second, there may be competing netmask and default 
>     route values that disrupt communication. 
> 
>    I don't understand this text at all.  If two zc networks merge,
>    both will use the same automatic IP address configuration protocol
>    and there will be no conflict - both will know how to forward pkts
>    and share the same network number (the link local prefix).  Also,
>    if there are two routers - each of which could be used as 
> a default 
>    route, provided the hosts could detect the router.

I'm not sure what part of the text is unclear. The comment appears to
understand the text. Perhaps the comment is meant to say the text is obvious
therefore unnecessary. Please provide more input.

> f. Unclear text
> 
>    What does this mean?
> 
>   section 2.2.2, p 11
>     A domain name consists of a host name and the name of the domain 
>     itself. A host has control over its host name, but some other 
>     entity configures or determines the name of the domain.

Yes this is unclear, I'll try again. See version 5.
   
> h. admin range allocation should be moved to the IANA considerations
>    section:
> 
>   section 2.3.2, p 14
>     To date, no range has been reserved for dynamic allocation of 
>     Single-source addresses in IPv6.  Hence, until such a range is 
>     reserved, dynamic allocation of Single-source addresses applies 
>     only to IPv4. 
> 
>   section 2.3.3, p 14
>     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. 
> 
>   section 2.3.7, p 16 repeates the above.
>    
>   These 2 paragraphs can go to section 4.

Good point. They will be moved.

> i. The idea that the last sender to a group should deallocate it
>    is simplistic.
> 
>   section 2.3.4, p 15
>     Here, the first source that needs the IP address MUST 
> allocate the 
>     address, yet it may not be the host that deallocates the 
> multicast 
>     address. This is because the first source may leave the multicast 
>     group before all the other sources stop sending packets 
> to that IP 
>     multicast address. This requires, the last source using the IP 
>     multicast address to deallocate the IP multicast address after it 
>     is done sending. 
> 
>    It is quite imaginable that there would be a protocol which would
>    want to allocate a mc address as long as there was a member of the
>    group (receiver).  That way, if anyone ever wanted to send 
> a message
>    to a member of that group it would go to that stable 
> membership set.
> 
>    The text should simply add 'or group member' where it says source
>    and I think it would work.

As far as I know only senders join multicast groups, not receivers. If
receivers don't join, they can't dealloc the address. I'll wait for others
to comment. 

> j. The 'Print Manager' example has problems.

Unless someone objects, I'll change the text as suggested.

-myron

---

From: Richard Johnson <[email-masked]>
Date: Tue, 8 Aug 2000 16:28:06 -0700 (PDT)

> This change seems worth trying. Opinions?

Agreed.  A "host name" is not a "domain name" unless it's in "domain
name" format; i.e. contains dots.  A "domain name" is not a "host
name" unless it's being used to name a host.

I wonder if we should add the requirement that there should be a way
to discover the host names of all hosts on the local-link, at least
all of the ones with zeroconf addresses?  Otherwise, you connect your
computer to your neighbor's computer on the train to exchange data but 
you don't know the name of the other computer unless you find out
out-of-band.  Just a thought.

I also wonder if we should add that the user should be given the
option of configuring a zeroconf address and joining a network before 
actually doing so, unless the user has already specified in some way
that the host should automatically configure zeroconf addresses and
join all networks.  I'm worried about having one's laptop simply
automatically joining all Wavelan networks in range, whether or not
the user really wants this.  Of course, printers purchased for home
use would want to automatically join the network when plugged in.
It's a trade off.  Maybe it's a security issue about which we should
be silent?

/raj

---

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 09:16:11 +0200 (MET DST)

> name" unless it's being used to name a host.

Let's find out what this distinction has meant historically
before we wander into any pits.

Bill, can you help us out here?

> out-of-band.  Just a thought.

We are trying not to add any requirements above and beyond what we need
to support features we already have, and have come to expect in non-IP
zeroconf protocols like Appletalk/NBP, NetBeui/SMB, IPX/SAP.  We need host
config, name to address resolution, service discovery.  We are also looking
at MADCAP function in the absence of MADCAP servers - but that's the extent
of what we are chartered to do.

> It's a trade off.  Maybe it's a security issue about which we should

No host is required to do anything unless it is configured to use an
IP network, then IETF RFCs apply.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 09:53:16 +0200 (MET DST)

> receivers don't join, they can't dealloc the address. I'll wait for others

You have it backwards.  Receivers join mc groups - which initiates 
IGMP messages, for example.   Senders merely use mc destination addresses.  
The point is subtle, though.  The point of allocating a mc address is
to distinguish one session from another - to keep them from colliding.
Who knows what constitutes a session?  Those who will send or those
who will receive?  I assert this is application dependent and Dave
Thaler (who wrote the text above) will likely agree.  

Dave?

Erik

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 9 Aug 2000 00:15:39 -0700 (PDT)

> Bill, can you help us out here?

I'll take advantage of the infamous Bill Anycast Protocol to interject
here...  

A _hostname_ is the name of a host, pure and simple.  It may or may not
have dots in it.

A _domain name_ is the name of a domain, and may or may not also
coincidentally be a hostname.  It may or may not have dots in it.  "us" is
a domain name, for instance.

A _fully qualified name_ is the combination of a hostname (which may or
may not contain dots) with a domain name (which may or may not contain
dots), delimited by a dot.

None of these are distinguishable algorithmically, without access to the
Internet DNS hierarchy for actual testing of specific instances.  A domain
name cannot be distinguished from a host name in any case.  A name can be
determined to be _not a domain name_, or a _fully qualified name_ via
testing against the DNS.  I don't believe any other determinations can be
made.

                                -Bill

---

From: Aidan Williams <[email-masked]>
Date: Mon, 21 Aug 2000 12:46:47 +1000

> It's a trade off.  Maybe it's a security issue about which we should

I believe that users need mechanisms which will allow them to
simply and securely create federations of devices.

There are several situations where this is important:
  - "drive by" joining of networks (as you describe),
  - wireless networks with overlapping coverage,
  - any shared network where you only want to exchange
    traffic with a subset of hosts on the network.

In these scenarios, you can view hosts as "borrowing" the network
medium..  Since there might be other people on that medium too,
they need to be able to do it safely.

The "standard" solution currently is to apply L2 encryption.
The implication of doing this is that the the user is required
to configure something (like a key) before zeroconf protocols
can begin to be used.  The techniques I have come across for
doing this are cumbersome.

At this stage, I think security in zeroconf networks needs
to be done above layer-2.  Comments welcome.

It seems to me that whilst allowing the user to turn off
zeroconf networking as a security measure is a good thing,
it is too coarse grained for many situations.  It is also
something that must be configured before the user can get
anywhere with zeroconf protocols.

regards
	aidan
____
:wq!