Overall: This is an important specification that plays a key part in the OGSA Data Architecture as well as being used 
standalone.  It has the support of several major players.  The specification seems sensibly scoped for a version 1.0 and
 is well written.

The following are all minor comments that I noted while reading the spec for the first time.



* Abstract

"will be greatly reduced" -> "is greatly reduced"?

"leverage off" -> "leverage"

* Introduction (opening section, before 1.1)

I think you need to clarify that the DMI mechanism transfers a copy of the original data, i.e. that whether the source 
retains or deletes its copy is outside the scope of this specification.  (Cf. POSIX "mv" vs "cp").

I think the introduction should mention that the user can optionally specify a preferred or suggested transport protocol
, i.e. the automatic negotiation is the ideal but can be bypassed if the client wishes.


* Architecture

First bullet points: the trailing "and" looks as if something has been omitted from that line.  I assume the intention 
is to link to the second bullet point, but it does not read well.  Perhaps a semicolon is needed before it?


Section 3.3.3

The DEPR, as described here, seems to contain similar functionality to a WS-Name.  Can a DEPR be built using a WS-Name?

Section 4.1.2

I don't understand what is meant by "undo strategy identifiers look like URLs but they are not necessarily so".  What is
 the characteristic of a URL beyond syntax that you are referring to?  Why don't you just say that they are URIs?

I also don't understand how the undo strategies relate to the "Failed:*" states. The "full" strategy says that cleanup 
is "guaranteed"; can this ever fail and leave the system in the "Failed:Unclean" or "Failed:Unknown" states?  Conversely
, can the "none" strategy every leave the system in the "Failed:Clean" state?

Section 5.2.7.1.1

"dmi:InstanceAtrributes" -> "dmi:InstanceAttributes"

Section 5.4.1.8

"Failed:Unkown" -> "Failed:Unknown"

Section 5.4.2

It would be useful to repeat here that the mechanism for emitting LifeCycle Events is not defined in this version of the
 specification.  When I read the document, I missed the initial explanation of events and was caught by surprise when I 
reached this section.  Anyone jumping straight to this section wouldn't understand the context.