Skip to main content

A Universally Unique IDentifier (UUID) URN Namespace
RFC 4122

Discuss


Yes

(Ted Hardie)

No Objection

(Alex Zinin)
(Allison Mankin)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Sam Hartman)
(Thomas Narten)

Abstain


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

(Ned Freed; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2004-02-03)
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_and_reserved>
                            <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
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.

(Ted Hardie; former steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-02-05)
I have no further objections

(Bill Fenner; former steering group member) (was Discuss) No Objection

No Objection (2004-12-16)
No further objection; MAP covered my concerns with -04.

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2005-01-11)
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.

(Jon Peterson; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) (was Discuss) No Objection

No Objection (2004-03-17)
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.

(Steven Bellovin; former steering group member) (was Discuss) No Objection

No Objection (2004-03-11)
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.

(Thomas Narten; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) Abstain

Abstain (2005-01-05)
  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.