[Rserpool] Some comments about "draft-ietf-rserpool-applic-00.txt"

Manuel Urueña <muruenya@it.uc3m.es> Wed, 06 August 2003 12:29 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14029 for <rserpool-archive@lists.ietf.org>; Wed, 6 Aug 2003 08:29:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNPZ-0002nP-52; Wed, 06 Aug 2003 08:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNOu-0002mt-Ub for rserpool@optimus.ietf.org; Wed, 06 Aug 2003 08:28:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14002 for <rserpool@ietf.org>; Wed, 6 Aug 2003 08:28:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kNOt-0002Ou-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:19 -0400
Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 19kNOs-0002Ob-00 for rserpool@ietf.org; Wed, 06 Aug 2003 08:28:18 -0400
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DAE2743165 for <rserpool@ietf.org>; Wed, 6 Aug 2003 14:27:43 +0200 (CEST)
Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id CC96E99FCA for <rserpool@ietf.org>; Wed, 6 Aug 2003 14:27:43 +0200 (CEST)
Received: from requiem.it.uc3m.es (requiem.it.uc3m.es [163.117.139.166]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA27218 for <rserpool@ietf.org>; Wed, 6 Aug 2003 14:27:43 +0200
From: Manuel Urueña <muruenya@it.uc3m.es>
To: rserpool@ietf.org
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-prmeW1YpLssCR41oMCyG"
Organization: Universidad Carlos III de Madrid
Message-Id: <1060172597.2179.108.camel@requiem.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4
Date: Wed, 06 Aug 2003 14:23:17 +0200
Subject: [Rserpool] Some comments about "draft-ietf-rserpool-applic-00.txt"
Sender: rserpool-admin@ietf.org
Errors-To: rserpool-admin@ietf.org
X-BeenThere: rserpool@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=unsubscribe>
List-Id: Reliable Server Pooling <rserpool.ietf.org>
List-Post: <mailto:rserpool@ietf.org>
List-Help: <mailto:rserpool-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=subscribe>

Hello,

I've just read the draft-ietf-rserpool-applic-00.txt and several other
Rserpool docs and I've found some typos and there are some paragraphs
that I don't understand.

Draft draft-ietf-rserpool-applic-00.txt says:

Page 4: "The PU's  may try to find out via the endpoint resolution
protocol(ENRP) which PE's are active"

As I have understood after reading draft-ietf-rserpool-arch-06.txt,
(although the "Endpoint Name RESOLUTION Protocol" name is a bit
misleading) ENRP is not employed by PUs to resolve the pool handle into
the list of PEs belonging to the pool, but ASAP.NAME_RESOLUTION is used
instead. ENRP servers (NS) speak ENRP among them to maintain a
consistent view of the pools namespace. 

IMHO this paragraph and some others later in the same page about this
issue are misleading, aren't they? or is my view of Rserpool wrong?


Some typos:

Page 1: "...to applications which want to have High avialebility
services."

s/avialebility/availability/

Page 3: "Reliable server pooling provides protocols for providing higly 
available services."

s/higly/highly/

Page 3: "Transport and network level redundancy are handle by the
transport and network layer protcols."

s/handle/handled/
s/protcols/protocols/

Page 3: "The terms are commonly identified in related work and can be
found in the Aggregate Server Access Protocol and Endpoint Name
Resolution Protocol Common Parameters documentRFC COMM [5]."

This document does not define any terminology, maybe reference [2] 
"Architecture for Reliable Server Pooling" is better.

Page 5: "May be used by allready existing applications which do not want
to change the interface between PU and PE."

s/allready/already/

Page 5: "All entities wil use Rspool protocols for communication withs
their respective peers"

s/wil/will/
s/Rspool/Rserpool/
s/withs/with/

Page 7: "No conegstion control is done..."

s/conegstion/congestion/

Page 7: "Only the ENRP server responsible for that particular server
pool will have a up to date view of the load distribution in the pool."

s/a up/an up/

Page 10: "Rserpool protocols(ENRP and ASAP) do NOT provide any service
for transfering state information of a application from one Processing
Element(PE) to another"

s/Processing Element/Pool Element/

Maybe the ASAP-Cookie mechanism should be cited here?

Regards,
--Manuel

-- 
Manuel Uruen~a - Universidad Carlos III de Madrid
GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75