Subject: [Rserpool] comments on draft-ietf-rserpool-arch-01.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 25 Mar 2002 22:32:56 +0100

Hi all,

IMHO, the overall use of the language could be improved,
below are some more detailed comments on
draft-ietf-rserpool-arch-01.txt.

1) Section Abstract:
Is not an abstract, merely describes a goal.

2) Section 1.1 Overview.
"The Internet is always on." does not provide needed information.

3)
Servers are grouped into pools; is it possible that pools
can also be grouped into pools??

3)
What is 'the server policy'??

4)
A picture of the architecture and/or entities would
improve the overview.

5)
Stating requirements, such as scalability, would be better
if it was in a seperate requirements section.
Although, I beleive that is already RFC3237.

6) Section 1.2 Terminology
"Pool element: A server entity having registered to a pool."

Where is the regstration done??

7)
"Pool user: A server pool user."
Somehow this seems obvious.
IMHO, the text of section 2.1 is better to use here; I suggest:
"A pool user is a client being served by a PE of a server pool."
Also figure 1 should improve if the user is placed in it.
It now looks like a pool user is always combined with a pool entity.

8)
What is the relation ship of the protocols to the elements above??

9) Section 2.1  RSerPool Functional Components
"A server pool is defined as a set of one or more servers providing the
same application functionality."

Repeats the definition of the terminology section,IMHO, the terminology
should bec improved.

10)
"Each server pool will be identifiable by a unique name which is simply
an ASCII string, called the pool handle."

Repeats the definition partially, IMHO, the terminology should be
improved. Why does it need to be an ASCII string??

11)
"All these servers have the complete knowledge"

Make it more precise, "All these name servers have the complete knowledge"
Or called it a ENRP server.

12)
"Therefore each PE is supervised by one specific name server, called the
home ENRP server of that PE."

is this not in contradiction with the earlier text

"In each operational scope there must be at least one name server.
Most likely there will be more than one."

13) Section 2.2
"The fault tolerant server pooling is gained by combining two parts,
namely ASAP and ENRP. ASAP provides the user interface for name to
address translation, load sharing management, and fault management. ENRP
defines the fault tolerant name translation service."

a) Repeats part of previous section.
b) "is gained"?? From what??
c) ASAP is a protocol and not a 'user interface'.

14)
Figure 1 could provide more clarity when multiple
PE/PU and ENRP-Srvr are drawn. It also would improve
the move towards figure 2.

15) Section 3 Examples:
"In this section the basic concepts of ENRP and ASAP will be described."

IMHO, the basic concepts should be describe in section 2. Thios section
provides 'usage examples'.

16)
"In this section we present two separate file transfer examples using
ENRP and ASAP. We present two separate examples demonstrating an
ENRP/ASAP aware client and a client that is using a Proxy or Gateway to
perform the file transfer."

Repeating similar text.

17)
I do not see clearly where the FTP protocol fits in the example
figures of 3.1.1 and 3.1.2.

IMHO, a better explaination of the various protocol messages in a
sequential order is needed.

18)
The telephony example is difficult to follow for me. OK, I
am not really a telephony expert.

regards,

Harrie

Internet Management Consulting
tel: +39-3474932300 / +31-625357135
mailto: [email-masked]                  http://www.lisanza.net/ 

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Mar 2002 23:25:10 +0100

Harrie,

the ID will be updated and I will incorporate the change you are
suggesting if they are still applicable to the new version.

See more comments below.

Best regards
Michael

> Is not an abstract, merely describes a goal.
This still comes from an old version the ID. The same applies to 2)
> can also be grouped into pools??
No.
> What is 'the server policy'??
I only find 'server pool policy' in the ID. This is defined in
RFC 3237. I will define it again the the ID.
> A picture of the architecture and/or entities would
I agree. Figure 2 gives an overview.
> Although, I beleive that is already RFC3237.
The overview section is from an old document which covered
architecture and requirements. I will update the overview for
the next version of the ID.
> Where is the regstration done??
The registration is done before a server entity become a pool
element. The RSerPool protocols are used for the registration
process.
> Somehow this seems obvious.
The notion has to be defined. It is nice if we have choosen a name
which induces the meaning.
> "A pool user is a client being served by a PE of a server pool."
The definition given is shorter.
> It now looks like a pool user is always combined with a pool entity.
Figure 1 is out of date now. It will be replaced.
> Repeats the definition of the terminology section,IMHO, the terminology
The terminology section is a place where you can find all important 
definitions
in one place. So it is OK that the definitions are also given in the 
text. If you
have any suggestion of a better description, please send it to the list.
> improved. Why does it need to be an ASCII string??
You are right. It is a sequence of bytes. Again. if you have some 
suggestions
for improving the text, please send it to the list.
> Or called it a ENRP server.
OK.
> is this not in contradiction with the earlier text
I do not think so. What is the contradiction you are thinking of?
> c) ASAP is a protocol and not a 'user interface'.
This text has to be modified. So a) is OK. ASAP is the name of
a protocol but in the document which defines ASAP an API is also
defined. The real meaning is that ASAP is the lower layer of an
Application level protocol making use of the RSerPool protocol suite.
> the move towards figure 2.
OK
> provides 'usage examples'.
OK
> perform the file transfer."
OK
> sequential order is needed.
OK
> am not really a telephony expert.
So we have to work on it. But it is always god to become a telephony
expert.
> Harrie
Thank you very much for your comments. They are very appreciated.
> mailto: [email-masked]                  http://www.lisanza.net/
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Mar 2002 23:25:10 +0100

Harrie,

See more comments below.

Best regards
Michael

No.
OK.
OK
OK
OK
OK