Subject: [nfsv4] [FedFS] meeting agenda (9/3)

From: James Lentini <[email-masked]>
Date: Wed, 2 Sep 2009 16:57:10 -0400 (EDT)

Tomorrow's proposed agenda is below. Please let me know if you would 
like to add anything.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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 will republish the NSDB draft with these changes on 8/20 

 - James Lentini will send the updated NSDB draft for LDAP expert review

 - James Lentini will checkin these changes to the SourceForge project on 8/20

+ Austin NFS Bake-a-thon

  Any announcements or status updates

+ FSL Pathname Format

  Trond Myklebust pointed out that the format of the fedfsNfsPath is 
  ambiguous. The fedfsNfsPath is described as:
  "The path component of an FSL encoded as a UTF-8 string."
  One interpretation of this is that the string contains the entire 
  path including pathname component separators (e.g. "/" or "\").

  This is in contrast to the NFS practice of not specifying an 
  explicit path component separator. The fs_locations and fs_locations_info 
  attributes represent pathnames using an array of path components. 
  Specifically, a pathname is encoded in an NFSv4 pathname4, an XDR encoded 
  variable length array of variable length opaque data.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Sep 2009 16:07:01 -0500

>   variable length array of variable length opaque data.

This being LDAP, I think a string with '/' will be much simpler.

Please see my comments (just posted) on the I-D.

I just checked with a local LDAP expert and he confirms my suspicion
that it's not correct to specify that o=fedfs (or whatever) be part of
the DN of every FedFS object.  The lack of search examples is definitely
a problem for me.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 3 Sep 2009 09:53:51 -0400 (EDT)

> This being LDAP, I think a string with '/' will be much simpler.

Correct, but a string with '/' as the path delimiter is more 
restrictive that what NFS allows for path components.

> the DN of every FedFS object.  The lack of search examples is definitely

I would agree except for the fact that the NSDB is not a general 
purpose LDAP database. The NSDB is an application specific directory 
that stores only FedFS records (see discussion at the end of section 
4.1). For this reason, it is appropriate to use a well known root DN 
to simplify the operation of the NSDB, fileservers, and administrative 
tools.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 03 Sep 2009 10:13:02 -0400

> restrictive that what NFS allows for path components.

The other argument is that FedFS is supposed to work with other
networked filesystems (the main one being CIFS) too...

Cheers
  Trond

---

From: James Lentini <[email-masked]>
Date: Thu, 3 Sep 2009 10:25:20 -0400 (EDT)

> networked filesystems (the main one being CIFS) too...

That would be another concern, although I would expect a new LDAP 
object class (maybe fedfsSmbFsl) along with SMB/CIFS specific 
attributes (maybe fedfsSmbPath).

-james

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 11:00:01 -0500

> networked filesystems (the main one being CIFS) too...

IIRC Windows treats '/' and '\' restrictively as path component
separators.  Unix does that only for '/'.  '/' seems to be near enough
to universally special.  But that's all irrelevant because: you can
always provide an escaping mechanism in the NSDB (in my previous post I
suggested the LDAP binary encoding option and NULs for path component
separators; other schemes are probably feasible).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 10:55:15 -0500

> restrictive that what NFS allows for path components.

Understood.  You could also use the binary option and use NULs as
separators.  That'd be better, though it would make it harder to use
LDAP command-line tools.  Unfortunately you could not use multi-valued
attributes, as LDAP quite explicitly treats them as unordered sets
(RFC4511, section 4.1.7).

You could also have an object for every path name component, then chain
them together into paths.  That'd be overkill, and very hard to use.

> to simplify the operation of the NSDB, fileservers, and administrative 

It is one thing if a directory operator decides to segreate all NSDB
objects into o=fedfs.  It is another thing altogether for the WG to
decide it.  IMO it's inappropriate for the WG to make this decision.

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Thu, 3 Sep 2009 12:49:59 -0400

> decide it.  IMO it's inappropriate for the WG to make this decision.

If it's a necessary part of a query, then it has to be part of the standard.

The decision or caprice of a local directory operator must not make
it impossible (or even inefficient) for an arbitrary client to find an FSN
record inside an NSDB.

The fact that LDAP is involved here should be far beneath the surface.
The operator is running an NSDB, not an arbitrary LDAP service.  I'm
struggling to think of a use case where any operator would care about
(let along change) the o attribute of NSDB-related records.  That would
be like a DNS operator deciding he didn't like "A record" being encoded
as 1 and changing it to something else.

-Dan

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 11:50:32 -0500

> If it's a necessary part of a query, then it has to be part of the standard.

Again, if you use scope=sub then it (o=whatever) need not be part of the
search filter nor base DN, therefore it need no be part of the standard.

Now, perhaps you have a good reason to reject scope=sub searches, in
which case scope=one searches with o=whatever in the base DN would be
justified.  I can't think of a good reason to reject scope=sub searches
though.  Can you?  What am I missing?

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 3 Sep 2009 13:25:06 -0400 (EDT)

> separators; other schemes are probably feasible).

I've come to the conclusion that the best way to support the full set 
of characters allowed in NFS path components is to define the 
fedfsNfsPath as a binary string that contains the XDR encoded 
pathname4 value.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 12:26:21 -0500

> fedfsNfsPath as a binary string that contains the XDR encoded 

That works.  A binary string using NULs as separators would also work,
but it's likely that implementors will already have the necessary XDR
code for what you propose.