Subject: [nfsv4] FedFS meeting (4/16)

From: James Lentini <[email-masked]>
Date: Thu, 16 Apr 2009 09:29:54 -0400 (EDT)

We'll be meeting at the usual time and place:

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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]).

   ---

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

+ Root Fileset Document

  (Postponed - Renu is on vacation)

+ Requirements Draft Last Call