A mistake many people make trying to use ITIL guidance is expecting it to be explicitly prescriptive (in other words, a step by step procedural how-to). That's not what it's intended to do. ITIL at its most useful describes a way of thinking about the work we do (from the point of view of our customers and how, or whether, our services are delivering the optimal value). At each level of detail, legitimate people will raise questions. For example, given the notion of Service Portfolio Management, the strategic decision to build an organizational capability prefaces the arrival of actual customers with explicit Service Level Requirements. Seldom is the real world quite so neat. For that matter, processes we associate with managing transition activities are often supporting strategic planning and prioritization of effort, processes we associate with operation are often providing explicit design and architecture support, and so on. In short, even ideas like the Service Lifecycle are nice models, but that's what they are - models, and not even simple linear ones.
Service Management guidance provides a good jumping off point for thinking about implementing processes, services, and considering underpinning tools. In particular, it allows us to begin to define the key activities (and then it's on us to describe more explicit procedures and work instructions), roles and responsibilities (which then need to be mapped to actual people and governance), and metrics (which then need to be turned into actual measurements with actual feedback, reporting, and oversight). Most of the time the academic arguments that find their way into discussion boards (is a reboot a change?) can be answered for a particular organization based on usefulness (Are we tracking reboot events? Are we logging incidents for which the reboot is a workaround? Are we tracking reboots as part of a change/release implementation? Are we tracking reboots for standard MTBF maintenance activities?)
The answer of course is clear - it depends on organizational need. Remember, the tools (and processes, and guidance) are supposed to work for you, not the other way around!