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

[Coene Lode <[e-mail]>]

sorry for the delay in answering.
See below for comments.

> -----Original Message-----
> From: Manuel Urueña [mailto:[e-mail]]
> Sent: Wednesday, August 06, 2003 2:23 PM
> To: [e-mail]
> Subject: [Rserpool] Some comments about
> "draft-ietf-rserpool-applic-00.txt"
> 
> 
> 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?

Yep, they are. I'll try to come up with something more correct. Must have
been confused...
Does happen from time to time...
> 
> 
> 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/
> 

All typos fixed...
Thanks

> 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?

Put something extra here. It is true that the protocol does not have
provisions for the direct state transfer between 2 PE(meaning from one PE
directly to another PE) but the ASAP cookie mechanism can be used to do some
state sharing via the PU(more or less indirect..PE -> PU -> PE..)
Will try to make it clearer.


> 
> Regards,
> --Manuel
> 
> -- 
> Manuel Uruen~a - Universidad Carlos III de Madrid
> GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75
> 
I've also put in some stuff from the service draft(more particular the
chapter 4 of the services draft)
I'm going to let it pass by Petere and Phil so they can check it out
first.(and add or/and remove some stuff...)

Thanks  Manuel for the comments.

your sincerly,
Lode

Siemens atea
atealaan 34          2200 Herentals, Belgium
E-mail: [e-mail]
Tel: [phone]
Fax: [phone]

_______________________________________________
rserpool mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rserpool