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

["Everhart, Craig" <[e-mail]>]

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:[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
>