|
Greg Newby: 05/06/2007 4:46 AM EDT
|
|
Action: |
Update
resolution changed from PUBLISHED to none (no value)
|
|
Greg Newby: 06/25/2006 9:03 PM EDT
|
|
Action: |
Update
Closed set to 06/25/2006
resolution set to PUBLISHED
Status changed from Open to Closed
|
|
Greg Newby: 05/03/2006 6:38 PM EDT
|
|
Action: |
Update
artifact_group changed from Management to <None>
artifact_status changed from ready to publish to Open
assigned_to changed from 9357 to 100
assigned_to changed from 9357 to 100
Category changed from Recommendations Track to <None>
group_artifact_id changed from Submit GGF Draft to Published
Priority changed from 1 to -
|
|
Joel Replogle: 04/25/2006 1:25 AM EDT
|
|
Comment: |
Published as GFD.69 on 25 April, 2006
|
|
Action: |
Update
|
|
Greg Newby: 04/22/2006 8:17 PM EDT
|
|
Comment: |
This document will now be published as GFD-R.069
Thanks to the authors/editors for work on this document!
|
|
Action: |
Update
|
|
Greg Newby: 04/22/2006 8:17 PM EDT
|
|
Action: |
Update
artifact_status changed from Final 15day GFSG Review to ready to publish
assigned_to changed from 628 to 9357
Priority changed from 2 to 1
|
|
Greg Newby: 04/11/2006 11:30 AM EDT
|
|
Comment: |
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.
|
|
Action: |
Update
|
|
Greg Newby: 03/31/2006 4:45 PM EST
|
|
Comment: |
My impression is that the changes are not
broad enough to require a further public comment
period, but let's go ahead and discuss this in the
GFSG conference call.
We can schedule it for the April 19 call, or as soon
thereafter as is feasible.
|
|
Action: |
Update
|
|
Greg Newby: 03/31/2006 4:45 PM EST
|
|
Action: |
Update
artifact_status changed from Submitted to Final 15day GFSG Review
|
|
dejan@hpl.hp.com: 03/28/2006 2:53 PM EST
|
|
Comment: |
Comments from Steve:
This is the updated document. As usual, the CVS image of this is the normative copy of the specification; what you are seeing here is are downstream
artifacts of that gold image.
I've made less changes than hiro suggested, not because I dont agree with them, but because I dont think the changes should go through except in co-
ordination with the other specifications. If we can do this, then yes, I am in favour of the changes.
A1, A2. Yes, there is duplication in the introductory commentary.
However, the team agreed to put a consistent preamble across all the standards. I do not want to change mine to be inconsistent, unless we change all
simulataneously. Accordingly, I have not applied any changes to that part of the document.
A2:
Looking at the engineering costs of this I'm more reluctant to make an immediate change. I'd have to change the schema information across all docs
including test documents, and it will be inconsistency across the different specs. We can do it, but it will require team-wide coordination.
An extra complexity is that GFD.58 doesnt define where other URIs should go, for example, MUWS capabilities. I have picked on http://www.gridforum.org
/cddlm/deployapi/2005/02/capabilities/portal for one of these. Similarly, Appendix B defines two
What I have done is declared in section 4.4.3.3 that all extra deployment options that begin with http://ggf.org/schemas/cddlm are reserved for the
cddlm wg.
A3. Declared which chapters are normative vs informative.
A5:. removed "Compliant" near OGSA.
A6: marked the XSD as copyright 2004-2006. It didnt exist until 2004.
Again, these are all minor changes. They make no changes to the semantics of any part of the specification.
-steve
|
|
Action: |
Update
|
|
|
John Tollefsrud: 03/28/2006 12:00 PM EST
|
|
Comment: |
There was an agenda item on the GFSG call of 3/28 for this doc to go into 15 day GFSG review. It was noted this doc was still out for edit and no
action was taken in the GFSG call.
During the discussion we discussed this document as being re-submitted following incorporation of changes from a previous public comment period. Hiro
feels the changes are small and a re-review is unnecessary. I feel the change is small but suffiently signifigant that there is a reasonable question
whether "before" and "after" independent implementations would interoperate. This criteria has been used before by the GFSG to make a call (this from
the time when there was no GFSG dedicated editor). It was mentioned that presently the editor decides, but that this is probably a matter of
practice and not policy. As it relates to this document undergoing another public review, I'm satisfied that the editor decide if this is the current
practice.
Thanks, jt
|
|
Action: |
Update
|
|
Greg Newby: 03/27/2006 12:02 AM EST
|
|
Comment: |
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.
|
|
Action: |
Update
|
|
Greg Newby: 03/27/2006 12:02 AM EST
|
|
Action: |
Update
artifact_status changed from Final 15day GFSG Review to Pending Info from Authors
|
|
Greg Newby: 03/26/2006 8:03 PM EST
|
|
Comment: |
Thanks for this revised document.
It is now in 15-day final GFSG review prior to publication.
|
|
Action: |
Update
|
|
Greg Newby: 03/26/2006 8:03 PM EST
|
|
Action: |
Update
artifact_status changed from Returned to Author(s) to Final 15day GFSG Review
|
|
dejan@hpl.hp.com: 03/20/2006 12:30 PM EST
|
|
Comment: |
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]
|
|
Action: |
Update
|
|
|
Greg Newby: 02/28/2006 4:16 PM EST
|
|
Comment: |
Authors, please review John T's comments, which
I as Editor support. We will await your response.
|
|
Action: |
Update
|
|
Greg Newby: 02/28/2006 4:16 PM EST
|
|
Action: |
Update
artifact_status changed from Final 15day GFSG Review to Returned to Author(s)
|
|
John Tollefsrud: 02/27/2006 11:08 PM EST
|
|
Comment: |
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
|
|
Action: |
Update
|
|
Greg Newby: 02/12/2006 3:29 AM EST
|
|
Comment: |
Moved to final GFSG review. We'll schedule
this for February 28 or ASAP afterwards.
|
|
Action: |
Update
|
|
Greg Newby: 02/12/2006 3:29 AM EST
|
|
Action: |
Update
artifact_status changed from Returned to Author(s) to Final 15day GFSG Review
|
|
dejan@hpl.hp.com: 02/12/2006 3:06 AM EST
|
|
Comment: |
From the perspective of the CDDLM group, this document is also ready for the final review by GFSG.
|
|
Action: |
Update
|
|
Greg Newby: 02/12/2006 2:48 AM EST
|
|
Action: |
Update
summary changed from CDDLM to CDDLM Deployment API
|
|
Takashi Kojo: 02/10/2006 11:26 PM EST
|
|
Action: |
Update
summary changed from CDDLM Deployment APIs to CDDLM
|
|
Greg Newby: 01/09/2006 5:32 PM EST
|
|
Comment: |
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.
|
|
Action: |
Update
|
|
Greg Newby: 01/09/2006 5:32 PM EST
|
|
Action: |
Update
artifact_status changed from Public Comment Period to Returned to Author(s)
assigned_to changed from 9357 to 628
Priority changed from 3 to 2
|
|
Greg Newby: 10/18/2005 10:01 AM EST
|
|
Comment: |
(It will be due 60 days after it is publicly announced)
|
|
Action: |
Update
|
|
Greg Newby: 10/18/2005 10:01 AM EST
|
|
Action: |
Update
assigned_to changed from 628 to 9357
|
|
Greg Newby: 10/18/2005 10:01 AM EST
|
|
Comment: |
(It will be due 60 days after it is publicly announced)
|
|
Action: |
Update
|
|
Greg Newby: 10/18/2005 9:58 AM EST
|
|
Comment: |
This is now ready for 60-day public comment.
|
|
Action: |
Update
|
|
Greg Newby: 10/18/2005 9:58 AM EST
|
|
Action: |
Update
artifact_status changed from GFSG Review to Public Comment Period
Priority changed from 4 to 3
|
|
John Tollefsrud: 10/18/2005 12:17 AM EST
|
|
Comment: |
I've read the document and recommend that it proceed to public comment.
Note, there is a cut/paste repeat of several lines of text at the bottom of p.2.
John
|
|
Action: |
Update
|
|
Greg Newby: 09/25/2005 5:24 PM EST
|
|
Comment: |
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.
|
|
Action: |
Update
|
|
Greg Newby: 09/25/2005 5:24 PM EST
|
|
Action: |
Update
artifact_status changed from Final Editor Review to GFSG Review
resolution changed from Remind to <None>
|
|
dejan@hpl.hp.com: 09/16/2005 7:02 PM EST
|
|
Comment: |
We have adderssed all issues raised by the GGF editor.
|
|
Action: |
Update
|
|
dejan@hpl.hp.com: 09/16/2005 7:02 PM EST
|
|
Attachment: |
draft-ggf-cddlm-deploy-api2.doc
(892.5 KB)
|
|
Action: |
Update
File added set to 680: draft-ggf-cddlm-deploy-api2.doc
artifact_status changed from Returned to Author(s) to Final Editor Review
|
|
Greg Newby: 08/30/2005 12:02 PM EST
|
|
Comment: |
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.
|
|
Action: |
Update
|
|
Greg Newby: 08/30/2005 12:02 PM EST
|
|
Action: |
Update
artifact_group changed from old-SRM to Management
artifact_status changed from Initial Editor Review to Returned to Author(s)
assigned_to changed from 302 to 628
Priority changed from 5 to 4
resolution changed from <None> to Remind
|
|
Greg Newby: 07/12/2005 9:39 AM EST
|
|
Action: |
Update
artifact_status changed from Open to Initial Editor Review
Priority changed from - to 5
|
|
|
|