It's a good thing it's a sunny day here. Otherwise my head would hurt wading through this acronym soup.
I say the above in case the following demonstrates a total ignorance of your topic.
"The CMDB is updated and referred to throughout the Release Management process concurrently with updates to the DSL ..."
- asrilrm quoting the "book"
Maintain the integrity of the DML is explicitly mentioned as one of the procedures that must be put in place by CM process in ITIL V3 Service Transition book.
All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System.
- IT Process Wiki by a company called IT Process Maps GbR (easy to find through google).
That's as far as I've got. I'm not saying this is complete or definitive (!), but it seems enough to proceed as follows:
1. a) The DML is a library and therefore
b) needs to be in the hands of a librarian who
c) has the appropriate skills and expertise for the role.
2. The DML librarian is responsible for the maintenance and access and use of the library.
3. The DML librarian is required to ensure that the library is subject to change management, release management and configuration management, just like any other CIs in the ITSM system.
4. The DML librarian is no more required to be "owned" by ChM, RelM or ConfM than is the (say) the server manager.
If we are to make sense of such statements as "X is controlled by release management [configuration management, change management, or anything else management] it is that X is subject to those processes, not that X is their responsibility. Everything is subject to, and everyone (whatever their role) is required to adhere to, those processes. Thus:
My opinion is that it is a little against the "take down the silos" approach of ITIL, but anyway theory must always be adapted to each organization needs and culture...
... doesn't go far enough for me. The issue is not an ITIL issue in that sense. In this context ITIL is about process, not about organization (it's hardly ever about organization). Even if you build your organization around the processes, at most, that becomes a factor in deciding where to place ownership of "physical" entities as distinct from owning the control of how they are managed. So who the DML librarian answers to is down to the practicalities of your particular organization and is not an ITIL matter beyond the fact that ITIL helps you understand those practicalities.
One useful thing, especially in large organizations, is to follow the chain of command up from the DML librarian and see if it rests sensibly further up or if a dotted line is appropriate for it. If neither of these fits, then perhaps it is in the wrong place.