February 2006 - saga-rg - lists.ogf.org

Re: SAGA and Security
by Andre Merzky 13 Feb '06

13 Feb '06

Hi Dane, thanks for the remarks and corrections - I should have known that its not _that_ easy as I thought ;-) It would be perfect to have you at the Wednesday session! Quoting [Dane Skow] (Feb 13 2006): > > Hi Andre, > > I have some reservations with this summary of our discussion but as I > indicated, I think I don't understand the scope/abstraction levels > you are after. We seem to be mixing several things here in this > discussion. I believe you've been talking primarily with Olle so > perhaps it's my confusion. I will try to attend your session at 10:30 > on Wednesday, though it conflicts with the CAOPs session we'll also > need to cover. > > Within the OGSA architecture in GGF we can make some simplifying > statements about a common paradigm. However, if the goal is to > provide an API generic across ANY Grid infrastructure, the task is > more difficult. The reason for that is that we need the SAGA API now, and running on current Grid middleware. If in the (far or not so far) future there is only OGSA, and its widely deployed and adopted, we obviously should step back and check what tighter relationshio we should have to OGSA. > We can also make simplifications if one assumes the API is for > accessing Grid services and does not expect to efficiently adapt to > local communications between individual users. I am not sure if I understand that part. Are you targeting at solutions which introduce latencies which do not matter if compared to (slow) remote ops, but are significant if compared to (fast) local ops? What would those look like? > I'm having a hard time understanding whether the desire is to > understand "the" common grid security model (there are some things we > can say pretty broadly now for the common ones in GGF: x509 > credentials are the common denominator for grid identification/ > authentication, etc), yes. > to find/build a common library set for building > tools to implement common security goals in applications (eg. set/ > read an ACL for accessing a file/service, etc), no (although that would be useful for our implementation) > or to identify what the elemental security actions are > for a broad set of grid services. yes. Let me give some examples, in the form of use cases. - Ann creates a stream server. A client Bob connects, Ann wants to authenticate and authorize that client. Should she - check for bobs distinguished name - ask a remote service for AA of Bob - ask for a shared secret - rely on out-of-band security (fine grained firewall or so) - Ann creates a file. She wants Bob to read it, but not Charlie. - should she set ACLs on the file? - chould she call chmod/chgroup on the file? - What is the user/group name of bob/charlie? - should she add bob Subject ID to a allow list, and charlies to a deny list? What are the defaults? - Ann runs a remote job, and want to allow bob to kill it, and charlie to suspend/resume it. - should she maintain allow/deny lists per operation? - should she include callacks (i.e. callouts) in the applicsation whcih ask for permissions for a distinguished name - should she change ownership of the job to bob or charlie or both? You see, we touch security in various places, and various paradigms. For each of them we would need to understand what security actually _means_. Does GGF have a notion of a user? Of a access/deny list? ACLs? ... ... ... > As I mentioned in our talk, I believe we have lessons to > learn here from how IETF has handled the job of > integrating security into application/protocol design. > The answer is clearly NOT to have external experts come > in a "sprinkle security pixie dust" (not what I > understand you to be asking for by the way) Well, its not that far off... ;-) > but rather to > consolidate on a common toolkit of security tools/protocols that are > well understood/reviewed and have developers consider possible abuses > of their protocols/services/software. Somehow we need to figure out > how to make this work in GGF. We considered tat: use callouts for streams, ACL for services, and ACLs for jobs. Would that be implementable though? No idea... > I (and I'll be Olle) will be happy to work with you on > how to make this happen. Many thanks! So, lets continue per mail or on Wednesday. We certainly are happy that we got your interest :-) Cheers, Andre. PS.: Disclaimer: the statements above are my personal opinion. I think we have widely varying ideas about security in our group, but we are not qulified enough to make good decisions - and I am the least qualified one I guess... :-P > Cheers, > Dane > > On Feb 13, 2006, at 10:58 AM, Andre Merzky wrote: > > >Hi group, > > > >we managed to corner the Security Area ADs at GGF in Athens, > >and to get some statements from them in respect to: > > > > "What security paradigms are generically available in > > Grids, and what should be exposed to the end user?" > > > >Well, their answer was basically, that there is no agreed > >upon approach in the scope of GGF, so, the best we can do is > >to look at Grid implementations, and abstract/generalize > >their security paradigms. > > > >A viable approach in their opinion would be to base security > >settings on strings, and allow the implementation to interpret > >them accordingly. That approach is very close to what we > >have right now for sessions, and what we want to have for > >streams. > > > >Shantenu and I discussed that shortly, and would like to > >propose as follows: > > > > - for the time being, keep security out of the API where > > not absolutely necessary > > - where absolutely necessary (case by case), keep exposure > > of security paradigms simple and generic > > > >I think the notion of context that we have in the SAGA API fits > >that approach well: by default they are invisible. > > > >We would be happy to get comments, also from the Cc'ed > >Security ADs (hope we interpreted your answer correctly). > > > >Cheers, Andre & Shantenu. > > > > > >-- > >"So much time, so little to do..." -- Garfield > > -- "So much time, so little to do..." -- Garfield

1 0

Subject: BOUNCE saga-rg@ggf.org: Non-member submission from [Dane Skow
by Shantenu Jha 13 Feb '06

13 Feb '06

From: Dane Skow <skow(a)mcs.anl.gov> Subject: Re: SAGA and Security Date: Mon, 13 Feb 2006 11:54:43 +0200 Hi Andre, I have some reservations with this summary of our discussion but as I indicated, I think I don't understand the scope/abstraction levels you are after. We seem to be mixing several things here in this discussion. I believe you've been talking primarily with Olle so perhaps it's my confusion. I will try to attend your session at 10:30 on Wednesday, though it conflicts with the CAOPs session we'll also need to cover. Within the OGSA architecture in GGF we can make some simplifying statements about a common paradigm. However, if the goal is to provide an API generic across ANY Grid infrastructure, the task is more difficult. We can also make simplifications if one assumes the API is for accessing Grid services and does not expect to efficiently adapt to local communications between individual users. I'm having a hard time understanding whether the desire is to understand "the" common grid security model (there are some things we can say pretty broadly now for the common ones in GGF: x509 credentials are the common denominator for grid identification/ authentication, etc), to find/build a common library set for building tools to implement common security goals in applications (eg. set/ read an ACL for accessing a file/service, etc), or to identify what the elemental security actions are for a broad set of grid services. As I mentioned in our talk, I believe we have lessons to learn here from how IETF has handled the job of integrating security into application/protocol design. The answer is clearly NOT to have external experts come in a "sprinkle security pixie dust" (not what I understand you to be asking for by the way), but rather to consolidate on a common toolkit of security tools/protocols that are well understood/reviewed and have developers consider possible abuses of their protocols/services/software. Somehow we need to figure out how to make this work in GGF. I (and I'll be Olle) will be happy to work with you on how to make this happen. Cheers, Dane On Feb 13, 2006, at 10:58 AM, Andre Merzky wrote: > Hi group, > > we managed to corner the Security Area ADs at GGF in Athens, > and to get some statements from them in respect to: > > "What security paradigms are generically available in > Grids, and what should be exposed to the end user?" > > Well, their answer was basically, that there is no agreed > upon approach in the scope of GGF, so, the best we can do is > to look at Grid implementations, and abstract/generalize > their security paradigms. > > A viable approach in their opinion would be to base security > settings on strings, and allow the implementation to interpret > them accordingly. That approach is very close to what we > have right now for sessions, and what we want to have for > streams. > > Shantenu and I discussed that shortly, and would like to > propose as follows: > > - for the time being, keep security out of the API where > not absolutely necessary > - where absolutely necessary (case by case), keep exposure > of security paradigms simple and generic > > I think the notion of context that we have in the SAGA API fits > that approach well: by default they are invisible. > > We would be happy to get comments, also from the Cc'ed > Security ADs (hope we interpreted your answer correctly). > > Cheers, Andre & Shantenu. > > > -- > "So much time, so little to do..." -- Garfield >

1 0

SAGA Implementations
by Steven Newhouse 12 Feb '06

12 Feb '06

The Steering Group is collecting a list of which GGF specifications have been implemented. Although you are still iterating on your API document we'd be interested in knowing if you are doing an implementation, or know of one. We are aware of the following: Andre Merzky (University of Amsterdam & Louisiana State University)- C++ (& therefore Python & others) Graeme Pound (University of Southampton) Full Java implementation Terry Sloan (EPCC) Partial Java implementation Could you please drop a short note to the list if you are, or have corrections to the above? Thanks, Steven & Dieter Applications Area Directors

2 1

test - please ignore
by Andre Merzky 12 Feb '06

12 Feb '06

no text. -- "So much time, so little to do..." -- Garfield

1 0

job states...
by Andre Merzky 12 Feb '06

12 Feb '06

Hi group, It seems I am lacking some understanding of the SAGA job states, and would appreciate if someone with more knowledge about job management could answer some questions (Chris, are you still watching this list by any chance?) Attached to this mail is a draft of a SAGA job state diagram. For simplicity, I did not distinguish between UserHold and SystemHold, nor between UserSuspend and SystemSuspend. The arrows show possible state changes, the method names denote methods which can initiate state changes from API level. I think that diagram is wrong, isn't it? Well, here are my questions: - if we submit a job, its immediately Queued - is that right? Should it be pending before (e.g. as long as the queuing request travels the middleware layers)? - can the hold and suspend states reached only from 'Running', or from elsewhere as well? - What is the difference between 'Hold' and 'Suspend'? - Are there signals defined (apart from KILL) which shange the job state? I guess that is not as simple as saying SUSP does suspend - that state is probably defined by the scheduler, not by the OS... - What is the use case for distinguishing between UserHold and SystemHold, or between UserSuspend and SystemSuspend? I would like to understand these states, in particular in correspndence to the task states we have. Well, I put questions to that relation in another mail - to keep this mail 'short'. Thanks, Andre. -- "So much time, so little to do..." -- Garfield

6 21

SAGA-CORE-WG charter revision 2
by Tom Goodale 09 Feb '06

09 Feb '06

Latest version with Steven's comments and spell-checked. Informational Section --------------------- Area: Applications [Standards] Name of group: Simple API for Grid Applications Core Working Group Acronym: SAGA-CORE-WG Type of group: Working Group (WG) Chairs: Tom Goodale, Andre Merzky Secretaries: TBD Email list: saga-core-wg(a)ggf.org Web page: http://forge.ggf.org/projects/saga-core-wg/ Charter: ------- Focus/Purpose: ------------- The SAGA-RG coordinates the development of simple, application oriented APIs for Grid Applications. This working group is the first working group spawned by the RG, and will concentrate on producing concrete API documents for the functional areas identified by the initial SAGA-RG design team. Specifically: - Files - Logical files - Job submission and management - Streaming communication between processes along with the core API areas which are independent of specific Grid operations: - Tasks - Sessions - Security Scope: ----- The initial SAGA-RG collected a number of application use cases which are published in the GGF Document number GFD-???. The work of this group will be based on this use cases, which will define the scope and target application areas for the API. Simplicity and conciseness will be the governing design principles. The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The WG will, however, actively liaise with relevant grid-middleware groups within the GGF. The WG will continue to identify projects outside GGF with similar API-focus and goals, and will seek their input in the development of the API and its implementation. The WG will provide detailed non-normative examples and 'cook-books' showing how the specified APIs could be used. Exit Strategy: -------------- The group will finish its work after the publication of the API Specification as GGF standard recommendation, accompanied by documents for API language bindings. Goals: ------ The SAGA-CORE-WG is the first WG spawned by the SAGA-RG, which produced the informational document ("SAGA Use-Case Document, version 1"), and is producing a related requirements document. The main goal of the WG is the creation of an API specification for the functional areas defined in these documents and explored by the first SAGA-RG design team, as listed above. This API will be submitted to GGF as a standard recommendation. The WG will produce the following documents: * Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral. * Recommendation documents: Language bindings for the "Abstract SAGA-CORE-API" specification These will be for a number of languages, such as C, C++, Java and Fortran. Milestones: ----------- GGF16: - SAGA API Specification pre-v1.0 GGF17: - Submission of abstract SAGA API Specification v1.0 - Implementation details review. GGF19: - Present Draft Language Bindings (C/C++/Java/Fortran)

3 5

SAGA-RG charter revision 2
by Tom Goodale 09 Feb '06

09 Feb '06

Latest version with Steven's comments, and spell-checked this time 8-) Informational Section --------------------- Area: Applications [Standards] Name of group: Simple API for Grid Applications Research Group Acronym: SAGA-RG Type of group: Reasearch Group (RG) Chairs: Tom Goodale, Shantenu Jha, Thilo Kielmann Secretaries: TBD Email list: saga-rg(a)ggf.org Web page: http://forge.ggf.org/projects/saga-rg/ Charter: ------- This charter is the result of a re-chartering of the SAGA Research Group. Focus/Purpose: ------------- Many application developers wish to make use of the exciting possibilities opened up by the advent of the Grid. Application developers, however, have their own agendas to pursue and often cannot spare the time or resources to fully investigate the vast wealth of Grid technologies and APIs which currently exist. They would rather be presented with a simple API close to the programming paradigms and interfaces they are used to. For example, the process of copying of a remote file may involve interaction with a replica location service, a data transport service, a resource management service, and a security service. It may involve communication via LDAP/LDIF, GRAM, HTTP, and GSI, as protocols or protocol extensions. A Fortran application programmer, however, wants to see a call very much like: call fileCopy (source, destination) Although this example is simplified, it illustrates the motivation for our work. The APIs developed by this RG will deliver a similar level of abstraction for a range of basic operations which need to be grid aware. The precise set of operations is to be decided by the RG based upon application requirements and use cases; examples of such operations may be file access, job submission, monitoring or steering. Scope: ----- The group will build on the results and feedback of the work of the former SAGA RG. As such, it will provide a forum in GGF to consolidate application driven API specifications. The primary goals of the group are two fold: 1) provide general guidelines for application driven API specifications in GGF (security guidelines, common look & feel, interoperability guidelines, conflict resolution, etc.) 2) The group will form, on an ad hoc basis, design teams which investigate new API areas for inclusion in the SAGA-API The design teams will - solicit related application use cases - issue an informal use case document - issue an informal requirement document 3) Spawn off focused working groups which will work on API specifications (standard recommendation track) for specific subsystems, e.g. RPC, CPR, application steering etc, after a design team has identified and explored an area as described in (2) above. 4) Coordinate the activities of the SAGA working groups and make sure that the resulting APIs are in line with the SAGA goals. The SAGA API does not strive to replace Globus or similar middleware systems, and does not target middleware developers, but solely application developers with no assumed background on Grid Computing who wish to grid enable their applications whilst spending as little time as possible learning new paradigms. Such developers typically wish to devote their time to their own goals and minimise the time spent coding infrastructure functionality. The API will insulate application developers from middleware. The specification of services, and the protocols to interact with them, is out of the scope of the RG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not be used to implement the functionality that the application developer needs. The RG will, however, actively liaise with all grid-middleware groups within the GGF. Exit Strategy: -------------- No clear exit strategy for this group exists, as it is supposed to provide means to continuously spawn off focused working groups. However, the group does have a list of deliverables, and should revisit its charter after these deliverables have been completed. Goals: ------ Note: As this charter is a result of a re-chartering process for the SAGA RG, it also contains goals and deliverables which have already been, or are currently in the process of being delivered. The group will produce an informal use case document ("SAGA Use-Case Document") and a informal requirement document ("SAGA Requirements Document"). In continuation, and broadening its scope, the group will create a Community Practise Document "SAGA API Guidelines", which will define the Look & Feel of SAGA APIs, and describe central paradigms (such as asynchronous operations and error handling) which should be respected in SAGA API specifications. That document will build upon the experience of the SAGA-CORE WG and their initial SAGA API specification v1.0. These documents are to guide the spawned off working groups, and to ensure short and concise working agendas for these groups. The formation of design teams is informal, and should always strive to find members from the specific areas of expertise - i.e. members from the relevant GGF community groups, and members from the relevant GGF standards groups. * Informational Document: "SAGA Use Case Document" - use cases * Informational Document: "SAGA Requirements document" - define exact scope of the initial SAGA API - define target user groups for initial SAGA API - define programming languages to be supported by the initial SAGA API * Informational Document: "SAGA use of other Grid specifications" This document will survey the survey and evaluate SAGA reference implementations with underlying models of grid-middleware including, but not confined to OGSA. * Community Practise Document: "SAGA API Guidelines" This document will define the Look & Feel of SAGA APIs, and describe central paradigms (such as asynchronous operations and error handling) which should be respected in SAGA API specifications. Milestones: ----------- GGF16: - Finalisation of "SAGA Use Case Document, version 1" - Presentation of "SAGA Requirements document, version 1" GGF17: - Finalisation of "SAGA Requirements document, version 1" GGF19: - Presentation of "SAGA use of other Grid specifications, version 1"

2 3

Revised SAGA-RG charter
by Tom Goodale 09 Feb '06

09 Feb '06

The Charter Informational Section --------------------- Area: Applications [Standards] Name of group: Simple API for Grid Applications Acronym: SAGA RG Type of group: Reasearch Group (RG) Chairs: Tom Goodale, Shantenu Jha, Thilo Kielmann Secretaries: TBD Email list: saga-rg(a)ggf.org Web page: http://forge.ggf.org/projects/saga-rg/ Charter: ------- This charter is the result of a re-chartering of the SAGA Research Group. Focus/Purpose: ------------- Many application developers wish to make use of the exciting possibilities opened up by the advent of the Grid. Application developers, however, have their own agendas to pursue and often cannot spare the time or resources to fully investigate the vast wealth of Grid technologies and APIs which currently exist. They would rather be presented with a simple API close to the programming paradigms and interfaces they are used to. For example, the process of copying of a remote file may involve interaction with a replica location service, a data transport service, a resource management service, and a security service. It may involve communication via LDAP/LDIF, GRAM, HTTP, and GSI, as protocols or protocol extensions. A Fortran application programmer, however, wants to see a call very much like: call fileCopy (source, destination) Although this example is simplified, it illustrates the motivation for our work. The APIs specified by this RG will deliver a similar level of abstraction for a range of basic operations which need to be grid aware. The precise set of operations is to be decided by the RG based upon application requirements and use cases; examples of such operations may be file access, job submission, monitoring or steering. The group will lower the barrier for application developers to make use of the grid by providing a small, consistent API for the operations of interest, the Simple API for Grid Applications (SAGA). Scope: ----- The group will build on the results and feedback of the work of the former SAGA RG. As such, it will provide a forum in GGF to consolidate application driven API specifications. The primary goals of the group are two fold: 1) provide general guidlines for application driven API specifications in GGF (security guidlines, common look & feel, interoperability guidlines, conflict resolution, etc.) 2) The group will form, on an ad hoc basis, design teams which investigate new API areas for inclusion in the SAGA-API The design teams are supposed to - solicit related application use cases - issue an informal use case document - issue and informal requirement document 3) Spawn off focused working groups which will work on API specifications (standard recommendation track) for specific subsystems, e.g. RPC, CPR, application steering etc, after a design team has identified and explored an area as described in (2) above. 4) Coordinate the activities of the SAGA working groups and make sure that the resulting APIs are in line with the SAGA goals. The SAGA API does not strive to replace globus or similar middlerware systems, and does not target middlware developers, but solely application developers with no assumed background on Grid Computing who wish to grid enable their applications whilst spending as little time as possible learning new paradigms. Such developers typically wish to devote their time to their own goals and minimise the time spent coding infrastructure functionality. The API will insulate application developers from middleware. The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The RG will, however, actively liase with all grid-middleware groups within the GGF to ensure compatability. Exit Strategy: -------------- No clear exit strategy for this group exists, as it is supposed to provide means to continously spawn off focused working groups. However, the group does have a list of deliverables, and should revisit its charter after these deliverables have been completed. Goals: ------ Note: As this charter is a result of a re-chartering process for the SAGA RG, it also contains goals and deliverables which already have been delivered, or are currently in the process of beeing deliverd. The group will produce an informal use case document ("SAGA Use-Case Document") and a informal requirement document ("SAGA Requirements Document"). In continuation, and broadening its scope, the group will create a Community Practice Document "SAGA API Guidlines", which will define the Look & Feel of SAGA APIs, and describe central paradigms (such as asynchroneous operations and error handling) which should be respected in SAGA API specifications. That document will build upon the experience of the SAGA-CORE WG and their initial SAGA API specification v1.0. These documents are to guide the spawned off working groups, and to ensure short and concise working agendas for these groups. The formation of design teams is informell, and should always strive to find members from the specific areas of expertese - i.e. members from the relevant GGF community groups, and members from the relevant GGF standards groups. * Informational Document: "SAGA Use Case Document" - use cases * Informational Document: "SAGA Requirements document" - define exact scope of the initial SAGA API - define target user groups for initial SAGA API - define programming languages to be supported by the initial SAGA API * Informational Document: "SAGA compatability with other Grid specifications" This document will survey the compatability of SAGA reference implementations with underlying models of grid-middleware including, but not confined to OGSA. * Community Practice Document: "SAGA API Guidlines" This document will define the Look & Feel of SAGA APIs, and describe central paradigms (such as asynchroneous operations and error handling) which should be respected in SAGA API specifications. Milestones: ----------- GGF16: - Finalization of "SAGA Use Case Document, version 1" - Presentation of "SAGA Requirements document, version 1" GGF17: - Finalization of "SAGA Requirements document, version 1" GGF19: - Presentation of "SAGA compatibility with other Grid specifications, version 1"

2 2

SAGA-CORE-WG charter
by Tom Goodale 09 Feb '06

09 Feb '06

The Charter Informational Section --------------------- Area: Applications [Standards] Name of group: Simple API for Grid Applications Acronym: SAGA-CORE-WG Type of group: Working Group (WG) Chairs: Tom Goodale, Andre Merzky Secretaries: TBD Email list: saga-core-wg(a)ggf.org Web page: http://forge.ggf.org/projects/saga-core-wg/ Charter: ------- Focus/Purpose: ------------- The SAGA-RG coordinates the development of simple, application oriented APIs for Grid Applications. This working group is the first working group spawned by the RG, and will concentrate on producing concrete API documents for the functional areas identified by the initial SAGA-RG design team. Specifically: - Files - Logical files - Job submission and management - Streaming communication between processes along with the core API areas which are independent of specific Grid operations: - Tasks - Sessions Scope: ----- The initial SAGA-RG collected a number of application use cases which are published in the GGF Document n umber GFD-???. The work of this group will be based on this use cases, which will define the scope and target application areas for the API. Simplicity and conciseness will be the governing design principles. The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The WG will, however, actively liase with all grid-middleware groups within the GGF to ensure compatability. The WG will continue to identify projects outside GGF with similar API-focus and goals, and will seek their input in the development of the API and its implementation. The WG will provide detailed examples and cook-book. Exit Strategy: -------------- The group will finish its work after the publication of the API Specification as GGF standard recommendation, accompanied by documents for API language bindings. Goals: ------ The SAGA-CORE-WG is the first WG spawned by the SAGA-RG, which produced the informational document ("SAGA Use-Case Document, version 1"), and is producing a related requirements document. The main goal of the WG is the creation of an API specification for the functional areas defined in these documents and explored by the first SAGA-RG design team, as listed above. This API will be submitted to GGF as a standard recommendation. The WG will produce the following documents: * Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral. * Recommendation documents: Language bindings for the "Abstract SAGA-CORE-API" specification These will be for a number of languages, such as C, C++, Java and Fortran. Milestones: ----------- GGF16: - SAGA API Specification pre-v1.0 GGF17: - Submission of abstract SAGA API Specification v1.0 - Submit Informational Document "SAGA Compatability with GGF middleware" - Implementation details review. GGF19: - Present Draft Language Bindings (C/C++/Java/Fortran)

2 2

Revised charters
by Tom Goodale 09 Feb '06

09 Feb '06

Hi, today we had a very productive discussion on the charters on the telecon, and I am about to post the revised charters to the list. * We decided on a 3-2 vote on the call that the working group should be SAGA-CORE-WG. * We intend to send the charters to the GFSG on Friday morning so they have sufficient time to digest them before their next meeting. So please get comments back asap. * There was discussion as to whether the SAGA-RG should define the process by which the abstract SIDL specification maps to language specific bindings. E.g., for procedural languages this would define the naming of constructors and the way in which overloaded functions get named. The argument for is that this is being implicitly done during the implementation phase in the SAGA-CORE-WG anyway, and we want to make sure that it is consistent across future SAGA-RGs. The argument against was that it is more documents to produce. We came to no consensus on this issue and would appreciate any comments from the wider group. Ok, I'm going to follow up with the latest charters in seperate mails so we can discuss. Cheers, Tom

1 0