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

James Lentini <jlentini@netapp.com> Thu, 28 October 2010 19:56 UTC

Return-Path: <jlentini@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 421C83A68E7 for <nfsv4@core3.amsl.com>; Thu, 28 Oct 2010 12:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.022
X-Spam-Status: No, score=-8.022 tagged_above=-999 required=5 tests=[AWL=2.577, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id J32PCP+-906M for <nfsv4@core3.amsl.com>; Thu, 28 Oct 2010 12:56:24 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com []) by core3.amsl.com (Postfix) with ESMTP id EAD2D3A6877 for <nfsv4@ietf.org>; Thu, 28 Oct 2010 12:56:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,253,1286175600"; d="scan'208";a="474439793"
Received: from smtp1.corp.netapp.com ([]) by mx2-out.netapp.com with ESMTP; 28 Oct 2010 12:58:04 -0700
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com []) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9SJw4v6014209 for <nfsv4@ietf.org>; Thu, 28 Oct 2010 12:58:04 -0700 (PDT)
Date: Thu, 28 Oct 2010 15:58:03 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: nfsv4@ietf.org
Message-ID: <alpine.LFD.2.00.1010281556530.32513@jlentini-linux.nane.netapp.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [nfsv4] [FedFS] Meeting Minutes, 10/28/2010
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 19:56:25 -0000

FedFS Meeting Minutes, 10/28/2010


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)


+ IETF Note Well Agreement

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


  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:


  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.