[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ggf-ogsa-sec-wg] A Question on Procedure [Was: Re: Virtualized channels as abstractions for the Ws-xxx specifications and beyond]
Raj,
> Comments/suggestions are most welcome and appreciated.
I don't mean to sound pessimistic or cheeky: I just want to know how
you/anyone else envision that we proceed. It's still not clear in my mind.
We now have a strange situation in which people can either contribute
top-down, by adding details and specifics to the roadmap, or bottom-up, by
writing service specifications that solves some of the already identified
needs.
IMHO, the difference between the two approaches in getting some actual
specs out is years vs. weeks. I think we would all prefer the latter
latency...
I do understand that the OGSA roadmap has many important
services/features, and that we should prioritize what to put our energies
into. Also, it's hard to settle on the small when the big picture is not
yet laid out completely. On the other hand, there will always be some
Sourceforge-type project working on some low-hanging fruit that is of
interest to them, be it prioritized or not. My concern is how we
tackle/encourage/coordinate/control such efforts.
Questions:
Do we want GGF to be part of any of the bottom-up activities at this early
stage, or do we simply ignore specifics for now?
If we wait, at what point in time would bottom-up activities be something
for GGF to consider? (Now, a year from now, when the roadmap is considered
mature enough, when we have got our priorities straight, ...)
Good night (2am),
/Olle
PS. For the sake of clarity, a concrete example: Had I put my mind to it,
I could have written a specification for a grid service that do credential
translations (X.509 to Kerberos and vice versa) already today. If I based
it on WS-Trust, the whole exercise might have taken me only a day or two;
It wouldn't really matter that the underlying GSS and WS-Trust documents
are still both in flux, as the spec would be on top of these documents,
void of any specific details (apart from any ServiceData definitions, and
the semantics and behavior of the service itself).