> P10 - use of term Helpdesk and Service Desk appears inconsistent.  Mostly
> referred to as Service Desk, with GGUS as the ticketing tool.  Consider
> clarifying.

I haven't used helpdesk and service desk as synonyms. According to the ITIL glossary there can be a slight difference: "Help desk: (Service Operation) A point of contact for Users to log Incidents. A Help Desk is usually more technically focussed than a Service Desk and does not provide a Single Point of Contact for all interaction. The term Help Desk is often used as a synonym for Service Desk."
I guess I can just use "Service Desk" for consistency.
However, I wanted to distinguish between the service (the Service desk) and the tool used to provide support (i.e. to handle incident records, we call it GGUS). I think I've found the right term for this. Should be "Incident Management Tool". Am I correct?

> P12 - interoperability - I didn't understand the "accounted for use of." do
> you mean ensure new services are measured individually and compared to
> targets as well as checking existing services continue to meet targets after
> new services are introduced?  Might you be able to clairify this?

I have clarified this. It means that in order to be interoperable, infrastructures need to host services which usage can be measured (accounting of usage).

> P13 - reword 2nd level support paragraph to be more in line with ITIL's
> definition of escalation of incident to problem management (reference the SO
> book, page 80, para 4.2.5.6 incident escalation).
Done!

> P13 - Early Life Support - clarify who records the incident details and use
> of the term "escalate".
Done!

> P15 - oversee instead of overlook.  Are you going to set service levels for
> availability?  Usually ITIL would expect us to set targets which we would
> attempt to meet or exceed, not just respond to low performance issues.
Correct, I have clarified this. This is what we have in place at EGI.

> P15 - service level management - you mention tools here, SLM sets the
> guidelines for measurement and ensures adherence to reporting schedules, you
> wouldn't usually expect SLM to manage the actual tools.
ok. Does ITIL have a process which owns this function (the management of tools for generation of the availability statistics?)

> P17 - service portfolio is owned by SS.  SS considers which services it
> wants to focus on and what should enter the service pipeline and when.  When
> SS charters a service, the commitment to deliver something in the pipeline
> is articulated through an entry in the Service Catalogue, which includes
> expected functionality and delivery date.
ok I have corrected this

> P18 - OLA's, interesting point - your RC's and RP's are internal service
> providers (no money changes hands, therefore no legal contract is required
> under broad ITIL terms), yet you can manage them as though they were 3rd
> party providers suspending their participation if they fail to perform.  Not
> pure ITIL, but an adaption of the ITIL concept.
yes this is the case

> P20 - availability, UP time, and WARNING appear to be interchangeable.  ITIL
> gives more definition here, as to what is a warning and what will you do to
> ensure rapid return to service.  You could consider including a calculation
> of UP and WARNING, with perhaps some reference to identifying "SPOF" single
> point of failure, to reduce the number of times services generate warnings.
> In fact you address availability issues in an ITIL way (very well) under the
> heading IT service continuity, which I suggest you move up to Availability.
I have clarified this

> P20 - IT service continuity, you have addressed this succinctly in one
> paragraph.  It would be priority to expand and focus on your risk
> assessment!
Indeed this is a gap area... Risk assessment activities will start only in 2012, and we are currently discussing which standards to adopt for this. Unfortunately at the moment I have little activities to report in this area.

> P25 - change management - careful to recognise the change process is NOT
> implementing the changes, but ensuring changes are accurately assessed for
> risk and managed accordingly to minimise disruption. The CAB has one key
> member - the Change Manager, who ensures relevant parties are invited to
> attend to give opinion and advice depending on the change under review.
I have clarified all this

> P31 - Problem management - proactive problem management is a key part of the
> problem process.  CSI sees the bigger picture, and may find proactive
> problems as part of it's analysis of capacity and availability and
> technology type measurements.
You are correct in saying that proactive problem management is currently delegated to resource centres and national providers (it is not conducted at a global EGI level). I have identified this activity as an area that deserves more development.

> P34 - CSI steps, there is probably room for growth here, as you become more
> mature your approach to CSI should be greater than looking at existing
> performance issues.  ITIL expands on this in huge detail - your initial
> explanation is fine for an early maturity suggestion.
> Finally, check consistency in naming conventions and terms, especially for
> example when using Helpdesk and Service Desk - which is the EGI using?  ITIL
> always uses the term Service Desk.
I have fixed this and adopted Service Desk, and used Incident Management Tool when I refer to the tool.