Subject: [nfsv4] FedFS Meeting Minutes, 03/12/2009

From: James Lentini <[email-masked]>
Date: Thu, 12 Mar 2009 17:50:33 -0400 (EDT)

FedFS Meeting Minutes, 03/12/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Robert Thurlow (Sun)
Paul Lemahieu (EMC)
James Lentini (NetApp)

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

  [AI] Renu Tewari will investigate how rsync handles ACLs

  [AI] James Lentini to write up formal proposal for how to use RFC 4122 UUIDs

  James proposed adding the following text (prefixed by a "+") to the 
  NSDB document on page 7:

   FsnUuid:  a 128-bit UUID (universally unique identifier), conforming
      to [RFC4122], that is used to uniquely identify an FSN.  An NSDB
      SHOULD ensure that no two FSNs it stores have the same FsnUuid. 
+     To minimize the probability of two UUIDs colliding, a consistent 
+     procedure for generating UUIDs SHOULD be used throughout the 
+     federation. Within the federation, UUIDs SHOULD be generated 
+     using the procedure described for version 1 of the UUID variant
+     specified in [RFC4122].

  This is a recommended rather than a required behavior because 
  the NSDB will be capable of eliminating UUID collisions if 
  they do occur.

  Those on the call said the text sounded good.

+ Admin Document Review

  We briefly discussed the Admin document changes that were 
  posted last week.

  - UUID field size

  One edit that we didn't discuss last week was the ONC RPC 
  protocols UUID field size. In the previous version the 
  field was The field was 512 bits. In the updated version, 
  the field is now the same size as a UUID, 128 bits. 

  Those on the call agreed with this change.

+ Bootstrap FedFS in an existing environment.

  During the Q&A question after Robert Thurlow's FedFS talk
  at Connectathon, the question was raised of how to 
  bootstrap FedFS from an existing environment.

  We discussed if there were any standardization requirements 
  in this area. The opinion was that there were not.

  We discussed several aspects of bootstrapping:

  In many companies, there are existing automounter maps that 
  define the namespace. Each map could correspond to FedFS a 
  junction point. This would provide a way to mirror the 
  automounter namespace into FedFS.

  At the same time, some users are likely to be dissatisfied with 
  the namespace organization. A conversion to FedFS 
  would give these user an opportunity to make changes 
  to their namespace. Bootstrapping may not be as important 
  to these users.

  One useful feature of the automounter is that it allows the 
  namespace to be customized per-client basis (e.g. to 
  provide binary image files compatible with the client's 
  OS and HW).

  With automounter maps provide different location for the 
  same part of the namespace. The NFSv4.1 spec describes 
  how to accomplish this using a referral (see the 
  client-specific variable substitution in section 11.10.3).

  Our expectation is that users will want to convert the 
  information they already have in NIS+ and LDAP, but
  not complex /etc maps.

  It might be nice to have an appendix in the documents that 
  describes what a well laid out FedFS namespace would look 
  like. We have some of this in the DNS SRV spec. It recommends 
  that the FedFS root for example.net be mounted at /nfs4/example.net.

  There will undoubtedly be tools developed to automate this 
  process, but there is no need to define a standard process 
  for bootstrapping FedFS.

+ IETF NFSv4 Working Group Presentation

  NFSv4 WG meeting is March 25, 9:00 AM - 11:30 AM.

  We have a presentation slot. What do we want to discuss?

  Root fileset: explain what it means and what are the benefits.

  LDAP for NSDB: review lack of replication between heterogeneous 
  LDAP implementations and error codes for LDAP operations.

  User identities across domains.

  Security considerations review.

  Review requirements document in detail.