Subject: [nfsv4] [FedFS] Meeting Minutes, 9/2/2010

From: James Lentini <[email-masked]>
Date: Thu, 2 Sep 2010 17:04:16 -0400 (EDT)

FedFS Meeting Minutes, 9/2/2010
-------------------------------

Attendees
---------

Lawrence Anthony
Craig Everhart (NetApp)
Sorin Faibish (EMC)
James Lentini (NetApp)
Chuck Lever (Oracle)
Trond Myklebust (NetApp)
Peter Staubach (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.

+ Status for draft-ietf-nfsv4-federated-fs-dns-srv-namespace

  Craig reported progress on the DNS SRV draft. He published a -05 
  version last week. This revision incorporates feedback from 
  Spencer Shepler.

+ October Bake-a-thon Planning

  Chuck Lever confirmed that he will be attending with his FedFs 
  implementation.

  Trond and several others from NetApp are planning to attend. 
  Trond reported that the Linux client's code for resolving 
  DNS names has changed since the last testing event. The 
  resolution code path is now shared between NFS, CIFS, and AFS. 
  This resolution mechanism is the one used for an NFSv4 
  fs_location's server name.

  Chuck suggested that a common NSDB might be useful
  at the Bake-a-thon. At the last event, Chuck and Rob 
  found they needed to coordinate their NSDB configurations 
  and believed a common one would be useful in the future.

  Sorin has 10 systems for the event, one of which could be 
  used for an NSDB.

  Participants from previous Bake-a-thons suggested that 
  any necessary network infrastructure (e.g. a DNS name 
  for the NSDB) be requested before the event.

  James recommended that a permanent machine rather than a 
  laptop be used for the NSDB, so that the testing isn't 
  dependent on the presence of a particular person and 
  their laptop. James volunteered to help setup the 
  NSDB.

  Chuck noted that a common NSDB would demonstrate that 
  implementations were not dependent on a particular 
  version or configuration.

+ NSDB Draft Update

  We reviewed the recommendations for processing an 
  LDAP referral described in this message:

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

  James thanked Chuck Lever who helped review and 
  draft the text.

  Offline, Craig Everhart suggested a rewording in section 5.3.
  This sentence:

	For example, an NSDB client might be configured
	to only follow LDAP referrals 
	received over a secure channel or an NSDB client
	might be configured to only follow LDAP referrals 
	that target an NSDB that supports encrypted
	communication.

  is more clearly stated as follows:

	For example, an NSDB client might be configured 
	to follow only those LDAP referrals that were 
	received over a secure channel, or only those
	that target an NSDB that supports encrypted
	communication.

  Since the feedback at the meeting was positive and there 
  have been no comments on the mailing list, the IETF version 
  of the draft will be updated with these changes.

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

  James reviewed the context for this agenda item. This 
  is a follow up to discussion we had some time ago:

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

  Craig asked if there were security considerations to this 
  operation. The RPC security context the ADMIN procedure is called 
  in may be different from the NFS procedure and therefore 
  makes diagnosing an NFS error using this mechanism difficult.
  Craig also asked if it was reasonable to assume that the ADMIN 
  server would faithfully recreate the fileserver's behavior.

  Peter asked if this was an implementation issue.

  Craig observed that describing it in the specification mandated 
  a cross platform behavior.

  Craig noted that if the ADMIN server returned a particular 
  answer to a LOOKUP, there was no guarantee a fileserver 
  would obtain the same value.

  Chuck saw two issues: implementation issues and security. He 
  pointed out that implementations might not require special 
  privileges to perform a LOOKUP operation because the LDAP
  query does not require special privileges (a read, not a 
  write of the LDAP database). However, in the current 
  model, the results of a LOOKUP could alter the state of the
  cache for all users. 

  Chuck noted that the correct title for this agenda topic 
  should be "Procedure for updating the Fileserver's FSN-to-FSL cache"
  since the result of a ADMIN LOOKUP does not completely 
  flush the entire cache.

  Rob felt that a implementation would have to provide an
  ability to modify the cache. If an administrator observed 
  an invalid cache entry with a large TTL, the administrator
  would want a way to invalidate it. Without a standard 
  mechanism for this, he foresaw vendor specific procedures 
  being developed.

  Chuck's original request was that the results of a LOOKUP 
  have more information about what happened and new error 
  codes.

  It was agreed that this procedure is intended for 
  diagnosing operational problems, not debugging the fileserver's 
  LDAP lookup implementation.

  Peter noted that in principle there could be other entities, 
  similar to nscd(1), caching results between the 
  fileserver/Admin server and the NSDB

  Peter asked if there was a standard way for LDAP 
  clients to cache results. James was aware of LCUP,
  but was unable to find widespread support for 
  this protocol extension. When we investigated this 
  topic previously we did not find a common mechanism.

  Rob observed that our architecture contains multiple layers 
  (NFS client, NFS server, LDAP Directory) where as many 
  uses of LDAP only involve two layers.

  We resolved to revise the LOOKUP procedures XDR definition 
  to include the new error codes and additional information.

+ Meeting Schedule

  Our next meeting will be on September 16.