========================================================
MJRA4.6 feedback and issues
EGEE JRA4 Face to Face meeting, Pisa, 24-25 October 2005
========================================================

Present
-------

UEDIN: Alistair Phipps (AP), Andy Jackson (AJ), Kostas Kavoussanakis (KK)
CNRS:  Benjamin Vial (BV)

Actions arising
---------------

[AKP] Add issues arising from MJRA4.6 Feedback + Issues session to Savannah

[AKP] Investigate likelihood of JRA3 implementing functionality required for
delegation in trust manager

Discussion
----------

General
  - all issues should go into Savannah.  Major issues should also be documented.
    Where issues will not be resolved within EGEE1, they should be marked
    "Future, Open" in Savannah, then marked "Future, Closed" when documented in
    the appropriate FINAL location (i.e. Feb docs or DJRA4.2 updates).

DT
  - general comment: data availability very variable - makes it hard to get
    decent results
  - AJ suggests the ability to enter query information, and get
    data back live as the information is changed, would be very useful
  - AJ says could be done as a web app, but this would be much more complex
    and would be more straightforward to do as a java client app
  - KK suggested applet, but AJ pointed out variability in JVM deployment
  - AP suggests that web app provides most straightforward deployment, so a
    live-updating web app would be the best of both worlds 
  - KK points out Set buttons make for an unintuitive user interface
  - DT: assumes unit uniformity -> savannah

Interfaces
  - NM-WG v1 is an internal draft -> go into February documentation and DJRA4.2
    interfaces document
  - Capability schema -> savannah
  - Discovery schema -> savannah

Discoverer
  - Discovery capabilities must be supported by frameworks -> savannah

Object model
  - faults - use error codes instead of multi-language -> savannah and OM design
    doc
  - TimeInterval should be allowed in Request -> Savannah and OM design doc
  - instanceof usage
    - all DT cares about is "what's the number"
    - i.e. converts results into array of numbers
    - AJ thinks request should include metric + field (e.g. %utilised) so just
      an array of values is returned
  - result map: units should be associated with numbers in the map
  - name issues: Savannah, document
  - interface name vs hostname: Savannah, document

Discussion on work to do in EGEE 1
----------------------------------

Additionally present:
CNRS:    Sophie Nicoud (SN)

Additional discussion followed on what work should be prioritised within EGEE 1.

It was agreed that the following is necessary:

- record additional requirements
- ensure bugs recorded in Savannah
- update documents (DJRA4.2 and overall NPM achievements)

The two main software-related items that were considered were:

- security: cannot deploy without it, but EGEE2 may have different solutions,
and we can't currently do delegation.  However, SN pointed out that we could
just pass host certs down between certs instead of delegation, and have DN
whitelists at each service.  Authorisation would have to be done at the topmost
level and it would not be an ideal solution; does not satisfy the requirement
for frameworks carrying out the authorisation and would not work at all where
there are different levels of EGEE users for a framework (e.g.  PerfSONAR ROC
and non-ROC EGEE users).  AKP will investigate the likelihood of JRA3
implementing required functionality for delegation.

- pcpd: will be taken up as-is in EGEE2, so worthwhile to either fix bugs or
evaluate alternatives.  If Laurence Field wants a wider e2emonit deployment,
this definitely becomes higher priority.

Additionally, e2emonit tool security could be considered (as a lower priority
task), as it is needed for wider deployment.

AKP 31/10/2005