A Universally Unique IDentifier (UUID) URN Namespace
RFC 4122
Discuss
Yes
No Objection
Abstain
Note: This ballot was opened for revision 05 and is now closed.
(Ned Freed; former steering group member) Discuss
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
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
I have no further objections
(Bill Fenner; former steering group member) (was Discuss) No Objection
No further objection; MAP covered my concerns with -04.
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) (was Discuss, No Objection) No Objection
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
(Margaret Cullen; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) (was Discuss) No Objection
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
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
(Russ Housley; former steering group member) (was Discuss) Abstain
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.