Subject: [nfsv4] FedFS Meeting Minutes, 04/16/2009

From: James Lentini <[email-masked]>
Date: Thu, 16 Apr 2009 14:56:25 -0400 (EDT)

FedFS Meeting Minutes, 04/16/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Dan Ellard (BBN)
James Lentini (NetApp)
Robert 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

  - James Lentini will re-phrase the root fileset's attribute requirements.

   ----

 For the draft-ietf-nfsv4-federated-fs-reqts document:

 R15:

   g.  If a root fileset is defined it SHOULD be stored using a compact
       representation that is compatible with heterogeneous fileserver 
       implementations. The root fileset's internal format SHOULD 
       contain enough information to generate any attributes, including
       referrals, required by the standard filesystem access protocols 
       in R9.

 In the future root fileset document, the specific attributes 
 exposed in NFSv4 would be enumerated:

   Rendering the Root Fileset via NFSv4[.x]
   ----------------------------------------

   When the root fileset is accessed by an NFSv4[.x] client, the client 
   SHOULD observe the same directory hierarchy and object attributes 
   regardless of which root fileserver is accessed. The supported 
   object attribute types are intentionally limited for two reasons:

   o The root fileset is designed to be exported by a variety of 
     fileserver implementations. In a heterogeneous fileserver 
     environment, it is necessary to limit the attributes to those
     that are supported across all fileservers. 

     Without this restriction, the client might interpret the root 
     fileset differently depending on the root fileserver being 
     accessed. This would increase the likelihood of a client being 
     incompatible with or dependent on a specific root fileserver. 
     These problems would be difficult to diagnose and limit the 
     client's ability to fail-over to a different root fileserver 

   o The root fileset's internal NSDB format is replicated.
     A compact internal representation of the root fileset aids 
     replication and storage in the NSDB.

  When accessed over NFSv4[.x], the root fileset's NFSv4[.x] 
  representation MUST support the following attributes:

  o fs_locations

  o fs_locations_info

  o fs_status

  The root fileset's NFSv4[.x] representation MUST NOT include any other 
  optional or named attributes. The root fileset's NFSv4[.x] representation 
  MUST conform to all other attribute requirements defined by the given 
  NFSv4[.x] specification (e.g. for NFSv4.1 the requirements are described 
  in Section 5.6 of [NFSv4.1]).

   ---

  There was consensus that the general approach of splitting the text into 
  two separate parts was correct. 

  There were only positive comments on the first proposed text (for 
  the requirements draft).

  For the second piece of text, there was general agreement that the 
  text went too far by saying that the root fileserver's "MUST NOT" 
  provide any of the other optional attributes.

  James was motivated by a fear that clients would become dependent 
  on optional features and thus lead to difficult to diagnose problems.

  Dan observed that if a feature is provide, then clients are likely 
  to use them. 

  Craig pointed out that there may be some optional attributes that 
  are optional because the attribute or a different attribute, but not 
  both are necessary.

  There was still consensus that some optional attributes, such as ACLs, 
  were not necessary in the root fileset. The functionality is better 
  supported by the regular filesets. For example, instead of setting an 
  ACL on an entry in the pseudo namespace an ACL can be set on the 
  the of a regular fileset.

  There was discussion on whether clients would function properly 
  in the absence of any of the optional attributes (e.g. what 
  would happened if there was no mtime or the change attribute?).
  Andy noted that at previous interoperability events, NFSv4 servers 
  that only supported the required attributes had been successfully 
  tested.

  The wording of the text should make clear that certain attributes 
  are supported by the root fileset, but not required to be present 
  on every object in the root fileset (e.g. every object in the 
  root fileset does not need to contain an fs_locations).

  The consensus was that the fear that a client would become 
  dependent on optional server behavior was unfounded. We 
  could not think of an optional attribute that would 
  ingrain itself in this way.

  Rob pointed out that client dependence on optional 
  behavior could be discovered and corrected at interoperability 
  events.

  We then reviewed how we arrived at this discussion. The 
  impetuous for this discussion was a concern that the root 
  fileset's LDAP schema would not contain information 
  for all attributes (e.g. ACLs). We did not want to 
  include ACL support in the root fileset because the 
  number of ACEs is unlimited. This would allow for  
  very large root fileset LDAP objects.

  The plan to go forward is to revise the NFSv4 
  specific text to describe how each NFSv4 attribute 
  is derived from the root fileset's LDAP data.

  Some NFSv4 attribute fields may have a one-to-one 
  mapping onto an LDAP field. Others may be derived 
  from the LDAP. Others may be implementation dependent.

  This text would be included in the root fileset draft.

  - Renu Tewari will create a root fileset I-D.

    Postponed. Renu is on vacation this week.