Comments on the comparison document

I have mostly nits which are optional.  Non-nits are first.

Non-nits:

2.3.3 Summary of SLP Issues

4th paragraph

SLP security makes no attempt to address the confidentiality of data
   transmitted between SLP agents. To properly address this concern, SLP
   agents would need to establish secure communication with each other.
   This would be achieved through the use of IPSec Encapsulating
   Security Payload.

I know from David Black that they changed some of the security in SLP to accommodate IP Storage.  So I'm not sure if this is still an issue.  I can ask David what they changed or we can delete this, your choice.  This single point does not change the our conclusion, however.

3.2.2 Technical Issues

Most of the extended features of ASAP [6] and ENRP [7] are not met by
   a device employing L4 switching techniques.

The use of the word "extended" has potential for confusion.  They might think that ASAP and ENRP have a set of extensions that L4 switches don't support.  In fact, ASAP and ENRP don't have any extensions defined right now.  I have two suggestions: 1) delete the word extended and 2) add to the end of the sentence (see comparison table in section 5) OR you could list some of the requirements that L4 switches don't meet.

4.2 ENRP

   Another important aspect of ENRP is that itself is fully distributed
   and replicated. This is to avoid the name service itself becoming a
   single point of failure in the system.

This wording has the potential for the reader erroneously concluding that ENRP servers have perfectly synchronized databases.  Also "fully distributed" might cause confusion as it leaves out the operational scope which is technically what ENRP is limited to.

How about this excellent wording taken directly from the ENRP internet draft abstract.  Then put your last sentence at the end.:

Within the operational
   scope of Rserpool, ENRP defines the procedures and message formats of
   a distributed, fault-tolerant registry service for storing,
   bookkeeping, retrieving, and distributing pool operation and
   membership information.  This is to avoid the name service itself becoming a
   single point of failure in the system.

Nits:

   Name Server: Entity which the responsible for managing and
      maintaining the name space within the RSERPOOL operation scope.

change to (* to help you find the word(s) to change):

   Name Server: Entity which *is* responsible for managing and
      maintaining the name space within the RSERPOOL operation scope.

2.2

   One requirement to any solution proposed by RSERPOOL would be to
   
change to (* to help you find the word(s) to change):

   One requirement *of* any solution proposed by RSERPOOL would be to
   

2.2.1

   These requirements are related to DNS.

confusing.  How about:

   These requirements are discussed below in relation to DNS.

2.2.2.6

Without significant extensions, the current DNS would have difficulty
   to achieve this type of name mapping.

change to (* to help you find the word(s) to change):

Without significant extensions, the current DNS would have difficulty
   *achieving* this type of name mapping.

2.2.2.7

These models basically define how a PE is going to
   behave when another PE 

change to (* to help you find the word(s) to change):

These models basically define how a PE *behaves* when another PE

3.1 Introduction

Since these technologies
   are highly proprietary, it is difficult to detail these techniques in
   a thorough manner.

change to (* to help you find the word(s) to change):

Since these technologies
   are highly proprietary, it is difficult to *discuss* these techniques in
   a thorough manner. 

4.1 ASAP

And ASAP
   allows extensions to be made in the future to accommodate new load

delete the And....

ASAP
   allows extensions to be made in the future to accommodate new load


   ASAP supports the "keepalive" monitoring of PEs by the name server
   and session failover, in which a set of application messages are
   defined as a "session" and ASAP provides best-effort transmission of
   all the messages in the "session" to the same PE in the destination
   pool, and failover the remaining message in the "session" to the same
   alternate PE if the first PE fails.

Failover is not provided for all classes of service.  Need to fix one word as well.  How about:

   and for some classes of service can provide failover *for* the remaining message in the "session" to *an*
   alternate PE if the first PE fails.

4.2 ENRP

ENRP itself is dynamically scalable, meaning that new ENRP servers
   can be added and existing servers be removed as needed. This feature
   can be used to achieve zero planned downtime upgrade of a system - an
   often found requirement in many mission critical applications.

change to (* to help you find the word(s) to change):

ENRP itself is dynamically scalable, meaning that new ENRP servers
   can be added and existing servers *can* be removed as needed. This feature
   can be used to achieve zero planned downtime upgrade of a system - an
   *common* requirement *for* many mission critical applications.

I think this is it.  Thanks.   

-- maureen