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

From: James Lentini <[email-masked]>
Date: Thu, 22 Oct 2009 14:40:38 -0400 (EDT)

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

---

From: "LeMahieu, Paul" <[email-masked]>
Date: Thu, 22 Oct 2009 11:52:36 -0700

James,

These topics have been discussed in the past. I'm trying to refresh my  
memory on where we left things. Two questions:

    1) Did we ever work on a doc describing the root fileset details  
(database schema, etc)?
    2) How do file servers exporting the root fileset export both the  
unified namespace root fileset, and other exports? Are we expecting a  
separate IP for a server to export "/" of the root fileset, so the  
physical path of other exports don't appear in the namespace?

--Paul

On 2009-Oct-22, at 11:40, James Lentini wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 22 Oct 2009 14:59:42 -0400

Hi, Paul,

(1) I don't think we ever did this.

(2) This is one of the updates pending for the old draft of mine on
locating NFSv4 roots for organizations.  Someone else recommended that
the indicated servers should export the organizational roots on some
reserved name (e.g., /.organization) rather than just "/".  That way, as
you observe, the indicated file servers could export both an
organizational root and other things as well.

Thanks for asking.  Apologies for not getting around to the (2) update.

		Regards,
		Craig 

> -----Original Message-----
> From: LeMahieu, Paul [mailto:[email-masked]] 
> Sent: Thursday, October 22, 2009 2:53 PM
> To: Lentini, James
> Cc: [email-masked]
> Subject: Re: [nfsv4] FedFS Meeting Minutes, 10/22/2009
> 
> James,
> 
> These topics have been discussed in the past. I'm trying to 
> refresh my memory on where we left things. Two questions:
> 
>     1) Did we ever work on a doc describing the root fileset 
> details (database schema, etc)?
>     2) How do file servers exporting the root fileset export 
> both the unified namespace root fileset, and other exports? 
> Are we expecting a separate IP for a server to export "/" of 
> the root fileset, so the physical path of other exports don't 
> appear in the namespace?
> 
> --Paul
> 
> >  This is a reminder that our discussions are governed by the  IETF 
> > Note Well Agreement. See:
> >
> >  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
> >
> >  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
> >

---

From: James Lentini <[email-masked]>
Date: Thu, 22 Oct 2009 15:15:21 -0400 (EDT)

> (1) I don't think we ever did this.

Correct. Renu had circulated a proposal. We've discussed the concept 
of a root fileset several times, most recently on May 14:

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 14:08:22 -0500

On Thu, Oct 22, 2009 at 02:59:42PM -0400, Everhart, Craig wrote:
> On Thursday, October 22, 2009 2:53 PM, LeMahieu, Paul wrote:

I'm not sure I understood the question.  Was the question "how to
identify the root FSL for some domain?"?  If so, a) I've asked this
before, b) I think one answer is: that's a local problem for root
servers.  Not a very satisfying answer, that.

It'd be nice to be able to store at least [and probably only] the "root
junctions" in a database, possibly the NSDB itself, or perhaps a DNS TXT
RR (you'll really want DNSSEC though!), so that root server roles are
trivial to configure (add the server location to the root FSN's FSL
list, twiddle a bit on the server.

> organizational root and other things as well.

To support virtualization without having to rely on separate IP
addresses (and host names) for each domain you really want something
like:

    /.nfsv4root/                (a directory present at the root of the
                                 pseudo-fs on root fileservers)
    /.nfsv4root/<domainname>    (a junction)
                     |
		     +--------->root FSL for <domainname>

I think (2) must be resolved ASAP.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 14:21:13 -0500

Comments:

 - I'm glad to see the schema using Integer syntax more, and
   fedfsNfsInfo gone.

 - Have we reached a consensus on path encoding?

 - Extensions to the ADMIN protocol for passing NSDB self-signed certs
   and/or TAs should be quite trivial: an array (<>) of opaque, each
   array element containing a TA in the format that PKIX WG is working
   on, and an array (<>) of {NSDB server hostname, opaque cert} in the
   create junction and lookup FSN RPCs.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 14:26:50 -0500

- Why does fedfsAnnotation implement a SET as an octet string with
   escaping conventions when LDAP supports SET OF attributes?  Why not
   make it a set of key=val instead of a concatenation of key=val's with
   separators and escapes?

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 22 Oct 2009 16:28:14 -0400 (EDT)

>  - Have we reached a consensus on path encoding?

The plan is to consider this format (and others that people would like 
to writeup and propose) between now and mid-November and resolve this 
question with the mid-November draft update.

>    create junction and lookup FSN RPCs.

Including this in the ADMIN protocol is one option. In that approach, 
I see advantages to creating a separate procedure(s) for managing the 
TAs. This would allow the TA management operations to be performed 
independently of the filesystem operations.

Another option to investigate is TAMP.

---

From: James Lentini <[email-masked]>
Date: Thu, 22 Oct 2009 16:31:49 -0400 (EDT)

>    make it a set of key=val instead of a concatenation of key=val's with

A fedfsAnnotation is a single key/value pair. The attribute is 
multi-valued, so an LDAP entry may contain multiple fedfsAnnotation 
values and hence multiple key/value pairs. 

What concatenation are referring to?

What is the alternative LDAP schema you are proposing?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 15:35:11 -0500

> What concatenation are referring to?

I must have mis-read.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Oct 2009 15:40:26 -0500

> question with the mid-November draft update.

OK.

> independently of the filesystem operations.

Indeed, separate procedures for TA mgmt sounds right.  They should be
OPTIONAL to implement (if not implemented the procedures should return
an error).

An error code would be needed by which the server could say "I couldn't
authenticat the NSDB" at junction-add time.

Speaking of errors, the server should try to resolve FSNs immediately
upon junction creation, and there should be a procedure for getting a
list of FSNs/FSLs that have been unresolvable "lately", as well as
FSN/FSL resolution error counts/stats.  The recent error list/stats part
seems particularly useful: there must be a way to diagnose such
failures, and without a protocol for it the diagnostic procedures will
be vendor-specific.

> Another option to investigate is TAMP.

Yes, but I suspect that the above approach is more likely to work well
for the simple reason that it's more light-weight because it's more
ad-hoc.

Nico
--

---

From: "LeMahieu, Paul" <[email-masked]>
Date: Thu, 22 Oct 2009 14:43:58 -0700

See my comments inline [psl].

> list, twiddle a bit on the server.

[psl]
My question was not about identifying the root FSL, but rather about  
the storing the entire "top-of-tree" root fileset, a collection of  
many top-level junctions, in the database. This makes it easier to  
deploy and manage root fileservers. The simplest use case I have is  
the /home use case. Today, I update an automount map, and my change is  
distributed. How will I add a new home user directory with Fed FS?  
Will I be able to update a database entry adding /home/bob, or will I  
have to update that on a physical file server, and rely on that  
filesystem being replicated by some proprietary means to other root  
file servers?

--Paul

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 22 Oct 2009 17:51:29 -0400

In-line. 

> Sent: Thursday, October 22, 2009 5:44 PM
> To: Nicolas Williams
> Cc: Everhart, Craig; Lentini, James; [email-masked]
> >>> These topics have been discussed in the past. I'm trying 
> to refresh 
> >>> my memory on where we left things. Two questions:
> >>>
> >>> unified namespace root fileset, and other exports?
> >>> Are we expecting a separate IP for a server to export "/" of the 
> >>> root fileset, so the physical path of other exports don't 
> appear in 
> >>> the namespace?
> >>
> > It'd be nice to be able to store at least [and probably only] the 
> > "root junctions" in a database, possibly the NSDB itself, 
> or perhaps a 
> > DNS TXT RR (you'll really want DNSSEC though!), so that root server 
> > roles are trivial to configure (add the server location to the root 
> > FSN's FSL list, twiddle a bit on the server.
> >
> 
> [psl]
> My question was not about identifying the root FSL, but 
> rather about the storing the entire "top-of-tree" root 
> fileset, a collection of many top-level junctions, in the 
> database. This makes it easier to deploy and manage root 
> fileservers. The simplest use case I have is the /home use 
> case. Today, I update an automount map, and my change is 
> Will I be able to update a database entry adding /home/bob, 
> or will I have to update that on a physical file server, and 
> rely on that filesystem being replicated by some proprietary 
> means to other root file servers?
> 
> --Paul
> 

As James mentioned, this work is stalled, not forestalled.

As to the "proprietary" mention, I always thought we'd get to an IETF
protocol to replicate file systems, following some basic namespace work
with FedFS.  And aren't LDAP replication schemes proprietary, today?

I rather like the idea of updating a physical file system when I want to
edit data.  Perhaps I'm old-fashioned.

I'll stop now.

		Craig

---

From: James Lentini <[email-masked]>
Date: Fri, 23 Oct 2009 10:51:09 -0400 (EDT)

On Thu, 22 Oct 2009, Nicolas Williams wrote:

> upon junction creation, 

That seems like a reasonable thing to recommend.

> and there should be a procedure for getting a list of FSNs/FSLs that 
> have been unresolvable "lately", as well as FSN/FSL resolution error 
> counts/stats.  The recent error list/stats part seems particularly 
> useful: there must be a way to diagnose such failures, and without a 
> protocol for it the diagnostic procedures will be vendor-specific.

Good idea. What should a stat operation return? It seems that the 
total # of installed junctions, their FSNs, their locations, and the 
number of successful + failed resolutions for each would be useful.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Oct 2009 09:54:43 -0500

> That seems like a reasonable thing to recommend.

I'd rather REQUIRE it: the server will have to resolve the FSNs
eventually, so why not _now_?  Though I'd allow an option in the RPC to
skip this (in case you're building a namespace at a time when not all
services are reachable).

> number of successful + failed resolutions for each would be useful.

Counters would certainly be nice (plus a way to reset them?).  I was
also thinking of resolution failure rate and referral failure rates
(resolution failed and not in cache) running averages (over hours, days,
weeks?), so you can have an idea of how likely it is that a server's
clients are noticing errors.

Nico
--