[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] FedFS Meeting Minutes, 10/22/2009
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:LeMahieu_Paul at emc.com]
> > Sent: Thursday, October 22, 2009 2:53 PM
> > To: Lentini, James
> > Cc: nfsv4 at ietf.org
> > 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
> > > nfsv4 at ietf.org
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> > >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4 at ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>