|
I have reviewed this document as part of the Operations
and Management
directorate effort. These comments were primarily written for the benefit of the O&M area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 1. Is the specification complete? Can multiple
interoperable implementations
be built based on the specification? I believe that the specification is complete in terms of client-server operation. There appear to be multiple implementations (though I am not familiar with
the level of interoperability that
has been demonstrated).
2. Is the proposed specification deployable? If not, how could it be improved? My overall concerns echo those described by Pekka
Savola in his review of the
Rserpool Overview document:
As noted in Pekka's review, the Rserpool architecture requires
changes to applications
as well as deployment of new infrastructure services.
There are also potential interactions
with other load balancing mechanisms, both at the application
and network layer.
The changes are so substantial that I believe it is highly
unlikely that Rserpool
will ever be widely deployed.
3. Does the proposed approach have any scaling issues that could affect usability for large scale operation? In practice, global as well as local load balancing is an important consideration; Rserpool largely focuses on the later concern. I
do have some concerns about
the scalability of the TLS-based security mechanism suggested
in Section 6.
4. Are there any backward compatibility issues? Yes. The Rserpool approach requires applications to be
rewritten, so it is not backward
compatible with existing applications. This is a major
limitation, especially given that
other load balancing solutions that do not require application
changes have already been widely
deployed.
5. Do you anticipate any manageability issues with the specification? Yes. As with SHIM6, there will be concerns relating to
interactions of Rserpool
with other load balancing mechanisms.
6. Does the specification introduce new potential security risks or avenues for fraud? The security issues are discussed in Section 6, and appear to
be adequately
addressed.
From: Seely, Ted A [CTO]
Sent: Saturday, April 05, 2008 5:59 PM
To: Bernard Aboba
Subject: Ops Dir Review Request As a member of the Operations Directorate you are being asked to review the following IESG work item for it?s operational impact. IETF Last Call http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-19.txt If possible please provide comments and review to the Ops-dir mailing list (ops-dir@xxxxxxxx), preferably before next Wednesday, April 9th if possible. Thank you, Ted |
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf