GloballyUniqueID duplicates

[Glen Freundlich]

According to H.225.0 section 7.6:

"The clock sequence is required to detect potential losses of
monotonicity of the clock."

...and...

"While a node is operational, the GloballyUniqueID generator always
saves the last UTC used to create a GloballyUniqueID. Each time a new
GloballyUniqueID is created, the current UTC is compared to the saved
value and if either the current value is less (the non-monotonic clock
case) or the saved value was lost, then the clock sequence is
incremented modulo 16,384, thus avoiding production of duplicate
GloballyUniqueIDs."

The obvious interpretation :-) is that the clock sequence is incremented
when the clock value of the previous GloballyUniqueID and current clock
do not allow unique identification. I'd be glad to modify the text to
make this clear.

Perhaps we could also add clarifying text to the implementors guide.

Glen


Douglas Clowes wrote:
>
> At 18:43 16/06/98 -0700, you wrote:
> >>----------
> >>From:  Douglas Clowes[SMTP:dclowes at OZEMAIL.COM.AU]
> >>On reading the text in H.225.0 describing the construction of a globally
> >>unique identifier, it seems to me that duplicates are possible if the clock
> >>has not advanced since the last identifier was generated.
> >That's what the clock sequence value is for.
> >
> >Paul Long
> >Smith Micro
> >
>
> Perhaps, but on my reading, it's not what the document says!
>
> Douglas Clowes
> OzEmail Interline

--
Glen Freundlich                           ggf at lucent.com
Lucent Technologies                       office: +1 303 538 2899
11900 N. Pecos                            fax: +1 303 538 3907
Westminster, Colorado 80234  USA