Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
Note: This ballot was opened for revision 18 and is now closed.
Magnus Westerlund (was Discuss, Yes) Yes
(Jari Arkko) No Objection
Comment (2008-06-05 for -)
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.