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

From: Tuexen Michael <[email-masked]>
Date: Tue, 23 Jan 2001 17:46:06 +0100

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]

> -----Original Message-----
> From: Maureen Stillman [SMTP:[email-masked]]
> Sent: Tuesday, January 23, 2001 5:04 PM
> To:   [email-masked]
> Subject:      Re: Alpha version of draft-ietf-rserpool-reqts-01a.txt for the De sign Team Conference Call
> 
> 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.
> 
        [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)
> 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
        [Tuexen Michael]  Yes, we did. It was in the old version. 
> 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: Ken Morneault <[email-masked]>
Date: Wed, 24 Jan 2001 13:40:40 -0800

A few more comments...

In last paragraph of Section 1, there are a few requirements
listed.  You may want to expand on the topic of scaling in Section
2 to include targeted maximums for clients and servers.  

In regards to Authorization, I'm not sure if this is a requirement
that rserpool should directly address.  There can be recommendations for
how Authorization could be done with existing mechanisms (along with 
Authentication and even Accounting if someone wanted to charge for a 
service).

Further, how would monopolization of services be dealt with.  Do you
equate this to denial of service?  It is probably worth covering
security reqs in Section 2 in more detail.

Finally, I can suggest many grammatical changes if you are interested.

Regards,

Ken