Subject: [nfsv4] [FedFS] Meeting Minutes, 7/15/2010

From: James Lentini <[email-masked]>
Date: Thu, 15 Jul 2010 16:07:06 -0400 (EDT)

FedFS Meeting Minutes, 7/15/2010
--------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Dave Noveck (EMC)
Robert Thurlow (Oracle)

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.

+ NSDB and Admin Drafts Updated 

  http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-06
  http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-admin-05

  Chuck Lever has pointed out an error in the text of the 
  protocol draft on the mailing list. See this thread:
  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08212.html

  Chuck also suggested this change to the admin XDR:

diff --git a/Drafts/admin-proto.xml b/Drafts/admin-proto.xml
index 9e492d5..b3bb4d1 100644
--- a/Drafts/admin-proto.xml
+++ b/Drafts/admin-proto.xml
@@ -221,7 +221,7 @@
   ///         FedFsPathName          nfs_path;
   /// };
   ///
-  /// struct FedFsCreateJunctionArgs {
+  /// struct FedFsCreateArgs {
   ///         FedFsPath              path;
   ///         FedFsFsn               fsn;
   /// };
@@ -232,7 +232,7 @@
   ///  FEDFS_RESOLVE_NSDB  = 2
   /// };
   ///
-  /// struct FedFsLookupFsnArgs {
+  /// struct FedFsLookupArgs {
   ///         FedFsPath              path;
   ///         FedFsResolveType       resolve;
   /// };
@@ -287,17 +287,17 @@
   ///  version FEDFS_V1 {
   ///      void FEDFS_NULL(void) = 0;
   ///      FedFsStatus FEDFS_CREATE_JUNCTION(
-  ///                   FedFsCreateJunctionArgs) = 1;
+  ///                   FedFsCreateArgs) = 1;
   ///      FedFsStatus FEDFS_DELETE_JUNCTION(
-  ///                   FedFsPathName) = 2;
+  ///                   FedFsPath) = 2;
   ///      FedFsLookupFsnRes FEDFS_LOOKUP_JUNCTION(
-  ///                   FedFsLookupFsnArgs) = 3;
+  ///                   FedFsLookupArgs) = 3;
   ///      FedFsStatus FEDFS_CREATE_REPLICATION(
-  ///                   FedFsCreateJunctionArgs) = 7;
+  ///                   FedFsCreateArgs) = 7;
   ///      FedFsStatus FEDFS_DELETE_REPLICATION(
-  ///                   FedFsPathName) = 8;
+  ///                   FedFsPath) = 8;
   ///      FedFsLookupFsnRes FEDFS_LOOKUP_REPLICATION(
-  ///                   FedFsLookupFsnArgs) = 9;
+  ///                   FedFsLookupArgs) = 9;
   ///      FedFsStatus FEDFS_SET_NSDB_PARAMS(
   ///                   FedFsSetNsdbParamsArgs) = 4;
   ///      FedFsGetNsdbParamsRes FEDFS_GET_NSDB_PARAMS(

+ Status of i18n in rfc3530bis

  At our last meeting we discussed what the FedFS drafts should say
  about internationalization. Sorin suggested that Dave Noveck attend
  our meeting to give us an update on the text he drafted for
  rfc3530bis. Our goal is to reference Dave's text in our documents so
  that both the NFSv4 and FedFS specifications have a consistent
  approach to internationalization. The goal of this agenda item was 
  to consult with Dave on how the FedFS documents should approach 
  this topic.

  Dave Noveck reported that he has re-written the Internationalization 
  chapter of rfc3530bis. Dave will present the specifics of on the 
  changes he made in Maastricht.

  Dave suggested that we consider if the FedFS drafts should follow 
  the rfc3530bis model or choose another (stricter?) approach. 

  There are two items that we need to consider: (1) path names and 
  (2) DNS names.

  With regards to (1), the rfc3530bis text says that servers SHOULD 
  check for UTF-8. The is in Chapter 12. Dave suggested that FedFS 
  might want to be stricter.

  With regards to (2), Dave's text references IDNA. The proposal is 
  to allow either a UTF-8 string or an A-label (ASCII label in punycode). 

  Craig asked if a UTF-8 string is another name for a U-label? Dave 
  said no. A U-label is a canonicalized UTF-8 string. There is a range 
  of things that are UTF-8 strings that are not U-labels.

  Dave's advice is to follow the same approach as rfc3530bis for DNS names.

  For path names, Dave suggested we might want to require UTF-8 strings. 
  
  Trond asked if rfc3530bis had considered requiring U-labels for all 
  paths since these are stored in the file system. Dave said that this 
  had been discussed, but there were objections to this approach.

  Dave noted that his proposed text in Chapter 12 might still change.

  Craig stated that we will follow any decisions made at Maastricht. 

  [Editor's note: Dave Noveck had to leave at this point]

  Chuck asked why FedFS should be restrictive about the contents of 
  a path name than rfc3530bis. Should FedFS state path names "MUST 
  be a UTF-8 string" rather than "SHOULD be a UTF-8 string" as is 
  proposed in rfc3530bis? There did not appear to be any strong 
  arguments in favor of the stricter approach although it was 
  suggested that FedFS might have fewer legacy concerns and thus 
  not restricted in the same way as rfc3530bis.

  Chuck had some operational concerns about naming an LDAP server 
  with a UTF-8 string because the X.509 certificate format and 
  any logic on the clients and servers used during the certificate 
  authentication process expects ASCII strings.

+ IETF NFSv4 WG Meeting

  Craig reviewed the FedFS topics to discuss at the Maastricht 
  meeting. He plans to present on the status of our documents 
  (1 RFC, 1 draft passed WG last call, 2 drafts under WG discussion), 
  internationalization, the Admin protocol's REPLICATION operations,
  and the semantics of a path in the Admin protocol. 

  There were no requests for additional topics to be added to 
  the list.

+ Procedure for Listing NSDB Parameters Database

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

  Chuck described the purpose of the procedure he proposed.

  At the end of last week, we were discussing why this 
  procedure would be useful and when an NSDB's parameters 
  should be configured.

  Craig pointed out that if an NSDB only wants to accept secure 
  connections it can reject insecure connections.

  Rob suggested that the onus should be on the administrator to 
  set up the security parameters.

  There are a few different times at which the NSDB params being 
  set, including:

  (1) before junction create for both secure and insecure connections
     (what the draft says currently)

  (2) before a lookup occurs for both secure and insecure connections

  (3) before lookup occurs for secure connections only, NSDBs with 
      no parameters are assumed to be insecure

  There seems to be support for changing to (3) above.

  Rob would like tools to investigate when an individual lookup is not working.
  Is this what the FEDFS_GET_NSDB_NAMES procedure is intended for?

  Chuck noted that the FEDFS_LOOKUP_JUNCTION procedure would generate an 
  error indicating the problem and therefore was more applicable to 
  the situation Rob described.

  Chuck noted that there needs to be a way to switch from a secure 
  connection to an insecure one. The current draft provides this 
  by allowing FEDFS_SET_NSDB_PARAMS to be called multiple times 
  for the same NSDB.

  Craig pointed out that the FEDFS_GET_NSDB_NAMES procedure could be useful 
  even if it didn't address the initial motivation.

  Chuck asked if there was a way to figure out what the appropriate NSDB 
  was for a given fileserver. Craig noted that the NSDB is more closely 
  associated with the target of a junction rather than the source of a 
  junction. Craig suggested that Chuck's question could be restated as 
  how resource discovery works. If a new filesystem is created, what NSDB 
  should contain its FSNs?

  Chuck suggested we table discussion of the FEDFS_GET_NSDB_NAMES 
  procedure until we have a large discussion on resource discovery. 

+ Procedure for Flushing the Fileserver's FSN-to-FSL cache

  [Editor's note: we ran out of time for this. We will discuss 
   this next time]

+ Future meeting topics

  Andy Adamson has requested an agenda slot to discuss his
  draft-adamson-nfsv4-multi-domain-access draft. James has 
  asked Andy for a date when we should be prepared for this 
  topic.

  Andy plans to create a list of outstanding issues for 
  us to review.

+ Meeting Schedule

  Our next meeting will be on August 5.