Reliable Server Pooling Policies
draft-ietf-rserpool-policies-10

draft-ietf-rserpool-asap-20.txt: No-Obj
=======================================

Comments:

Section 1:

   When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
   seamlessly incorporate the link-layer redundancy provided by SCTP.

Link layer? Its not just that. I think you mean ... the redundancy
provided by SCTP.

Section 2.2.2:

   Note that deregistration is NOT allowed by proxy, in other words a
   PE may only deregister itself.

I got confused here because at first I thought you had defined a
ASAP proxy role somewhere in the document. However, I think you
simply meant that the PE must de-register its own identifier.
I wonder how to check for this? Is the receiver tracking the
IP address of the sender of the register and de-register? Or
something else? If you can't test it, remove the statement.
Upon reading Section 3.2, I don't think I got any additional
clues about this.

Section 2.2.5:

   Note that if a new Home ENRP server is adopted any 'dynamic update
   request' will need to be resent to the new Home ENPR server if the
   endpoint would like to continue to receive updates.

How does the PU/PE know that a Home ENRP server has been added?

draft-ietf-rserpool-enrp-20.txt: No-Obj
=======================================

Section 3.2.1:

   Note, there is a very remote chance (about 1 in about 4 billion) that
   two ENRP servers in an operational scope will generate the same
   server Id and hence cause a server Id conflict in the pool.  However,
   no severe consequence of such a conflict has been identified.

Hmm. I thought that by the birthday paradox the chances of such a
conflict would be greater. Is there a recovery procedure upon a
conflict? Can the above text be modified to take into account the
paradox? Same issue exists in Section 3.1 of -asap.

draft-ietf-rserpool-common-param-17.txt: Yes
============================================

  This document is in good shape.

draft-ietf-rserpool-policies-09.txt: No-Obj
===========================================

  No comments.

All the documents: 
==================

I am not particularly fond of the security mechanisms. They represent
the "hard-outside-soft-inside" security model. Outsiders will be
unable to pretend to be one of the parties. However, there are no
safeguards with nodes within the system becoming compromised or making
inappropriate actions for their role. For instance, the document does
not define or require the use of certificate fields to bind nodes into
particular addresses or PE/server identifiers.

As an interesting thought experiment, I wonder what RSERPOOL
security would have looked like, if it used HIP-like cryptographic
identities as server/pe identifiers? 

However, I do not recommend the authors do anything abou this. Any
change here would be a major effort and not worth the time at this
stage.