Mass Move

Update on current status:

After discussion among the active participants of the UR-WG, consensus is to merge the NLD and XML specifications into a single recommendations 
document.  Rebekah, Scott, and Laura have agreed to draft the consolidated document, incorporating responses to the comments received during the 
public comment period for the original 2 documents.

contacted rodney mach to unify the two UR documents on 8/30

public comments for this document can be entered at
https://forge.gridforum.org/forum/forum.php?forum_id=413

In response to editor comments:
   
      1. There are items in the UR that I think are misnamed or miscast.
  For example there is a globalidname. In the emergent view of
  federations, these identifiers may not be globally unique, just
  unique within the federation (which is perhaps all we care about).
  I suppose that if I cared about this passionately, I should
  have chimed into the doc at the WG level and at this point,
  my role on GFSG is to approve/disapprove this doc on a high
  level.

The description of this data element specifically calls out that this may be global with reference to a metascheduler or federation scheduler.

         2. There are items missing in the UR that I would have assumed should be in a usage record, for example, the time (in GMT) that the job 
initiated, so that an audit can be done if needed.
  Again, I assume that I should have gotten involved in the WG earlier and such low-level concerns should not be raised now at the GFSG level.

The NLD defines an extension element to encourage the exchange of data specifically between sites that is not individually addressed in this document.
  Further, the implementation document (XML Schema) provides several extension facilities for representing such data relevant to a particular 
accounting record.

         3. The most important concern is that there is no security mention in this doc, except to say that security is out of scope. That
  raises lots of issues for me. The two biggest are a.) declaring
  something out of scope might be prudence and encourages flexibility,
  but unless someone else declares the issue to be in scope, it
  doesnt get addressed. What we have learned in other standards
  processes is that flexibility often leads to a lack of real
  interoperability, as implementers take different approaches
  to doing the unspecified tasks. With something as complex as
  Grid software, I would think we want to be careful on what we
  leave unspecified, lest we lose interoperability.  For groups
  that want to use the UR, they will apply their own flavor of
  security around the UR and make it unreadable by others.  b.)
  The lack of security is especially serious given that there
  is no apparent architecture that this UR fits into  who will
  consume this record? Since we dont have an accounting/audit
  architecture (at least I dont know of one, and Ive asked a
  few people), the lack of any inherent security around this record
  makes it very unclear what to do with this record. I am used
  to design work where an architecture is done first, and then
  requirements on payloads (such as UR) within that architecture
  are better understood. I think the lack of an architecture in
  this area is a GFSG issue, a serious one. I dont want to inflict
  that issue on the UR group (they did their narrow job) but wonder
  where to address it.

Response:

Security was determined to be an issue for data interchange and 
implementation, not the format of the data record itself. That's what 
pushed this into the realm of "out of scope". In practice (e.g. the 
Teragrid's Accounting WG's AMIE implementation), we're seeing 
implementations of the UR that accept this and are building security into the interchange, rather than modifying the UR structure itself.  Other GGF 
groups are working on information interchange issues. Since the UR is just a data packet, it should be exchangeable via whatever standards are 
developed for other "system administration" type data (e.g. account creation, job scheduling requests).
Nevertheless, introductory and security section were included at the beginning of the document that indicate this position.

Editor mistake- this draft should be held until after 2 week GFSG internal review (which was initiated today).

Draft in PDF format attached for public comment.

I note that the reference (survey results) is a draft that has been submitted to the GGF editor for review.  The reference can be adjusted once that 
draft has been published.

Changed Group to "SCHED"