There is a minor editing error in the prepub version of H.225.0v4. In section 7.6, concerning the definition of GloballyUniqueID, there is a numbered list specifying the algorithm. In item 5, the reference to table 20 should be to table 19 (tables were renumbering from v3 and the renumbering of the reference evidently didn't stay in synch). Perhaps this should be corrected in IG.
In addition, the specification of conditions underwhich the clock sequence value should be changed (two paragraphs above the numbered list) omits the case where the current UTC EQUALS the saved UTC. It specifies that the clock sequence value should be changed if the current is LESS than the saved value (non-monotonic case) but a similar problem occurs if the clock has not ticked (GID will not be unique). It would be better if the condition were reworded to say "if the current value less or equal or the saved value was lost..." and the bullet item above changed to "... the local value of UTC has gone backward or not increased..." (or an additional bullet item added). Admittedly, if the recommended 100ns clock tick is used, the probability of the clock not having advanced may be low, but not impossible as we move to faster processors. This problem is not new to v4 but since the correction would not cause a compatibility problem, it would be good to correct. If we do not choose to modify v4 through the IG we should at least make this change in v5.
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla