Subject: requirements -04 draft comments

From: Daniel Senie <[email-masked]>
Date: Tue, 01 Aug 2000 15:53:44 -0400

I'd read and annotated the -04 draft this morning before the zeroconf
session. Due to the time constraints and the direction the discussion
went, I figured I'd post my commentaries rather than bring them up
during the session.

Some of these are nits, some are more substantial.

1.2.2 Transitions: Second paragraph. Last sentence is an example. As
such, using MUST, capitalized, seems out of place. Such usage is for
requirements, and I'd prefer if examples weren't held up as
requirements. Phrase the requirements with MUST, MAY, SHOULD or
whatever, then give examples.

1.2.3 Coexistence: This may be moot after the discussion today in the WG
meeting, but in the last paragraph, the wording "MUST NOT be able to
coexist" is awkward, and difficult to parse. Remove the words "be able
to" and the meaning is the same, but less confusing.

2.1.1 Ping: I'm not sure why we have so much detail here on how hosts
decide to route packets. This was mentioned briefly in the WG meeting.
This is long-established methodology. Reference appropriate RFCs rather
than re-describing it here.

Also in this section, in the conclusions from the example, is a derived
requirement that zeroconf hosts have the ability to determine the
default route for the subnet. This is a requirement ONLY if there is a
need to converse off the local subnet. For the much-discussed light bulb
case, there may be no need for a default route. Seems like we're being
too strong here.

Peer networks come up and function with self-assignment today, and do so
without any default routes. I think we should be careful about imposing
requirements which aren't required in all cases.

2.1.4 Requirements Summary: Same comments on default route discovery.
Also, there are legitimate uses for having more than one possible
default route on a network. This is easy to do in manually configured
environments, and has some uses. The text in this section seems to imply
we'd always want to harmonize default routes, and I'm not sure that's
true.

2.2 Domain Name to IP Address Resolution Issues: "The problem with DNS
preventing DNS ..." change second DNS to "it". Later in that sentence,
change "entering" to "configuration of".

2.2.1 Web Browsing: Just a note to keep in mind the degree to which DNS
is inherent in today's applications. Applications including web browsers
find it useful to implement DNS Resolver functionality in the
application. This permits caching, and probably has other benefits.
Changing the mechanism for name resolution will be painful. I'm not
arguing to not do it, just reminding folks what's involved. It may be
worth mentioning in the document that applications as well as operating
systems and libraries will need revamping.

2.2.2 Domain Name Selection: There's talk here about having duplicate
host names for load balancing. This seems to contradict the scalability
statements earlier in the draft (which state that scalability is not an
issue since we expect zeroconf to be on small networks only). If the
scalability statement is to be believed, why are we even talking about
load balancing and such. Those tend to be large network issues. We seem
to have some consistency issues here.

2.2.5 Requirements Summary: "The ability to detect the presences ..."
should be presence.

3. Security Considerations & Requirements

"By definition security requires configuration." and later "... this
section focuses on the minimal configuration necessary to make zeroconf
protocols secure" This section appears to conflict with the definition
of zeroconf at the top of the document.

If we go with the definition of zeroconf at the top of the document,
security is necessarily out of scope. I understand the desire to address
this area, but the wording of this section and of the top of the
document are at odds. Some more work is required to make this document
consistent with itself.

3.6 IPv6 Considerations: The document seems to dismiss the need to do
anything in the security area for IPv6 since IPv6 already has security.
However, this security also requires configuration. As with the overall
security section, we've got issues with document consistency and
applicability.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com