Subject: Comments on Requirements/Architecture document

From: Maureen Stillman <[email-masked]>
Date: Wed, 7 Feb 2001 10:10:11 -0600

I'm very pleased with the latest draft.  The suggestions to change the
architecture examples were very helpful.  I have 5 comments starting with
***:

***** 1)
Although the term pool handle is used in the document, it is not defined in
the list of the terminology.  Given the importance of this term, I think it
should be defined up front in the terminology section.

How about this text borrowed from section 4.1:

         Pool Handle:  Each server pool will be identifiable in the
operation scope
          of the system by a unique "name" called a pool handle.

**** 2)
From the document section 3. DNS

3.2.1.  Name/Address Resolution

The technical requirement for DNS name/address resolution DNS is that
given a name, find a host associated with this name and return its IP
address.

The technical requirement for RserPool name/address resolution is that
given the name of a service return the address of an operational server
(one that is up) that will provide this service.

*** Given the degree of confusion over the relationship between names,
services and named pools and our decision to use the term pool handle, maybe
we should change this to something like:

The technical requirement for RserPool name/address resolution is that
given the name of a pool handle return the address of an operational server
(one that is up) that will provide this (*** Uh, what.... service or group
of services or just service(s)??? ***).

*** 3)  From the same section

3.2.4.  Dynamic Mapping of Ports to services

DNS supports the concept of well-known port numbers statically.  The
assumption is that if I resolve the host name, the host will be up and
the service on the well-known port will be able to provide me the
service.  If the host, network interface or service is down, then I
lose.  In other words, if DNS finds the IP address to the right host,
the service with the well-known port number might be available for
service but might not.

In contrast, RserPool is a dynamic and distributed port mapper.  Given
the name of a service, RserPool will find a server that both provides
the service and is available, so when I connect to it on the well-known
port number, I really get the service.  This is not 100% reliable as the
server could go down and the name server has yet to discover the change
in state from up to down, but it is more reliable than the DNS approach.

** Suggested changes to the second paragraph for the same reasons as above:

Given the name of the pool handle ( or just ... given the pool handle),
RserPool will find a server that both provides
the service(s) and is available, so when I connect to it on the well-known
port number, I really get the service(s).

***** 4) The following is just a nit to tighten up the wording in the SLP
section:

The directory agent of SLP functions simply as a cache and is passive in
this regard.  Also, the directory agent is optional and SLP can function
without it.  It is incumbent upon the servers to update the cache as
necessary by reregistering.  The directory server is not required in
small networks as the user agents can contact service agents directly
using multicast.  User agents are encouraged to locate a directory at
regular intervals if they can't find one initially. Security in SLP is
optional but mandatory to implement and supports authentication and
integrity.

*** Delete this last sentence on security because it is repeated in the next
paragraph.  No need to say it twice.

5) *****  Probably this paragraph should be changed to be more specific:

SLP does not have fault tolerance or robustness.  There is nothing in
the SLP architecture to address this.  SLP uses multicast, but RserPool
doesn't use it.

*** How about:

The SLP directory agent does not support fault tolerance or robustness in
contrast to the the ENRP servers which do support it.  ENRP also monitors
the state of the servers which are registered in the pool but the SLP
directory agents do not perform this function.  SLP uses multicast and in
Rserpool multicast is optional.

-- maureen

Maureen Stillman
Nokia
Member of Scientific Staff             Voice: (607)273-0724 x62
Internet Commerce Enhancement  Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: [email-masked]
www.nokia.com