OGSA Teleconference - 23 February 2005
======================================

* Participants 

  Dave Berry (NeSC)
  Ian Foster (ANL)
  Andrew Grimshaw (UVa)
  Hiro Kishimoto (Fujitsu)
  Fred Maciel (Hitachi)
  Mark Morgan (UVa)
  Steven Newhouse (OMII)
  Andreas Savva (Fujitsu)
  Frank Siebenlist (ANL)
  Jem Treadwell (HP)
  Jay Unger (IBM)

  Minutes: Andreas Savva

* Data (ByteIO BoF)

  Review of basic proposal; simple data access interface.

  Dave B has sent the revised charter to Stacey (and the
  list). Malcolm's comments are taken care.
    (1) WG will produce informative usecase  document
    (2) WG will define API including WSDL (i.e., a WS interface, not
        java binding)

  Dave B will also send 7 Q&A to Stacey and Data Area ADs (Malcolm and
  Dave Martin) (It is probably not required at this point and in any
  case one purpose of the BoF is to review and draft the final
  answers.)

  - Proposed Milestones
    - Draft document and implementation by June
    - Draft experience document by GGF15

  - Is there no other similar or related WS standard? WS-Enumeration
    was mentioned but it deals with XML streams rather than
    bytestreams.

* WS-Naming

  A number of documents were sent out prior to the call.
  1. A presentation for review in this call 
  2. A document describing the proposal
  3. A draft Naming profile that was split off from Basic profile

   - There is one more (earlier) document that discusses motivation,
     use cases, etc.

   - GGF13 Plans
     - A union of these documents will be presented at GGF13
     - Everything except the 'resolve' can be a profile. So one spec
       and one profile
     - The reason for the alternative document (2) is also to present
       to people who may not have an interest in the wider OGSA
       picture.

  The Profile is based on extending WS-Addressing EPRs with additional
  information. These extended EPRs can be used as normal EPRs by
  existing clients with no changes. This is an important requirement
  that is neeed to help initial adoption.

  Two elements are added:
  1. Abstract name: A string, globally unique, only equality comparison
    allowed
    - Anything in profile should be testable; so how can global
      uniqueness be tested?
      - Probably not testable though there could be an argument that
        they are. No good answer at this point.
    - Strings are already comparable; why re-state this?
      - To emphasize that lexicographic ordering is not
        meangingful. Only equality is defined.
    - Why not use a URI?
      - No need to constrain the Abstract Name further at this point
    - Interesting points on whether it might have structure, and
      whether it can be reasoned about to some extent.
    - Scheme presented as 3-levels; but actually there can be many
      more levels than that.
      - Three levels capture requirements of many systems. It's not
        the intention to constrain it to (at most) 3 levels. This
        should be made clearer.
        
  2. Resolver
    - Optional: it may appear and if it does its usage is optional
    - Singleton or list?
      - Currently saying that this is at-most-one
      - Leaving this as an issue for the WG that will define this.
        - If a list then there is additional complexity with whether
          you get the same answer from all resolvers or not, which one
          to use, and so on.

    - The resolver is a WS with an EPR and a portType with the
      operation 'resolve' that receives an epr and returns an
      (equivalent) updated one.
      - Could there also be a WSRF binding that casts the resolver as
        a WS-Resource with just the operation 'resolve' (no arguments;
        the resource is 'pointing' to what needs to be resolved.)
      - If necessary, it could be defined as a separate profile.

  - EPR examples slide
    - Case with "No resolver," "Simple," and "Resolver with resolver"
    - Resolver with resolver can be stateful or close to the WSRF
      rendering of a resolver mentioned before.

  - Exactly one abstract name or is it possible to include different
    names or aliases in the same EPR?
     - Is it inevitable or not? (Perhaps)
     - Sameness issues?
     - Might be better to constrain it at this level and at this point
       in time.

  - Properties on resolver, e.g., to distinguish them?
    - It is out of band

  - Extensible scheme for Names so that people can introduce names
    that are unique for that authority or not? (context)
    - Names are defined as globally unique but there is nothing
      stopping an organization to produce them in such a way that they
      can be interpreted differently within a context or domain (and
      those domains do not overlap)
      - For example, IP addresses are globally unique but many
        organizations use certain spaces (10.*) internally.
      - Issue of addressability from other places
    - Can generate a unique name/id, but someone else could re-use it
      later. Can't stop people from doing that.
      - No guarantee. Need to be careful when saying 'globally
        unique.' Might need to look at making this statement in a
        better or more descriptive manner.

   - Andrew and Mark are working to bring Tom's document (Naming
     profile draft) and this document together.

   - OGSA Naming session will probably be used as BoF for these
     activities.

* OGSA-BES update

  - Not ready for a detailed review yet. Will continue on a separate
    teleconference to discuss logistics and come back to the main call.
  - Haven't completed the 7 questions yet
  - The draft reviewed at the F2F is not updated yet. Refinement of
    that document is not the focus at the moment.

* Basic security profile

  - Frank is not available before GGF13. Probably discuss this at that
    time.