A Universally Unique IDentifier (UUID) URN Namespace
draft-mealling-uuid-urn-05

[Ballot comment]
Reviewed by Michael Patton, Gen-ART

Substantive technical issues identified in the review of -04 seem to have been addressed in -05. While the explanatory stuff could still be improved, that is always true for all documents, so I've changed to no-obj.

[Ballot comment]
In an 802 MAC address, the most significant bit is the I/G bit.
  This bit indicates whether the address is an individual station or
  a broadcast or multicast address.  The next bit is the U/L bit.
  This bit indicates whether the address is universally or locally
  administered.  Universally administered addresses have this bit
  set to zero, and locally administered addresses have this bit
  set to one.  This convention is described in IEEE Std 802-2001.

  The text in section 4.5 says:
  >
  > (For compatibility with earlier specifications, note that this
  > document uses the unicast/multicast bit, instead of the arguably more
  > correct local/global bit.)
  >
  Why not set both the I/G and the U/L bits?  The I/G bit would be
  set for backward compatibility with unreferenced specifications, and
  the U/L bit would be set to avoid confusion.  IEEE Std 802-2001 says
  that the local authority is responsible for the entire address, which
  I believe includes the I/G bit, when the U/L bit is set.

[Ballot discuss]
Reviewed by Michael Patton, Gen-ART
He has been in dialogue with the author about the issues below; I'm just hanging on to them until the updated version comes along.

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


Given that this draft has only been out for a few days and differs
substantially from the previous draft (based mainly on the fact that
it's half as long), I am a little concerned that it can't have gotten
enough scrutiny.  Given the number of things I found, and I am by no
means an expert in this area, I feel that this needs additional review
and another round of revision.  In particular things like the blithe
denial in Section 3 heading "Process for identifier resolution" and
the trivial disclaimer under "Validation" concern me.  There were
several places in the document that caused vaguely unsettled feelings,
but only the following seemed worth specific comment:

Several times the document implies that UUIDs are guaranteed to be
unique, while, in fact, this is only probabilistic (the probability of
collision is very small, but non-zero).

Technical glitch:
    In Section 3, under "Rules for Lexical Equivalence", the third
    paragraph seems to be self-contradictory.  "the first one follows
    the second if..." and "The second precedes the first if..." are
    equivalent consequents, however the following conditions are
    disjoint.  I think the paragraph meant to read:

      UUIDs as defined in this document can also be ordered
      lexicographically.  For a pair of UUIDs, the first one precedes
      the second if the most significant field in which the UUIDs
      differ is greater for the second UUID.  The second precedes the
      first if the most significant field in which the UUIDs differ is
      greater for the first UUID.

    However, that's just the way I'd design it.  They may well have
    meant it the other way.  Additionally, that's a pretty stilted and
    hard to understand construction, and I would suggest this instead:

      UUIDs as defined in this document can also be ordered
      lexicographically.  For a pair of UUIDs, the fields are compared
      as described above until a field differs.  The ordering of the
      UUIDs is the same as the ordering of the respective field values.

The one sentence paragraph that's all of section 4.1 doesn't make
sense.  It's not proper English.  In one place it's talking about 16
octets and in another 8 octets.  I couldn't figure it out at all.

Section 4.1.1 could benefit from a bit layout diagram to make the
specification more like other IETF docs.  If not, the terms Msb0,
Msb1, and Msb2 should be explained.  I think I know what it means, but
it may be easy for some readers to get wrong.  Section 4.1.3 could
also use such a diagram.

The table in Section 4.1.3 has two rows with the same values for the
four bits.  I assume that the line for version 5 is incorrect.

In section 4.3 the first requirement sounds wrong.  You want multiple
UUIDs to be different, not "MUST be equal".  I think it was trying to
say that the node ID part is equal, but I'm not sure what it was
trying to say, only that what it does say can't be right...  But on
later reflection I'm even more confused as the algorithm seems to
generate only one UUID per name, I was expecting from earlier parts of
the document that the name-based form was going to give a base for
generating many UUIDs (using the timestamp).  I guess that means the
earlier parts need some clarification, and possibly the intro to 4.3.

In one of the algorithm steps in section 4.3 it refers specifically to
the MD5 hash, but I think was supposed to be non-specific.  That is to
say, change the single occurrence of "the MD5 hash" to "the hash"

I don't understand the third paragraph in the Security Considerations.

[Ballot discuss]
REVISED DISCUSS:

  In an 802 MAC address, the most significant bit is the I/G bit.
  This bit indicates whether the address is an individual station or
  a broadcast or multicast address.  The next bit is the U/L bit.
  This bit indicates whether the address is universally or locally
  administered.  Universally administered addresses have this bit
  set to zero, and locally administered addresses have this bit
  set to one.  This convention is described in IEEE Std 802-2001.

  The text in section 4.5 says:
  >
  > (For compatibility with earlier specifications, note that this
  > document uses the unicast/multicast bit, instead of the arguably more
  > correct local/global bit.)
  >
  Why not set both the I/G and the U/L bits?  The I/G bit would be
  set for backward compatibility with unreferenced specifications, and
  the U/L bit would be set to avoid confusion.  IEEE Std 802-2001 says
  that the local authority is responsible for the entire address, which
  I believe includes the I/G bit, when the U/L bit is set.

[Ballot comment]
Even though it's clearly stating that this is not a controlling specification for UUIDs, it is not very clear about stating exactly which specification is the authoritative one. As far as I remember from the previous 2-3 tries to get the IETF to define UUIDs, this is a tangled space; I don't think it's worth trying to untangle it.
Note: draft-zeilenga-ldap-uuid quotes ISO 11578 as the normative source for the UUID spec. Consistency would have been nice.

[Ballot comment]
The abstract contains two references.  I don't think it's a good idea to include references in text that will be distributed without the accompanying document to resolve the references.  I'd suggest removing the references.

[Ballot discuss]
The ABNF provided in Section 3 allegedly conforms to RFC 2234, but the rulenames that contain the "_" character are invalid per the 2234 rulename production:

rulename = ALPHA *(ALPHA / DIGIT / "-")

[Ballot discuss]
ORIGINAL DISCUSS:
  The security considerations (section 6) ought to discuss the consequences
  of using a predictable random number source.  It should also reference
  RFC 1750.

REVISED DISCUSS:
  Section 4.5 says:
  >
  > If a system does not have the capability to generate cryptographic
  > quality random numbers, then implementation advice can be found in
  > RFC1750 [4].
  >
  RFC 1750 offers advice on the generation of cryptographic quality random
  numbers.  If a system does not have this capability, then there will be
  trouble.  I think that this paragraph should simply point implementors to
  RFC 1750.  I suggest that the "If" portion of the sentence go away.

[Ballot comment]
This text:

  If a system does not have the capability to generate cryptographic
  quality random numbers, then implementation advice can be found in
  RFC1750 [4].

should read:

  Advice on generating cryptographic-quality random numbers can be found
  in RFC 1750 [4].

Rationale:  1750 can be used to evaluate nominally-cryptographic random number generators.

[Ballot discuss]
It would be good to get a semi-formal statement from the Open Group
saying they have reviewed the doc and are OK with the IETF publishing
this as a proposed standard.

The intro is fairly clear that this document is about URNs. And text
like:

>    The information here is meant to be a concise guide for those wishing
>    to implement services using UUIDs as URNs. Nothing in this document
>    should be construed to mean that it supersedes the DCE standards that
>    defined UUIDs to begin with.

also seems to say that this is not about defining UUIDs.

But Section 4 really sounds like it is defining (or restating?) what a
UUID is in a lot of detail. Is this a superset of what is documented
elsewhere? I'm not sure its appropriate for this part to be part of
the "proposed standard", if it really relates to the UUID definitiion,
as opposed to URNs.

As an example, Section 4.2.1 talks about comparisons. Seems to me that
UUIDs are just compared for equality bit-for-bit. Why is this document
going into so much detail here, including talking about the fields
themselves? Is this really about URNs, or about the UUID itself?

Note: I'd be a lot less worried about any of the above if the Open
Group were known to be OK with the IETF publishing the doc as a PS.

[Ballot discuss]
It would be good to get a semi-formal statement from the Open Group
saying they have reviewed the doc and are OK with the IETF publishing
this as a proposed standard.

The intro is fairly clear that this document is about URNs. And text
like:

>    The information here is meant to be a concise guide for those wishing
>    to implement services using UUIDs as URNs. Nothing in this document
>    should be construed to mean that it supersedes the DCE standards that
>    defined UUIDs to begin with.

also seems to say that this is not about defining UUIDs.

But Section 4 really sounds like it is defining (or restating?) what a
UUID is in a lot of detail. Is this a superset of what is documented
elsewhere? I'm not sure its appropriate for this part to be part of
the "proposed standard", if it really relates to the UUID definitiion,
as opposed to URNs.

Section 4.2.1 talks about comparisons. Seems to be that UUIDs are
compared for equality bit-for-bit. Why is this document going into so
much detail here, including talking about the fields themselves? Is
this really about  URNs, or about the UUID itself?

Note: I'd be a lot less worried about  any of the above if the Open
Group were known to be OK with the IETF publishing the doc as a PS.

[Ballot discuss]
The security considerations (section 6) ought to discuss the consequenses
  of using a predictable random number source.  It should also reference
  RFC 1750.

[Ballot discuss]
Section 4.5 leaves out an important aspect of 802 addresses: bit order.  It's true that the multicast bit is the high order bit, but the tendency seems to be to use Ethernet notation for these addresses (as opposed to token ring order, where the bits are usually reversed).  This means that 01:00:5e:00:00:00 is a multicast address; a naive reading of section 4.5 would lead me to set the 0x80 bit, not the 0x01 bit, of the first octet, since it just mentions high order bit of the 48 bits and doesn't mention the funny bit order.

Is the extra bit gained from overloading unicast/multicast sufficiently useful to mask the semantics?  I think that using the local bit for its intended purpose (to indicate that an address is not globally assigned) and keeping the unicast/multicast bit set to zero is more appropriate (thus only allowing for 46 bits of randomness, with the two low-order bits of the first octet [in IETF order, anyway] set to '1' and '0', respectively).  If the current scheme stays, I'd like to see a discussion of the extra bit of randomness vs. semantics of IEEE addresses.

[Ballot discuss]
First of all, the syntax definition for UUIDs is messed up. It currently
reads as follows:

  UUID                  =  "-"  "-"
                            "-"
                           
                            "-"
  time_low              = 4*
  time_mid              = 2*
  time_high_and_version  = 2*
  clock_seq_and_reserved =
  clock_seq_low          =
  node                  = 6*
  hexDigit =
        "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
        | "a" | "b" | "c" | "d" | "e" | "f"
        | "A" | "B" | "C" | "D" | "E" | "F"

This is not syntactically valid ABNF: It uses angle brackets around productions,
| rather than / for alternation, production names containing underscores, and
unnecessarily lists both upper and lower case quoted characters. Then again,
the document doesn't say this is ABNF, but rather "extended BNF". But that's
a problem, because this "extended BNF" uses a bit of uniquely ABNF syntax: The
n*m variable repetition rule. Even worse, it uses it incorrectly, e.g "4*"
is used here to mean "exactly four" when in ABNF it means "anywhere from
four to infinity". Using non-ABNF BNF is one thing; using something that
isn't specified anywhere and whose conventions conflict with ABNF is quite
another.

The right way to fix this is to use proper ABNF and reference RFC 2234. Here's
the corrected ABNF for this:


  UUID                  = time-low "-" time-mid "-"
                            time-high-and-version "-"
                            clock-seq-and-reserved
                            clock-seq-low "-" node
  time-low              = 4hexOctet
  time-mid              = 2hexOctet
  time-high-and-version  = 2hexOctet
  clock-seq-and-reserved = hexOctet
  clock-seq-low          = hexOctet
  node                  = 6hexOctet
  hexOctet              = 2hexDigit
  hexDigit =
    "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
    "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F"

Second, something should probably be said in section 4.1.1 about how future
definitions of addition UUID variants would be done. It would be fine to
say that a standards-track RFC would be needed to do this.

Third, the same sort of extensibility issues need to be nailed down in
section 4.1.3; how would a new version be defined?

Rather than having a brief discussion of pseudorandom number generation,
how about deleting what's there and instead referring to RFC 1750?

The first paragraph of the security considerations reads:

  Do not assume that UUIDs are hard to guess; they should not be used
  as capabilities, for example.

I have no idea what "capabilities" refers to here.

[Ballot comment]
Even though it's clearly stating that this is not a controlling specification for UUIDs, it is not very clear about stating exactly which specification is the authoritative one. As far as I remember from the previous 2-3 tries to get the IETF to define UUIDs, this is a tangled space; I don't think it's worth trying to untangle it.