Subject: RE: [Rserpool] Re: draft-ietf-rserpool-comp-00.txt

From: [email-masked]
Date: Tue, 17 Jul 2001 14:12:13 +0300

Hi Erik,

Some follow-on

>   The directory agent of SLP functions simply as a cache and is
>   passive in this regard. Also, the directory agent is optional and
>   SLP can function without it. It is incumbent upon the servers to
>   update the cache as necessary by reregistering. The directory server
>   is not required in small networks as the user agents can contact
>   service agents directly using multicast. 
> 
> It is also possible to unicast queries to SAs - for instance 
> - subsequent to having discovered them initially via multicast service 
> discovery or via SA discovery, etc.

I've added clarification.
 
>    User agents are encouraged
>    to locate a directory at regular intervals if they can't find one
>    initially.
> 
> UAs can also detect DAs by listening passively for DA advertisements.

Thanks, I've added clarification.

>    The most fundamental difference between SLP and RSerPool is that SLP
>    is service-oriented while RSerPool is communication-oriented. More
>    specifically, what SLP provides to its user is a mapping function
>    from a name of a service to the location of the service provider, in
>    the form of a URL string. Whether the service provider is reachable
>    and how to access it by the URL are out of the scope of SLP.
>    Therefore, the granularity of SLP operation is at application
>    service level.
> 
> The manner in which one access the service can be described using
> the attribute list associated with the service URL.

Got it.

>    In contrast, what RSerPool provides to its user is a mapping
>    function from a communication destination name to a set of routable
>    and reachable transport addresses that leads to a group of
>    distributed software server entities registered under that name that
>    collectively represent the named communication destination.
> 
> This information could also be represented in SLP attributes.

Got it.

>    RSerPool
>    also takes the responsibility of reliably delivering a user message
>    to one of these server entities. What service(s) this group of
>    servers are providing at the application level or whether the group
>    is just a component of an application service provider is 
> out of the
>    scope of RSerPool. In other words, the granularity of RSerPool
>    operation is at communication server entity level.
> 
> Agreed.  SLP is a discovery protocol, not a transport protocol.
> Still, these are distinct functions.  One could use SLP to 
> discover which (suitable) servers exist and also which to use
> (based on load information, etc.)  The transport function of
> rserpool could use this information to provide its services.

I've clarified this.
 
>    Moreover, RSerPool is designed to be a distributed fault-tolerant
>    and real time translation service. SLP does not state either of
>    these as design requirements and thus does not attempt to fulfill
>    them. 
> 
>    In addition, SLP defines optional security features which
>    support authentication and integrity.
> 
> If a SLP UA issues a request specifying security parameters,
> only SAs and DAs will respond which can supply appropriately
> secured replies.  In this sense security is not optional in
> SLP.
>
>    These are mandatory to
>    implement but optional in terms of use. RSerPool has stronger
>    security requirements.
> 
> Does it?  draft-ietf-rserpool-reqts-03.txt states the security
> requirements to be:
> 
>   2.13.1.  General
> 
> YES    -    The scaling characteristics of the security architecture
>             should be compatible with those given previously.
> 
> YES    -    The security architecture should support hosts 
>             having a wide range of processing powers.
> 
>   2.13.2.  Name Space Services
> 
> YES    -    It must not be possible for an attacker to 
> falsely register as
>             a pool element with the name server either by 
> masquerading as
>             another pool element or by registering in 
> violation of local
>             authorization policy.
> 
> YES    -    It must not be possible for an attacker to 
> deregister a server
>             which has successfully registered with the name server.
> 
> YES    -    It must not be possible for an attacker to spoof 
> the response
>             to a query to the name server
> 
> YES    -    It must be possible to protect the privacy of 
> queries to the
> (with       name server and responses to those queries from the name
> IPSec)      server.
> 
> YES       - Communication among name servers must be afforded the same
> (may        protections as communication between clients and 
> name servers.
> require
> IPSec)

I've updated this section.
 
> 
>    The SLP directory agent does not support fault tolerance or
>    robustness in contrast to the name servers which do support it.  
> 
> By fault tolerance, I assume you mean the following requirements
> from draft-ietf-rserpool-reqts-03.txt
> 
>   2.1.  Robustness
>  
>   The solution must allow itself to be implemented and 
> deployed in such a
>   way that there is no single point of failure in the system.
> 
>   2.2.  Failover Support
> 
>   The RSerPool architecture must be able to detect failure of pool
>   elements and name servers supporting the pool, and support 
> failover to
>   available alternate resources.
> 
> SLP does support this.  See RFC 3049 - a standards track protocol which
> supports exactly this function for a specific application.

But, SLP does not support this across the board - I will mention this.
 
>    The
>    name servers also monitor the state of the servers which are
>    registered in the pool but the SLP directory agents do not perform
>    this function. 
> 
> Very short registration lifetimes in SLP can achieve the same, unless
> one is looking for sub-second accuracy.  SLP would require a lot of
> updates in this case, but this would be true of any 
> centralized solution
> for naming with a high degree of correspondence between the name &
> the actual state of the name binding.
> 
> Another possibility would be to use naming to locate rserpool 
> endpoints and then use the 'transport' protocol to provide monitoring 
> functions.

I would suggest that now we are trying to fit SLP into the requirements.
I think that is OK, but would require a submission along the lines of
"Using SLP for RSerPool Name Service" and then we could address
the comparison better in this document.

best regards,
John

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