Options for generating RAiD handles

[ardc-shorn]

Options for generating RAiD handles

"Do nothing" - use existing shared ARDC prefix

• Legacy Raid app uses this
• Current Raido implementation uses this
• ARDC DevOps supports operation and infra of this
• Shared between ARDC customer, no unique prefix to raid, no way to tell what handles are raid or not raid
• other reg-agents do whatever they want, no requirements
• how to tell if a given handle is a raid
  • can't, at least not just by looking at it
  • would have to use the reg-auth central endpoint
    • which would have to be coded to "fan out" to all reg-agencies

"Ad-hoc prefix registration" - registered with reg-authority

• We initially register a single handle prefix, exclusively for Raido
• newly minted Raido raids (including via V1 legacy API) will use this new prefix
• handle server is run by ARDC devops, as a standalone service exclusive to raido
  does not need special authn/authz because exclusive to raido, simple API key will do fine
  • other reg-agents will register and purchase their own handle prefix
    • reg-agent will be required to register their prefix with the reg-authority as part of becoming a reg-agency
    • reg-agent will be responsible for operation and infra of their handler server, configured to use their assigned prefix
• how to tell if a given handle is a raid
  • see if its prefix exists in the "known prefix map"
    • list of up to about 20 reg-agent prefixes, identifying which reg-agent it belongs to
  • list of known prefixes is published on raid.org or somewhere (it's not a raido thing)
  • can tell which reg-agent minted which raid handle based on the "known prefix map"

"Single global prefix" - operated by reg-authority

• newly minted raids for all reg-agents, including raido will use this new prefix
• handle server is run by ARDC devops, as a standalone service used by all raid-agents around the world
  • all reg-agents will be required to use this handle server
  • ARDC pays for operation and infra of the handle server
  • will still need some kind of APIDS-like functionality to handle authn of the the various reg-agents
• how to tell if a given handle is a raid
  • see if its prefix is in the "blessed prefix"
  • can't tell which reg-agent minted which raid
  • search/get operations will have to be "fan out"

"Reserved prefix range" - managed by the reg-authority

• register a contiguous range of new prefixes for raid, the "reserved range"
  • i.e. 20.500.XXXXX.1 to 20.500.XXXXX.20
  • I believe the cost is approx $50 per prefix annually
• use the first prefix for raido
  • handle server is run by ARDC devops, as a standalone service exclusive to raido
    • does not need special authn/authz because exclusive to raido, simple API key will do fine
• when a reg-agent registers with the reg-authority, they are assigned one of the "reserved range"
  • assigned reg-agent prefixes form the "known prefix map"
  • reg-agent will be responsible for operation and infra of their handler server, configured to use their assigned prefix
• how to tell if a given handle is a raid
  • see if its prefix exists in the "reserved range"
  • can tell which reg-agent minted which raid handle based on prefix in the "known prefix map"
• short term, paying for unused prefixes
• long term, might run out of prefixes
  • can just have a second range, not that much more complicated

"Short root prefix" - managed by the reg-authority

• Join DONA foundation and get a "short root prefix"
  • unknown cost to register the root prefix
• when a reg-agent (including raido) registers with the reg-authority, they are assigned a specific prefix based on the root prefix
  • I don't know if this involves extra overhead or not
    • i.e. register allocated prefixes with DONA or anything like that?
  • reg-agent will be responsible for operation and infra of their handler server, configured to use their assigned prefix
  • it may also be possible to pay for DONA to run a handle proxy service for Raido, instead of having DevOps do it, other reg-agencies might also want to do that
• assigned reg-agent prefixes form the "known prefix map"
• how to tell if a given handle is a raid
  • see if its prefix starts with the "short root prefix"
  • can tell which reg-agent minted which raid handle based on prefix in the "known prefix map"

"reserved range under the 10378 prefix" - managed by the reg-authority

• ARDC already has an allocated handle prefix: 10378
  • This is separate from the 102.100.100 individual prefix, which is used for APIDS production environment
  • it's some kind of "root prefix" where nobody other than ARDC can allocated handles within the 10378 range
  • Currently, ARDC use only three individual prefixes from this range
    • 10378.1 - APIDS demo environment
    • 10378.2 - APIDS test environment
    • 10378.3 - APIDS dev environment
• we could reserve a range under the prefix, e.g. 10378.1000 - 10378.2000
  • ARDC DevOps would agree to never allocate handle prefixes from within the 10378 prefix for anything other than RAID usage
  • the reg-authority would then allocated reg-agents their own prefixes from within this range
  • we could further split up the range into "prod" and "non-prod" ranges so we can differentiate between prod and non-prod raids
• we would only need to purchase and allocated prefixes on an as-needed basis (instead of purchasing a range of prefixes just to reserve them)
• reg-agent will be responsible for operation and infra of their handler server, configured to use their allocated prefix
• how to tell if a given handle is a raid
  • see if its prefix exists withing the "prod" range, e.g. 10378.1000 - 10378.1100

Dealing with legacy raids

For any option chosen that isn't "Use existing shared ARDC prefix" - we have to figure out how we will deal with legacy raid handles from the shared ARDC prefix.