[Rserpool] Here are minutes of IETF #57

[[e-mail]]

Sorry this is late.  Comments are always welcome.  

-- maureen

IETF #57
Reliable Server Pooling WG (rserpool)
Monday, July 16, 2003 9:00-11:30AM

CHAIRs:
Lyndon Ong <[e-mail]> 
Maureen Stillman <[e-mail]>

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/draft-ietf-rserpool-comp-06.txt
John Loughney

Rserpool architecture document
http://www.ietf.org/internet-drafts/draft-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/draft-conrad-rserpool-service-03.txt
Peter Lei

TCP mapping
http://www.ietf.org/internet-drafts/draft-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/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
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/draft-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/draft-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.

_______________________________________________
rserpool mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rserpool