Subject: [nfsv4] [FedFS] meeting agenda (10/1)

From: James Lentini <[email-masked]>
Date: Wed, 30 Sep 2009 18:19:41 -0400 (EDT)

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

    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.

+ Review Action Items

  - Rob Thurlow will consider the use of alternative LDAP ports 
    for an NSDB and report back with a recommendation to the group.

  - Trond Myklebust will consult with Craig and send 
    zero-configuration DNS SRV proposal

+ Austin NFS Bake-a-thon

+ Requirements Draft Update

+ Discuss Open Issues

  - Configurable NSDB port?

  - fedfsNfsPathname format

  - FSN format: <NSDB location, LDAP base DN, UUID>

  - NSDB location format: hostname or SRV RR?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Sep 2009 17:54:24 -0500

>   - NSDB location format: hostname or SRV RR?

Conveniently enough, the FSN format had better include the NSDB port #
if SRV RRs are not in use, unless you wish to have a single alternative
port number used throughout.  Yet another way in which SRV RRs help
here.

As a compromise, you could try SRV RR queries, then fallback on A
RRsets, but I don't think that simplifies anything (it's not RRset
administration that's the problem -- it's the code to do SRV RR queries
that is).  We all already have SRV RR query code for other purposes, so
I say just use SRV RRs.

Also, see my secdir evaluation of the requirements document: you may
want to include optional authentication information in the FSN format:

    FSN = {NSDB information, UUID}
    NSDB information = {NSDB domainname, [LDAP base DN],
			[TLS certificate fingerprint or trust anchor
			 name/fingerprint]}

The LDAP base DN could be "" (which is what is currently required), some
arbitrary DN, or, if not present, a DN derived from the domainname
(DC=leftmost-label,DC=next-to-leftmost-label,DC=...,DC=tld).

If the NSDB TLS server authentication information is not present, then
use a set of TAs configured out of band, else use the specified TA or
server self-signed cert.

Nico
--