Subject: [nfsv4] [FedFS] Meeting Minutes, 1/21/2010

From: James Lentini <[email-masked]>
Date: Thu, 21 Jan 2010 14:49:49 -0500 (EST)

FedFS Meeting Minutes, 1/21/2010
--------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (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

  - James Lentini draft text for Admin draft with security 
    mechanisms.

    Complete. See below. Additional changes may arise during 
    discussion.

+ Requirements Specification Published

  See RFC 5716

  http://www.ietf.org/rfc/rfc5716.txt

+ Weekly Meeting Schedule

  We have pending updates to both the NSDB and Admin drafts. 
  Would it be useful to publish these updates and suspend 
  our weekly meetings for 2-3 weeks to give time for 
  review and comments on the drafts?

  Trond pointed out that with the publication of the NFSv4.1 
  RFCs last week, it would be idea to make sure our references 
  are still accurate (i.e. section numbers, etc.).

  The idea would be to continue the weekly meetings after the break. 
  The break is intended to give everyone time to review the drafts 
  and determine if there are further updates necessary.

  The break will also give time for the implementations to progress and 
  uncover any issues.

  The consensus was that this is a good idea. We choose February 11 
  as our next meeting date.

  Between now and February 11, we will review the drafts and send 
  feedback in email to the WG mailing list. On February 11, we will 
  re-convene and evaluate consensus. The expectation is that we will 
  return to weekly (or bi-weekly) meetings after February 11.

  [AI] James Lentini update IETF versions of NSDB and Admin drafts

  Trond pointed out that February 11 is the week before Connectathon 
  begins on Thursday, February 18. This will also be a good date to 
  discuss logistics for FedFS testing at Connectathon.

+ Discuss Admin protocol operations 
  FEDFS_SET_NSDB_PARAMS and FEDFS_GET_NSDB_PARAMS

  Full text for the operations is here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-03bis.txt

  RFC diff here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-rfcdiff.html

  James mentioned that his proposal defined the certificate to be 
  x509v3 in binary DER format. Other formats could be supported if 
  necessary if there is an interest.

  James also mentioned that he had included guidance for the fileserver 
  when existing NSDB params are replaced with new NSDB params. The advice 
  is to terminate and re-establish any fileserver to NSDB connections with 
  the new parameters.

  Finally, James mentioned that he had focused on the TLS security mechanism 
  in this revision. We discussed the benefits of supporting multiple security 
  mechanisms last week (less risk if a mechanism is compromised). Additional 
  security mechanisms can be added in future updates. The focus was on getting 
  TLS correct in this update.

  Trond suggested that it would be useful for FEDFS_GET_NSDB_PARAMS to 
  allow users with different privilege levels to see different information. 
  For example, the fileserver might have a privilege level that allowed a 
  user to issue FEDFS_CREATE_JUNCTION, but not FEDFS_SET_NSDB_PARAMS. It 
  would be useful for such a user to be able to view a limited about of 
  information about what type of security would be used to contact the 
  NSDB, but not the details. 

  For TLS, there is not much that is revealed if all the information is 
  shared (certificate is public), but for other security mechanisms there 
  might be sensitive information that only a user with FEDFS_SET_NSDB_PARAMS 
  should be allowed to see.

  The suggestion is to add a parameter to FEDFS_GET_NSDB_PARAMS to 
  indicate the amount of information being requested. The fileserver 
  will then judge if the user has sufficient permission to view this 
  information and respond accordingly.

  [AI] James Lentini will add an argument indicating the amount of information 
       being requested to FEDFS_GET_NSDB_PARAMS and make the corresponding 
       updates to the response.

---

From: James Lentini <[email-masked]>
Date: Thu, 21 Jan 2010 17:33:34 -0500 (EST)

On Thu, 21 Jan 2010, James Lentini wrote:

<snip> 
>   [AI] James Lentini update IETF versions of NSDB and Admin drafts

The updated versions have been posted:

 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-05
 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-admin-04

Again, please read these over and send feedback on the mailing list.

<snip>
>        being requested to FEDFS_GET_NSDB_PARAMS and make the corresponding 

When I sat down to write this up, I took a slightly different 
approach. Rather than overloading the FEDFS_GET_NSDB_PARAMS procedure, 
I defined a separate procedure, FEDFS_GET_LIMITED_NSDB_PARAMS, for the 
above.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 21 Jan 2010 18:31:44 -0500

> I defined a separate procedure, FEDFS_GET_LIMITED_NSDB_PARAMS, for the 

How about just FEDFS_GET_NSDB_SECURITY_TYPE? I can't think of any other
parameter that would be of interest to someone who just wants to set a
junction.

Cheers
  Trond

---

From: James Lentini <[email-masked]>
Date: Fri, 22 Jan 2010 09:42:47 -0500 (EST)

On Thu, 21 Jan 2010, Trond Myklebust wrote:

> How about just FEDFS_GET_NSDB_SECURITY_TYPE? 

With the procedure's current definition, that name would work well.

> I can't think of any other parameter that would be of interest to 
> someone who just wants to set a junction.

There isn't anything else at the moment.

I've been pondering if the NSDB Container Entry (NCE), the LDAP DN 
that identifies the root of NSDB information, should be moved to the 
list of NSDB parameters. The intention was for there to be only one 
NCE for a given NSDB. Including the NCE in the NSDB parameters, rather 
a copy in each of the NSDB's FSNs, would make this clear. This would 
also decrease the size of the FSN data, which is a concern for some 
implementations. Opinions?

If there are other NSDB parameters of interest to someone who just 
wants to set a junction, should there be a single function to return 
all of them (e.g. FEDFS_GET_LIMITED_NSDB_PARAMS) or specific functions 
for each one (e.g. FEDFS_GET_NSDB_X where X = SECURITY_TYPE,...)?

-james