Subject: [nfsv4] [FedFS] Meeting Minutes, 4/15/2010

From: James Lentini <[email-masked]>
Date: Thu, 15 Apr 2010 15:17:57 -0400 (EDT)

FedFS Meeting Minutes, 4/15/2010
--------------------------------

Attendees
---------

Andy Adamson (NetApp)
Matt Benjamin
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Paul LeMahieu (EMC)
Peter Staubach (EMC)
Chris Stacey (EMC)
Robert Thurlow (Oracle)

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.

+ Admin Protocol: Error Codes

  Chuck Lever has suggested additional error codes for the 
  Admin protocol:

  FEDFS_ERR_NAMETOOLONG: For when a component or pathname is too long

  FEDFS_ERR_BADNAME: For when a pathname component has an invalid characters

  FEDFS_ERR_LOOP: For when too many symbolic links were encountered 
                  resolving a pathname

  He was building the logic that manages the paths in his prototype 
  and identified the above errors as missing.

  James Lentini noted that NFSv4 has NAMETOOLONG and BADNAME.

  Chuck Lever noted that the Admin protocol already has FEDFS_ERR_INVALID 
  that could cover these cases. It would be nice to have something more 
  specific though.

  Chuck Lever noted that FEDFS_ERR_BADCHAR exists, but is intended for UTF-8 
  errors (unlike the proposed FEDFS_ERR_BADNAME).

  We agreed that the next Admin draft will include these error codes.

  James Lentini asked if improvements should be made to the way errors are 
  listed in the Admin draft. Each procedure description lists what errors 
  the procedure can return, but there is no list at the end of the 
  description.

  We discussed if a "MAY return list" or "MUST NOT return list" would be 
  useful. We decided that a "MAY return list" would be useful. These 
  will be added in the next Admin draft revision.

+ Admin Protocol: Junction Size

  There is a proposal to place the junction's NCE information in the 
  NSDB's root DSE. We review the compatibility of this approach with 
  existing LDAP directory implementations.

  We have not been able to configure this in OpenDS yet.

  Matt Benjamin researched if this was possible with Active Directory. 
  He has not found documentation in MSDN that suggests this is possible.

  Chuck Lever asked what LDAP directory implementations we're interested in? 

  To date, we've ensured that the LDAP mechanisms used by FedFS are (1) 
  standards based and (2) widely implemented. For (2), we've looked at 
  OpenLDAP, OpenDS, Active Directory, and other implementations.

  Chuck Lever requested that Red Hat 389 be included in this list. We 
  agreed and noted that it was one of the directory implementations we've 
  tested on in the past.

  We discussed if the LDAP RFCs require directory implementations to be 
  able to modify the root DSE. We haven't found a conclusive statement 
  on this.

  We discussed if other applications require modifications to the root 
  DSE. We are unaware of any.

  We will continue to investigate this approach. If we discover that 
  this solution does not meet (1) or (2) above, we believe that there 
  other approaches to storing the NCE information in LDAP that will 
  accomplish the same goal.

+ Admin Protocol: International Strings

  We reviewed the mailing list discussion.

  James Lentini had interpreted the conclusion to be that strings would 
  be UTF-8. Others had come away with a different understanding.

  Craig Everhart reiterated that FedFS would follow the NFSv4 precedent
  on this issue.

  Chris Stacy noted that UTF-8 is a popular common denominator and its 
  use is mandated by IETF.

  Trond Myklebust pointed out that file path names have dependencies on the 
  file system.

  Trond does not see consensus yet on the topic of domain name formats (IDN). 
  He sees the string prep discussions as essentially concluded and only 
  discussing details.

  What should be done in the FedFS documents? Should the FedFS documents depend 
  on NFSv4? 

  We were unsure. The FedFs document could make a normative reference to 
  rfc3530bis. This would ensure that the NFSv4 discussion would conclude 
  before the FedFS specifications were complete.

  One problem is that stringprep is deprecated. This is an IETF issue.

  Discussions on domain names are in progress. We will wait for their 
  resolution.

+ Admin Protocol: Pathnames

  We reviewed the mailing list discussion.

  There was discussion about adding FedFS administration procedures to 
  the NFSv4 protocol. We noted that there are opinions on both sides of 
  this issue.

  Within the Admin protocol, there is a proposal to associate a type 
  with the pathname parameter. There would be an "ADMIN" type for a 
  server local path, an "NFSv4" type for a path relative to the NFSv4 
  pseudo-root, and additional types could be added.

  Rob Thurlow likes type approach. He is interested in one type: NFSv4. 
  He likes the idea that other types could be defined in the future.

  Chuck is mostly interested in the server absolute path type. 

  For the June Bake-a-thon, Rob Thurlow suggested that the Admin 
  prototypes only support one type. Chuck suggested that the admin-04 
  draft's protocol, which does not contain the type concept, be used.
  There was consensus that the June Bake-a-thon prototypes would target 
  the admin-04 draft.

  We agreed that the next Admin draft would include the path name type.

  Chuck Lever suggested a "path type not supported" error code be added.
  We agreed to add this.

  Including the FedFS admin operations in NFSv4 will require broader 
  discussion.

+ Next Meeting

  Our next call will be in two weeks on April 29.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Apr 2010 18:03:43 -0500

> FedFS Meeting Minutes, 4/15/2010

I'm sorry I missed this meeting.  I've nothing to report re: OpenDS and
the root DSE.

>   be UTF-8. Others had come away with a different understanding.

Dave Noveck is drafting text.

I suspect (hope!) that the consensus we'll reach for _filenames_ is that
NFSv4 itself will treat filenames as opaque (modulo excluding ASCII '/'
and NUL byte values) but that _filesystems_ SHOULD (not MUST) treat them
as UTF-8, SHOULD reject byte sequences that are not valid UTF-8, and
SHOULD be normalization-insensitive (but MAY normalize on CREATE).
Clients SHOULD send UTF-8 only.  We may also want to have fs attrs to
indicate that some filesystems deal in non-Unicode codesets to
facilitate interop.  But in the end the real problem is that real-world
clients lose codeset information at the system call boundary (or
equivalent), and they're not going to be doing codeset conversions at
that point any time soon, which means that there will always be
potential for codeset ambiguity.

>   Craig Everhart reiterated that FedFS would follow the NFSv4 precedent

That precedent is incomplete.

>   Chris Stacy noted that UTF-8 is a popular common denominator and its 

UTF-8 is going to have to be what we do for I18N interop, but there's
much legacy content that we should not turn our backs on.  A just-send-8
_option_ is required.

>   Trond Myklebust pointed out that file path names have dependencies on the 

Right!

>   Trond does not see consensus yet on the topic of domain name formats (IDN). 

Indeed, we're not there, but this is separate from I18N for pathnames.

However, I think we're going to have to pick from very few options for
NFSv4's (and ADMIN's) domainname slots.  Really, there's only three
options, and none seems to have any significant adavantage over the
others.

>   He sees the string prep discussions as essentially concluded and only 

For filenames, I think that's right.

>   What should be done in the FedFS documents? Should the FedFS documents depend 

Yes.

>   before the FedFS specifications were complete.

Yes.

>   One problem is that stringprep is deprecated. This is an IETF issue.

IMO we should not depend on stringprep for anything in NFSv4.
Stringprep is not a good fit for NFSv4.  We do need to depend on IDNA
for NFSv4's domainname slots; IDNA is on the RFC-Editor Queue, so that's
not a problem.

>   He likes the idea that other types could be defined in the future.

I agree.

>   Chuck is mostly interested in the server absolute path type. 

That's fine.  To use the "ADMIN" type the user will have to have an idea
of what the local filesystem namespace looks like on the server.  I
suspect that's not a big deal, but it'd be nice if the user could just
use NFSv4 (or CIFS) to browse it.

Clients will need to know which types the server understands.  That's
not a big deal, I'm sure.

Nico
--