Subject: [nfsv4] Use of generic LDAP UUID in NSDB schema

From: Chuck Lever <[email-masked]>
Date: Mon, 16 Jul 2012 19:33:28 -0400

Hi-

In this e-mail:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg10851.html

Howard Chu recommended that we replace our local definition of a UUID (section 4.2.1.1, fedfsUuid) with the UUID syntax definition already provided by LDAP.  This would affect sections 4.2.1, 4.2.1.1, 4.2.1.4, and 4.2.1.8 of the FedFS NSDB draft.

RFC 4530 defines a "UUID syntax, the 'uuidMatch' and 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute type."  At first blush, it looks like 4530 is purpose-made for LDAP entries uniquified by UUIDs, as FedFS records are, and that we should build on this rather than maintain our own definitions.  At the very least, fedfsUuid should inherit from 1.3.6.1.1.16.1.

Before I propose specific changes, does anyone remember why we have the fedfsUuid definition and its children fedfsFsnUuid and fedfsFslUuid?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Daniel Ellard <[email-masked]>
Date: Tue, 17 Jul 2012 12:02:15 -0400

> Before I propose specific changes, does anyone remember why we have the fedfsUuid definition and its children fedfsFsnUuid and fedfsFslUuid?

If I remember correctly after all this time, I think that one of the
reasons was that there are some types of UUIDs that were shown to be
unsatisfactory to use as fedfsUuids -- too easy to guess (types 1, 2,
3, or 5), too tied to a platform (ditto), or too unconstrained (type
4).  We wanted a uuid that was both strong and also provided
provenance info; sort of a hybrid of types 2 and 4.

I believe that the current consensus is to use type 4.  As long as it
is spec'd that way (or whatever the current consensus is), using a
more general representation seems fine to me.

-Dan

---

From: Chuck Lever <[email-masked]>
Date: Tue, 17 Jul 2012 12:04:36 -0400

> provenance info; sort of a hybrid of types 2 and 4.

RFC 4530 does not appear to mandate a particular type of UUID. Rather, it provides an appropriate ASN.1 syntax and a pair of matching rules, so it appears to be more about representational form than about how these UUIDs are actually generated.

RFC 4530 also specifies an "entryUuid" attribute, which appears to be an UUID generated by the LDAP server itself and can appear in an entry.  It's not part of the DN, and LDAP clients have no control over the type of UUID that is generated, of course.  But it does provide an unique and immutable identifier by which to refer to an entry.

Howard's initial complaint was about basing our fedfsUuid attribute type on the "name" type rather than on "UUID".  At the very least we can replace the "name" with "UUID" it seems to me.

---

From: Daniel Ellard <[email-masked]>
Date: Tue, 17 Jul 2012 12:19:34 -0400

> RFC 4530 does not appear to mandate a particular type of UUID. Rather, it provides an appropriate ASN.1 syntax and a pair of matching rules, so it appears to be more about representational form tha…

It's true that it provides a representation for any type of uuid, but
the representation is one that is tailored for type 1: it has fields
for the time, clock gen sequence, and the node ID separated by dashes:

time-low "-" time-mid "-" time-high-and-version "-"
clock-seq-and-reserved "-" node

and I don't want to give anyone the impression that they should use
anything other than type 4 uuids, for which this format has little
meaning.

> Howard's initial complaint was about basing our fedfsUuid attribute type on the "name" type rather than on "UUID".  At the very least we can replace the "name" with "UUID" it seems to me.

That seems fine with me.

We didn't want to call it a uuid unless we were going to use an RFC
4122 UUID, but now that we've agreed that this is what we should use,
we should call it that.

-Dan

---

From: Chuck Lever <[email-masked]>
Date: Tue, 17 Jul 2012 14:35:53 -0400

Here's what the draft has now in section 4.2.1.1:

>    A fedfsUuid is the base type for all of the universally unique
>    identifiers (UUIDs) used by the federated filesystem protocols.
> 
>    To minimize the probability of two UUIDs colliding, a consistent
>    procedure for generating UUIDs SHOULD be used throughout a
>    federation.  Within a federation, UUIDs SHOULD be generated using the
>    procedure described for version 1 of the UUID variant specified in
>    [RFC4122].  This is the time-based UUID variant provided by many UUID
>    programming libraries (e.g., the OSF DCE uuid_generate_time(1) API).
> 
>    The UUID’s text representation (as defined in [RFC4122]) SHOULD be
>    encoded as a UTF-8 string.
> 
>    A fedfsUuid is a single-valued LDAP attribute.
> 
>    <CODE BEGINS>
> 
>            ///
>            /// attributetype (
>            ///     1.3.6.1.4.1.31103.1.1 NAME ’fedfsUuid’
>            ///     DESC ’A UUID used by NSDB’
>            ///     SUP name
>            ///     SINGLE-VALUE
>            ///     )
>            ///
> 
>    <CODE ENDS>

My comment is:

LDAP is concerned only with storage and representation of data elements, not with verifying the semantics of data it stores.  We can specify syntax and matching rules in the schema, but further constraints need to be dealt with somewhere else (ie, in another section, perhaps, and in other parts of a FedFS implementation).  There is no mechanism for an LDAP server to enforce the type variant of a UUID, for example.

Thus, I propose moving the second paragraph to another section of this draft where a fuller discussion of the UUID uniqueness constraints and a justification of which UUID variant we prefer can occur.  I believe these issues have been discussed in previous mail to this list.

I propose removing the third paragraph since it no longer makes sense to constrain the contents of this attribute to be UTF-8.  The ASN.1 definition of the UUID type limits the characters to ASCII hexadecimal digits and hyphen.

Then I propose inserting a paragraph with a cross reference to this new section.  This paragraph may also refer to RFC 4350, which defines how an LDAP server represents a UUID.

The schema definition for fedfsUuid should then be changed as follows: replace the "SUP name" with a "SUP UUID".  I will try this out on my own NSDB soon.

Finally, we should update other areas of the draft that deal with UUIDs to be consistent with these changes.  For example, the schema definitions of fedfsFsnUuid and fedfsFslUuid could also be changed to use "SUP UUID."