[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.