[dmis-bof] Comments on the charter?

[Peter Kunszt]

hi bill

here it comes  - my dreaded comments ;-) 

>  - I changed the name to OGSA-DMI

i don't like that. having my EGEE hat on, please consider that we cannot
adapt and use OGSA in any of the near future (next year) as everything
is set up for production pretty much now. there is no time for us to migrate
to OGSA quickly and to deploy and use it. there are lots of question marks
concerning especially the security infrastructure and how that will interoperate
with classical transport-level security.

so to recap: we would very much appreciate a pure WS-I interface standardization
first, where we can talk cleanly about interfaces and semantics and we would not
clog our discussions about which semantics of WSRF should be applied to what. we
could focus on the transfer specs. then someone can take the spec and 'ogsafy' it.
so please consider to keep this just as DMIS-WG. (sorry hiro - i have to be pragmatic here)

>  - we need to address naming.  What will we accept as source 
> and destination names? URLs? URIs? any string? EPRs?

URL seems like a good choice, this would probably suit all use cases.
this is what we use in the GSM-WG. we have storage URLs.
an EPR is nothing more than a decorated URL so a simple URL would
suit that too.

>  - There is a general issue which will affect a lot of this 
> and that is just extensible WSDL.  How do we allow parameters 
> to change when options in the WSDL change.

the pragmatic approach is to increase the minor version number
for compatible changes and the major one for incompatible changes.
however, there are alternatives that we have investigated also in
the GSM-WG: it is possible to leave an extensibility hook in the WSDL,
so that new functionality can be tried on existing services, before
it is migrated into the mainstream WSDL. this is a good idea also
for interoperating between versions.

>  - I think we all agree that this needs to be transport 
> agnostic, but we need to figure out how best to implement 
> that (related to the WSDL question)

unless i'm mistaken, doc/literal should just do the trick..?

>  - what statement do we want to make (and does the OGSA data 
> architecture
> need) about delivery semantics

i think we need to make as detailed statements as possible/reasonable!
we need to define what states the transfer service exposes to the client
and what failure modes the client has to expect.

>  - what about scheduling / planning aspects?  Do we want to 
> include elements in this WSDL that specify rate (bandwidth), 
> quantity (file size), and timing (START BY, FINISH BY, etc)

our experience: individually for each transfer job: no. that is very complicated and of questionable use.
on the scale of the service itself as a service parameter/configuration: yes.

>  - everybody's favorite: security.  I hope we can basically 
> punt on this and say we will do whatever OGSA does

well.. please see 
http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf

and the discussion here on transport and message-level security.
GT4 currently supports both in parallel.

together with my comment on top, i think for this essential service
we need to at least task the OGSA security group to give us a clear
path of how both can interoperate and what are the migration paths.
this is highly nontrivial and until it is not given, it will not be
practical for us to talk about message-level security at all. we don't
have the effort available to do what GT4 did and to run both everywhere.

>  - A sort of pet project of mine is monitoring / 
> troubleshooting.  I would like to potentially include 
> elements in the WSDL or state that is exposed that would 
> enable better/easier monitoring and troubleshooting.  For 
> instance, some sort of unique job identifier that can be 
> passed down to children, so that you can trace the chain back 
> when you have a failure.

yes, statistics gathering is another one. very important to have -
i already sent the wsdl's we have today to this list..

>  - groups that we need to be aware of to one extent or 
> another include OGSA, OGSA-D, info-d, gsm, byte-io, naming, 
> grid file systems, authz (other security groups), 
> ws-agreement (GRAAP?).  are there others? how should we 
> liaise with those groups?  some will require more work than others.

:-) the best thing to have is if there are individuals participating
in both who can act as liaisons. i am happy to take gsm and parts of
ogsa-d, together with you of course.

> 
> Let me know what you think.

keep'em coming ;-)

cheers
peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2779 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dmis-bof/attachments/20051214/50e370a4/attachment.bin