[nfsv4] [FedFS] Meeting Minutes, 7/08/2010

[James Lentini <[e-mail]>]

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

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Renu Tewari (IBM)
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 Draft Update

  We reviewed the changes described in the meeting agenda.
  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08170.html

  There were no questions or comments on the changes.

  The plan will be to update the official IETF version before July 12.

  Chuck suggested that future revisions provide guidance on 
  the handling of LDAP referrals.

+ Admin Draft Update

  We reviewed the changes described in the meeting agenda.
  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08170.html

  Chuck suggested that two additional error codes be added: 
  FEDFS_ERR_PATH_TYPE_UNSUPP and FEDFS_ERR_DELAY 

  We discussed what FEDFS_ERR_DELAY would mean. The idea is that 
  this error would allow the admin server to indicate to the admin
  client that it was waiting on some other system. For example, the 
  admin server might be waiting on a response from an NSDB or for 
  a hierarchical storage system. It was suggested that the client 
  could recover by waiting and then sending a new procedure call 
  with the same parameters to the server under the assumption that 
  the error was transitory.

  Craig asked if a generic error such as this was necessary. Chuck 
  believes that it is because of RPC retransmission. He pointed out 
  that NFSv4 has an NFS4ERR_DELAY which is used to tell the client 
  to go off and do something else. Trond pointed out that NFS4ERR_DELAY
  can be abused. He suggested that returning a descriptive error 
  would be more useful for the client.

  We discussed what the text description for this error code would 
  be. Chuck suggested that the text in RFC5661 could be used. There 
  was concern that portions of that text would not be appropriate. 

  We agreed to discuss this topic further at a future meeting so 
  that we could adequately review the proposal.

  There were no objectsion to adding the FEDFS_ERR_PATH_TYPE_UNSUPP 
  error code in the next update.

+ Admin Protocol topics
 
 - Listing the NSDB Parameters Database

   Chuck described the proposal he sent to the mailing list:
   http://www.ietf.org/mail-archive/web/nfsv4/current/msg08171.html

   The purpose of this procedure is to allow administrators to 
   review entries in the NSDB parameters database. This information 
   might be used to check for errors or to populate a graphical UI 
   with the contents of the admin server's database.

   Chuck modeled the procedure on RFC5661's READDIR.

   Rob suggested that the admin client should not need to set NSDB 
   parameters before hand if it will be using SEC_NONE. We will 
   discuss this further next time.

 - Explicit Cache Flush procedure

   There wasn't time to discuss this.

 - i18n text

   Sorin noted that Dave Noveck was drafting text on this topic 
   and would be presenting his proposal at the WG meeting at 
   the end of the month. Sorin will invite Dave to join us 
   next week.

   James reiterated that the plan is reference the appropriate 
   i18n sections of the rfc3530bis document in the FedFS drafts.

   Chuck noted that we should review the representation of 
   NSDB names in the Admin protocol and in X.509 certificates. 
   He observed that X.509 certificates are not IDN aware and 
   only contain A-labels. When the IDN text is complete, we will 
   review this area.

+ Meeting Schedule

  Due to the upcoming IETF WG meeting, we will shift our meeting 
  schedule around. We will meet on July 15 and then on August 5
  after the WG meeting.

+ Boston Bake-a-thon

  Sorin requested that groups planning to bring equipment to the 
  BAT contact him with their space requirements by the end of 
  August. Several individuals interested in FedFS are planning 
  to attend the BAT. Sorin said he would welcome FedFS testing 
  at the event.