COmanage Developers List

[Steve Olshansky <>]

Begin forwarded message:

> From: Steve Olshansky 
> <>
> Date: December 6, 2010 12:34:52 PM MST
> To: MACE 
> <>
> Subject: [mace] Draft Minutes: MACE Call 6-Dec-2010
> 
> **MACE Call 6-December-2010**
> 
> **Attending**
> 
> RL "Bob" Morgan, U. Washington (chair)
> 
> Rodney McDuff, U. Queensland
> 
> Ken Klingenstein, Internet2
> 
> Michael Gettes, CMU
> 
> Jim Jokl, U. Virginia
> 
> Nate Klingenstein, Internet2
> 
> Keith Hazelton, U. Wisc. - Madison
> 
> Steven Carmody, Brown U.
> 
> Mark Poepping, CMU
> 
> Scott Cantor, The Ohio State U.
> 
> Renee Frost, Internet2
> 
> Ann West, Internet2
> 
> Rob Carter, Duke U.
> 
> Heather Flanagan, Internet2
> 
> Jan Meijer, UNINETT
> 
> Steve Olshansky, Internet2 (scribe)
> 
> 
> NEXT CALL: 20-December-2010
> 
> 
> *New Action Items**
> 
> [AI] (Rodney) will send out the link for an open source tool similar in 
> functionality to DropBox.
> 
> 
> *Carryover Action Items*
> 
> [AI] (Ken) will coordinate a small working group with Heather to look into 
> access control and IdM layer requirements for shared file services, 
> calendaring, and web-conferencing in a federation-centric context.
> 
> [AI] (All) with suggestions for other foundations that the Shib Consortium 
> could eventually be embedded in are encouraged to discuss them on the list.
> 
> [AI] (All) Volunteers for the ACAMP program committee are encouraged to 
> contact Ann, TomB, or RL "Bob"
> 
> [AI] (Ken) will convene a small subgroup of MACE to consider the seed cord 
> issues in more depth and report back on a forthcoming call, soon.
> 
> [AI] (Ken) will invite Mike Conlin (U. Florida), the VIVO PI, to a 
> forthcoming MACE call.
> 
> [AI] (Keith) will maintain an issues list to inform a potential new charter 
> for MACE-DirNG, syncing it with the FedApps charter.
> 
> [AI] (RLBob, Scott, and SteveO) will proceed with the process of 
> formalizing the FedApps working group, including setting up a 
> list/wiki/website, and advertise it in the appropriate venues.
> 
> [AI] (Ken) will draft a one-pager about what MACE does and what questions 
> it has, for review by MACE, as a discussion guide with Internet2 leadership.
> 
> [AI] (Ken) will distribute a draft requirements framework for VO support 
> engagement
> 
> [AI] (David) will contact GSA for an update on the approval process for 
> InCommon Silver.
> 
> [AI] (ReneeS) will revisit the list of potential new MACE members on the 
> list.
> 
> [AI] (Ken) will revise the mission statement based upon feedback received 
> on the call.
> 
> [AI] (Ken) will send out info on DHS secure online transactions
> 
> [AI] (Ken) will follow up on a MACE/AMSAC call.
> 
> [AI] (Ken) will follow up with Kuali/Rice about I2MI collaboration.
> 
> [AI] (Ken) will draft a catalyst doc, covering the key items to be 
> addressed in advising VOs how to use our infrastructure.
> 
> [AI] (Leif) will contact Ken/Steven/Tom about potential overlaps between 
> the SDCI proposal and projects in the EU.
> 
> [AI] (Leif) will discuss the IDTrust meeting on the PKNG list, seeking 
> feedback.
> 
> [AI] (Jens) will speak to an Eduroam rep about communicating with Educause.
> 
> [AI] (Ken) will draft and circulate a letter to Rice leadership, requesting 
> input to roadmaps and use cases, and to ensure our projects with Kuali 
> projects are aligned with their high-level strategic direction.
> 
> [AI] (Nate) will distribute information to the list about upcoming tactical 
> issues facing MACE
> 
> [AI] (All) send Bamboo IAM comments to Tom ASAP for coordination.   
> 
> [AI] (All) interested in participating in the international collaboration 
> activity contact RL "Bob."
> 
> [AI] (RL "Bob") will contact a representative of Kuali Rice about 
> coordinating a call.  
> 
> [AI] (Ken and Mark) will distribute some information on trust anchors in 
> the context of dynamic network configuration in GENI testbed, as well as 
> for general access control.
> 
> [AI] (Ken) will circulate some meeting notes from the last TERENA/ REFEDS 
> meetings.  
> 
> 
> **Discussion**
> 
> Theme call on collaboration-related file sharing, as discussed briefly on 
> the last call.
> 
> It was suggested that it would be useful to categorize the various efforts, 
> to better understand how the various use cases relate to each other (or 
> not).
> 
> There is interest in domestication and access control as it relates to 
> these projects.
> 
> Jan Meijer described work going on in the FileSender project, which is ~ 3 
> years old at this point and is intended for ad hoc file sharing. This work 
> started in response to the lack of available/functional alternatives for 
> sharing large files within groups, and without the bother of using 
> .htaccess on webservers. Their goal was to leverage existing work rather 
> than reinventing the wheel, but that ended up not being viable. They ended 
> up working with AARnet...
> 
> Filesize limits were an early issue they tackled. It ended up being 
> Flash-based with a Gears plugin for files larger that 2 GB.
> 
> http://www.assembla.com/wiki/show/file_sender/News_-_FileSender_Google_Gears_and_HTML5
> 
> With several hundred users, response has been positive.
> 
> In addition to the client/server software, there is also a service hosted 
> by AARnet (CloudStor).
> 
> https://cloudstor.aarnet.edu.au/
> 
> The file owner authenticates, enters e-mail address for the recipients, 
> then uploads the file(s). The service generates an e-mail for each 
> recipient  with a download URL (no login required for recipients), then 
> notifies the sender when it has been delivered. The e-mail appears to come 
> from the sender, and not the service. SPF is an issue, but tackling this is 
> on the roadmap.
> 
> Q: Is the download URL single use only?
> 
> A: No, it can be forwarded and the file downloaded as much as the recipient 
> desires. The file sender can set a deletion date, but not limit the number 
> of downloads. The file sender can track who forwards (or posts) the URL 
> because each is unique.
> 
> Q: Is the file encrypted in storage?
> 
> A: No, it is not yet clear whether that is something the service should do 
> rather than the sender
> 
> Q: Is there a separate client?
> 
> A: No, it is web-based using Flash.
> 
> Q: What dependencies are there on the underlying file system, if any?
> 
> A: None
> 
> Q: Can access control functionality in the file system be utilized?
> 
> A: No
> 
> Q: What functionality is being requested by users, that is not yet in place?
> 
> A: The ability to do bulk uploads, not one at a time. HTML5 is coming 
> soon...
> 
> Q: Is there a need for checkpointing - restarting a file xfer midway 
> through?
> 
> A: This is available now.
> 
> Q: Is maintaining a file structure (e.g. nesting) available?
> 
> A: No, multiple files without any structure, per user needs.
> 
> Q: What is in DropBox that is not in FileSender?
> 
> A: DropBox is really more of a file sync tool, rather than for transporting 
> files.
> 
> Rodney noted an open source tool similar in functionality to DropBox.
> 
> [AI] (Rodney) will send out the link for an open source tool similar in 
> functionality to DropBox.
> 
> Open APIs have been requested by developers wishing to hook this 
> functionality into their apps, especially the physics community, but to 
> date they have not been developed.
> 
> Q: Where are conversations about this taking place broadly?
> 
> A: Nowhere to date...
> 
> Q: Has distributing files using a torrent-based approach been looked at?
> 
> A: Most universities block torrent traffic at the firewall, this this would 
> probably not be very useful.
> 
> Rodney noted that the AARnet instance of this service is very popular.
> 
> Rob described the related WebFiles work at Duke, developed in response to 
> the inadequacies of AFS for their purposes, and in use for ~ 2 years now.
> 
> http://www.oit.duke.edu/comp-print/storage/webfiles/
> 
> This is a collection of tools built into the web interface, which collects 
> a listing of directories that a user has access to in the file system, 
> based on the preferences of the user wanting to share files. They have tied 
> it to their Grouper instance, which enables sharing by group (e.g. by 
> course).
> 
> They are working on federated authn coupled with local access control...
> 
> Links for reference:
> 
>         FileSender:
> 
>         http://www.assembla.com/wiki/show/file_sender
>       (demo available)
> 
>         Globus Online:
> 
>         
> http://ianfoster.typepad.com/blog/2010/11/globus-online-a-cloud-based-managed-file-transfer-service-.html
> 
>         BioTorrents:
>         http://www.biotorrents.net/
> 
> 
>       CloudStor:
>       http://www.aarnet.edu.au/Projects/2010/09/22/AARNet-Cloudstor.aspx
> 
> 
>       Updates on the TF-Storage meetings and the slides of the last update 
> are here:
>       
> http://www.terena.org/activities/tf-storage/ws9/slides/10092010-7tf-storage-meijer.pdf
> 
> 
>