Subject: Re: Alpha version of draft-ietf-rserpool-reqts-01a.txt for the De sign Team Conference Call

From: Maureen Stillman <[email-masked]>
Date: Tue, 23 Jan 2001 10:03:36 -0600

Here are some initial comments on Alpha:

1)
 1 Introduction

  Considerations for real time applications and mission critical
   applications should addressed.

*** Mission critical is a loaded term and has all kinds of implications that
come along with it.  I think this phrase should be deleted from the text.
We don't want to say that we will fulfill mission critical requirements.
This is out of scope, in my opinion.  Someone might leap to that conclusion
that we support all mission critical requirements while reading this text.
The words "consideration for" are vague allowing for this misinterpretation.

2)
Scalability is another important
   requirement.  Unauthorized use and monopolization services MUST be
   prevented. The solution MUST prevent denial of service style
   attacks.

*** Nit, Did you mean monopolization of services?

3)
1.1 Basic Requirements
Support for legacy support

*** Nit Support for legacy applications

4)
     Servers should join & leave transparently

*** Nit didn't we agree on register and deregister, so should be servers
should register and deregister transparently

5)
   Operation Scope - the part of the network visible by a specific
   instance of the reliable server pooling protocols.

*** Visible to whom?   How about, the part of the network visible to pool
users by a specific instance....  Then move up the definition of pool user.

6)
   Named Group - a group of ASAP endpoints sharing the same endpoint
   name in the name space.

*** There is no mention of an ASAP definition and we want to make these
requirements generic.  How about changing this to PE and then defining PE
first.  I'm fine with any way of removing ASAP and substituting another
generic term.

7)

Add a reference for SLP:

[RFC2608]  Guttman, E. et. al, "Service Location Protocol, Version 2", RFC
2608, June, 1999.

-----Original Message-----
From: ext John Loughney [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 7:48 AM
To: [email-masked]
Subject: Alpha version of draft-ietf-rserpool-reqts-01a.txt for the
Design Team Conference Call

Hi all,

I've edited the Requirements document.  This is not complete - I left two
sections for Michael Tuexen to update - Architecture & Examples.  This would
roughly correspond to Section 2 of the current draft.

Please forgive all grammer mistakes & inconsistancies in the text.  This is
meant as an alpha version of the document, to generate some discussion for
the conference call.  I'd appreciate it if we the major discussion for the
conference call.

What I hope for would be comments going into the conference call if this
format is better suited to the document.  I'd like to know what additional
requirements we should add.  Also, Chapter 3 Relation to Other Solutions may
be too wordy.

For all of the current authors of the draft, please look it over as far as
your own contributions are concerned - I may have gotten a little carried
away with the delete button!

best regards,
John

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 24 Jan 2001 15:40:36 +0100

Hi Michael, 

I agree to add the already discussed items in the reqs-spec, but I think this format is much clearer than the old one. So, I suggest to keep this as the baseline and correct/add the proper stuff.  :-D

BR  // Javier.

> From: Tuexen Michael [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 5:46 PM
> Subject: Re: Alpha version of 
> draft-ietf-rserpool-reqts-01a.txt for the
> De sign Team Conference Call
> 
> 
> See my comments below.
> Best regards
> Michael
> 
> Michael Tüxen     Tel.:   +49 89 722 47210
> Siemens AG        Fax:    +49 89 722 48212
> ICN WN CS SEN 51  E-mail: [email-masked]
> 
> > From: Maureen Stillman [SMTP:[email-masked]]
> > Sent: Tuesday, January 23, 2001 5:04 PM
> > Subject:      Re: Alpha version of 
> draft-ietf-rserpool-reqts-01a.txt for the De sign Team Conference Call
> > 
>         [Tuexen Michael]  We have some introductionary text in the
>         old version. That text has gone through discussions like this.
>         Why should we not stay with the old version?
> 
> > 2)
>         [Tuexen Michael]  Yes, we did. It was in the old version. 
> > 5)
> > away with the delete button!> 
> > 
> > best regards,
> > John
>

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 24 Jan 2001 15:31:55 +0100

See my initial comments below...

BR  // Javier.

>
> 1 Introduction
>
>    The Internet is always on.  Many users expect services to be always
>    available; many business depend upon connectivity 24 hours a day, 7
>    days a week, 356 days a year.  In order to fulfill this, many
>    proprietary solutions and operating dependent solutions have been
>    developed to provide highly reliable and highly available servers.

I like this part. It is from 12000 meters high (50000 feet)  ;-)

>    This document defines requirements for reliable server pooling and
>    a proposed architecture, which can be used to provide highly
> available
>    services.  Reliable server pools can be used for providing high-
>    available services by using a set of servers in a pool.

I would change this parragraph into: (changing the last sentence)

This document defines requirements for reliable server pooling and a proposed architecture, which can be used to provide highly available services. The way this is achieved is by using set of servers, which offer the same service, grouped into pools. Therefore, when a client wants to access a server, it will be able to use any of the servers associated to it (belonging to that pool) taking into account a well-defined policy.

>    applications should addressed. Scalability is another important

What kind of real-time applications are we talking about? It is a very wide concept. Are we talking about telephony signaling, voice?  May be, a more specific "consideration" can be stated here. I don't see a basic requirement related to it...

I don't understand what monopolization and mission critical is referring to, either...

> 1.1 Basic Requirements
>
>    The basic requirements are:
>
>      Based on a peer-to-peer model
>      Implementable in small devices
>      Should be congestion control friendly
>      Should not require multicast

Don't we have to add as well that the transport protocol that RserPool is design for is SCTP? In one of the next terminology definition there is an implicit call to this: "primary destination transport address".

Shouldn't scalability be a basic requirement as well?

> 1.2 Terminology
>
>    This document uses the following terms:
>
>    Endpoint Name - the registered tag of an endpoint.
>
>    Endpoint Handle - a logical pointer, consisting of a name and the
>    primary destination transport address to a particular endpoint in > a
>    named group.
>

I agree with Maureen. A better definition could be:
Named Group - A group of PE that gives the same service and shares the same Endpoint Name.

where...

PE - Pool Element, an element belonging to a group of servers (i.e. server pool) that can give a concrete service.

>    Name Server - Entity which the responsible for the name space >within
>   the operation scope of the Server Pool(s).
>
>    Name Space - A cohesive structure of names and relations that may > be
>    queried by an internal or external agent.

What about...

Name Space - A cohesive structure of names and relations that may be   queried by a PE of a Name Server.

The word "agent" hasn't a clear meaning here... It can be understood as a software agent or whatever

>    Pool User (PU) - A server pool user, i.e. one who uses the server
>    pool.
>
>
> 2 Requirements
>
> 2.1 General Requirements
>
>    The general architecture should be based on a peer to peer model.
>    However, the binding should be based on a client server model.

What kind of binding is it talking about? Yes, I know is server binding to the RserPool, but I think it is good to state that to make it easier to understand...

[...]
>    There must be a way for the client to provide information to the
>    name server about the pool elements.

The word "PU" is probably better that "client" ...

And maybe a drawing like this can help to see the network...

    -----                              -----
   /     \                            /     \--
  |   PU  |==========================|   PE  | \
   \     /                            \     /   |
    -----                              -----   /
         \                            /   -----
          \                          /
           \      ---------         /
            \    /  Name   \       /
             ---|  Servers  |------
                 \ Network /
                  ---------

> 2.3 Failover Support
>
>    The solution MUST be able to detect server failure quickly and be
>    able to perform failover without service interruption.

I think it can be worthy to explain what kind of fail-over we are talking about, since it is a very generic concept. Just a few words. I mean: at the beginning of the communication, in the middle, etc. Some of the fail-over procedures implies state-sharing, and I suppose this is out of the scope...