Proposed agenda for Oct. 19th call
Hi all,
The following is a proposed agenda for OGSA-WG telecon on Oct. 19th
Thursday from 8:30am - 10:30am (CDT).
Dial-in numbers for Thursday:
Free: +1-888-452-0308
Intl/Toll: +1-484-644-0505
PIN: 71815
See more information:
- https://forge.gridforum.org/sf/go/wiki1477?nav=1
Screen share service will be provided.
URL: http://ogsa.glance.net
Session key: 1019
See more explanation:
https://forge.gridforum.org/sf/go/wiki1584?nav=1
1) Early discussion (20 min)
Note taker assignment
Roll call
Telecon minutes approval (Oct. 16)
- https://forge.gridforum.org/sf/go/doc13952
Action Items status review (see the bottom of this email)
Agenda bashing
2) Nov. F2F update (Hiro Kishimoto, 10 min)
3) OGSA AuthN WG BoF draft (Alan Sill, 30 min)
> - Alan Sill willing to take responsibility for pushing the process
> for getting a charter ready
> - AI-1005a: Alan Sill to have draft Charter ready before next
> security telecon (Dave to help and only as stand in for new area
> director).
> - Do we need more covereage if we have an active authorization and
> authentication working groups
> -- No, we need more covereage
> -- AI-1005b: People to send Dave Snelling more information, ideas for
> more security calls to complete coverage
4) Security Profile Update (Takuya Mori, 30 min)
> AI-0928a: Takuya will issue a final call on BSP-Core on the list.
> - Need to check status of WS-I documents
> - Secure Channel Profile on next telecon
5) Information/data modeling (Ellen Stokes, 30 min)
> - Discussion on if a requirements XML document could be constructed
> with powerful comparative expressions and at same time avoids the
> XPath expressions/joins on collecting input documents? Perhaps just
> the relevant subset of a query in job. - Agreed to discuss more in
> second hour on Next Call - Oct 19th
6) Wrap up
AOB
<*NEXT CALL*>
https://forge.gridforum.org/sf/go/wiki1477?nav=1
Oct. 23 (Mon): EGA reference model, OGSA roadmap
Oct. 26 (Thu): Information/data modeling, EMS scenarios
Oct. 30 (Mon): DMTF work register
Nov. 2 (Thu): Security
Nov. 6 (Mon): EGA reference model, OGSA roadmap
Nov. 9 (Thu): F2F prep
<*ACTION ITEMS*>
https://forge.gridforum.org/sf/go/wiki1569
> From Oct. 16 call.
AI-1009d: Jem Will post tomorrow, comments received and will put
into tracker.
AI-1005a: Charter form created, ready for review. Hiro will send
links to charters.
Paper work for new working group needed - can use security
design team folder in OGSA temporarily.
Feedback: Use next OGF to start WG rather than form a BOF.
Hiro will bring proposal to GFSG, since needs
security Area Director approval & GFSG.
> From Oct. 8 call.
AI-1009a: Review slide 6 again and clarify what the problem is
(Reference Model Design Team)
AI-1009b: Review the Reference Model 'Manage Job' in more
detail. Specifically look at it from the perspective of
an enterprise application (e.g., a 3-tier app) (Reference
Model Design Team)
AI-1009c: Hiro to ask Jay to provide his comments for Slide 6
- Perspective of submitter vs platform provider and the
hierarchical model connection
AI-1009d: Jem will produce a topic discussion list for the
converged glossary
> From Oct. 5 call.
AI-1005a: Alan Sill willing to take responsibility for pushing
the process for getting a charter ready (by Oct. 19)
AI-1005b: People to send Dave Snelling more information, ideas
for more security calls to complete coverage
(Since this does not have any specific owners, it will
be closed Oct. 19)
> From Sept. 28 call.
AI-0928a: Takuya will issue a final call on BSP-Core on the list.
> From Sept. 25 call.
AI-0925c: Hiro to ask Alan Clark to ask EGA TC member who want to
contribute to join the OGSA list and this convergence work. -
Members may have changed but organizations have not
AI-0925g: Tom will send a note to the list (to: Ellen S and Fred M)
on why the current separation of service/info model may
not be quite right.
> From Sept. 15 OGSA F2F
AI-0915a: (A Savva, S McGough): Set up a telephone conference to
collect workflow (BPEL) experience
AI-0915d: Tom will post BP base faults issue to tracker
AI-0915e: Hiro to talk with OGF Editor to start an errata process
> From Aug. 17 call
AI-0817a: Dave Berry and Jay Unger will approach groups (GIN,
Globus, etc) that have implemented practical grids and
start a discussion on how they handle data:
- how data is treated as a resource that can be scheduled
- how transfers are modeled
- how files are advertised
- how applications find files (query, by knowledge,?)
(Due Oct. 9)
> From Aug. 3 call
AI-0803e: Jun will provide an example of the CDL mechanism and why
using ID/IDREF is not a good idea.
AI-0803f: Jun will update the CDL document to remove the Environment
variables
> From July 20 F2F
- EGR-WG (Ravi) will contact Geoffrey Fox and invites him to
contribute use cases.
- Andreas to go through the minutes and formulate a reply mail to
Geoffrey on each artifact covered in these minutes.
Postponed:
Until next EMS call (Oct. 26):
AI-0914a (Andreas Savva): Integrate the simple Data scenario just
presented into the scenarios document
AI-0913a: Andreas to update function names of BES.
AI-0913b: Andrew to write-up a couple of such JM functionalities
(short paragraph for each, e.g. time constraint as JSDL
extension.)
AI-0913c: Andreas to add another scenario to use this “terminate”
method of activity interface.
AI-0913e: Andreas to separate un-deployment as a separate scenario.
AI-0913f: Andreas to describe relation between ACS and CDDLM.
AI-0913g: Donal to provide his proposal on
"ActivityExecutionCandidate."
AI-0831e: (A Savva) Talk to ACS working group for refining this
scenario.
AI-0831f: (A Savvva) Research RNS and probably update the EMS Arch
Scenarios document
AI-0921c: Dave S (as Standards VP) to talk to the next
Security AD (when one is selected) about the Security Area
task list.
----
Hiro Kishimoto
Here's the basis for info/data item on Oct 19 agenda. Jay and Ellen ------------------------------------------------------------------------------------- Original XQuery Usage Proposal We proposed XQuery as a means of expressing job requirements and matching those requirements against resource capabilities. It was expected that job submission would actually contain XQuery logic/language as the means of expressing those job requirements. This was proposed because such a comprehensive, robust, and expressive language would permit very detailed and powerful matching to take place. Also, this was consistent with projection of the Condor Class-Ad concept and approach into the more modern and open XML space. Class-Ads also has a very programming language-like syntax for writing job requirements specifications. Oct. 2 OGSA call Michel showed a particular pattern of usage of XQuery that we believe is very limiting. Additionally, Michel stated that while he agreed that XQuery was very powerful, it was also potentially very open ended and therefore might be dangerous to the integrity of a system. Response Michel suggests a model in which XQuery logic/functions would be used as an intermediate mechanism for comparing a more value-static XML job requirements document to collections of similar value-static resource capabilities documents. Michel?s model would create several problems that would lead to a much more fragile and brittle system. Any extension of the requirements or capabilities elements in documents would require that not only schema (XSD) be written, but that comparator XQuery functions would have to be supplied. Further, no matter how well such comparator functions might be crafted, there would always be combinations of comparisons, ranges, and boundary conditions that they couldn't express without further extension. This means that even moderately complex job requirements documents might require extensions to the comparator functions in order to be accommodated. As a powerful query language, XQuery does provide opportunities for abuse either accidental or intentional. It is possible to create queries that would either consume a great deal of resource (compute power or I/O bandwidth) or exhibit malicious behavior and damage the environment that query was run in. As always with any interface these are situations that need to be protected against both in design and in implementation. One primary mechanism that could cause XQuery programs to run unchecked is the ability to reference external sources: additional XQuery syntax (Imbeds, prologs etc.), documents to operate on (accessor functions), or schemas. While the mechanisms specified in the XQuery standard do not limit the scope of such accesses, implementations are free to (and expected to) protect their environment. Similarly, our use of XQuery in job submission and resource matching should not explicitly place limits on the scope of either documents or schemas referenced or define specifically whether the resource capabilities documents are collected by some "repository" or whether queries are distributed, executed by distributed engines and returned to a scheduler. We should, however, recommend that implementations of collections of schedulers do need to limit the scope of such references. Like most programming environments, XQuery does provide a means to "write" external functions that operate outside the XQuery specification but that can be invoked by any XQuery. We should not explicitly disallow the use of such external functions since they might prove useful, for example, in probing dynamic information like the present utilization of an endpoint, but we should alert implementers of schedulers that some limitations on external function definition are warranted to protect the system. XQuery also permits functions to be defined in XQuery syntax for reuse, convenience, and expression brevity/clarity. While this type of function is less troublesome than external function not written in XQuery syntax, it is still possible to define looping, long running, or non-terminating recursive functions that could consume excess resources. The traditional means of protecting against this kind of pathological behavior (whether it is introduced by accident (bugs) or malice) is to provide timeouts that terminate long running queries, especially those that don't appear to be generating any usable output. Our specifications should not dictate what the limits on query execution should be, but rather recommend that implementations will need such limits to protect system resources. OGSA use of XQuery as the basis of our scheduler job requirements and resource capabilities matching should permit most of the expressivity and power of the language to be exploited. We can explicitly profile such features as externally defined functions to implementation controlled prologs (or built in definitions) and thereby control their impact. If profiling out some language features would not be wise since it would limit flexibility, we can point out in implementation notes what restrictions should be applied to protect system. Lastly, there are already some features in XQuery that are implementation dependent and create the possibility of users creating non-portable query expressions which would not work in some implementations. We should identify and profile any such particular feature that we think needs to be supported in a particular interoperable fashion for our usage or simply profile it out to avoid problems. ------------------------------------------------------------------------------------- 5) Information/data modeling (Ellen Stokes, 30 min)
- Discussion on if a requirements XML document could be constructed with powerful comparative expressions and at same time avoids the XPath expressions/joins on collecting input documents? Perhaps just the relevant subset of a query in job. - Agreed to discuss more in second hour on Next Call - Oct 19th
participants (2)
-
Ellen Stokes -
Hiro Kishimoto