This document will now be published as GFD-R.069

Thanks to the authors/editors for work on this document!

GFSG cconsensus is that we will move these to publication,
but we'll allow a 10-day "final call" on the GFSG mailing list.
There is a question about whether the changes after
public comment warrant a new public comment period.

Sorry, this is not quite ready after all.  There is
still some editing in process.  We will leave this
with the authors until it is re-submitted to this 
tracker.

Thanks for this revised document.

It is now in 15-day final GFSG review prior to publication.

Thanks for your comments which will improve the rigors of our document. We have addressed all comments provided. They were all minor, except for one 
which required syntactical, but not semantical changes to spec. We believe that due to the nature of changes there is no need for another full 2 
months review cycle, but we will leave it to  your discretion. Below is a summary of the changes provided by Steve Loughran:

Overall, these comments are a welcome application of rigorousness to the
use of the RFC2119 keywords to the document, highlighting when they are
not used where they are needed, and indicated places where their use is
inappropriate. with one exception all of the changes are minor, and 
do not change any of the semantics of the specification, merely reduce
ambiguity.

The biggest change is in section 7.2.1, in which the "scheme" element 
representing a URL scheme was misspelled as "schema". 
This is part of the public deployment API XML Schema:
changing it will affect the implementations, but not the semantics of
the actual implementation. Members of all four implementation teams
were consulted over the change, and agreed that it was minor and that
it should take place immediately.

In the process of updating the document I also
 -changed the date to 2006
 -updated the copyright years
 -corrected an error in which a code sample had merged with the following
 paragraph, and was not marked as code.

----------------------



The following is my comments on the 2005-09-13 draft of the Deployment API. 
The comment format is similar to the Aardvark Comment Format described in the 
following page: 
 
http://www.opengroup.org/austin/aardvark/format.html 
 
 
@ page 10 section 3.4.3.3 Extra deployment options 
 
Problem: 
  In the 1st item of the bullet list, the following sentence: 
 
    Every option is named by a URI. 
 
  does not contain RFC2119 keyword. 
 
To fix: 
  Change the sentence as follows: 
 
    Every option MUST be named by a URI. 
 
    
-fixed as advised.
    
    
@ page 10 section 3.4.3.3 Extra deployment options 
 
Problem: 
  In the 7th item of the bullet list, the following sentence: 
 
    Options MAY be processed in any order. 
 
  "MAY" is inappropriate in a list of requirements. 
 
To fix: 
  Use "may" instead of "MAY" and change the order of the 
 sentences, 
  as follows: 
 
    Options MUST NOT require a specific order of processing.  Options 
    may be processed in any order. 
 
    
-fixed as advised.

@ page 11 section 3.5 WS-DM Integration 
 
Problem: 
  The 2nd sentence of the 1sst paragraph says: 
 
    Both Portal and System endpoints support the MUWS ResourceId and 
    ManageabilityCapability attributes ... 
 
  It is unclear whether it is a requirement or not. 
 
To fix: 
 
  If it is a requirement, use "MUST", such as: 
 
    Both Portal and System endpoints MUST support ... 

-fixed as advised.    
@ page 13 section 4.2.2 Portal Endpoint Operations 
 
Problem: 
  In the description of the "Create" operation, the following 
 sentence: 
 
    hostname is OPTIONAL. 
 
  is inappropriate because the "OPTIONAL" in RFC2119 keyword means 
 that 
  "an implementation can choose whether to implement the feature or 
 not". 
  An optional parameter is not "OPTIONAL" in RFC2119's sense. 
 
To fix: 
  Change the sentence to: 
 
    hostname is optional. 
 
-fixed as advised. Also changed the text
 in section 6.2.1 as advised above.


@ page 13 section 4.2.2 Portal Endpoint Operations 
here and also at 
page 15 section 4.3.2 System Endpoint Operations 
 
Problem: 
  Typo.  The operation name "GetResourceProperties" should be 
 "GetResourceProperty". 
 
To fix: 
  Change "GetResourceProperties" to "GetResourceProperty". 
 
@ page 14 section 4.3.1 System Endpoint Properties 
 
-fixed as advised.

Problem: 
  The "Meaning" column of the property "api:StartedTime" 
 says "Time system was 
  *terminated*."  Is it intentional? 
 
To fix: 
  If the property indicates "started" time, say so. 
 
  BTW, when a system is "started"?  After receiving "Initialize" 
 message, or 
  "Run" message, or otherwise?  The word "started" must 
 also be clarified. 
 
-fixed by changing the sentence to "Time system moved into the running
state.". 
 
@ page 19 section 6.2.1 AddFile 
 
Problem: 
  In the AddFile operation, the word "schema" is used to indicate 
 the first 
  part of the URL/URI (e.g. "http" in "http://www.example.com/";). 
  However, 
  RFCs defining URL/URI format (RFC1738 and RFC2396) uses the word 
 "scheme" 
  for that part. 
 
To fix: 
  Change "schema" to "scheme". 
 
-fixed as advised. Updated the XSD document in the repository, and
 in the appendix.

@ page 22 section 6.2.7 Destroy 
 
Problem: 
  In the 2nd paragraph, "MAY NOT" is used.  However, in RFC2119, "MAY 
 NOT" 
  is undefined and its use is confusing to the readers. 
  You may not use "MAY NOT". 
 
  In general, "MAY" means "allowed to do".  Negation of 
 "MAY" ("MAY NOT") will 
  mean "not allowed (prohibited)" but such a sense is properly indicated 
 by the 
  use of "MUST NOT".  If you want to say "allowed not to do", 
 "need not" or 
  "not required to do" will work. 
 
  In this specific case, "MAY" is used to indicate *possibility*. 
  However, 
  "MAY" in RFC2119 only indicates *permission* to implementations. 
  In such a case lowercase "may" may be appropriate. 
 
To fix: 
  Change "as it MAY NOT be valid" to "as it may be 
 invalid". 
 
-fixed as advised.

[END]

Authors, please review John T's comments, which
I as Editor support.  We will await your response.

On 12/22/2005, in tracker https://forge.gridforum.org/forum/forum.php?thread_id=1052&forum_id=574, Toshinori Numata of Fujistu raises nine succinct 
issues for this specification dated 9/16/2005.  I am unable to find any subsequent discussion in the tracker of Numata-san's comments, nor has a 
revised document incorporating Numata-san's corrective suggestions been posted.  Discussion could of course have occured in the WG and be documented 
in WG meeting minutes, but as a formal public record the tracker(s) should contain at least a summary of responses by the authors.

I'm regretably unable to recommend approval by GFSG in this circumstance, which I expect is an unintended oversight not characteristic of the typical 
work in this WG. I recommend this document be returned to the authors for their comment and/or document correction. Should the authors have a revised 
document to submit, and where the changes are limited to corrections consistent with Numata-san's comments, I propose a shortened public comment 
period of thirty days (I do not agree with a waived public comment period for a document with edits based on previous public comment, I consider this 
an expediency not consistent with the intention of public review of a proposed specification). If additional changes are made, the document should 
have the normal 60-day recommendations-document public comment period.

Thanks,
jt

Authors, please review public comments here:
  https://forge.gridforum.org/forum/forum.php?forum_id=574

Respond in that tracker, or this one.  Create a new revision
to your document, if needed.

When the document is ready fo rthe next phase (GFSG review),
please indicate so in this tracker, or via email.

(It will be due 60 days after it is publicly announced)

(It will be due 60 days after it is publicly announced)

Thanks.  This document is now in 15-day
GFSG review prior to public comment.  Because
the GGF15 conference is next week, we will
allow until October 18 for a GFSG decision.

We have adderssed all issues raised by the GGF editor.

Thanks for this submission.  I have several items I would 
like to be fixed or responded to before moving this document
to the next phase of the review process.

First is that the header states this is an informational track
document (GWD-I), but the tracker has Recommendations
track submitted.  Which is the intent of the working group?

For these other comments, use the template in the Editor
tracker, or a recently published GGF document, as an example:

Second, please fill in the compete information for the 13 Editor
section.

Third, "12 Security" should be "12 Security Considerations."

Fourth, the references nearly all need a lot of work.  References
need to be complete:
- author (or corporate author)
- title and (if applicable) volume
- publication location (for online sources, the publisher/organization's
location)

For online materials, they may only be cited in the References
section if they are persistent documents - not to Web sites
or other transient content.  For citation fo something like
a WG's homepage or organization, use an inline reference
or footnote, for example, in text:  "The Global Grid Forum (http://www.ggf.org)," instead of putting the hyperlink
in the References section.

I don't think *any* of the references are complete, and
several are simply hyperlinks that don't belong in the References
section.

Here is the rule of thumb for references: you need to provide
sufficient information so that a future reader (say, in 10 years)
can use your reference to find the exact same document you
used in your authoring.  If it seems unlikely the same document
will be available (for example, because a Web page will have
changed), then this might be a better candidate for inline citation
or a footnote.

Fifth, the GGF logo, copyright statement and IP notice are
misplaced (see the sample documents), and you don't
need to include the logo.

Sixth, page footers are missing except on the first page
(they don't need to be on the first page, but should be
on the other pages).  Email address, also page number.

Seventh, the Status and Abstract headings don't match
the rest of the document, or the GGF's other samples.

I'm sorry for this big list of changes.  As you see, none
of them are focused on the content -- it's all about
the presentation & formatting, consistently with the GGF
standards.

I did read the content, too -- to me, this appears to be
a well-written document, and presents valuable information.
Once you have re-submitted with the above suggestions
addressed, we'll continue to advance it through the editor
pipeline as specified in GFD-C.1.