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

[James Lentini <[e-mail]>]

On Thu, 22 Oct 2009, Everhart, Craig wrote:

> Hi, Paul,
> 
> (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

> (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:[e-mail]] 
> > Sent: Thursday, October 22, 2009 2:53 PM
> > To: Lentini, James
> > Cc: [e-mail]
> > 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
> > 
> > On 2009-Oct-22, at 11:40, James Lentini wrote:
> > 
> > >
> > > 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-pr
> > > otocol-04.txt
> > >
> > >  and a diff against the -03 version is here:
> > >
> > >   
> > > 
> > http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-pr
> > > otocol-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-ad
> > > min-03.txt
> > >
> > >  and a diff against the -02 version is here:
> > >
> > >   
> > > 
> > http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-ad
> > > min-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
> > >
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> > >
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> > 
>