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

[James Lentini <jlentini at netapp.com>]

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

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
James Lentini (NetApp)
Robert Thurlow (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.

+ Draft Updates

  The IETF website's NSDB and Admin drafts are now several months old. 

  The plan is to update the drafts on the IETF website with the changes we
  have accumulated before the IETF draft update cutoff on Monday 10/26. We 
  plan to make at least one further update to the drafts in mid-November after 
  the IETF'76 meeting.

+ NSDB Draft Update

  The working version of the NSDB draft is here

   http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-04.txt

  and a diff against the -03 version is here:

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

  The update includes:

  * updated boilerplate for pre-RFC5378 contributions
  * Removed NFS-specific FSL fields from the overview and concepts 
    section. With the number of NFS-specific fields growing, the 
    overview was becoming drowned in details.
  * Changed "NSDB location" and "NSDB server" to "NSDB node" for 
    consistency. The "NSDB node" term is what we define in the 
    glossary, use occasionally in the NSDB draft, and use in the 
    requirements document.
  * Clarified examples in Section 3 (Nico requested this on the mailing 
    list)
  * Added the NSDB Container Entry concept to allow flexible LDAP 
    configurations (Nico requested this on the mailing list)
  * Removed text about the conventional DN of the privileged LDAP user 
    (cn=admin,o=fedfs). Nico recommended this on the mailing list.
  * Added CODE BEGINS/CODE ENDS markers to LDAP schema to clearly 
    indicate the license on these definitions.
  * Defined a fedfsNfsPathname to be an XDR encoded field. There 
    are concerns about viewing and editing this field to discuss.
  * Split fsl_info into separate attributes for flag bits, class,
    order, and rank fields. This allows searches on these individual 
    attributes.
  * Listed the references to the FedFS admin protocol and FedFS 
    requirements as informational. Neither are required to implement 
    the NSDB protocol and the requirements draft, as an informational 
    document, cannot be a normative reference.
  * Added tracking FSN references as an example use of annotations
  * Stated that an FSL's validFor (time a client may cache a referral) and 
    TTL (time a server may cache a referral) may be different.
  * LDAP UID space partitioned more logically with 1-99 for generic attributes, 
    100-199 for NFS attributes, 1000+ for object classes
  * NFS FSL format doesn't contain attribute for FSLI4GF_CUR_REQ or 
    FSLI4GF_ABSENT. These will be set by the fileserver. Should the 
    document say something about this?

  TODO: Use of DNS SRV for locating an NSDB

  James tested the new schema in OpenLDAP and OpenDS. As expected, both
  handled the new attributes correctly.

  Sorin asked if the "NSDB node" term was clear. He said he would review the
  document and suggest changes if he felt clarifications were necessary.

+ Admin Draft Update

  The working version of the Admin draft is here

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

  and a diff against the -02 version is here:

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

  * updated boilerplate for pre-RFC5378 contributions
  * updated pathname definition to match NFSv4 format
  * added NSDB Container Entry value to FSN
 
  TODO: Add recommended operations for setting NSDB Trust Anchors

  We have 2 options to provide the above functionality:

  - Add optional operations to the Admin protocol
  - Recommend the use of an existing (or soon to exist) protocol

  The pkix WG is chartered to work on this:

  http://www.ietf.org/dyn/wg/charter/pkix-charter.html

  and has produced the following:

  Trust Anchor Management Requirements
  http://www.ietf.org/id/draft-ietf-pkix-ta-mgmt-reqs-04.txt

  Trust Anchor Format 
  http://www.ietf.org/id/draft-ietf-pkix-ta-format-04.txt

  Trust Anchor Management Protocol (TAMP) 
  http://www.ietf.org/id/draft-ietf-pkix-tamp-03.txt