FW: Rserpool minutes for IETF #58

Here are the minutes.  Send any comments, however, they are already in the proceedings.  Sorry I didn't get from the group comments before the deadline.

Happy holidays.

-- maureen

-----Original Message-----
From: Stillman Maureen (NES/Ithaca) 
Sent: Friday, December 19, 2003 3:26 PM
To: '[email protected]'
Cc: [email protected]; '[email protected]'; '[email protected]'
Subject: Rserpool minutes for IETF #58


Reliable Server Pooling WG (rserpool)
 
Monday, November 10, 2003
=================================
 
 CHAIRs:
 Lyndon Ong <[email protected]>
 Maureen Stillman <[email protected]>


http://www.ietf.org/internet-drafts/draft-conrad-rserpool-service-02.txt

The Rserpool services draft is still under construction.     Two modes are defined: basic and enhanced.  Basic just performs server selection, that is, it uses a pool handle to get an IP address and ports of servers.  Then the application must take care of all failure detection etc.  Enhanced mode uses TCP+shim or SCTP. Data is transported through RSERPOOL service.  The next draft needs to be reviewed as there have been a number of changes since the -02 draft.

There have been a number of requests for a socket layer defined to make Rserpool more easily accessible to implementers.  A high availability socket layer would be a useful addition.  Some volunteers for a draft were identified.
 
http://www.ietf.org/internet-drafts/draft-rserpool-tcpmapping-00.txt
There have been no changes to the TCP Mapping document.  The references in it need to be updated.  This document is considered stable at this point.

http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-07.txt

Rserpool architecture document has been submitted to the IESG for review.  It was updated to point to the security threat document in the security considerations section.  Comments received during last call were incorporated into the document before it was sent to the IESG for review.

http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-06.txt

ENRP and ASAP issues and updates were addressed.  Security considerations section was added to both ASAP and ENRP based on the work of the security design team over the last year.  The decision to use TLS as the security mechanism for Rserpool was documented.  A namespace consistency audit was added to ENRP.  It was pointed out that the databases will not be 100% consistent with each other.  A checksum is used to determine if the databases are in synch.  If the checksums do not match, then a resynch is required.  The use of multicast is still an open issue due to security concerns.  Everyone should read the drafts carefully and send any comments.

http://www.ietf.org/internet-drafts/draft-ietf-rserpool-threats-02.txt

The security design team has completed its work after meeting for over a year.  The threat document has been submitted to the IESG for review and comment.  Several comments were incorporated during last call.  Information regarding security of the ENRP namespace needs to be added to the ENRP document security considerations section.  One outstanding issue is the TLS cipher suite. A MUST implement cipher suite needs to be implemented.  This was brought up on the list.  We agreed on AES as MUST implement at the meeting. The security design team declares victory and has meet all of its objectives.
 

http://www.ietf.org/internet-drafts/draft-rserpool-applic-01.txt

Applicability Statement draft is waiting on a new revision of the rserpool services document.  These documents need to be in synchronization.  The draft will be updated to reflect the changes in services.


http://www.ietf.org/internet-drafts/draft-xie-rserpool-redundancy-model-00.txt

Rserpool redundancy model support is not sufficient to support some commonly deployed high availability systems.
This draft defines an extension to the load sharing policy to support an advanced N+M or N-way redundancy model.  There was a request to incorporate this draft into ASAP/ENRP.  There is potential IPR on this draft.  Motorola will clarify the IPR issue.  Decision will be made after Motorola provides more information on its IPR claim.