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

[James Lentini <[e-mail]>]

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

Attendees
---------

Andy Adamson (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Pavan Mettu (Sun)
Trond Myklebust (NetApp)
Chris Stacey (EMC)
Robert Thurlow (Sun)
Renu Tewari (IBM)

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.

+ Review Action Items

  - James Lentini will investigate if an LDAP client can automatically 
    determine the security properties of an LDAP directory.

    Open. James did some initial research but has not found anything 
    yet. 

+ Mailing List Questions

  - FSL Resolution

    The mailing list thread is here:

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

    The question raised in this discussion is how a fileserver 
    generates a referral based on the results of resolving a junction. 

    The example in Section 3.2 of draft-ietf-nfsv4-federated-fs-reqts-06 
    states: 

       5.  The server converts one of the FSLs to the location type used by
       the client (e.g., fs_location for NFSv4, as described in
       [RFC3530]).

    An FSN may map to multiple FSLs, but the example indicates that a 
    single FSL is returned to the client.

    While this is just an example and not a requirement, it nevertheless
    confusing.

    James proposed changing "one of the FSLs" to "one or more of the FSLs"
    to clarify the example. No objections were raised to this change.

    Chris stated that he was in favor of leaving the process of generating 
    a referral an implementation decision.

    James agreed and suggested that it would be conceivable that a 
    fileserver would filter the FSLs for any number of reasons.

    Trond suggested that one case where a fileserver might wish to 
    filter the FSLs would be when fileserver knew some of the FSLs 
    were inaccessible to the client. For example an FSL might be behind 
    firewall that prevents the client's access.

    Chris offered another potential use case: a fileserver may wish to 
    do load balancing.

    Rob pointed out that allowing a fileserver to perform some type of data 
    reduction on the FSL results was also required. FedFS FSLs store the full 
    NFSv4.1 fs_locations_info data. Some fileservers will be reducing FSLs to 
    the more limited NFSv4.0 fs_locations data. Therefore, the fileserver need 
    to think about what to present to clients. The fileserver might want to 
    simplify the list, although Rob didn't see a big problem with returning 
    the full list.

    Trond noted that, in this particular case, the v4.0 client will only 
    choose one of these entries.

    James asked about read only FSLs. FedFS FSLs have a writeable flag which 
    can be communicated in an fs_locations_info attribute, but not an 
    fs_locations attribute. Would it make sense for the a fileserver to cull 
    out the readonly FSLs for a v4.0 client?

    Trond felt that this might be a more practical example. He also noted 
    that for replicated filesets, the fs_locations_info allows the client 
    to learn now how often the fileset is updated. There is no way to 
    communicate this information in an fs_locations attribute. To direct 
    a v4.0 client to the most up-to-date instance of a fileset, the entries 
    for a fileset could be arranged in the fs_locations list in order of 
    most to least up-to-date (the best option would be first in the list).

    Chris stated that the current approach for allowing fileservers to 
    generate referrals was useful.

    Trond proposed that recommendations on how a fileserver generate 
    a referral from FSL information be included in one of the drafts and 
    that the door be left open for fileserver filtering of the FSL 
    information. 
 
    James proposed adding the recommendations to the NSDB draft and 
    making the minor working change above to the requirements draft.

    [AI] James Lentini draft clarification for step 5 of the example in 
         Section 3.2 of draft-ietf-nfsv4-federated-fs-reqts-06.

    [AI] James Lentini draft recommendations for how to generate 
         a referral based on FSL information.

  - Root Fileset

    The mailing list thread is here:

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

    Chris reviewed the current options for implementing the root of a 
    namespace. The root may be either a normal filesystem or root fileset
    NSDB object. Chris is uneasy about allowing both options. The 
    filesystem option implies to Chris that only homogeneous fileservers 
    could be used for root servers because it implies some amount of 
    replication between the root servers. Heterogeneous fileset replications 
    seems a long way off.

    Rob suggested that heterogeneous replication might not be as difficult 
    with new facilities in v4. For example, volatile filehandles mean that 
    filehandles do not need to be replicated. That said, Rob sees the 
    future work of this group is on a draft describing how root fileset 
    data is stored in the NSDB. In some ways we are moving the replication 
    problem from the fileservers to the NSDBs. The LDAP replication story 
    is not great, but there are options and will allow the namespace root 
    to be hosted on fileservers from multiple vendors.

    Chris noted that if option to use a real filesystem is present,
    then all the functionality that implies is possible. If the namespace root 
    is a real filesystem, the namespace root can contain real files, all the
    richness of security options, etc. This will make moving to an NSDB-base 
    FSL difficult. We do expect an NSDB-based root fileset to be more 
    restrictive.

    Renu suggested that it was time to start up the discussions on the 
    root fileset again.

    Chris asked how allow both a filesystem or root fileset as the namespace 
    root.

    Andy suggested describing the expectations and restrictions.

    Chris noted that even the names of directories become sensitive. For 
    example, the fact that a directory exists with a project name should 
    not be visible to everyone. 

    Rob asked if these types of security concerns were our problem. He 
    suggested that we are in the connectivity business. There are ways to 
    arrange the namespace to protect information, for example by placing 
    sensitive project names as subdirectories in a normal fileset.

    Rob suggested that when the root fileset draft was ready, the other 
    drafts be updated to point to it as a SHOULD. Rob would like the 
    expectation and norm be that the root fileset is defined in the LDAP 
    NSDB. Building a root fileset by hand would be possible, but not 
    desirable.

   Andy suggested that rules are necessary and important when 
   organizations are joined together and combine their namespaces.

   Chris believes that there are parallels between an NSDB root 
   fileset and a DFS root fileset. 

   James noted that he was concern about placing dependencies to 
   an unwritten draft on the existing documents. The plan proposed in 
   April'09 was to move forward with the core FedFS specifications 
   and allow the root fileset definition to proceed at its own pace.

   Chris said that this sounds good. He would like to capture our 
   tentative conclusions from today.

+ Admin NSDB Trust Anchor Management

  We reviewed our discussion from last week and the following 
  mailing list discussion.

  Trond noted that we need more detail on the proposals.

  James agreed. We discussed several potential security 
  options. It seems like there are three options emerging: 
  NULL, TLS, and SASL+Kerberos 5. It is unclear how useful 
  SASL+Kerberos 5 would be.

  Trond asked if we could define a set of security options 
  and allow for future extensions. He suggested that a 
  possibility would be to include an opaque field with a format 
  determined by the security parameter, similar to RPC.

  James agreed that this was a good idea and said he had been 
  thinking along these same lines.

  Trond suggested that, if the ADs were comfortable with this 
  approach, it would be reasonable to define one or two 
  security mechanisms now and defer the defining other options 
  until there was a need.

  [AI] James Lentini draft text for Admin draft with security 
  mechanisms.

  James noted that we are falling a bit behind our schedule. 
  We had hoped to have the documents finalized before the end 
  of the calendar year. Given that reviewing the changes above 
  will take some amount of time, the earliest documents would 
  be finalized is January'10.