Subject: [nfsv4] [FedFS] Meeting Minutes, 07/09/2009

From: James Lentini <[email-masked]>
Date: Thu, 9 Jul 2009 15:03:54 -0400 (EDT)

FedFS Meeting Minutes, 07/09/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
James Lentini (NetApp)
Pavan Mettu (Sun)
Renu Tewari (IBM)
Rob Thurlow (Sun)
Sorin Faibish (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.

+ NSDB Draft Update

 - Review text of Section 7.1.2: 

   "If FSL records for this FSN still exist in the database 
   of the NSDB that receives this request, then this function 
   MUST return an error."

   James pointed out that there was nothing preventing an 
   administrator from accomplishing the above (deleting an FSN 
   with FSLs) by using a multi step process (delete each FSL 
   and then FSN). 

   Rob suggested that the requirement be a SHOULD and be on 
   the administrator, not the NSDB.

   We then discussed the standard LDAP behavior. A vanilla LDAP Directory 
   service does not enforce this rule. It allows a user to delete a 
   node in the LDAP DIT that has children. However, the children are also 
   automatically deleted as well. Some LDAP Directory implementations 
   allow for plugins to modify the directories behavior, so conceivably 
   the draft's text could be implement without a great deal of pain.

   Renu noted that the intention of the draft text was to require that 
   no dangling objects were left in LDAP. If the standard behavior is 
   compatible with this goal, there is no reason for this text.

   We agreed to remove this text and add text earlier in the document 
   (in the section describing general LDAP requirements) that states 
   the behavior we expect when deleting a node in LDAP.

 - Review need for Section 4: Interaction with client protocols

   Rob noted that Section 4 is problematic for two reasons: First, the 
   NFSv4 referral mechanisms in RFC 3530 is incomplete. The Noveck and 
   Burnett draft:

   http://tools.ietf.org/id/draft-noveck-nfsv4-referrals-00.txt

   has the complete description of v4 referrals. 

   (As an aside: Should we ask for an informational publication of the 
   Noveck/Burnett draft? [AI] Include this on next weeks agenda.)

   A second problem is that the text on other distributed filesystem 
   protocols is a claim, but the text does not explain how to fulfill 
   this claim.

   We agreed that the text in Section 4 was redundant with text in other 
   parts of the document and therefore should be eliminated.

 - Comments on NSDB draft

   In Section 3.2, the text states that the NSDB SHOULD ensure that no 
   two FSNs have the same FSN UUID. There is the same statement made 
   about FSLs. 

   Rob asked why this was a SHOULD and not a MUST?

   If this was a MUST, we would be requiring non-standard LDAP behavior. 
   In LDAP, Distinguished Names (DNs) must be unique, but the attribute of 
   an entry used to construct the DN is not fixed. Therefore, it would be 
   possible that two FSN (FSL) would have the same FSN UUID attribute value 
   but differ in some other attribute. However, the draft requires that an 
   FSN's (FSL's) DN include its UUID attribute and therefore, by implication 
   no two FSNs (FSLs) can share the same UUID.

   We agreed that a statement indicating that the DN requirements implies a 
   unique UUID be added to the draft.

+ Update on NFSv4 Multi-Domain Access (draft-adamson-nfsv4-multi-domain-access)

  Andy provided an overview his newly published draft.

  Andy folded in comments from James, Mike Eisler, and others. He 
  tightened up the text to focus on discussion of user ID (UID) mapping. 
  He did not include Group mapping or issues related to managing foreign users
  in this -0 version. Overall the draft is considerably shorter than the 
  pre-publication version he circulated with the group.

  Andy has a number of questions to ask about the direction of this 
  work at the WG meeting. He sees similarities between the management 
  of foreign users and the SLO/SLA agreements for routing messages between 
  autonomous systems. There may need to be a protocol for managing the 
  foreign UIDs. Do foreign users have permanent UIDs? What about users that
  leave the organization?

  Andy pointed out that addressing these security issues will benefit 
  federated filesystem usage. He noted that AUTH_SYS, the predominant 
  security flavor in use today, was a poor match for a federated 
  filesystem.

---

From: James Lentini <[email-masked]>
Date: Fri, 10 Jul 2009 11:18:39 -0400 (EDT)

> FedFS Meeting Minutes, 07/09/2009
<snip> 
>    service does not enforce this rule. 

I misspoke. After the meeting, the idea occurred to me that the behavior 
I was familiar with was the by-product of the LDAP client I was using 
(Apache Directory Studio) and not the directory. To test this 
hypothesis, I tried deleting an internal entry with the ldapdelete(1) 
command line tool. Sure enough, it refused. I did some digging in the 
LDAP specs and found that the LDAP protocol only allows leaf entries 
to be deleted. Therefore, I've amended the text in the draft I'll 
post shortly as follows:

   If the FSN entry being deleted has child FSL entries, this function 
   MUST return an error.  This ensures that the NSDB will not contain 
   any orphaned FSL entries.  A compliant LDAP implementation will 
   meet this requirement since Section 4.8 of [RFC4511] defines the 
   LDAP delete operation to only be capable of removing leaf entries.