[Gen-art] Review of draft-ietf-rserpool-*

Cover note (not part of the review):
I have not reviewed these documents for detailed nits; I do not consider 
that a good use of my time.
Neither did I forward this to the WG chairs directly, since I regard it as 
the AD's business to deal with the problem - if the IESG decides that these 
documents are better published anyway, disregarding my advice, it's better 
if this review is published quietly.

This is the most negative review I've done so far. Sorry, John.

-----------------------------------------------------------
Document: draft-ietf-rserpool-arch-10
          draft-ietf-rserpool-comp-10
          draft-ietf-rserpool-threats-05
Reviewer: Harald Alvestrand
Summary: Should be killed, not improved.

These documents are, in my opinion, fundamentally flawed, and should not 
just be DISCUSSed, they should be rejected, and the WG shut down.

The flaws include:

- No security architecture
- No identity architecture to base security on
- No client-locates-server architecture
- No monitoring architecture
- No transaction support architecture

Specific questions that are not answered by the architecture:

- How do the front-end servers get to agreement on which processing servers 
to put load onto? Is there feedback from the servers to the front-ends, 
apart from "up/down" indications?
- How do they handle state?
- Does the model support transactions? Any other integrity model?
- Are sessions sticky by default - so that second requests from the same 
client are *normally* sent to the same server, or does load-balancing 
happen per-request?
- Is the session mode from the users to the frontends the same as from the 
frontends to the servers? Always? Some of the time?
- What is the model for identity exchange between the servers, between the 
front-ends and between servers and front-ends? Do the users engage in any 
kind of identity exchange with the servers at all, or do they just deal 
with an "anonymous blob"?
- What is the model for a front-end going down, as seen from the users? How 
do they figure out which front-end to switch to?

Formalisms that should IMHO prevent publication:

- The -arch draft is normatively dependent on the ENRP and ASAP protocols. 
In fact, I'd claim that the architecture alone is incomprehensible; you 
need the details of the protocols.
Omitting them from the references list is a fatal error.

- The -comp document is trying to answer the question of "why can't you 
just use protocol X". As such, it's a shooting gallery for alternative 
candidates. It does not answer the question of "in which cases do you need 
rserpool".

Again, this has a normative dependency on the protocols.

- The -threat document is simply very badly done.
But again, it can't even be evaluated without the protocols, including the 
parts of the protocols (like identity handling) that aren't specified in 
the current protocol documents.

So this too is normatively dependent on the protocols.

Formalist advice: Send them back to the working group and ask for them to 
be re-forwarded when the protocols are ready.

Operational advice: Disband the working group, and tell them to ask for 
publication of the protocols as Experimental.