Re: [802.21] Discussion thread for MIHF ID
Kevin,
I agree with your views here. All along we are advocating to have the
uniqueness within a given scope.
The current text says:
"MIHF Identifier (MIHF ID) is an identifier that is required to uniquely
identify an MIHF entity for delivering
the MIH services. MIHF ID is used in all MIH protocol messages. This
enables the MIH protocol to be transport
agnostic.
MIHF ID may be assigned to the MIHF during its configuration process.
The configuration process is outside the
scope of the standard. For example, MIHF ID may be an FQDN or NAI of the
sender of the registration request."
Since FQDN and NAI are examples, ID like IMEI can be easily used at the
mobile node. For network side, we
need a FQDN or NAI to discover the network MIH entity.
regards,
_Subir
Noll, Kevin wrote:
> 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.
>