Comments on the Per-Entity Working Group report from Michael Gettes

Scott,,

I had a conversation with Michael Gettes on Thursday in which he mentioned number of things about the Per-Entity Metadata report.  Here are my notes and subsequent thoughts.  I'll also post them on the feedback page, assuming Michael doesn't speak up saying I've misrepresented something.

1. The sponsor should be the InCommon TAC, rather than Steve Carmody.  That's actually how I had originally envisioned T&I's document stewardship process working, although I got some people saying that a sponsor should be a specific person.  In this case, through, Mark Scheible will soon be the TAC chair, not Steve.  If you're OK with it, I say we put TAC there and see if we get push back.
2. We should add an appendix listing the work group participants.  This could be subscribers to the Sympa list, although, I'm tempted to list only people who attended at least one call to distinguish participants from lurkers.
3. There will be a number of cases where a local MDQ service makes sense; we should make sure that whatever is deployed is open source, documented, and that operational parameters are well understood.  While we want InCommon to provide a good, solid service, it also can't be a black box.  This openness should also extend to the monitoring solution required by section 7.5
4. Section 5.6 (cost as a risk) doesn't say much.  Maybe drop it, or add some options of outsourcing, etc.?
5. In section 6.2, we talk about two example deployment models but not others.  Perhaps it would be better to replace "CDN" with "outsourced service," as that may be more the distinguishing characteristic?
6. Performance monitoring in 7.2 seems to conflict with 7.5, as it specifies monitoring from the Internet2 backbone, rather than from participant sites.  Also, where did 200ms come from as the requirement?  I'm not sure there is a conflict between 7.2 and 7.5, but maybe we should clarify to avoid confusion.  (And, frankly, I don't remember how we came up with 200ms.  Perhaps just a compromise of other numbers that were thrown out in discussion?)
7. Section 9.2 says that MDQ criteria should be added to the nascent implementation and deployment profiles, but we don't say what those criteria are.  Keith Wessel has also asked about this, as he chairs the deployment profile working group.  Perhaps just that it's supported?  Maybe something about caching parameters?  I'm not sure how far our group can help with this.  Maybe it's fodder for another working group that works with InCommon through deployment.
8. Section 9.3 raises the issue of what default cache parameters should be.  TomS has also raised this issue.  I'm not sure our group can make an intelligent statement, but maybe there's been something learned from the testing InCommon has been doing, or for a group that works with InCommon through deployment.
9. The appendix mentions a number of SAML implementations that do not support MDQ.  Should InCommon (TAC) do something about that?  Perhaps we should distinguish between implementations that do or don't support any kind of metadata distribution and observe that we aren't changing that issue with the introduction of MDQ?  Either way, TAC should be tracking the implementations mentioned for MDQ support in the future.
10. Thinking more broadly, is central distribution of all metadata by one's federation the right business model?  This is out of scope for our group, but it resonated for me, given my recent post to REFEDS about interfederation and how we need to support multiple sources of trust.  Maybe there should be a recommendation for a working group that takes a step back to explore how all of this should  work?