Last Modified: 2003-07-09
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 Architecture draft to IESG for Informational RFC | |
Mar 03 | Submit Services document to IESG for Informational RFC | |
May 03 | Submit TCP mapping to IESG for Proposed Standard RFC | |
May 03 | 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 |
well.IETF #57 Reliable Server Pooling WG (rserpool) Monday, July 16, 2003 9:00-11:30AM CHAIRs: Lyndon Ong <lyong@ciena.com> Maureen Stillman <Maureen.Stillman@nokia.com> Approximately 20 people attend the meeting. Summary: Some documents are now nearing completion, while most others have been updated to be consistent. Rserpool comparison document http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-comp-06.txt John Loughney Rserpool architecture document http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-arch-06.txt Michael Tuexen The Rserpool comparison draft and architecture draft have been updated with new information. The comparison draft now includes further description of rserpool and its relationship with DNS and Layer 4-7 switches in response to questions from the Transport Directorate. The architecture draft has been updated with clarification of the control vs. data channel identification and usage and failover support using cookies and business cards. The plan is to do a 1 week WG last call on the comparison document (which was already approved in its previous version) and a 2 week LC on the architecture. Rserpool services http://www.ietf.org/internet-drafts/draf t-conrad-rserpool-service-03.txt Peter Lei TCP mapping http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-tcpmapping-00.txt Peter Lei New versions of the services draft and TCP mapping draft will be available soon. The mapping document has added a PPID which will be used to multiplex like SCTP in the case where data and control channels are present. The use of TSNs has been updated to clean up initialization. ENRP and ASAP issues and updates http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-common-param-04.txt http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-asap-07.txt http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-enrp-06.txt Michael Tuexen New versions of the ENRP and ASAP protocol are available. These update the documents for consistency and also add the clarifications of control and data channel made in the architecture. Among the updates is that a control only channel is disallowed. The default has been changed to a data only channel. A data channel is required; with the control channel being optional. Documents have been updated to reflect that all PEs in a pool use exactly one transport protocol. The use of multicast in ENRP remains an open issue and was briefly discussed. This will continue on the list. Security http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-threats-00.txt Maureen Stillman The current design team consensus was that the network designer could either use TLS or IPsec as mandatory to implement for ENRP-PE and ENRP-ENRP communication. The PU authentication of the ENRP server using TLS was previously decided to be mandatory to implement for reasons of interoperability. Direction from the ADs and agreement in the meeting was that one security mechanism should be made mandatory to implement for all. It was agreed to use TLS as mandatory by those attending the meeting, but we will take the final decision to the list. Other clarifications included the restriction of pool elements within a particular pool to provide the same level of security, for simplicity. In addition, an ENRP server will either have all elements secured or none, also for reasons of simplicity. A mixed security rating for the elements stored in the ENRP database would complicate the client as well as the ENRP server. The client would have to implement a security policy which would review the entries returned by ENRP and select them based on a security policy. It is also unclear what the impact of a mixed database is on security as a whole. It was agreed to restrict the ENRP database to secure registrations only and secure communications between ENRP servers OR insecure registrations only by those attending the meeting. The decision to restrict the ENRP database in this manner will be further debated and validated over the list. Applicability Statement http://www.ietf.org/internet-drafts/draf t-ietf-rserpool-applic-00.txt Lode Coene The applicability statement was reviewed. It has been updated with several comments from the last WG meeting. This is still in an early state and needs alignment with the other documents, especially the services draft. |