Re: [nfsv4] [FedFS] Meeting Minutes, 12/03/2009

[Daniel Ellard <[e-mail]>]

A few comments below.  If they're just rehashing things
covered in the conf call, just let me know...  Sorry that I
have a perpetual conflict on Thursday...

On Thu, Dec 3, 2009 at 3:54 PM, James Lentini <[e-mail]> wrote:
>
> FedFS Meeting Minutes, 12/03/2009
> ---------------------------------
>
> Attendees
> ---------
>
> Craig Everhart (NetApp)
> Sorin Faibish (EMC)
> Paul LeMahieu (EMC)
> James Lentini (NetApp)
> Trond Myklebust (NetApp)
> 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.
>
> + Review Action Items
>
>  - Chris Stacey will writeup a description of an SNMP MIB.

I really like the idea of having an SNMP MIB for NFSv4, and
eventually for the NSDB and fedfs aspects of the file servers.
But is doing an NFSv4 MIB part of the charter for the fedfs
discussions?  It seems like there's plenty of work to do already.

>  - NFS URL
>
>    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL
>    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS.

One of the original goals of the fedfs effort was to make the
fedfs part of the protocol as fs-agnostic as possible.  It seems
like putting the string "nfs" in the URL (as I've seen in at least
one suggestion) is a bit NFS-centric.  (yes, I'm aware that I'm
addressing this to the nfsv4 wg...)

>    This was not the type of NFS URL Paul was asking about.
>
>    Trond noted the NFSv4 has a public filehandle concept, but the
>    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is
>    different from WebNFS.

If we rely on the availability of  a "public filehandle", will we be able
to support underlying file systems that do not?  (how do people feel
about putpbfh in the first place--is it something we'd want to support
in perpetuity ourselves?)

>    ...
>
>    A fileserver's pseudo root and federated namespace root are intentionally
>    different. This allows for greater flexibility. A single server can be
>    the root of multiple namespaces, contain other directories, etc.

An old topic, but just in case...

Junction can still point to something *other* than the root of the pseudo-fs,
right?

>
> + Admin NSDB Trust Anchor Management
>
>  We briefly reviewed the mechanisms by which LDAP can be secured. LDAP
>  connections can be secured using TLC or SASL. [Editor's note see RFC4513].
>
>  We discussed the following question who or what determines if a fileserver's
>  NSDB connections are secure. We asked if the ONC RPC Administrative protocol
>  should indicate, possibly at junction create time, the desired security
>  properties to use for an FSN's resolution.
>
>  There are at least three different ways the security properties of an NSDB
>  connection could be derived: (1) each implementation could have its own
>  policy and settings, (2) the ONC RPC Admin protocol could indicate the
>  desired security mechanism, or (3) the NSDB could require a particular
>  security mechanism.

I'm missing something here.  Given that it's possible for any server to
host a junction referring to an NSDB in any (or every) other admin domain,
how can (1) possibly work (unless the entire federation is homogeneous)?

The possible permutations of different security policies and mechanisms
could be a real headache.  The fewer the better.

-Dan