Subject: [Rserpool] WG Last Call on Rserpool Requirements

From: "Lyndon Ong" <[email-masked]>
Date: Wed, 18 Apr 2001 09:07:26 -0700

Folks,

Sorry for the slight delay, but Maureen and I are initiating WG Last Call on the Rserpool requirements document today, to close Wednesday May 2nd.  The current draft is draft-ietf-rserpool-reqts-02.txt, and the document is aimed at going for Informational status when it gets to the next level.

I know there are still some concerns about the requirements, but it seems to me that the best way to move forward is to focus on what we have in the draft and make any further comments specifically on the text.  Even better, we'd like people commenting on the text to actually propose alternative text where they want a change :o)

Thanks,

Lyndon

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2001 08:26:39 -0700

Hi,

For the reasons I've previously mentioned and others, I object to this
document moving forward as informational.  To recap, those reasons are
both general as they relate to the "other mechanisms" document, and
specific to the document (sections 2.4 and 2.5, as previously mentioned).

Let's be clear: the reason one has a requirements document is to engineer
to them.  Without the other document the requirements document lacks
sufficient context to engineer a solution.  Another way to put this- we
may need to change the requirements document based on what is in the other
document.

Here are the additional concerns:

Section 2.6 contains vague wording starting with "There must be a way for
the client to provide information to the server about pool elements."  I
think we can be more specific in what we are asking by replacing the word
"information" with "operational status feedback" or some such.

The plug-in architecture discussion needs to be restated as protocol
extensibility.  The IETF isn't in the business of specifying platform
architecture.

The next paragraph, about client stickiness, needs to be expanded, and
should remain consistent with 2.5.  Keeping in mind that we are not trying
to solve all process migration issues, we should mention a demarcation
point in the requirements.  In IP, it would be that if two systems share
an IP address, they are responsible for preventing confusion.  Where is
that demarcation with RSERPOOL?

2.7 directly conflicts with 2.11.

2.8 is ambiguously vague.  Failover of the name service itself, right? 
The word server should be further specified.

I haven't considered the security requirements portion, so perhaps we
could start with these issues and get to those later?  In the meantime we
really need the other document.
--
Eliot Lear
[email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Apr 2001 14:50:09 -0500

Eliot,

To my understanding, the other document is just going to be a summary on
what we've talked about on the list plus what was pulled from the old
requirements document (unless John is planning to add some substantial
new material to it, John?). In other words, we should already have all
the materials and points to generate feedback and comments to the new
requirements document. Therefore, it seems to me that to wait for the
other document to be released is not necessary.

regards,
-Qiaobing

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 20 Apr 2001 14:54:21 +0200

Dear all,

the requirements documents is a document on its own and should
be readable without the other documents.

More comments to follow, because I'm currently setting up the SCTP
test network.