[nfsv4] [FedFS] Meeting Minutes, 09/24/2009
James Lentini <jlentini@netapp.com> Thu, 24 September 2009 19:03 UTC
Return-Path: <jlentini@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A165F3A6922 for <nfsv4@core3.amsl.com>; Thu, 24 Sep 2009 12:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.481
X-Spam-Level:
X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNEWKWmUXflm for <nfsv4@core3.amsl.com>; Thu, 24 Sep 2009 12:03:54 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 641A43A6816 for <nfsv4@ietf.org>; Thu, 24 Sep 2009 12:03:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,446,1249282800"; d="scan'208";a="248656145"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Sep 2009 12:05:03 -0700
Received: from jlentini-linux.nane.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n8OJ52M5000431 for <nfsv4@ietf.org>; Thu, 24 Sep 2009 12:05:03 -0700 (PDT)
Date: Thu, 24 Sep 2009 15:05:00 -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.0909241504120.15919@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, 09/24/2009
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, 24 Sep 2009 19:03:55 -0000
FedFS Meeting Minutes, 09/24/2009 --------------------------------- Attendees --------- Craig Everhart (NetApp) Sorin Faibish (EMC) Paul Lemahieu (EMC) James Lentini (NetApp) Trond Myklebust (NetApp) Chris Stacey (EMC) Renu Tewari (IBM) Rob Thurlow (Sun) 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. + Review Action Items - Nico Williams will send his proposed changes to our LDAP configuration (o=fedfs) and the format of the FSL's pathname attribute. Complete. - James Lentini, in consultation with Trond, will think about a pathname format that is human readable and capable of describing all possible NFS paths. Complete. - Rob Thurlow will consider the use of alternative LDAP ports for an NSDB and report back with a recommendation to the group. Open. We will discuss next time. - Trond Myklebust will consult with Craig and send zero-configuration DNS SRV proposal Open. We will discuss when Trond/Craig have completed the write-up. + Austin NFS Bake-a-thon Trond is preparing a Linux prototype of FedFS for Bake-a-than. This implementation will be backed by an LDAP-based NSDB. Trond does not plan to have the admin protocol implemented. Rob is preparing a Solaris prototype of FedFS. This prototype will also generate referral information using LDAP. Both Trond and Rob are using the schema supported by the SNSDB soureforge project. [Editor's note: The SNSDB project is current as of the schema in the latest IETF draft: http://tools.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-03.txt] + Requirements Draft Update IETF general last call closed on 9/22. One comment from Gen-ART on Non-Requirement N2 (Q. What does "federation data" referred to in the context of N2? A. The NSDB records). We will address this and boilerplate nit. + Admin Draft Update An updated version of the Admin draft is available for review. The full version is here: http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-02bis.txt and a diff against the previous version is here: http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-rfcdiff.html The only change is to define a pathname as an array of path component strings rather than a single string. + Discuss Open Issues - fedfsNfsPathname format James mentioned that he had written C program, path2xdr, to convert a string path name to the XDR format that is being proposed to validate the procedure described in: http://www.ietf.org/mail-archive/web/nfsv4/current/msg07408.html Rob reiterated his concerns about the availability of such administrative tools. He noted that general LDAP tools would likely be available on a decked out machine. He also stated that for serious NSDB administration he would envision a dedicated tool being necessary. For debugging, Rob believes that a text format would be more convenient. Craig pointed out that the binary format is the same for NFS and LDAP and therefore equivalent from the standpoint of debugging difficulty. On the subject of debugging, Paul said that people are going to want a traceroute-like command that a client can run to figure out why a series of referrals have been generated/taken. Rob noted that Sun has a tool similar to the above, but he was unsure if its licensing/availability outside Sun. Paul also speculated if a filesystem interface similar to the /proc filesystem would be useful for viewing the junctions (and other extended attributes?). The server could provide this information in a special file. We also discussed how the client could provide this information. - FSN format: <NSDB location, LDAP base DN, UUID> Ramifications for both NSDB and Admin specification Rob stated that he would like to keep the FSN size modest. Renu noted that there were two possibilities: (1) store the search base in the FSN or (2) query the LDAP server for the search base (mechanism TBD. can we use LDAP?). Rob suggested that we should support both co-existing with existing LDAP servers and a separate, dedicated NSDB infrastructure. - NSDB location format: hostname or SRV RR? James emailed DNS Directorate with a question about the capabilities of SRV RRs. We are waiting for response. Rob noted that on some platforms the resolver library used to lookup a hostname is different from the DNS specific library needed to lookup a DNS SRV record. This can be an implementation barrier to using SRV RRs. - Configurable NSDB port? Time expired before we could cover this. We will discuss this next week.
- [nfsv4] [FedFS] Meeting Minutes, 09/24/2009 James Lentini