Subject: [nfsv4] FedFS Meeting Minutes, 04/23/2009

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

FedFS Meeting Minutes, 04/23/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
James Lentini (NetApp)
Renu Tewari (IBM)
Paul Lemahieu (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

  - Renu Tewari will create a root fileset I-D.

  Renu has written up our earlier discussions in the form of an I-D. 
  The document is still a work in progress. Renu is planning to 
  complete it by the end of the month.

+ Root Fileset Draft Schedule

  We are making slow progress on the Root Fileset draft. 
  We believe that the schedule for the Root Fileset draft 
  should not be tied to the schedule for the other 3 
  protocol documents:

  draft-ietf-nfsv4-federated-fs-protocol
  draft-ietf-nfsv4-federated-fs-admin
  draft-ietf-nfsv4-federated-fs-dns-srv-namespace

  In particular, we are unaware of any reason the standardization 
  (e.g. WG last call) of the 3 protocol drafts should affected by 
  the root fileset draft.

  Renu pointed out that the NSDB schema and Root Fileset schema are 
  separate definitions.

  The requirements draft already contains root fileset 
  requirements. Note that the root fileset defined as an optional 
  feature in the requirements document.

  Please speak up if there are alternative viewpoints.

+ Other Topics

 - Migrations and cached FSN-to-FSL mappings

  Renu pointed out that we had not closed on the text addressing beepy's 
  question at the spring WG meeting on migrations and cached FSN-to-FSL 
  mappings. On 4/9, we discussed this and came to a conclusion on how 
  to proceed. We need to get our conclusions into the documents.

  What document should the text be added to? NSDB or Admin? Renu 
  suggested that the admin protocol could create the referral (see the 
  minutes from 4/9 for context) when a migration occurs. James wondered 
  if including the referral generation in the fileserver's migration 
  mechanisms would make more sense. In the end, we agreed that more 
  implementation experience was necessary on this topic.

  [AI] James Lentini will draft migration and cached FSN to FSL mappings text

 - Multi-domain UID (GID) mapping

  Andy has been working on a multi-domain UID/GID mapping document. This 
  would be useful in a FedFS environment. Andy does not know where this will 
  go.
  
 - FSL type field

  The type field in an FSL is only roughly defined. To add new supported 
  types once the document is ratified, additional RFCs that document
  future type values would be necessary.

  This is workable. To avoid requiring a special document for new 
  types, James had thought of using a URL field in the FSL. Since the 
  URL syntax already has well known formats for many types of 
  access protocols, including some such as HTTP that we have not 
  considered yet. 

  Renu and Andy remembered us discussing URLs in the past and for 
  objections being raised regarding their usage (perhaps from Rob?)

  James will review the old minutes for these objections.

 - Annotations.

   The annotations field in the FSL is not precisely defined. The 
   document notes that it is a name-value field, but does not define 
   the syntax.

   James proposed that we define an exact syntax. He proposed something 
   along the lines of a list of "<name> = <value> ;" items.

   [AI] James Lentini will draft annotations syntax text

---

From: James Lentini <[email-masked]>
Date: Thu, 23 Apr 2009 15:40:30 -0400 (EDT)

Hi,

I'd like to call attention to one item we discussed at the FedFS 
meeting today.

We have been working to define a root fileset mechanism for use as the 
federated namespace root. We've been making good but slow progress on 
this topic and we will continue to work on this.

A future individual I-D describing the root fileset will not add 
dependencies to the 3 protocol drafts. Therefore the standardization 
of the 3 protocol drafts should be independent from the 
standardization of the root fileset. This has been something we've 
discussed on our weekly calls, but I realize that many on this list 
are unable to attend those. If there are differing opinions, please 
speak up now.

Thanks,
-james

> FedFS Meeting Minutes, 04/23/2009
<snip>

---

From: Rob Thurlow <[email-masked]>
Date: Thu, 23 Apr 2009 16:25:52 -0600

>   (e.g. WG last call) of the 3 protocol drafts should affected by 

I think this is OK, but not ideal.  If we can catch up
the root fileset work a bit over time, that would be nice;
it seems like it could be possible once we have an initial
draft.

>   objections being raised regarding their usage (perhaps from Rob?)

Please do check your minutes in case this isn't the only
concern raised, but I believe I was worried about lack of
overlap in what types were supported.  I think using URLs
and being able to expand the types is a good idea, but we
probably need to make sure we have mandatory-to-implement
types so that we don't have servers giving out types that
clients can't understand.  Having alternatives (e.g. being
able to switch from NFS to CIFS) could be handy at times.

Rob T

---

From: James Lentini <[email-masked]>
Date: Fri, 24 Apr 2009 10:43:13 -0400 (EDT)

On Thu, 23 Apr 2009, Rob Thurlow wrote:

> >   We are making slow progress on the Root Fileset draft.   We believe that
> > the schedule for the Root Fileset draft   should not be tied to the schedule
> > for the other 3   protocol documents:
> > 
> >   In particular, we are unaware of any reason the standardization   (e.g. WG
> > last call) of the 3 protocol drafts should affected by   the root fileset
> > draft.
> 
> >   This is workable. To avoid requiring a special document for new   types,
> > James had thought of using a URL field in the FSL. Since the   URL syntax
> > already has well known formats for many types of   access protocols,
> > including some such as HTTP that we have not   considered yet. 

I now remembered what Renu and Andy were referring to. It was a 
separate discussion at our 3/19 meeting. We had discussed using a URL 
for the NSDB's FSN mapping protocol to allow for different types and 
versions. We agreed not to go in that direction because there would be 
no common FSN mapping protocol.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 24 Apr 2009 11:01:48 -0400

> I now remembered what Renu and Andy were referring to. It was 
> a separate discussion at our 3/19 meeting. We had discussed 
> using a URL for the NSDB's FSN mapping protocol to allow for 
> different types and versions. We agreed not to go in that 
> direction because there would be no common FSN mapping protocol.

I think you need to distinguish between "going in that direction" and
allowing going in that direction at some point in the future if desired.

I agree that we only want one protocol now.  However I still believe
that we should give ourselves or our successors the option of switching
to another protocol, in case of need.  

So I propose that there should be a protocol ID, but that it MUST be a
specific value defined in a standards-track RFC, with the only such
value defined now, and for the forseeable future to be "FedFS1".  This
allows the specification of future versions should that be desirable but
assures a common protocol now. 

-----Original Message-----
From: Lentini, James 
Sent: Friday, April 24, 2009 10:43 AM
To: Rob Thurlow
Cc: [email-masked]
Subject: Re: [nfsv4] FedFS Meeting Minutes, 04/23/2009

> >   In particular, we are unaware of any reason the standardization
(e.g. WG
> I think this is OK, but not ideal.  If we can catch up the root 
> fileset work a bit over time, that would be nice; it seems like it 
> could be possible once we have an initial draft.
> 
> >  - FSL type field
> > 
> >   The type field in an FSL is only roughly defined. To add new 
> > supported types once the document is ratified, additional RFCs that
document
> >   This is workable. To avoid requiring a special document for new
types,
> Please do check your minutes in case this isn't the only concern 
> raised, but I believe I was worried about lack of overlap in what 
> types were supported.  I think using URLs and being able to expand the

> types is a good idea, but we probably need to make sure we have 
> mandatory-to-implement types so that we don't have servers giving out 
> types that clients can't understand.  Having alternatives (e.g. being 

I now remembered what Renu and Andy were referring to. It was a separate
discussion at our 3/19 meeting. We had discussed using a URL for the
NSDB's FSN mapping protocol to allow for different types and versions.
We agreed not to go in that direction because there would be no common
FSN mapping protocol.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: James Lentini <[email-masked]>
Date: Fri, 24 Apr 2009 13:06:06 -0400 (EDT)

> assures a common protocol now. 

We have a building block for versioning the FSN mapping protocol, but 
we are not taking advantage.

A FedFS junction may be created using the FedFS ONC RPC Admin 
protocol:

https://datatracker.ietf.org/drafts/draft-ietf-nfsv4-federated-fs-admin/

As with all ONC RPC protocols, the FedFS Admin protocol has a version. 
The current FedFS Admin draft does not mandate that the FSN in 
junctions created using FEDFS_CREATE_JUNCTION be resolved using the 
NSDB LDAP protocol. The text could be improved to address your 
concerns.

Perhaps something along these lines would be appropriate for the FedFS 
Admin draft:

 For a junction created using version 1 the FedFS Admin protocol, a
 fileserver MUST resolve the junction's FSN using the NSDB protocol
 described in [FEDFS-NSDB] or via a local cache of these results.

 If a junction is created using a mechanism other than the FedFS Admin
 protocol, the junction MUST be annotated with the protocol (e.g.
 [FEDFS-NSDB]) that will be used to resolve the junction's FSN.