Document: draft-mealling-uuid-urn-04.txt
Review: Michael A. Patton
Date: 13 december 2004 


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.


Typos
-----

Section 3 under "Identifier uniqueness considerations":
    "the second another uses" => "the second uses"

Section 3 under "Process of identifier assignment":
    "does not require that it be a registration authority be contacted"
 => "does not require that a registration authority be contacted"


Section 3 under "Conformance with URN Syntax":
    "an bit-oriented" => "a bit-oriented"

Section 4.2.1.2: "using it to construction the"
    => "using it to construct the"

Section 4.3: "the a UUID" => "a UUID"