OGSA Teleconfence - 13 July 2005
================================

* Participants

  Pete Ziu (Northrop Grumman)
  Jay Unger (IBM)
  Andreas Savva (Fujitsu)
  Takuya Mori (NEC)  
  Mark Morgan (UVa)
  Tom Maguire (IBM)
  Fred Maciel (Hitachi)
  Hiro Kishimoto (Fujitsu)
  Mike Behrens (R2AD, LLC)

  Apologies: Andrew Grimshaw

  Minutes: Andreas Savva

* July 11 Minutes approved with no changes

* August F2F meeting update

** Venue
   
   - Andreas is following up with the (Fujitsu) Sunnyvale
     arrangements.
   - Jay is contacting Almaden

** Schedule

  - ByteIO requested an earlier slot (not Friday) 
    - Mark has to leave early and Neil cannot make Friday
  - Considered and rejected moving Naming to Friday
  - It is likely that ByteIO will not need a half-a-day slot.
  
  - Agreed that having a regular session on Friday is not a good
    idea. Friday morning should be reserved for wrap up.
    - And that the sessions could start earlier on other days to
      accomodate the extra session.

  - Agreed to start early on Thursday and put ByteIO in that slot.

  - WSDM conflict
    - Jay/Fred could not contact Heather yet.

  - Not sure about Allen L's schedule. (Affects Data session)

* OGSA WSRF BP 1.0 Security section review

  Based on draft sent out by Takuya
  http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/07/msg00037.html

  - Sec.8.1. Should use the same style as the other sections. 
    - Add a statement that there are no extensibility points beyond
      those in WS-I BSP. (Takuya)
    - l.451: References should be in the same style as the rest of the
      document. Delete. (Takuya)
      - Also, if the TLS and HTTP-TLS references are not cited they
        should be deleted (Confirmed they can be cited against other
        text.) (Takuya)

  - l.454: Text added in response to tracker 1320 (require one or the
    other). Change is ok.

  - Sec.8.1.2: On mandating the use of mutual authentication
    - Latha's comment needs followup. Since Latha is not on the call,
      follow up by email and finalize at next Monday's call.
    - Agreed that this requirement is very restrictive.
    - This was discussed at the Security session at GGF14. The reason
      given for mandating it, is that the profile addresses
      inter-organization (server to server) interactions and that the
      expectation is that those interactions must be secured. If
      operating in some special environment it might be possible to do
      things differently but then interoperability is not the main
      concern.(?)
    - The concern with mandating this requirement is that it sets too
      high a bar, especially for existing middleware. Very few, if
      any, systems do this at the moment. (The mechanism of acquiring
      and validating credentials is the problem not their usage
      afterwards.) It seems overly restrictive and many people might
      not be able to comply to this profile because of this.
    - The consensus on the call was therefore to soften this
      requirement. Specifically to change the requirement from MUST to
      SHOULD (or possibly RECOMMENDS; semantically equivalent to
      SHOULD but slightly different nuance).
 
  - Sec.8.1.3: Changes are ok.
    - [Comment JT8]: Clarified that the introductory paragraph is
      informative text and should not use normative terminology. Only
      the compliance statements should do so.
      - There are a couple of places where this is not observed and
        they should be checked and changed during for the final
        review. (Hiro)

  - Sec.8.1.4: Add a normative reference to XML-Signature (Takuya)
    - And also rebuild the table at the back (Hiro)

  - Sec.8.1.5: Changes are ok.

  - Sec.8.1.6: Re-write the first paragraph in the same style as the
    other sections. (Takuya)
    - R0824: Appendix A reference is wrong and should be fixed. (Takuya)

  - Sec.8.1.7: SAML Token Profile 1.0 reference is needed. Also by
    adding this reference an earlier section that discusses the
    relation of this profile to other profiles has to be updated
    (Takuya)
    - Otherwise ok.

  - Appendix E
    - l.936: The definition of EndpointKeyInfo should also be added to
      the normative schema in Appendix D. (Takuya)

  - Editing Actions:
    1. Takuya to update the document and put on gridforge as draft 25
    2. Hiro to update table
    3. If anyone wants the pen talk to Hiro after that.
    
* Other Business

** Roadmap document
   
   - Public comment ends July 29
   - No comments received yet
   - All group members should solicit comments for this document

** Resource modelling 

  - Confirmed that Resource modeling is on the agenda of the Monday
    call.
  - Jay, Mark, Andrew had a call to discuss the issue. They will also
    discuss it in the BES call.

** Agenda for Monday call

   1. Final call on BP
   2. Resource modelling
   3. RNS specification review