Early Review of draft-ietf-nfsv4-federated-fs-protocol-
review-ietf-nfsv4-federated-fs-protocol-tsvdir-early-black-2011-11-26-00

I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. The authors
should consider this review together with any other last-call comments they
receive. Please always CC tsv-dir at ietf.org if you reply to or forward this
review.

First, I should apologize for the delay in this review - my day job has this
recurrent habit of distracting me from IETF work ;-), and Taipei was a rather
long journey to/from Boston.

Summary: This draft is on the right track but has open issues, described in the
review.

NFSv4.0 and NFSv4.1 provide support for replicas of an exported filesystem, but
don't contain any details on how to manage the replicas or access multiple
filesystems in a single coherent namespace.  This draft is one of NFSv4 several
federated filesystem drafts that serve to fill that gap.  This draft primarily
specifies an LDAP schema and use of LDAP operations to manage a federated
namespace - at a junction point in the namespace (between two exported
filesystems), an LDAP lookup is done to find the destination filesystem, thus
enabling LDAP to provide a level of indirection by comparison to hard-wiring
the location of the destination filesystem into the junction point metadata in
the source filesystem.

This is a relatively straightforward use of LDAP - I did not see any
significant transport protocol usage issues, but I do have one open issue that
should be relatively straightforward to address.

The NFSv4 replica mechanism is not simple, especially in its full NFSv4.1 (RFC
5661) form - section 4.2.2.4 of this draft lists nearly 20 attributes that have
to be specified in an LDAP entry in order to characterize a replica (a File Set
Location in NFSv4 parlance). The details of how replica selection works are in
RFC 5661, and require some careful reading to understand.  For replica
selection and usage, Section 2.8.1 of this draft bothers me - despite being
about consistency, it clearly states that replicas do not need to be read-write
consistent, and that clients may switch among replicas transparently ... and
this should all be ok because "it is the responsibility of administrators to
guarantee the functional equivalence of the data" among replicas.

That current text reminds me of the Forrest Gump quote: "Life was like a box of
chocolates. You never know what you're gonna get."  Needless to say, "You never
know what you're gonna get" is not a good network filesystem behavior, and the
expectation is that administrators will configure the use of replicas to do
considerably better than that.  Towards this end, I'd like to see some guidance
to administrators in this draft for how to stay out of trouble; some of that
guidance could be provided by reference to the longer explanation of the
replica mechanism that's already in RFC 5661.

idnits 2.12.12 didn't find any nits.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------