[nfsv4] [FedFS] Meeting Minutes, 11/5/2009

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 11/5/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Renu Tewari (IBM)
Robert Thurlow (Sun)
Chris Stacey (EMC)
Nico Williams (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.

+ Admin STAT command

  James re-capped last weeks discussion.

  We reviewed the concerns about how to report statistics 
  in an implementation independent function. 

  The results of this procedure would be error counters and 
  junction resolution counters. 

  As an aside, Paul envisioned a traceroute-style reporting tool
  being constructed. Such a tool would be useful when a user 
  told an administrator "I can't get to my data". The tools would 
  be used to determine where the error occurred. It might need to 
  traverse multiple junctions before locating the source of the 
  problem. There command would take the path as input, and trace 
  the path using the current set of FedFS operations. Paul did 
  not think additional operations (beyond the extensions to 
  FEDFS_LOOKUP_FSN described below) would be necessary.

  We then returned to discussing a STAT command.

  Craig raised the issue of information leakage and permissions
  for a  command since it would allow the administrator 
  to determine what the fileserver is doing on everyone else's 
  behalf.

  Rob suggested that if such an operation were added that it 
  be optional to implement.

  Chris speculated that such a facility might be useful for 
  diagnosing a Federation error. He envisioned a tool that would 
  examine all the fileservers in a namespace and give a yes/no 
  if anyone of them were seeing resolution errors. For each of 
  the fileservers experiencing errors, a second level of detail 
  would be provided on which junctions were failing.

  We need more information on the use cases for such a facility 
  before determining if it is necessary.

  [AI] Chris Stacey will write up example use cases for 
       a statistics command.

+ Admin FEDFS_LOOKUP_FSN resolve parameter

  We reviewed the updates posted here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-03bis.txt

  and diff here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-rfcdiff.html

  The first parts of the diff should be ignored. The xml2rfc tool has 
  been updated to place the abstract first in the document.

  The real changes start on page 6.

  Craig suggested adding an unstructured text field to the results to 
  indicate the source of a failure.

  We discussed the NSDB error. There is only one error being proposed without 
  distinction between NSDB node is down, the NSDB service is not listening, 
  the fileserver can't negotiate an LDAP connection, etc. There was consensus 
  that a coarse grained error for failure to establish and end-to-end NSDB 
  connection was all that should be provided.

  We also discussed reflecting LDAP error codes back through the procedure's 
  results. We agreed that the free form string field that will be added is 
  the appropriate place for this.

  Rob suggested that a malformed response be added as a fourth type of
  resolution error.

  As an aside, we discussed what the fileserver's behavior would be 
  when a junction resolution error occurred when a client was traversing
  the junction. What should the client see? Should the fileserver wait or 
  return an error? It seemed prudent for the fileserver to return a DELAY
  error if the problem was transient. For persistent errors the fileserver 
  should indicate a hard error.

  The admin protocol should return an error on junction resolution failure 
  immediately. This will allow the administrator to diagnose problems 
  immediately.

  Craig suggested that the resolve parameter be a ternary instead of binary
  value: 0 = don't resolve, 1 = resolve using cache value, and 2 = resolve 
  using nsdb.

  We also agreed that a generic catch all for resolution errors would be 
  useful to distinguish a resolution error from SVRFAULT.

  [AI] James Lentini add malformed response error code, string field to 
       response, generic resolve error code, and make resolve a 
       ternary value.

+ Admin NSDB Trust Anchor Management  

  Nico proposed TA format and TAMP, pick one as required to implement. 
  We need to discuss this more.

  [AI] James Lentini to discuss TA management with Nico.

+ No Meeting Next Week

  Next week is IETF'76 in Hiroshima. We will not meet next week.