Subject: [Rserpool] Comments on [Requirements draft]

From: "Guo, Xingang" <[email-masked]>
Date: Fri, 13 Apr 2001 16:59:38 -0700

Hi, I thought I'd jump in and offer some comments.

--1. Section 1.2 Terminology: "Pool element handle (or endpoint handle): A
logical pointer to a particular pool element in a pool, consisting of the
name of the pool and a destination transport address of the pool element."

Shouldn't that be "multiple destination transport addresses"?

Given that 1) a typical transport address consists of an IP and a port
number, and 2) a pool element is a logical pointer.  Then for a service on a
multi-homing server (physical computer), will each IP address become a
separate pool element?

--2. Section 2.1 Communication model: "The general architecture should be
based on a peer to peer model."

Just what exactly does "peer to peer" mean in this context?  Is it in alien
with the peer-to-peer working group (ptpwg.org), or a loosely used term?
That could cause some confusion.

--3. [typo] Section 2.5 Registering and deregistering:

... No PE will establish a new connection with the deregistered PE, because
other PE of the server pool will be used.

Shouldn't it be "No PU will establish ...."

A related question, if a PE deregisters because of the termination of
service provision (e.g. server shutdown).  Will ENRP server be required to
notify all PUs that have that PE on their server lists? or it should be left
to individual PUs (through ASAP) to find out that the PE no longer accepts
connection?  The current draft assumes that a PE always continues providing
service after deregistration.

--4. Section 2.7 Timing Requirements: "A server pool can consist of a large
number (up to 500) of pool elements."

Why 500?  I think the motivation of an upper limit is to provide a delay
bound to "real-time" name resolution.  If no such delay bound can be
guaranteed, then "real-time" doesn't make sense at all, which further makes
the number 500 even more ad-hoc.  So why not say something like,

"A server pool can consist of a large number of pool elements.  However, the
architecture will provide bounded delay in handling real-time name
resolution."

Moreover, "bounded delay" is closely relevant to the next paragraph which
talks about PE supervision.  In order to maintain a list of operational PEs,
the server status has to be updated periodically (by name server or PE).
Delay bound governs such update interval, while number 500 not.

--5. [typo] Section 2.12.2, item 3.  There should be a trailing period "."

--6. Section 2.12.2, item 4: "It must be possible to prohibit unauthorized
queries to the name server."

Is it necessary or achievable without bringing in extra AAA stuff all
together?  Shouldn't it be out of the scope of RserPool and left to
individual server?

Thanks

--Xingang Guo

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool