XRootD and FTS Workshop

• FTS and Tokens
  • storage.read, storage.write, storage.overwrite?!?!
    • discussion was more generic not exactly about WLCG profile
  • this will be mapped in WLCG profile to
    • storage.write -> storage.create
    • storage.overwrite -> storage.modify
  • three tokens for job submission
    • access token used to submit transfer
    • access token for source
    • access token for destination
  • use token exchange to refresh access tokens for for queued / running FTS transfer
    • FTS needs client registration with enable token exchange flow for each supported issuer
    • cache valid access tokens to limit load on token issuer
      • efficiency depends on granularity
      • e.g. AT with storage.read:/ can be reused by all transfers with same audience
      • e.g. AT with storage.create:/full/path/to/destination/file can't be really reused
    • AT are opaque to the FTS, token issuer must be configured to issue fresh AT with same storage.* content using token exchange flow
• FTS Planning Session
  • timeouts & slow / no progress? e.g. DMC-1278
    • what happens on active party side when FTS drop connection to stuck transfer
      • should we ask for HTTP-TPC improvement / clarification?
      • write email to the TPC/BDT mailing list
    • this is already well defined in HttpTpcTechnical specification
      • nothing to discuss => no mail to TPC/BDT mailing list
      • updated related DMC-1278