Rserpool Overview - Lyndon Ong 
draft-ietf-rserpool-overview-00.txt 

We have decided to replace the architecture document with an overview of Reliable Server Pooling.  Lyndon asked for 
comments on the document to be sent to the list.  

Rserpool threats - Maureen Stillman 
draft-ietf-rserpool-threats-05.txt 

We reviewed the trust argument for rserpool.  The presentation consisted of a discussion of each threat against each 
architectural component of Rserpool and included the threats posed by interactions between components.  In each case, 
a mitigation was proposed for the threat.  A high level summary of the mitigations required are: confidentiality, 
authentication, integrity, protection from replay attacks and protection from man in the middle attacks.  TLS was 
selected as the security mechanism which meets these requirements.  We discussed the issue of ENRP databases with 
mixed entries; some from secure PE and some from unsecured PE.  It was decided that mixed entries are insecure and 
we agreed to send a security error message from a secure ENRP server to a unsecured PE indicating that it is trying 
to register with a secure ENRP server.  Alternatively, the ENRP server could listen only on 443 and any message not 
using TLS will be rejected.  We will modify the protocol documents to add this error message.

ENRP Implementation Status - Michael Tuexen 

Michael presented an ENRP implementation that was coded just from reading the ENRP protocol specification.  A number 
of specification issues were identified, such as what messages can use the multicast channel, handling of takeover 
requests with a non-responding server and topological connection of servers.  It was commented that an implicit handling 
of the takeover case that was used in the original implementation was to take any non-responding servers off the list of 
active servers.  Michael agreed that this is reasonable but needs to be documented in the ENRP protocol.  We will modify 
the ENRP document to add this explanation.

Address scoping - Michael Tuexen 

Michael presented an issue with the addresses returned by the ENRP server. Part of the issue concerns SCTP address scoping 
drafts that are expired and need to be resubmitted, part has to do with defining Rserpool-specific aspects. The AD asked if 
documenting the SCTP issues, independent of Rserpool, was important. The general view was that this was important and that 
the desired action would be to resubmit the SCTP drafts as well as documenting Rserpool specific aspects.  However, as a 
fallback, in case the SCTP drafts do not progress well we could document all aspects of address scoping in a Rserpool 
document.  The next step will be to resubmit the expired SCTP documents.

ASAP - Randy Stewart 
draft-ietf-rserpool-asap-14.txt 
Randy noted that he had done a major update on the ASAP specification and has addressed all of the major issues, except for 
a security update based on the recent threats work described above.  The draft  specification for this update was included 
in the latest ASAP draft.

Rserpool Interop - Randy Stewart 

Randy reported on the results of an Rserpool Interop held in Vancouver in July.  At the Interop there were 2 ASAP 
implementations, one from Cisco and one from University of Essen, and one ENRP implementation.  These were tested in an 
ad hoc manner but were found to work together successfully.  200 ENRP server processes were run simultaneously to test the 
ENRP implementation.

Next steps: 

The WG reached consensus on submitting the documents as experimental.  The following documents will comprise the Rserpool 
package that will be submitted to the IESG:

Overview 
ASAP 
ENRP 
Common parameters 
Threat document 
Policy 

We will update these documents based on the comments from the WG meeting and submit the package to an external reviewer.