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 [email protected] 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 [email protected] Mobile: +1 (978) 394-7754 ----------------------------------------------------
