Subject: Re: [nfsv4] Second request for LDAP expert review of FedFS LDAP object identifier descriptors

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 2 Sep 2009 11:25:26 -0700

On Aug 20, 2009, at 1:36 PM, James Lentini wrote:

>
> Hello,
>
> In accordance with BCP 64 (RFC 4520), we request an expert review of
> the FedFS LDAP object identifier descriptors defined in
>
> NSDB Protocol for Federated Filesystems
> http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-03.txt
>
> As suggested in the previous review, we have updated our FedFS LDAP
> schema to use the common prefix "fedfs" for all object identifier
> descriptors.
>
> Once again we look forward to your comments and feedback on this
> request.
>
> -james

James,

As the assigned "expert" for the LDAP parameter registries, I  
tentatively approve your request conditional on IESG approval of  
document as a Standard Track RFC.   I note that the request is missing  
information concerning the usage information (attribute type or object  
class) for each descriptor (see Section A.4 of BCP 64).  You should  
update the template in the I-D before it's sent to IESG for  
consideration (and initial IANA review).

No action is required of IANA at this time.  IANA should process the  
registration request as part of its normal pre-RFC publication  
processing.

Regards, Kurt

>
> --
> James Lentini | NetApp | 781-768-5359 | [email-masked]
>
>
> -------------------------------------------------------------------
>
>   Subject:  Request for LDAP Descriptor Registration
>   Person & email address to contact for further information:  See
>      "Author/Change Controller"
>   Specification:  draft-ietf-nfsv4-federated-fs-protocol
>   Author/Change Controller:
>
>   James Lentini
>   NetApp
>   1601 Trapelo Rd, Suite 16
>   Waltham, MA  02451
>   US
>   Phone: +1 781-768-5359
>   Email: [email-masked]
>
>   Craig Everhart
>   NetApp
>   7301 Kit Creek Rd
>   Research Triangle Park, NC  27709
>   US
>   Phone: +1 919-476-5320
>   Email: [email-masked]
>
>   Daniel Ellard
>   BBN Technologies
>   10 Moulton Street
>   Cambridge, MA  02138
>   US
>   Phone: +1 617-873-8000
>   Email: [email-masked]
>
>   Renu Tewari
>   IBM Almaden
>   650 Harry Rd
>   San Jose, CA  95120
>   US
>   Email: [email-masked]
>
>   Manoj Naik
>   IBM Almaden
>   650 Harry Rd
>   San Jose, CA  95120
>   US
>   Email: [email-masked]
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.1
>   Descriptor (short name):  fedfsUuid
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.2
>   Descriptor (short name):  fedfsNetAddr
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.3
>   Descriptor (short name):  fedfsFsnUuid
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.4
>   Descriptor (short name):  fedfsNsdbName
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.5
>   Descriptor (short name):  fedfsFslUuid
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.6
>   Descriptor (short name):  fedfsFslHost
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.7
>   Descriptor (short name):  fedfsFslTTL
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.8
>   Descriptor (short name):  fedfsNfsPath
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.9
>   Descriptor (short name):  fedfsNfsMajorVer
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.10
>   Descriptor (short name):  fedfsNfsMinorVer
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.11
>   Descriptor (short name):  fedfsNfsCurrency
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.12
>   Descriptor (short name):  fedfsNfsInfo
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.13
>   Descriptor (short name):  fedfsNfsFlags
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.14
>   Descriptor (short name):  fedfsNfsValidFor
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.15
>   Descriptor (short name):  fedfsAnnotation
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.16
>   Descriptor (short name):  fedfsDescr
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.1001
>   Descriptor (short name):  fedfsFsn
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.1002
>   Descriptor (short name):  fedfsFsl
>
>   Object Identifier:  1.3.6.1.4.1.31103.1.1003
>   Descriptor (short name):  fedfsNfsFsl

---

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

On Wed, 2 Sep 2009, Kurt Zeilenga wrote:

> As the assigned "expert" for the LDAP parameter registries, I tentatively
> approve your request conditional on IESG approval of document as a Standard
> Track RFC.   I note that the request is missing information concerning the
> usage information (attribute type or object class) for each descriptor (see
> Section A.4 of BCP 64).  You should update the template in the I-D before it's
> sent to IESG for consideration (and initial IANA review).
>
> registration request as part of its normal pre-RFC publication processing.
> 
> Regards, Kurt

Thank you Kurt. I will add the usage information for each descriptor 
before this draft is sent to the IESG.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Sep 2009 15:48:12 -0500

- Why is the o=fedfs part necessary?  Why can't a client know to do a
   sub scope search from a specific base DN?

   How is a client expected to search for these?  Specifically: with
   what scope, and with what search filters?

 - Why is there a need to have o=fedfs in admin user names?  Or is that
   just an example?

 - In the LDAP examples, could you use example domainnames, such as
   foo.example?

 - Could you add examples where you hook an FSN into a particular path
   in a namespace?

 - Could you add examples for how to search for the root of a namespace?

 - Why is the NFS minor version not a range of versions spoken by the
   server?  Doesn't NFSv4 negotiate versions anyways?  If so, why is
   this needed at all?  Is the NFSv4 minor version negotiation subject
   to downgrade attacks?

 - What is the relationship of this document to draft-ietf-nfsv4-
   federated-fs-dns-srv-namespace?

Cheers,

Nico
--

---

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

Hi Nico,

Thanks for the comments. Replies below:

>    sub scope search from a specific base DN?

The client (NFS server) needs a specific base DN to search from. For 
that reason, the NSDB service uses root DN of o=fedfs.

>    what scope, and with what search filters?

These search parameters are detailed in section 5.2.1. 

>  - Why is there a need to have o=fedfs in admin user names?  Or is that

The recommended LDAP admin DN is cn=admin,o=fedfs. The text states: 

   It is permitted to use a different DN (or add
   additional privileged users) but if a different DN is used then every
   admin entity that needs to modify the contents of the database or
   view privileged information must be made aware of the new DN.

>  - In the LDAP examples, could you use example domainnames, such as

Which examples are you referring to? There are some in section 3 and 
others in section 5.

>  - Could you add examples where you hook an FSN into a particular path

Section 3 describes how to do this. If one of the steps is unclear, 
let me know.

>  - Could you add examples for how to search for the root of a namespace?

The client would discover the root of the namespace using the 
procedure described in:

 http://tools.ietf.org/id/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt

The process isn't really a search. The client queries DNS for the 
relevant information.

This document is about how the NSDB is organized and how fileservers 
and administrators interact with it.

>    server?  

For a single FSN, there can be multiple FSLs. If the fileset is 
exported via different versions (or different protocols) each can be 
described with a unique FSL.

>    Doesn't NFSv4 negotiate versions anyways?  If so, why is
>    this needed at all?  

The NFS client never sees this information directly. The version 
information may be used by the NFS server to prepare the fs_locations 
or fs_locations_info. There are no restrictions on how the NFS server 
decides to return NSDB information to the client.

>    Is the NFSv4 minor version negotiation subject
>    to downgrade attacks?

I'm not sure what you are thinking of here. Can you give an example?

>    federated-fs-dns-srv-namespace?

The two documents do not have any dependencies on one another. This 
document describes the NSDB and the DNS SRV document describes the 
procedure a client may use to locate the root of its namespace.

---

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

> that reason, the NSDB service uses root DN of o=fedfs.

Not so.  They can simply do scope=sub searches and specify objectClass
in the filter -- your new classes are structural classes, after all.

There's no need to dictate where these objects must live.

> These search parameters are detailed in section 5.2.1. 

Ah.  I recommend that you drop the o=fedfs part and set scope to sub.
You'll get the same results, minus the obnoxious o=fedfs bit.  And you
could then still use o=fedfs if you like.

> The recommended LDAP admin DN is cn=admin,o=fedfs. The text states: 

No one is going to use a shared admin DN.

> Which examples are you referring to? There are some in section 3 and 

Any examples that involve the fedfsNsdbName attribute, or any other
attribute whose value(s) is(are) supposed to be DNS domain names.

> Section 3 describes how to do this. If one of the steps is unclear, 

Yes, it's unclear.  Please provide examples.

I should also add these comments:

 - Why UUIDs?

 - Do you have examples of "consistent procedure for generating UUIDs"?

> and administrators interact with it.

So there's no root in the NSDB.  Instead root servers designated by DNS
SRV RRs happen to be a path into an NSDB.  Thanks.  That's good.

Do see my comments on draft-ietf-nfsv4-federated-fs-dns-srv-namespace,
specifically the need to distinguish the ROOT FH of a server designated
as root server from the root of a namespace.

The next question will then be: how are FSNs from the NSDB mounted onto
/.nfsv4root (or whatever) on the root servers.

> described with a unique FSL.

Ah!  I'd failed to understand that.  That helps.

> I'm not sure what you are thinking of here. Can you give an example?

Never mind.

> procedure a client may use to locate the root of its namespace.

Well, I think this document has a soft dependency on that one.  You can
get by without a blocking, normative reference, but it'd be nice if
there was a section in this I-D describing how the two go together.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 3 Sep 2009 16:33:49 -0400 (EDT)

Replies below:

> There's no need to dictate where these objects must live.

Where is it stated that the search base is optional? 

There is no mention of this in section 4.5 of RFC 4511, which 
describes the search operation.

The LDAP tools I've used either require a search base or use a default 
value (OpenLDAP's ldapsearch pulls a value out of 
/etc/openldap/ldap.conf regardless of the particular directory being 
searched).

> No one is going to use a shared admin DN.

True. The admin DN will have a different password for each 
administrative domain. As I said, the draft doesn't restrict the admin 
DN in any way. It only gives a recommended default.

> attribute whose value(s) is(are) supposed to be DNS domain names.

There are no examples that meet that criteria in section 3. I'll 
change the examples in section 5 to use actual DNS domain names and 
give specific values for the other fields (FSNUUID, HOST, ...) along 
with my next set of proposed changes.

> Yes, it's unclear.  Please provide examples.

OK, I can add some specific examples.

> I should also add these comments:

The FSN and FSL objects needs to be identifiable throughout the 
federation.

>  - Do you have examples of "consistent procedure for generating UUIDs"?

The next sentence after the one your quote gives the procedure:

       Within the federation, UUIDs SHOULD be generated using the 
       procedure described for version 1 of the UUID variant 
       specified in [RFC4122].
 
> /.nfsv4root (or whatever) on the root servers.

An administrator create junctions on the root fileservers. These 
junctions store FSN information which the fileserver then resolve to 
FSLs using the NSDB.

There is a description of this in section 3. 

> Well, I think this document has a soft dependency on that one.  You 
> can get by without a blocking, normative reference, but it'd be nice 
> if there was a section in this I-D describing how the two go 
> together.

Yes, I'll included it as an informational reference.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 16:19:34 -0500

> describes the search operation.

I never wrote that the search base is optional.

The point is that you should not need to add o=fedfs to whatever would
have been your base DN in the first place.

I think the onus is on you to justify scope=one and adding o=fedfs to
the base DN.

Oh, and I just noticed this:

"
   Given the above configuration guidelines, an NSDB SHOULD be
   constructed using a dedicated LDAP directory.  Separate LDAP
   directories may be used for other purposes, such as storing user
   account information.  By using an LDAP directory dedicated to storing
   NSDB records, there is no need to disturb the configuration of any
   other LDAP directories that store information unrelated to an NSDB.
"

Why?  Why couldn't I use an existing directory server, say, using a
container with DC=foo,DC=example as the base DN?

In any case, that explains the zeal for o=fedfs.

The example search in the I-D is:

ldap://nsdb.example.com/fsnUuid=FSNUUID,o=fedfs??one?(objectClass=fedfsFsl)

If you remove the "NSDB SHOULD be constructed ... dedicated directory"
part and if you allow scope=sub searches and forget o=fedfs, then in the
real world the example would look like:

ldap://nsdb.example.com/fsnUuid=FSNUUID,o=fedfs,dc=foo,dc=example??one?(objectClass=fedfsFsl)

Which, with scope=sub and no o=fedfs becomes:

ldap://nsdb.example.com/fsnUuid=FSNUUID,dc=foo,dc=example??sub?(objectClass=fedfsFsl)

(Also, note that you should NOT use "example.com" in your examples.  The
IETF has set aside the "example" TLD for this.  So use "foo.example", or
"xyz.example", and so on.)

I also just noticed:

"
   It MUST be possible for the anonymous (unauthenticated) user to
   perform LDAP queries that access the NSDB data.
"

Why?  Servers must be able to search the DS for these objects, clearly,
as must admins, but why anyone else?  IMO this should be a SHOULD or a
MAY, not a MUST.

> DN in any way. It only gives a recommended default.

It should not even do that!  Default admin names (and worse: passwords)
are a bad idea.

> The FSN and FSL objects needs to be identifiable throughout the 

But object DNs will be unique as it is anyways.  UUIDs (or whatever you
use for the RDNs of these objects) need only be unique within their base
DN.

What you should do is say that these objects must have a CN that is
unique to the rest of their DN.  And then recommend the use of UUIDs
(since these RDNs are not necessarily meaningful -- all the meaning is
in the objects' other attributes) as CNs.

>        procedure described for version 1 of the UUID variant 

D'oh.  Right.

> There is a description of this in section 3. 

I could go read it.  But I really want a ternary answer (sorry, my
bandwidth is limited) to this question: where is the "mount" of some FSN
unto /.nfsv4root (or whatever) on root servers specified?  Possible
answers: the local admin on the root servers, the NSDB admin (and the
root servers know how to search for the root FSN), or either.

Armed with that answer I'll be able to read that section to confirm.

> Yes, I'll included it as an informational reference.

Excellent.  Thanks.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Tue, 8 Sep 2009 10:48:26 -0400 (EDT)

I've removed [email-masked] since I that list is for expert 
review requests. Replies below:

> container with DC=foo,DC=example as the base DN?

The fileserver isn't able to discover the NSDB's DIT structure. Let me 
explain.

A fileserver uses an NSDB to map an FSN to FSLs. An FSN is defined as 
a (nsdb-name, uuid) pair. So the fileserver knows the DNS/IP of the 
FSN's NSDB, but not the DIT structure. By using a well defined DIT 
structure (o=fedfs) it is easy for the fileservers to search the NSDB 
using LDAP. If each NSDB administrator was able to arbitrarily define 
their DIT structure, a fileserver would not know the search base.

> "xyz.example", and so on.)

example.com is perfectly fine and is reserved for this purpose. See 
RFC 2606 (BCP 32).

> as must admins, but why anyone else?  IMO this should be a SHOULD or a

The fileservers search the NSDB as unprivileged users. Only the 
administrator knows the NSDB's privileged LDAP user DN and password.

I'll make a note to clarify the text on this point.
 
> It should not even do that!  Default admin names (and worse: passwords)

There is no default password. That is why having a default admin name 
doesn't add any real value. I'll remove the suggested default admin 
name in the next version.

> Armed with that answer I'll be able to read that section to confirm.

The protocol supports arbitrary junction pathnames so there is no need 
to define a reserved junction pathname like the one you mention above.

An administrator of the root NFS server would create junctions in its 
namespace using the ONC RPC administrator protocol defined in:

 http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-admin-02.txt

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 10:26:23 -0500

> review requests. Replies below:

That's exactly what you need here.  Of course, I was never subscribed to
that lsit, so my posts weren't seen by it :(

> > I never wrote that the search base is optional.

Incidentally, the base DN is not optional, but can be the empty string.
I should have mentioned that earlier.

> The fileserver isn't able to discover the NSDB's DIT structure. Let me 

The base DN has to be configured or derived from a domain name by
convention (e.g., like Active Directory does, where each DNS label
becomes a DC, so that foo.example becomes DC=foo,DC=example).  You can't
declare a globally well-known base DN that everyone must use.  You
simply cannot.

> their DIT structure, a fileserver would not know the search base.

See above.

What you propose is totally inappropriate.  Your desire to avoid having
to configure a base DN has led you to the wrong solution.

> I'll make a note to clarify the text on this point.

Who says that servers must be as anonymous though?  Why can't the
servers have credentials for machine accounts that are privileged to
read these objects?

> name in the next version.

You MUST NOT even "RECOMMEND" an admin DN.

> to define a reserved junction pathname like the one you mention above.

I disagree.  See the thread on the NFSv4 DNS SRV RR document.

>  http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-admin-02.txt

If one would administer junctions locally on each server, then what does
one need the NSDB for?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 10:39:13 -0500

I looked, and the best way to discover the base DN appears to be this:

  Discover LDAP first (DNS SRV RR query for _ldap._tcp....), then get
  the root DSE (scope=base, base DN="", filter="") to get the
  defaultNamingContext, whose value will be the DN that should be used
  as a base DN.

There are probably other ways, but this one shouldn't fail.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Tue, 8 Sep 2009 13:01:19 -0400 (EDT)

On Tue, 8 Sep 2009, Nicolas Williams wrote:

> That's exactly what you need here.  Of course, I was never 
> subscribed to that lsit, so my posts weren't seen by it :(

Of course review by LDAP experts is appreciated. AFAIK, 
[email-masked] is only for requests for reviews as described 
in RFC 4520 (BCP 64).

> declare a globally well-known base DN that everyone must use.  You

As you say, there are conventions for configuring the base DN. You 
cite one convention (dc=foo,dc=example), but there are others (o=foo 
and o=foo,c=US). They are all just conventions. Any format is equally 
valid. To suggest otherwise is incorrect.

> What you propose is totally inappropriate. Your desire to avoid 
> having to configure a base DN has led you to the wrong solution.

The base DN is configured. 

> servers have credentials for machine accounts that are privileged to 

Fileservers are not required to be anonymous, but they are allowed to 
be anonymous.

The fileservers may not have any association with the NSDB they query. 
For example, see Figure 2 (Page 10) in:

 http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-reqts-03.txt

The fileserver X must query NSDB Y to resolve an FSN. Fileserver X and 
NSDB Y are in different administrative domains. It would be 
impractical and undesirable to require the administrators of ALPHA to 
alert the administrators of BETA every time a fileserver was added or 
removed.

> You MUST NOT even "RECOMMEND" an admin DN.

As I said, I will propose that text is removed in the next draft.

> If one would administer junctions locally on each server, then what does

The NSDB maps an FSN to FSL. This allows the administrator of the FSL 
to change its location and parameters without updating all the 
fileservers containing the junction.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 12:08:26 -0500

> [email-masked] is only for requests for reviews as described 

Well, RFC4520 doesn't say where the review will take place, only that
requests should be sent there.  Presumably reviews should take place on
that list.  The fact that that list is subscriber-posts-only is
obnoxious.  I think I'll subscribe and send a post about this.

In the mean time, I think you should ask your AD about where the review
should take place -- if nothing else you should want to know (yes, I
want to know too, and I could ask the AD myself).

> valid. To suggest otherwise is incorrect.

See my other post.  You can look at the defaultNamingContext operational
attribute of a DS' root DSE.

> The base DN is configured. 

You've _specified_ what it must be.  That's the problem.  If it were
merely configurable then we'd not be having this discussion (I might
have pointed out that there's a way to _default_ the base DN by looking
up the defaultNamingContext root DSE attr, but I'd have been happy
enough).

> Fileservers are not required to be anonymous, but they are allowed to 

That's fine.  What is NOT fine is mandating that NSDB data be readable
by anonymous principals.  That may be something that you want to
RECOMMEND, but certainly not REQUIRE.

> The fileservers may not have any association with the NSDB they query. 

Irrelevant.

> As I said, I will propose that text is removed in the next draft.

OK, thanks.

> fileservers containing the junction.

My question was: how does one specify the _root_ of a domain's
namespace.  I'm really only looking for examples of objects that one
would have to create in order to do that.  Can you post such examples?

Nico
--

---

From: James Lentini <[email-masked]>
Date: Tue, 8 Sep 2009 15:53:14 -0400 (EDT)

> want to know too, and I could ask the AD myself).

We have asked and received feedback from LDAP experts such as the 
NFSv4 WG technical adviser, Leif Johansson. He has given us comments 
on both the mailing list and at IETF'75.

In any event, I will consult with our AD to ensure that all LDAP 
review requirements are met.

The LDAP configuration described in the NSDB document is valid. The 
NSDB is designed to be a dedicated service that is simple to 
administer and query. Since it is a dedicated service, it is possible 
to use a well known base DN.

I agree that other LDAP configurations are possible. However 
configurations that allow the NSDB records to be interspersed with 
other data and use an arbitrary base DN have greater complexity. There 
are a number of pitfalls (consider an LDAP directory with multiple 
DITs). The question is whether the benefits outweigh the added 
complexity. Could you clearly articulate the benefits you see from 
using an arbitrary base DN?

I also question whether such a configuration would be used in 
practice. In conversations with operators of LDAP directories, we have 
been told it is unlikely system administrators would resist adding a 
new schema to an existing LDAP installation.

> would have to create in order to do that.  Can you post such 

A DNS SRV RR is used to specify the root of a domain's namespace. 
Again this is not part of the NSDB protocol. See the examples in

 http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 15:04:52 -0500

> review requirements are met.

That wasn't my problem.  My problem is I'd like to know where the review
took place, assuming that it took place in a public forum.

> to use a well known base DN.

I disagree.  I believe the hardcoded requirement for o=fedfs, and worse,
o=fedfs as the base DN, is not acceptable.  Other reviewers may have
missed this, but that doesn't make it any more acceptable.

> using an arbitrary base DN?

I'll begin by articulating the main problems with mandating that search
scope=one and base DN=o=fedfs:

a) it forces administrators to create a new naming context;
b) there's a single namingContext for all deployments, which means that
   a merger/acquisition necessarily results in the need to merge two or
   more deployments of this namingContext;
c) there's a single namingContext for all deployments, which greatly
   complicates federation: you must either have a single, shared
   directory for the entire federation, or you must implement directory
   synchronization.

The benefits of specifying that search scope=sub and not specifying a
base DN is the exact opposite of the above!  To wit:

a) existing directories can be used for NSDB purposes after installing
   the NSDB schema, without further ado;
b) if there's a merger/acquisition, directory merges are not required,
   but if desired can proceed a pace and as usual, without any
   requirements imposed by the NSDB beyond repairing any UUID conflicts;
c) federation is trivial: let NSDB objects refer to others by DN and
   federation is automatic.

> new schema to an existing LDAP installation.

I never said that "system administrators would resist adding  a new
schema to an existing LDAP installation", not any more than I ever said
that "base DNs are optional".  Stop ascribing statements to me that I
have never made.

The issue here, for the Nth time, is this: your document REQUIREs that
search scope be "one" and the base DN be "o=fedfs".  Neither of those
two requirements is acceptable, for all the reasons that I've given.

> A DNS SRV RR is used to specify the root of a domain's namespace. 

Please, please re-read what I wrote.  Can you post examples of _LDAP_
NSDB objects which would specify the _root_ of a domain's namespace?

I'm NOT looking for DNS SRV RR examples here.  I don't know how much
more specific I can be.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Tue, 8 Sep 2009 17:36:57 -0400 (EDT)

Hi Nico,

Replies below:

> a) it forces administrators to create a new naming context;

Sorry, I'm not following you.

The NSDB service is separate from all existing LDAP directories. An 
administrator is not required to create an o=fedfs entry in any 
existing LDAP directory's namespace.

>    more deployments of this namingContext;

The system was designed with the merger/acquisition scenario in mind. 
There is no need to modify an NSDB's contents when a federation's 
membership changes.

>    directory for the entire federation, or you must implement directory

There is no single, shared directory for the entire federation. Each 
NSDB is a separate LDAP directory. I agree that a single LDAP 
directory would be impractical, but that is not how it works.

If there are sections of the draft that are unclear on the above 
points, I would appreciate your help identifying them. I would like to 
make this as clear as possible.

> that "base DNs are optional".  Stop ascribing statements to me that I

*I* questioned whether "system administrators would resist adding a 
new schema to an existing LDAP installation". I never tried to ascribe 
that statement to you. I was giving one reason why we choose to design 
a dedicated NSDB service rather than a more flexible, but complex 
solution.

> I'm NOT looking for DNS SRV RR examples here.  I don't know how much

There is no LDAP NDSB object that defines the domain's root namespace. 

An NFS client locates a root fileserver using the DNS SRV RR 
mechanism. The root fileserver exports a namespace (just like any 
other NFSv4 server). The root fileserver's namespace may contain FedFS 
junctions (FSNs). The NSDB LDAP database stores the FSN to FSL 
mapping.

In summary, there are only FSN and FSL LDAP objects.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 17:06:15 -0500

> existing LDAP directory's namespace.

That's problem number one.  Why should I have to deploy a new directory
for this?  What makes the NSDB so special?

> There is no need to modify an NSDB's contents when a federation's 

See below.

> directory would be impractical, but that is not how it works.

Having a any distinct directories which are separate from normal
enterprise directories creates a problem: how to find these separate
directories.  You can't use the traditional _ldap SRV RRs to find them.

And now I see why you're using UUIDs.  I'm going to guess how you came
up with your scheme:

 - first you familiarized yourself with LDAP and LDAP APIs
 - then you noticed that LDAP APIs typically require a base DN to be
   specified when searching a DS (the LDAP APIs that I'm familiar with
   don't automatically discover and use the defaultNamingContext or
   anything of the sort)
 - so you hardcoded a base DN (o=fedfs)
 - then you noticed that you couldn't scale this, so each domain in a
   federation would have to have its own directory, but...
 - ...now you could no longer ensure DN uniqueness, since each domain
   would now have a distinct directory with the same namespace,
 - so you decided to use UUIDs to enforce uniqueness.

This is a very twisted way to use LDAP!

Try doing this instead:

 - make the DSes configurable and/or discoverable
    - discover the DSes via a DNS query for _ldap._tcp SRV RRs
 - make the base DN configurable and/or discoverable
    - to discover the base DN lookup a DS' root DSE's
      defaultNamingContext
 - when searching for NSDB objects format a search filter that starts
   with "(&(objectClass=<NSDB-classname>)"
 - when searching for NSDB objects set the search scope to "sub"

You'll find that you no longer need to ensure object DN uniqueness!  The
directory will do that for you.  Thus you'll no longer need to use UUIDs
(you'll still be able to, but they will not be necessary).  You'll also
find that you no longer need o=fedfs (though deployers might create an
OU or container for NSDB objects, of course).

> make this as clear as possible.

The I-D is clear enough on this, and what it specifies is clearly not
acceptable.

> *I* questioned whether "system administrators would resist adding a 

Ah, I misunderstood that.

> a dedicated NSDB service rather than a more flexible, but complex 

That's a choice that deployers should make!  Not the IETF.  By making
the DSes and base DN configurable you allow deployers to have separate
DITs for their NSDBs if they like.  But you're forcing them to.

> There is no LDAP NDSB object that defines the domain's root namespace. 

I think that's a problem.

> junctions (FSNs). The NSDB LDAP database stores the FSN to FSL 

I understand all that.  Did you read the thread on the NFSv4 SRV RR I-D?
THere we agreed there that the NFSv4 pseudo-root of a domain root server
and the actual domain root should be separated.

Now, why couldn't I publish in the NSDB the FSN of a domain's root, and
then let the NSDB specify all the other junctions down from there?

I think I know why: because your document has a single, global, _flat_
NSDB object namespace, which in turn derives from the insistence on base
DN = o=fedfs and search scope=one.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 17:43:42 -0500

> directories.  You can't use the traditional _ldap SRV RRs to find them.

Another problem: you can't know where to look for an NSDB object knowing
only its DN.  Nor can the directories help you by, say, returing
referrals -- a DS can't know the location of an NSDB object that lives
in another domain's DS for the simple reason that the DN gives it not a
clue.

The I-D calls for searching the NSDB by object DN, which only has the
UUIDs in it.  I think this is a fatal flaw with your approach.

Of course, _not_ forcing the use of a specific base DN, and allowing the
use of scope=sub, completely avoids that problem, because then every
NSDB object DN will contain the name of a namingContext that will allow
every DS to construct referrals.

I asked the LDAP Expert reviewer who reviewed your document, and he says
he only reviewed the IANA considerations.  I'm going to ask the LDAP
Directorate to ensure that a full review takes place.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 18:15:30 -0500

> in another domain's DS for the simple reason that the DN gives it not a

Of course, here I meant the DN of an NSDB object as it would be in the
current I-D.  Normally an LDAP object DN does provide enough information
to find it (DSes in the DIT know which DSes serve which naming contexts,
and the DN of an object in the DIT should have the DN of a naming
context as a suffix).

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Daniel Ellard <[email-masked]>
Date: Wed, 9 Sep 2009 09:38:51 -0400

>  - so you decided to use UUIDs to enforce uniqueness.

There's really no reason to guess about the history
of the project; both the history and reasoning behind
the current protocol are well-documented.  It would
probably be better to start with the requirements document

http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-reqts-03

and the IETF WG presentations (hopefully on-line somewhere)
rather than diving immediately into the protocol.

It's clear from your comments and suggestions that you
haven't been properly introduced to the underlying
assumptions and restrictions of the system, the terminology
used in the documents, nor the purpose and goals of the
protocol.  I think your suggestions will be much more
useful once we're all speaking the same language and
trying to solve the same problem.

-Dan

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 9 Sep 2009 11:50:57 -0500

> trying to solve the same problem.

So it seems that this is our first use case for the requirements  
document.

Nico, if, after reviewing the requirements document referenced,
there are still issues, please summarize those back to the list.

Thanks,
Spencer

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 12:12:27 -0500

> >trying to solve the same problem.

I understand enough of LDAP to know that the specific requirements in
your document do violence to the LDAP directory model.

> there are still issues, please summarize those back to the list.

I will review the requirements document.  I will report back.

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Wed, 9 Sep 2009 13:39:12 -0400

> your document do violence to the LDAP directory model.

I'm not questioning your LDAP expertise.  I assume it's far
greater than mine, since I have very little.  I do understand
enough of LDAP to know that your suggestions are addressing
different problems than those we are trying to solve.

-Dan

---

From: James Lentini <[email-masked]>
Date: Wed, 9 Sep 2009 16:11:44 -0400 (EDT)

>     - discover the DSes via a DNS query for _ldap._tcp SRV RRs

Sure. A DNS SRV RR format for LDAP would need to be standardized 
(draft-ietf-ldapext-locate expired long ago and I don't see a 
replacement), but we know how to do that. We would loose the ability 
to have multiple, separate NSDBs within a domain though.

>     - to discover the base DN lookup a DS' root DSE's

Again, that will work, but the defaultNamingContext isn't a standard 
attribute (see the list in Section 5.1 on page 37 of RFC 4512). One 
goal was to avoid using anything that was implementation specific.

>    with "(&(objectClass=<NSDB-classname>)"

Could you complete this example? What is the entire search filter you 
propose?

> OU or container for NSDB objects, of course).
<snip> 
> then let the NSDB specify all the other junctions down from there?

You could. We call this the root fileset (see section 2.6 of the NSDB 
draft). We don't define such an object in the draft, but we allow for 
one to be defined in the future.