This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3410?nav=1&selectedTab=comments at Sun, 06 Nov 2022 08:41:19 GMT SourceForge : artf3410: (1558) CDDLM Deployment API

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: Editor     Trackers > Published > View Artifact
Artifact artf3410 : (1558) CDDLM Deployment API
Tracker: Published
Title: (1558) CDDLM Deployment API
Description:
This document describes CDDLM Deployment APIs. The CDDLM framework needs a deployment API for callers to deploy services
 described in the component model languages. This API must support remote access for deployment, terminating existing 
deployed systems, and for probing their state. This document defines the WS-Resource Framework-based deployment API for 
performing such tasks. It is targeted at those who implement either end of the API.
.
Submitted By: dejan@hpl.hp.com
Submitted On: 07/07/2005 8:56 AM EST
Last Modified: 05/06/2007 4:46 AM EDT
Closed: 06/25/2006 9:03 PM EDT

Status / Comments Change Log Associations Attachments (4)  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 0
Assigned To: * None
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
resolution: *
Comments
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
dejan@hpl.hp.com: 03/28/2006 2:53 PM EST
  Attachment: draft-ggf-cddlm-deploy-api.doc (910 KB)
  Action: Update
File added set to 822: draft-ggf-cddlm-deploy-api.doc
artifact_status changed from Pending Info from Authors to Submitted
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
dejan@hpl.hp.com: 03/20/2006 12:30 PM EST
  Attachment: draft-ggf-cddlm-deploy-api.doc (910 KB)
  Action: Update
File added set to 809: draft-ggf-cddlm-deploy-api.doc
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
dejan@hpl.hp.com: 07/07/2005 8:56 AM EST
  Action: Create

dejan@hpl.hp.com: 07/07/2005 8:56 AM EST
  Attachment: ggf-cddlm-deploy-api.doc (929 KB)
  Action: Update
File added set to 644: ggf-cddlm-deploy-api.doc

 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3410?nav=1&selectedTab=comments at Sun, 06 Nov 2022 08:41:19 GMT