Last Modified: 2005-01-07
Done | Initial draft of Protocol Comparison | |
Done | Initial draft of Threat Analysis | |
Done | Initial draft of MIB | |
Done | Initial draft of Rserpool Services document | |
Done | Initial draft of Pool Management document | |
Done | Initial draft of Rserpool Architecture document | |
Done | Initial draft of Binding Service document | |
Done | Submit Requirements document to IESG for Informational RFC | |
Done | Submit Comparison document to IESG for Informational RFC | |
Done | Initial draft of Resrpool Requirements document | |
Done | Initial draft of TCP Mapping document | |
Done | Initial draft of Applicability Statement | |
Mar 03 | Submit Services document to IESG for Informational RFC | |
Done | Submit Architecture draft to IESG for Informational RFC | |
May 03 | Submit TCP mapping to IESG for Proposed Standard RFC | |
Done | Submit Threat Analysis to IESG for Informational RFC | |
Aug 03 | Submit Binding Service and Pool Management to IESG for Proposed Standard RFC | |
Aug 03 | Submit Applicability Statement to IESG for Informational RFC | |
Nov 03 | Submit MIB to IESG for Proposed Standard RFC |
RFC | Status | Title |
---|---|---|
RFC3237 | I | Requirements for Reliable Server Pooling |
Rserpool summary from IETF #62
Chairs: Lyndon Ong lyong@ciena.com Maureen Stillman maureen.stillman@nokia.com This meeting was attended by approximately 25 people. The Rserpool architecture document was discussed. Changes in terminology have been added to the document. These changes are to clarify the architecture and make it easier for the reader to understand Rserpool. The document contains several examples of applications of Rserpool. We added a load balancing example due to the recent work of the design team in load balancing. Due to these changes we will reissue the document and perform another short last call. ASAP and ENRP have been stable for a long time. Currently, changes are suggested on the mailing list from people who are writing implementations. Several changes have been incorporated into both protocols. They also have updated terminology to match the terminology in the architecture document. We solicit and encourage more implementation feedback. The load balancing design team has been meeting for four months and has made good progress. We are working with load balancing vendors to understand their requirements. Based on requirements, our goal is to examine the advantages and disadvantages of several approaches. Based on the load balancing design, changes to the Rserpool protocol, if any, will be proposed. The design team is working on an internet draft to reflect load balancing requirements. Several scenarios were presented at the meeting that have been discussed by the design team. The design team will continue to meet and is working on an internet draft on load balancing requirements. |