Subject: [nfsv4] FedFS Meeting Minutes, 03/05/2009

From: James Lentini <[email-masked]>
Date: Thu, 5 Mar 2009 15:55:38 -0500 (EST)

FedFS Meeting Minutes, 03/05/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Renu Tewari (IBM/ARC)
Robert Thurlow (Sun)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Andy Adamson (NetApp)

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.

+ Working Group Recharter

  An update to the NFSv4 working group charter has been proposed. 
  The proposed update includes federated file systems and dates for 
  the FedFS drafts to move to last call.

  While the dates look aggressive, we believe that they are 
  achievable. The requirements document in particular is ready for 
  the March review. 

  It would be desirable to align a testing event with these dates or 
  align the dates with a testing event so we have some feedback from 
  multiple implementations.

+ Review Action Items

  [AI] James Lentini will investigate if including a copyright and 
       license on code is acceptable

  We have two roughly opposite requirements:

  Code needs to be BSD licensed to include a code sample in the IETF 
  documents.

  Code needs to be dual GPL/BSD to meet the requirements of all the 
  organizations that would consider contributing to the open source 
  NSDB project.

  While some licensing scheme might be able to satisfy both these 
  requirements (e.g. having one version of the code for the 
  IETF documents and another for the open source project), we decided to 
  take a simpler approach. Instead of including code in the NSDB 
  protocol document to illustrate the different types of errors, we will 
  add a written description of each operation and the types of errors it 
  can return. In the end, this will be a better approach as it will keep 
  the implementation details out of the protocol documents.

+ Report from Connectathon and FAST'09 BOF

  Rob gave a presentation at Connectathon. There were several 
  comments. One interesting question that came up was how to 
  boot strap FedFS in an existing environment.

  There was a FedFS BOF at FAST. We had about 20 attendees. We had some 
  questions on how to map user identities across domains. Andy Adamson 
  has investigated this in the past. Andy offered to share some pointers 
  to documents describing how to map map foreign users into a file systems
  UID/GID space. 

  We also discussed how RSYNC handles ACLs.

  [AI] Renu Tewari will investigate how rsync handles ACLs

+ UUID Version

  RFC 4122 describes multiple UUID formats. 

  James proposed explicitly specify the use of one of these versions.

  Craig pointed out that there is a version field in the UUID 
  so different versions may still be unique. However, version 5 UUIDs
  are built from a custom namespace. If two different implementations 
  used version 5 UUIDs (thus the version bits would be the same) and 
  did not attempt to coordinate, it is unclear if the results would 
  still be unique.

  [AI] James Lentini to write up formal proposal for how to use RFC 4122 UUIDs

+ Admin Document Review

  Changes to review: 

	- IPR text updated

	- Introduction updated to refer to other documents (e.g. requirements)

	- XDR updated for compatibility with rpcgen

	- ONC RPC protocol's FSN UUID size were 512 bits, 
          RFC 4122 UUID's are 128 bits

	- host and path XDR types made variable length

	- Format of UUID, host name, and pathname specified
	  more exactly

	- Security considerations added

	- IANA considerations updated

	- Reference updated (normative versus informational)

	- Acknowledgments added

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Fri, 6 Mar 2009 12:00:01 -0500

NFSv4 name to UID/GID in a multi realm environment

The topic of ACE and RPC credential name to UID/GID mapping in a cross
realm environment came up at the FAST FedFS BoF. I did some work in
this area when I was at CITI, and have a power point slide describing
the problem and the Linux proto-type implementation.

This problem arises as a name space crosses UID/GID mapping
administrative realms, and so becomes of interest as the FedFS work
progresses.

There are notes associated with many of the slides which helps
understanding given the lack of a presenter :) The slides can be found at:

http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.ppt

Nico Williams has an expired draft that addresses these issues.

draft-williams-nfsv4-ace-mapping-01

-->Andy

On Thu, Mar 5, 2009 at 3:55 PM, James Lentini <[email-masked]> wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: James Lentini <[email-masked]>
Date: Thu, 12 Mar 2009 09:55:08 -0400 (EDT)

> FedFS Meeting Minutes, 03/05/2009
<snip> 
>   [AI] James Lentini to write up formal proposal for how to use RFC 4122 UUIDs

Following up on my action item from last week:

I would propose adding the following text (prefixed by a "+") to the 
NSDB document on page 7:

   FsnUuid:  a 128-bit UUID (universally unique identifier), conforming
      to [RFC4122], that is used to uniquely identify an FSN.  An NSDB
      SHOULD ensure that no two FSNs it stores have the same FsnUuid. 
+     To minimize the probability of two UUIDs colliding, a consistent 
+     procedure for generating UUIDs SHOULD be used throughout the 
+     federation. Within the federation, UUIDs SHOULD be generated 
+     using the procedure described for version 1 of the UUID variant
+     specified in [RFC4122].

I believe this should be a recommended rather than a required behavior 
because the NSDB will be capable of eliminating UUID collisions if 
they do occur.