[nfsv4] [FedFS] Meeting Minutes, 10/28/2010

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 10/28/2010
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Steve Dickson (Red Hat)
Craig Everhart (NetApp)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Chuck Lever (Oracle)
Trond Myklebust (NetApp)
Peter Staubach (EMC)
Robert Thurlow (Oracle)
Nico Williams (Oracle)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ NSDB Last Call Wrap-up

  We briefly reviewed the issues.

  Rob noted that he had a use for the fedfsAnnotation attribute.

  James will start a summary thread on the WG reflector to close on 
  last call issues.

+ Admin Last Call

  Chuck will be sending an email to the WG reflector about a 
  misspelled constant.

+ Discuss draft-adamson-nfsv4-multi-domain-access-03.txt

  Andy and Nico presented their draft:

  http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-03

  Nico noted that the draft is not NFS specific. The mechanisms 
  could be useful to other protocols that use ACLs.

  Andy and Nico has two general questions: Are the technologies described 
  useful in our environments? Is the draft going in the right direction?

  One of the key things the draft defines is how to resolve user and group 
  names to identifiers that can be stored on disks.

  Nico explained that without the facilities described in the draft only 
  read-only, public (world readable) documents can be shared safely across 
  domains. To allow cross-domain access to protected documents in domain B, 
  it is necessary to store ACLs for a user from domain A in the other domain.

  Craig asked what domain A would want to know about other domains?

  Nico and Craig discussed this issue. Some points:

  * There is no Internet scale federated system for resolving names currently
  * Numeric identifiers are easier to keep from reusing than names. Names 
    can change. Numeric ids can just be auto incremented.
  * The draft uses Kerberos because it is scalable. It is impractical to 
    imagine every possible client-to-server pair in the federation 
    establishing a relationship. This will not scale.

  As an example scenario, we discussed how these mechanisms could be 
  used to allow a student at MIT and intern at Toaster Corp. Inc. to 
  access files on machines in the Toaster Corp. Inc. domain using 
  an MIT account. We discussed the pros and cons of different solutions.

  Nico described two use cases for the mechanisms proposed in the draft: 
	(1) corporate mergers
	(2) universities that want to federate
	    (or businesses like Walmart and its suppliers)

  The existing "solutions" to these problems are more workarounds. For example,
  in the case of a merger, Nico has seen two approaches. One is to use double entry
  (create an account in domain B for every user in domain B). This doesn't scale well. 
  Another is to completely eliminate the IT infrastructure of one company and 
  move everything to the other company's systems.

  We discussed how this work relates to existing IETF WGs.

  The IETF abfab WG is about building a GSS-API mechanism the can do federated
  authentication with no requirements that the client and server use the same 
  authentication mechanism. The idea is to use radius credentials to get kerberos 
  tickets. There is an emphasis on using the authentication systems that are 
  already deployed. Their use case is ISPs and universities. Andy and Nico's
  draft addresses name resolution, which isn't covered by abfab.

  Andy and Nico will email the NFSv4 and abfab WG chairs and ask for guidance 
  on how to move their work forward and which WG it might belong in. Andy will 
  be at next months Beijing meeting. He will see if he can get this on the 
  agenda for discussion at one of the WG meetings.

  James noted that this version of the draft had more context for the reader, 
  especially in the new introduction.

  Trond suggested that Section 6 needed some additional context.

  Trond requested that there be discussion of how to deal with local changes 
  made on the client. For example, a user might be running an application 
  that calls setgid(2). Nico said he understood the issue and believed that 
  is was handled by RPCSEC-GSSv3.

+ Meeting schedule

  Our next two meeting dates have conflicts. November 11 is during the IETF'79 
  and November 25 is Thanksgiving, a US holiday. Therefore out next regular 
  meeting will be on December 9, We'll plan on meeting then and make adjustments 
  as we get closer. If we need an interim call, we will schedule something 
  (avoiding the rfc3530bis meetings). Depending on the resolution of our last 
  call items, we may or may not need a meeting on December 9.