[nfsv4] [FedFS] NSDB draft changes for review

[James Lentini <[e-mail]>]

At last weeks meeting, I was assigned an action item to draft 
recommendations on how to generate a referral based on FSL 
information.

I've written up a proposal in a new section of the NSDB draft, Section 
2.4.3 "Generating A Referral from Fileset Locations", and included it 
with other changes queued up for the NSDB draft.

A new version of the NSDB draft is here:

 http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-04bis.txt

and a diff against the -04 version is here:

 http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-rfcdiff.html

(the real changes start on page 6)

Included in this set of changes are the following:

 1. The proposed text on generating a referral in Section 2.4.3

 2. A synchronization of the examples with the requirements 
    document (see page 12).

 3. updated text on how to identify and locate an NSDB (more on this 
    below)

 4. small text updates to synchronize with the RFC-Editor's 
    suggestions for the requirements specification (capitalization 
    changes in the glossary, etc.)

With regards to 3, my co-authors and I have drafted updated text on 
how to identify and locate an NSDB.

Previously an NSDB was identified by either an IPv4, IPv6, or DNS 
name. After careful consideration, we believe that an NSDB should only 
be identified by a DNS name for the following reason (page 17, line 
42):

    FSNs are immutable and invariant. The attributes of an FSN,	
    including the fedfsNsdbName, are expected to remain constant.	
    Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such	
    as an IPv4 or IPv6 address, as this would indefinitely assign the	
    network address.

We've discussed resolving the DNS name using SRV RRs. The idea of 
using SRV RRs to locate LDAP services has been discussed by the IETF 
in the past. I've provided some background on this topic below [1]. 
The summary is that the IETF has not standardized a way to to locate 
LDAP services using SRV RRs. As a result, many LDAP clients and APIs 
require an LDAP service to be identified using a traditional DNS host 
name.

The above results in both standardization issues and implementation 
impediments to requiring the use of SRV RRs to locate NSDBs.

These text updates are intended to clarify the format of an NSDB name 
and define the DNS name resolution process in a way that is compatible 
both with today's format for identifying an LDAP service and future 
extensions, such as an SRV RR format, should they arise.

As always, comments and suggestions are welcome.

I will allocate time in tomorrow's FedFS weekly meeting to discuss 
these changes.

-james

----

[1] Background on LDAP and DNS SRV RRs

Some LDAP implementations use SRV RRs for locating directories. For 
example, SRV RRs can be used to locate an Active Directory domain 
controller and OpenLDAP commands (see ldapsearch(1)) can lookup 
specially formatted LDAP URIs using SRV RRs. However, these uses are 
all non-standard.

RFC2782, which defines the SRV RR format, uses LDAP in its examples. 
RFC2782 states:

  Note: LDAP is chosen as an example for illustrative purposes only,
  and the LDAP examples used in this document should not be considered
  a definitive statement on the recommended way for LDAP to use SRV
  records. As described in the earlier applicability section, consult
  the appropriate LDAP documents for the recommended procedures.

The "applicability section" of RFC2782 states:

  In general, it is expected that SRV records will be used by clients
  for applications where the relevant protocol specification indicates
  that clients should use the SRV record. Such specification MUST
  define the symbolic name to be used in the Service field of the SRV
  record as described below. It also MUST include security
  considerations. Service SRV records SHOULD NOT be used in the 
  absence of such specification.

Therefore, the LDAP examples in RFC2782 are not standard and any use 
of SRV RRs with LDAP would need to be defined in a separate RFC. 
Unfortunately, no such RFC exists.

A long expired individual I-D describing the use of SRV RRs with LDAP 
was written in 1999:

https://datatracker.ietf.org/idtracker/draft-armijo-ldap-locate/

and was replaced by a WG I-D in that also expired:

https://datatracker.ietf.org/idtracker/draft-ietf-ldapext-locate/

The later was reviewed by the IESG between 2002 and 2004. The IESG had 
concerns, including that the format would only allowed for one LDAP 
service per domain. This was a concern I had raised on using SRV RRs 
to locate NSDBs.

No proposals on this have been made since 2004.