Subject: [nfsv4] [FedFS] meeting agenda (5/20)

From: James Lentini <[email-masked]>
Date: Wed, 19 May 2010 16:41:21 -0400 (EDT)

Tomorrow's proposed agenda is below. Please let me know if you would
like to add additional topics.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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.

+ Locating NSDB entries in an LDAP Directory

  At our 3/18/10 meeting, we discussed adding a FedFS attribute 
  to the root DSE. The goal was to eliminate the need for a 
  NCE field in a junction and thus shrink the size of a 
  junction.

  This configuration has proven difficult to performB on some 
  LDAP implementations. The following is a modification on that 
  original proposal that addresses this issue. This approach uses 
  standard LDAP facilities, and, as an added benefit, modifying 
  an LDAP directory as described below does not require a reboot.

  The FedFS specification would define the following auxiliary object 
  class:

  objectclass (
      1.3.6.1.4.1.31103.1.1000 NAME 'fedfsNsdbContainerInfo'
      DESC 'Describes NCE location'
      SUP top AUXILIARY
      MUST (
              fedfsNsdbContainerEntry
      )
      MAY (
              fedfsAnnotation
              $ fedfsDescr
      ))

  For each namingContext in an LDAP directory that contains NSDB 
  records, the namingContext's root entry would be required to include 
  the fedfsNsdbContainerInfo as one of its object classes.

  The fedfsNsdbContainerInfo's fedfsNsdbContainerEntry attribute in 
  the namingContext's root entry would contain a string. Prepending this 
  string to the namingContext value would produce the Distinguished 
  Name (DN) of the NSDB Container Entry. An empty 
  fedfsNsdbContainerEntry string value would indicate that the 
  NSDB Container Entry is the namingContext's root entry.

  For example, an LDAP directory might have the following entries:

  -+ [root DSE]
   |  namingContext: o=fedfs
   |  namingContext: dc=foo,dc=com
   |  namingContext: ou=system
   |
   |
   +---- [o=fedfs]
   |      fedfsNsdbContainerEntry:
   |
   |
   +---- [dc=foo,dc=com]
   |      fedfsNsdbContainerEntry: ou=fedfs,ou=corp-it
   |
   |
   +---- [ou=system]

  In this case, the o=fedfs namingContext has an NSBD Container Entry at 
  o=fedfs, the dc=foo,dc=com namingContext has an NSDB Container Entry 
  at ou=fedfs,ou=corp-it,dc=foo,dc=com, and the ou=system namingContext 
  has no NSDB Container Entry.

  To find the NCEs for the NSDB foo.example.com, a fileserver would do 
  the following:

    nce_list = empty
    connect to the LDAP directory at foo.example.com
    for each namingContext value bar in the root DSE
        /* bar is a DN */
        query for a fedfsNsdbContainerEntry value at bar
        /*
         * The LDAP URL for this search would be
         *
         *  ldap://foo.example.com:389/bar?fedfsNsdbContainerEntry??(objectClass=fedfsNsdbContainerInfo)
         *
         */
         if a fedfsNsdbContainerEntry value is found
              add the attribute's value concatenated with bar to nce_list

  The size of a junction would be decreased by removing the 
  NsdbContainerEntry field from an FSN. As a result, an FSN would be a 
  (NsdbName, FsnUuid) pair. To resolve an FSN such as (foo.example.com, 
  baz), where baz is the FSN's UUID value, a fileserver would do the 
  following:

   for each nce in nce_list
       /* nce is the DN of an NCE */
       search for FSLs below the DN "fsnUuid=baz" + nce
       /*
        * The above search is defined in section 5.2.1
        * of the NSDB document
        */

+ Admin Protocol

  Any updates on the replica discussion from last week.