For the definition of Grid Computing it is better to use more reliable
sources than Webopedia, e.g.
"Grid Computing -- Making the Global Infrastructure a Reality",
edited by F.Berman, A.Hey and G.Fox, 2003, John Wiley & Sons,
ISBN: 0-470-85319-0.

The Grid infrastructure should be able to dynamically link together
geographically dispersed resources as an ensemble to support the
execution of user's applications.
The user's applications are not necessary Ice servers.
The Grid resources are geographically dispersed and they are not
under single administrative control, i.e. the Grid infrastructure should
provide tools for the owner of a resource to set use policies.

Two use-cases as examples:
- the owner of computing farm sells the computing cycles;
- a user wants to analyze data stored on several mass storage systems.

Different people use slightly different definitions of Grid because
of different problem domains. For example, the classical dilemma is
should we send the executables to the data or the data to the executables.
But independently of definition, the Grid computing has two challenging
tasks: resource location and security.

IceGrid focuses on deployment and monitoring of Ice servers.
Clearly, this will be important and useful tool but how is it related to
the Grid Computing ? (IcePack2 would be the better name).
What are the mentioned 'Ice servers' ?
If they are user's applications then this is the serious restriction.

Moreover, both critical features of Grid are missed or oversimplified.

Resource Location
-----------------

Fig.2 shows that the resource location is done via IceGrid Locator,
i.e. IceGrid Locator serves as a database of available computational
resources. But what is the quality of these resources ?
Maybe, 'Server-1' is an Intel-286 from a museum, and 'Server-2' is
a new supercomputer, and 'Server-3' is a computational farm.
Which is the best ? Maybe, to run 'hello, world' the Server-1 is the
best one because the two others are overloaded.

The other aspect which is ignored is data.
IceGrid Locator publishes computational resources. But data is also 
a resource and sometimes important.

Security
--------

Grid infrastructure is usually expected to run over untrusted WAN.
The communicating parties can be unknown to each other as in the
example of selling the computing cycles.
Therefore the Grid infrastructure must provide a high-level of security.
This includes, but not limited to:
- an authentication of the communicating parties;
- ensuring message (data) integrity;
- ensuring message (data) confidentiality;
- an authorization, i.e. the controlling access to resources;
- an auditing.
Without these features any commercial (and usually non-commercial too)
use of Grid is questionable.

Of course, all communications in IceGrid can be protected with IceSSL
(assuming that PKI has been installed everywhere). Note that this
is a protection on the transport layer. This provides
authentication, message integrity and confidentiality assuming that
there is no delegation of credentials in the system. If the delegation
is possible, e.g. a user's job is assigned to Server-3 but Server-3 decides
to send the job to Server-4 which is hidden behind it, then the transport
layer security is not enough.

The authorization and auditing aspects are not covered by Ice at all.
Maybe it worths to consider the idea to accompany each Ice object with
Security Descriptor (similar to Windows):

struct SecurityDescriptor
{
    UserId owner;    // can be, for example, owner and issuer of certificate
    StringSeq DACL;  // hook for authorization
    StringSeq SACL;  // hook for auditing
};


Summary
-------

IceGrid is not a Grid infrastructure because:
1. It is designed for Ice-aware applications.
2. Resource location service is oversimplified.
3. Security is far from the acceptable level.

I would not use the word 'Grid' for the proposed service because
it is misleading.