RE: [802.21] Discussion thread for MIHF ID
Uniqueness needs to have a scope. One can speak of uniqueness in terms
of administrative domains, global, etc. For example, MAC addresses are
(supposed to be) globally unique (I know there are exceptions to this),
but RFC1918 IP addresses are *not* globally unique, but are typically
unique to an administrative domain, or at least to a specific network.
So, what is the scope of the "uniqueness" referred to in and required by
8.3.1? Is this defined anywhwere (apologies for not reading the latest
draft, yet, to find out myself)?
I would argue from a SP's perspective that a globally unique ID would be
the best approach and that it should be something that is already
available on the mobile device (e.g., the IMEI for a mobile phone, or
MAC address for an 802-type device). Unfortunately, there is no
absolutely common unique identifer across all possible platforms that
might implement MIH functions.
In fact, in this approach, it's possible that a single device may have
multiple candidate unique ID's (for example, a laptop with a wired 802
interface and a wireless 802 interface).
I think the standard paints itself into a corner if it *requires* a
globally unique ID. Perhaps the language should be clarified that the ID
must be unique within an MIH administrative domain, and that if
administratively different networks are connected (which will be a
common case), then appropriate measures must be taken to guarantee
uniqueness between the domains.
Beyond this, I think we can make suggestions (as already have been), but
ultimately it will be up to the industry and implementors to figure out
the best practice.
--kan--
--
Kevin A. Noll, CCIE
Sr. Wireless Engineer
Time Warner Cable
13241 Woodland Park
Herndon, VA 20171
o: +1-703-345-3666
m: +1-717-579-4738
AIM: knollpoi
-----Original Message-----
From: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
Sent: Thursday, March 06, 2008 8:41 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Discussion thread for MIHF ID
Michael,
Thanks for bringing up the issue on the list. As I mentioned during the
ad hoc meeting, FQDN and NAI should be sufficient for our purpose. NAI
can be represented either as 'username' or 'username@realm'. In IETF, we
also made similar assumptions. Also IMO, the current text is good since
we provide the example of FQDN and NAI.
regards,
-Subir
Michael G Williams wrote:
>
> Colleagues,
>
> In the Santa Clara ad hoc and in previous meetings, we've discussed
> the definition of the MIHF ID. A commenter in the last SB requested a
> more definite specification for this field. Here is a summary of the
> issue, to help avoid spending a long time in the upcoming meeting
> revisiting the details.
>
> The discussion has centered around two approaches to choosing the MIHF
> ID 'space', let's label them as the unique and non-unique approaches.
>
> In the unique approach, the ID space is a finite collection of well
> known existing spaces that contain only unique elements such as FQDN,
> NAI@realm, IMEI, perhaps even something from 802.1.
>
> In the non-unique approach, we have added additional spaces to the
> above, that might have collisions, such as IP address and NAI.
>
> Currently the MIHF ID is mandatory in the PICS and must be non null in
> the MIB.
>
> 8.3.1 says the MIHF ID is required to uniquely identify the MIHF
entity.
>
> One proposal to resolve the two approaches was to define the MIHF ID
> to be the FQDN, the NAI with or without realm, the IMEI, or the IP
> address. This proposal is essentially the non-unique approach as
> namespaces with collision are included.
>
> If we permit collision name spaces as in the non unique approach, then
> we should define a way of resolving collisions in the spec.
>
> If we disallow collisions as in the unique approach, we can leave it
> to the implementation how to deal with collisions, as it is against
> the spec for a MN or NN to use such an MIHF ID.
>
> Please send comments to the list here, and we can resolve the comment
> by building consensus before the meeting.
>
> Best Regards,
> Michael
>
>
>
>
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.