Subject: [nfsv4] [FedFS] Meeting Minutes, 10/01/2009

From: James Lentini <[email-masked]>
Date: Thu, 1 Oct 2009 16:00:28 -0400 (EDT)

FedFS Meeting Minutes, 10/01/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Pavan Mettu (Sun)
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

  - Rob Thurlow will consider the use of alternative LDAP ports 
    for an NSDB and report back with a recommendation to the group.

    Close, see below.

  - Trond Myklebust will consult with Craig and send 
    zero-configuration DNS SRV proposal

    No update.

+ Austin NFS Bake-a-thon

  - status of referral support in client implementations

    Paul asked what the status was for referral support in client
    implementations.

    Rob and Pavan will be bringing a Solaris client that handles referrals
    to bake-a-thon. It handles a strict referral case where the client has not 
    seen the filesystem before. A migration event is not supported. 
    A referral on mount (where the client receives a referral while 
    following a referral) is also not supported yet. These capabilities are 
    only available in the development build. Currently, the client follows the
    first FSL in a referral. 
 
    Craig pointed out that although migration and replication were specified
    first, implementations are adding support for referrals (namespace) first.

    At the bake-a-thon, we hope to have the implementations querying the 
    NSDB to map FSN to FSLs.

    James will be bringing an OpenLDAP NSDB and OpenDS NSDB.

  - No Meeting next week

    We decided to cancel next weeks meeting since many participants would be
    at the bake-a-thon.    

+ Requirements Draft Update

  James presented the changes published today in -04. A -05 is already in 
  the works that will include the improvements suggested by Nico Williams's 
  review for the security directorate. The review contained 5 suggestions:

  improvements to security considerations:

	- noting the authorization separation inherent in the design
	- the resource consumption considerations for NSDB objects 
	- implications regarding NSDB authentication

  improvements to general description:

	- regarding the absence of junctions in the NSDB 
	- the benefits of using bounded size FSNs

+ Discuss Open Issues

  - Configurable NSDB port?

    We reviewed the email discussions on the mailing list from this morning. 

    Given that Nico felt firewalls were a minor issue:

    http://www.ietf.org/mail-archive/web/nfsv4/current/msg07440.html

    and nobody argued for requiring NSDBs to run on the standard LDAP port
    we are going to consider this issue closed.

    The drafts will be updated to clarify this point and note the 
    potential interactions with firewalls.

  - FSN format: <NSDB location, LDAP search base DN, UUID>

    Rob suggested that the LDAP search base DN should be an optional 
    field with a default value specified if it is omitted.

    We discussed the advantages of keeping the FSN size bounded.

    We reviewed the sizes of the various fields. The NSDB domain name 
    is at most 255 bytes (Section 3.1 RFC 1034 255) and the UUID is 
    16 bytes.

    For the LDAP search base DN we discussed requiring fileservers 
    to support a minimum size and allowing them to support a larger 
    size. 

    256 bytes seemed like a reasonable minimum size to require fileservers 
    to support for the LDAP search base DN.

    We also discussed specifying a maximum size for the entire FSN.
    1 KB was proposed.

    The consensus was that the additional flexibility allowed by 
    this change would be useful and therefore worth including.

  - NSDB location format: hostname or SRV RR?

    Nothing new to add.

    James needs to get an answer to his question:

    http://www.ietf.org/mail-archive/web/nfsv4/current/msg07398.html

 - fedfsNfsPathname format

   Nothing new to add.