Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050425/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 25 April 2005 =================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Dave Berry (NeSC) [first 15 minutes] Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * April 20 minutes approved with no changes * May F2F update - Choosing the same hotel is a good idea to make it more convenient to meet off-hours. Internet connectiviy may not be an issue since it should be ok during the day at IC. - The Rydges hotel on Gloucester Rd was one choice. Andrew will follow up. Action: Andrew to mail out the hotel recommendation * EMS related work - How to follow up with the people (Germany, Naregi, etc) who volunteered to do RSS (CSG) work. It is not clear if anyone from the OGSA-WG has the time to commit to follow up on this effort at the moment. Some of them are coming to the May F2F but it may be a good idea to talk to them in advance. Action: Hiro and Andrew to coordinate and arrange a call with the people who volunteered to start up the RSS group. Preferably arrange it this week and in any case before the F2F. * Profile definition document review (v1.5) - Tracker exists but no issues registered yet. Action: Tom to check and upload any unresolved issues. - No comments on the "Status" or "Abstract" sections ** Section 1 (On a side-note it was mentioned that the DMTF has decided to use ISO terminology rather than RFC 2119. The downside is that there is more variation in the use of words. For example, many different flavors of MUST.) ** Section 2 - [2.1] - Delete 'similar to' as it does not add anything. - 'claim attachment mechanism' : Does WS-I have 'many' such mechanisms and if so which is being referred to here? - Tom confirmed that there is only 1 such document (WSDL 1.1 claims, UDDI claims, ...). Action: Tom to provide a proper reference to the WS-I claims document. ** Section 3.2 *** Status - 'consortium of one or more': Does 'one' make sense in this context? The idea is not to preclude specs coming from one company. This statement does need to be revised for clarity, however. - Is 'consortium' the right word here? And should a consortium category be listed or not? Examples of consortia: DAT collaborative, EGA, etc. Consensus that it is worth leaving in 'consortium' and making the distinction that a specification from one company would mean a 'draft' categorization. Proposal that to make things clearer examples should be added for each category defined. In the order given in the document the following examples were mentioned for each category: - WS-Security - WSDL 1.1 - WSRF, WSN - EGA or perhaps SNIA specs: SMIS, EGA reference models etc - Evolving standard comment in document: Agree with it; Delete. *** Adoption levels - Need to point out that 'Adoption' levels are 'additive': the next level builds on top of the lower level definition; no exceptions. - Consensus that definitions are to some extent subjective (e.g., what defines a community?) and that there is no way to get over this subjectivity completely. The classification is intended as a guideline and the actual decision will be done by a group of people (so judgement calls and consensus will be needed). Agreed to leave definition as is. - 'Ubiquitous' statement: - 'but' is really an 'and'. - Reached rough consensus on what is 'ubiquitous' (e.g., html, http, tcp/ip) but not sure how to wordsmith the definition to bring out the desired meaning. Action: Tom will follow up on ubiquitous definition on the list. ** Section 3.4: Restrictions Agreed to leave intentionally vague. Tom will review text again. ** Section 4: Profile type distinction - The decision on profile document type depends on the state of the referenced specs. It is not clear whether the evaluation of the state of the referenced specs should be made strictly at submission time or whether there should be more 'freedom'; i.e., allow a profile to enter the recommendation track based on the expectation that the referenced specs will be at the right state when publication time comes. The consensus on the call was to add wording that the criteria should be satisfied at submission time. This decision was made on the assumption that the GGF process does not permit revisions of a 'proposed recommendation' document and that since a change in the referenced specs would result in such a revision the document would be invalidated anyway. The only concern here is that of extra serialization and backtracking for what may be only minor changes. - There seems to be no problem with submitting a document on one track and also (perhaps partially overlapping) re-submitting it on another. (A document could also be withdrawn from one track in this case). The motivating use case here is a profile being submitted on the information track but due to rapid changes in the states of the specification it uses becoming eligible for the recommendation track. In this case the process would start again; switching tracks without restarting the process does not look like good practice. - Agreed to drop 'evolving' from proposed recommendation - Agreed to delete existing comments on informational profiles - Tom will look at other options for putting profile documents in a 'lighter' publication track without going through the requirements of the recommendation track. (Community, experimental were mentioned.) * JSDL introduction Overview of parts of JSDL relative to draft 16. (Draft 17 is out and there is work to produce draft 18) Same presentation as that given to the DMTF Utility WG Focus is describing requirements at submission. But submission API and results of submission are out of scope. Also no elements that describe post-submission concepts, e.g., job id generated by submission system. This is done simply for scoping purposes. Spec provides a number of extensibility points and other information (e.g., job id) can be added. Normative extensions for the known gaps may be produced at a later time. [Slide 6] JSDL version 1.0 only attempts to cover a part of what is needed. More work, possibly by other groups is expected to cover this area. For example, scheduling, workflow, etc. Abstract-refined-incarnated/grounded: This model is supported but not required by JSDL. Submitter can write a document at the desired level. (EMS big-picture implies this kind of refinement too so JSDL is aligned with that approach.) Data staging is a common requirement (not 'fundamental' as the slide mentions). The copy and completion semantics are built in but it may not be necessary to copy over existing files (overwrite or not). Some more refined cases may be covered using the filesystem attribute. It was not clear how RNS work could be used here. Need more discussion offline. JSDL examples slides: - slide 11: an example of adding a job id extension element - slide 12: user section has been deleted in the latest pre-draft. - slide 13: Application and its extensibility (POSIXApplication) - Why not define as application types and draw out commonalities? - Application types were defined in an earlier draft. One problem is that there was not that much commonality between the different types: e.g., a posix application versus a WS invocation or a SQL call. Common parts seemed to be just name and version. - slide 16: Resource definition does not offer sufficient abstraction. (Also the order that is used to present the elements in the slide is problematical.) - The starting point (and main use cases) is existing DRMs. More generalization may be needed but it is also necessary to make sure the existing systems and use cases are covered. - It is possible to completely ignore the jsdl sub-resource elements (all are optional) and use a different resource description if that is more appropriate and if another standard comes along. - <exact> and <lowerboundedrange> are part of a rangevalue definition. - slide 17: In certain cases, values are also defined in addition to elements: Processor architectures and OS types are such examples. The values are based on CIM defined ones. - slide 18: the source or target urls also define the protocol that should be used for the transfer, e.g., http, rsync, and so on. How far along is the group? The goal is to submit the spec to the GGF Editor before GGF14.