[nfsv4] [FedFS] Meeting Minutes, 10/29/2009

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 10/29/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Faibish (EMC) 
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp) 
Robert Thurlow (Sun)
Chris Stacey (EMC)

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.

+ Requirements Draft Status

  Approved for publication as an RFC:

  http://www.rfc-editor.org/queue2.html#draft-ietf-nfsv4-federated-fs-reqts

+ DNS SRV Draft Update

  Review new version:

  http://tools.ietf.org/id/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt

  Diff:

  http://tinyurl.com/yfjhjbz

  Craig didn't have too much to comment on beyond what had been discussed on 
  the NFSv4 wg mailing list. He coalesced the comments that he received and 
  updated the draft on Monday.

+ Multi-Domain Draft Update

  Review new version:

  http://tools.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-02.txt

  Andy reviewed a set of slides that he put together. This draft has
  substantial updates from the -00 version. 

  The draft addresses the following two types of mappings:

  - Authentication identity <-> Authorization Context
  - On the wire authorization identity <-> On disk authorization identity

  We discussed how authorization context information is shared between domains. 

  Trond suggested that for authorization information from a remote domain, 
  a fileserver is likely to only trust the remote domain to provide
  information about itself. 

  As an example, we discussed how sample.com and university.edu might be 
  two domains. Andy explained that name@domain (e.g. [e-mail]) might 
  have one GID in sample.com and a different one in university.com.

  Andy described extensions to the posixAccount object class defined in 
  RFC2307. He mentioned that an RFC2307bis is under preparation.

  We discussed some questions about local and remote mapping.

  Andy listed these next steps for the draft:

  - Drill into NFSv4 Authorization Context definition
  - Complete LDAP extensions
           - ID mapping (remoteID <-> localID)
  - Additional text on remote groups

+ NSDB and Admin Draft Updates

  The updates discussed last week were posted.   

+ Admin resolve FSN before completion of FEDFS_CREATE_JUNCTION?

  We discussed some of the ordering implications of this.

  A warning might be appropriate, but there was consensus 
  that it should not generate a hard error.

  We discussed if a fileserver should be required/recommended/optional
  to do this.

  Paul suggested that there be a second RPC to test the status of a 
  junction. This would kill two birds with one stone. Work for both testing
  a newly created junction and diagnosis down the road.

  James suggested that the existing FEDFS_LOOKUP_FSN procedure be extended 
  to include a parameter to indicate if a junction be resolved.

  To determine if a newly created junction is resolvable, an 
  admin program would perform a FEDFS_CREATE_JUNCTION followed 
  by a FEDFS_LOOKUP_FSN.

  The draft should also discuss the advantages and disadvantages of 
  performing the test at junction create time.

  What errors should be returned if junction resolution fails? 
  There may be many different types of errors. Some will be implementation 
  specific. Some may be pretty standard: there is no junction, the NSDB is 
  not responding, the NSDB does not have a record for the FSN, ...). We 
  will define errors for the common cases and have a catchall for the 
  implementation specific ones.

+ Admin STAT command

  We discussed proposal from the mailing list.

  There were concerns about the scalability. There were also concerns about
  storing the extra information in a log. 

  There didn't seem to be support for this.

  We did not have time to fully discuss this topic. We will return to 
  it next week.