perfsonar development work

[Andreas Hanemann <>]

Cándido Rodríguez Montes schrieb:
> Hi Andreas,
>
> El 11/03/2008, a las 14:54, Andreas Hanemann escribió:
>
> > Hi Roman,
> >
> > Thanks for your input. I have now added an additional interaction 
> > diagram to the document that depicts the interactions. It seems to me 
> > that your proposal is more flexible in the way how MAs can be 
> > combined with transformation services and it also helps to keep the 
> > complexity away from the client (which does not become aware that 
> > there is a transformation service involved). For DFN I did not want 
> > to make the MA address known to the outside world for security 
> > reasons, but I think that the access can be prevented by other 
> > mecanisms, too.
>
> I have a question. At the moment the authorization will be available 
> would you still need to hide the MA address?
No, if there is an AA mechanism in place, then we do not have to hide 
the address anymore.
> > In summary, I would propose that your proposal is the way to go and I 
> > would then change the document accordingly. Are there further opinions?
>
> Yes. In the JRA1 meeting in Seville, Jeff and me were talking about 
> the actual specification of authentication and authorization doesn't 
> include the case of perfSONAR services sending messages between them. 
> In case that the TrS will be available for all services (like the 
> interactions between all services and the LS), it doesn't affect to 
> the AS, but, if you want to use the authentication or the 
> authorization process in it, we will have to specify a new profile for 
> this case (more AA work :-) ).
I think a good way to discuss this further is that I include the AS into 
the interaction diagram of the document. Then we can discuss the changes 
that are necessary .
> Regards
>
> > Best regards
> > Andreas
> >
> >
> > Roman Lapacz schrieb:
> > > Andreas Hanemann wrote:
> > > > Hi all,
> > >
> > > HI
> > >
> > > > In attachment I am providing a document about the Transformation 
> > > > Service. It contains a discussion about the scope of the service 
> > > > and also a description how the protocol for the service may look 
> > > > like. Some comments are left in the document which result from 
> > > > discussions involving few JRA1 people (Nina, Szymon and Nicolas).
> > > >
> > > > Comments especially for the scope and the protocol would be desired.
> > >
> > >
> > >
> > > If I remember correctly the idea of TrS was little bit different. 
> > > Example scenario:
> > >
> > > 1. The client requests MA for data in specific format X
> > > 2. MA contains data in format Y so finds (in LS) TrS which can 
> > > transform from format Y into X (TrS can be also specified in the 
> > > request from the client so in this case there is no need to use LS)
> > > 3. MA sends the request and data to TrS
> > > 4. TrS transforms data into format X
> > > 5. TrS sends data back to MA (MA sends them to the client) or 
> > > directly to the client
> > >
> > > Roman
> > >
> > >
> > > > Best regards
> > > > Andreas
> >
> >
> > --
> > Dr. Andreas Hanemann      DFN-Verein
> > Stresemannstr. 78
> > 10963 Berlin, Germany
> > Tel.:   ++49 30 884299 64
> > Fax:    ++49 30 884299 70
> > E-Mail:  <mailto:> (Please do not use 
> >  <mailto:> anymore)
> >
> > <Transformation-Service_v5.doc>
>
>
>
> --
> Cándido Rodríguez Montes E-mail:  
> <mailto:>
> Middleware warrior Tel:+34 955 05 66 13
> Red.ES/RedIRIS
> Edificio CICA
> Avenida Reina Mercedes, s/n
> 41012 Sevilla
> SPAIN


--
Dr. Andreas Hanemann      
DFN-Verein
Stresemannstr. 78
10963 Berlin, Germany
Tel.:   ++49 30 884299 64
Fax:    ++49 30 884299 70
E-Mail:  (Please do 
not use  anymore)