A Universally Unique IDentifier (UUID) URN Namespace
RFC 4122

Note: This ballot was opened for revision 05 and is now closed.

(Ned Freed) Discuss

Discuss (2004-02-03 for -)
First of all, the syntax definition for UUIDs is messed up. It currently
reads as follows:

   UUID                   = <time_low> "-" <time_mid> "-"
                            <time_high_and_version> "-"
                            <clock_seq_low> "-" <node>
   time_low               = 4*<hexOctet>
   time_mid               = 2*<hexOctet>
   time_high_and_version  = 2*<hexOctet>
   clock_seq_and_reserved = <hexOctet>
   clock_seq_low          = <hexOctet>
   node                   = 6*<hexOctet
   hexOctet               = <hexDigit> <hexDigit>
   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

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-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.

(Ted Hardie) Yes

(Harald Alvestrand) (was Discuss, No Objection) No Objection

Comment (2005-01-11)
No email
send info
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.

(Steven Bellovin) (was Discuss) No Objection

Comment (2004-03-11)
No email
send info
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.

(Margaret Cullen) No Objection

(Bill Fenner) (was Discuss) No Objection

Comment (2004-12-16)
No email
send info
No further objection; MAP covered my concerns with -04.

(Sam Hartman) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-03-17)
No email
send info
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.

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) (was Discuss) No Objection

(Jon Peterson) (was Discuss) No Objection

(Bert Wijnen) No Objection

Comment (2004-02-05 for -)
No email
send info
I have no further objections

(Alex Zinin) No Objection

(Russ Housley) (was Discuss) Abstain

Comment (2005-01-05)
No email
send info
  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.