Versions Compared

Old Version 3

changes.mady.by.user David Walker (internet2.edu)

Saved on

compared with

New Version Current

changes.mady.by.user David Walker (internet2.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Per-Entity Metadata Working Group - 2016-08-24
Agenda and Notes

[Etherpad used to create these notes: Agenda_and_Notes_-_2016-08-24.etherpad]

Dial in from a Phone:
 Dial one of the following numbers:
  +1.408.740.7256
  +1.888.240.2560
  +1.408.317.9253
 195646158 #
 Meeting URL (for VOIP and video):  https://bluejeans.com/195646158
 Wiki space:  https://spaces.at.internet2.edu/x/T4PmBQ


Attendees

  • Scott Koranda (LIGO)
  • Nick Roy (InCommon/Internet2)
  • David Walker (InCommon/Internet2)
  • IJ Kim (Internet2)
  • Scott Cantor (tOSU)
  • Michael Domingues (University of Iowa) 
  • Tom Scavo, InCommon/Internet2
  • Tom Mitchell (GENI)
  • Ian Young
  • John Kazmerzak, University of Iowa
  • Kevin Morooney (InCommon/Internet2)
  • Walter Hoehn (Memphis)
  • Jorj Bauer (Temple)


Agenda and Notes

  1. NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework. - http://www.internet2.edu/policies/intellectual-property-framework/
  2. NOTE WELL: The call is being recorded.
  3. Agenda bash
  4. FYI: InCommon TAC webinar at 2:00p ET today
    1. https://www.incommon.org/forum/
    2. Slides: https://docs.google.com/presentation/d/1YJiDpFUshWKpP77iBw1qvQeREHsRgVL8vTsvt3JEhfA/edit?usp=sharing
  5. Distributing split aggregates
    1. Is this a good idea?  How does it fit in our roadmap?
        1. (SK input) Yes, good idea, should be in roadmap in near future
        2. (DHW) Does the end of our roadmap include aggregates?
          1. (SK input) No
        3. Nick: We'd (InCommon Ops) like to avoid doing this, unless it's necessary.
          1. Tom has a document outlining the issues.  He'll put a version on our wiki space.
        4. TomS: Middleground is to create an IdP aggregate and hold it in reserve.
          1. Things are more critical for SPs.  IdPs are in better shape.
          2. Things are harder, however, for SPs that use the aggregate for discovery.
            1. Perhaps create a JSON file for discovery
        5. IJ has run some experiments that have given Ops confidence that they have the capacity to do signing for multiple MDQ services
          1. Tom is hoping to have something to show at TechEx.
        6. ScottC said that there may be a fix coming soon for 32-bit IdPs (which is where the biggest concern has been)
          1. So, the larger concern may shift to IdPs.
          2. An IdP-only aggregate may still make sense.  It can be used to support discovery, and it's much smaller.  (There are fewer IdPs.)
            1. It's not clear there are any good alternatives to a list of IdPs for discovery.
        7. => We agree we should have an IdP-only aggregate, to preserve stability for the federation while the infrastructure evolves.
          1. Should it have the three stages (preview, production, fallback)?   Current working thought is to only pull off of the production aggregate.
          2. It should stay around as long as we provide any aggregates.
    2. Should production of split aggregates have the same stages as current aggregate?
      1. Many of the risks are still there.  Who needs to accept those risks?
      2. An IdP-only aggregate is no more risky than the current main production aggregate (since both incorporate eduGAIN metadata directly, without curation). In fact, an IdP-only aggregate is less risky since it is significantly smaller.
      3. (DHW) Somewhat related question:  Should MDQ services have stages?
        1. If you change all entities' metadata for some reason, it has the potential to break all MDQ-distributed entities.
        2. Global mods could be rolled out slowly over time, a few entities at a time.
        3. For later discussion...  How do we handle preview/fallback for new versions of the MDQ server software and protocol?
  6. Draft report
    1. https://spaces.at.internet2.edu/x/u4EQBg
    2. Constructing the text/language for availability requirement
      1. Azure SLA example: https://azure.microsoft.com/en-us/support/legal/sla/cdn/v1_0/
      2. Amazon CloudFront example: https://aws.amazon.com/cloudfront/sla/
      3. Google Cloud CDN example: https://cloud.google.com/cdn/sla
      4. There was general consensus on the structure of the Availability section.  We'll need to talk more about the implications of the specific 3-nines metric.