[Rserpool] Comments on draft-ietf-rserpool-arch-11.txt

1.1.  The Problem Space
   5.  How does a server assure that when it fails (or dies), the
       clients will access the "best" server that is able to handle the
       failure (or if you will take over for the departed server)?

I'm confused by this statement.  The server that dies is not assuring
anything, the reliability mechanism that does this.  Also, the last
statement in parenthesis is a separate condition and should be stated by
itself -- see #6.

Suggestion:

5. How does the relialbility mechanism assure that when a server fails
(or dies), the clients will access the "best" server that is able to
take over on behalf of the failed server?

6. How does the reliability mechanism allow a server to take over for a
failed server?

Nits below:
So how can application writers solves these issues and makes it easy
   for the application designer to add fault tolerance without hacking
   or rewriting the application code?

*** Seems that designers and writers are backwards.  Also several
grammar fixes.

How about:
How can application designers solve these problems and make it easy
   for the application programmers to add fault tolerance without
hacking
   or rewriting the application code?

More nits around designers versus programmers and fixing the application
writters to be programmers :-).

This removes considerable complexity for the application designer and
frees the
   application programmer to concentrate on the application.

More nits, too many words in one sentence, less is more:

Note that not
   all of the issues listed above can be solved by the session layer
   framework alone, in particular the application will still need to
   deal with state sharing, however the session layer framework will
   also provide small tools when it can to help make even this job
   easier for the application writer.

How about:

Note that not
   all of the above issues above can be solved by the session layer
   framework alone, in particular the application will still need to
   deal with state sharing. However the session layer framework also
provides 
   simple tools to make this job easier for the application writer.

More nits:

A second important point is that this layering no longer requires
   each application to custom programmed for fault tolerance.  By
running an application on top of the session layer fault tolerant
   services, there is no longer the need to design and implement fault
   tolerance one application at a time.  There are several benefits to
   this approach:

How about:

A second important point is that this layering no longer requires
   each application to be custom programmed for fault tolerance.  By
running an application on top of a session layer which provides fault
tolerant
   services, there is no longer the need to custom design and implement
fault
   tolerance for each application.  There are several benefits to
   this approach:

More nits:

In this document you will be introduced to a set of concepts for
   solving a number of these problems.  Often times the document will
   refer to a named element (e.g Pool User) in the architecture sending
   or receiving a message.  When seeing this, please note that this is
   NOT the application sending or receiving the query, but the session
   layer below.  Envision if you will the application opening up a
   special form of socket.

This document introduces a set of concepts for
   solving a number of these problems.  Often times the document will
   refer to a named element (e.g Pool User) in the architecture which
sends 
   or receives a message.  Note that this is
   NOT the application that sends or receives the query, but the session
   layer below.   The application opens up a
   special form of socket to communicate with the session layer below. 

-- Maureen 
Maureen Stillman 
Nokia Enterprise Solutions 
Acting Director SMC Systems Architecture  

_______________________________________________
rserpool mailing list
rserpool@ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool