Subject: [Rserpool] Last Call Comments - summary

From: "Lyndon Ong" <[email-masked]>
Date: Tue, 24 Apr 2001 15:53:31 -0700

Folks,

I think we're now at a point where we have a clearer understanding of the issues people have on the requirements:

-- the main issue, I think, focuses on section 2.7, Timing Requirements - what we want to convey is that (cribbing from Eliot's earlier message) the name space should reflect changes in pool elements as rapidly as possible, and that requirements for scalability are correspondingly reduced compared to other mechanisms.  In particular, the size of an individual server pool and its corresponding set of name servers is limited in order to support bounded delays (borrowing from another message).  This also limits the impact of frequent updates, compared to a global name server structure, as updates affect only the set of name servers directly supporting an individual pool.

-- other comments:

  - the overview could use some smoothing out and alignment after we finish with the text.

  - there was a suggestion that we change the definition for "handle" to reflect pool elements having more than one address.

  - there was some confusion about 2.1, Communication Model, esp. what we mean by "peer-to-peer".

  - there was some concern about 2.4, Support of RSerPool Unaware Clients - we should indicate more precisely what can be expected for non-RSerPool clients, they will not get full RSerPool responsiveness.

  - there was a suggestion to add "non-stochastic policies" or something like this to the examples in 2.6, Server Selection.

  - also on 2.6, there was a suggestion to change the wording on "plug-ins" to reflect protocol extensibility rather than implementation.

  - there was a suggestion on section 2.8, Failover Support, to clarify whether this is pool element failure or name server failure (also we probably need to qualify "without service interruption").

  - there was some confusion on 2.11, Scalability, as to whether this is referring to number of pools, number of pool users, or number of pool elements - I think not the last, that would in fact contradict earlier text.

  - there was some concern with the fourth dash in 2.12.2, prohibiting unauthorized queries, as this was felt to be out of scope.

I hope that if we make appropriate modifications (esp. on 2.7) that this will satisfy people's concerns.

Cheers,

Lyndon

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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