Subject: RE: [Sip] GRUU Issue 3: Format of instance ID

From: "Orit Levin" <[email-masked]>
Date: Fri, 12 Mar 2004 17:00:14 -0800

Whatever ensuring global uniqueness format we recommend, the document
needs to make clear that from SIP perspective the uniqueness MUST be
achieved per AOR, not necessarily be globally unique in general.

Some system integrators will require (and ensure) that different vendors
generate unique instance identifiers in "HW" according to a
specification chosen by the integrator (and hopefully recommended by
us).

Other SW system integrators will be able to configure a simple formula
for generating instance identifiers unique within an AOR.

The complexity to find a perfect formula depends on what kind of clients
are allowed to register under a single AOR in a given system.

Orit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Friday, March 12, 2004 4:17 PM
To: [email-masked]
Subject: [Sip] GRUU Issue 3: Format of instance ID

The specification is currently not clear on how ones computes an
instance ID. It  has this to say:

Summary of the media feature indicated by this tag: This feature tag
       contains a string that indicates a unique identifier associated
       with the UA instance registering the Contact. This identifier is
       globally unique, and remains bound to the UA instance for as long
       as is achievable. For UA instances that are implemented as
       hardware, such as an IP phone, the instance ID would ideally be
       burned into firmware when the device is manufactured. For
       software, the instance ID would generally be randomly created at
       installation time.

Do we need to say something more specific? A point was raised during the
meeting that its not sufficient to merely say its unique. THe problem is
that two separate instances may compute an instance which is unique
within the approach they are using, but conflicts with a value in
another approach.

As an example, lets say one UA defines uniqueness by encoding its MAC
address forwards, and the other by encoding it backwards. Two instances
with unique MAC addresses may end up with the same instance ID.

So, it seemed like we DID need to say something about how to compute
this. That seemed a difficult thing to do, as we had several different
proposals on the table that all seemed reasonable. So, we left the
meeting without consensus.

I'd like to recommend the following solution:

"This feature tag contains a string that is a URN [URN-REF]. This
specification makes no normative recommendation on the specific URN that
is to be used. However, the URN namespace and URN value MUST be selected
such that the instance can be certain that no other instance would
choose the same URN value for that particular namespace. One URN that
readily meets this objective is the UUID URN [UUID-REF], which allows
for non-centralized computation of a URN based on time, unique names
(such as a MAC address) or a random number generator. An example of a
URN that would not meet this objective is the national bibliographic
number [RFC3188]; since there is no clear relationship between an SIP UA
instance and a URN in this namespace, there is no way a selection of a
value can be performed that guarantees that another UA instance doesn't
choose the same value."

UUID-REF corresponds to
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt. This
seems to really be exactly what we want, since it allows for computation
of a URN based on MAC address, time, or random number, and all of the
hard stuff is already worked out. My proposed text, fortunately, makes
the URN UUID specification only informative. However, in the absence of
any other viable URNs that are already at RFC, practically speaking this
would be the only choice, and so completion of that spec will be
important for us. Its currently under IESG evaluation, but not without
some controversy.

Do people feel that this is an acceptable solution?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip