Re: [802.21] Discussion thread for MIHF ID
Hi, Michael,
Please see my response in-line.
Michael.G.Williams@nokia.com wrote:
>> The only motivation that I know of for having MIHF_ID in the
>> first place is to have an unambiguous way to identity an MIHF
>> among a group of MIHFs that are talking to each other.
>> Uniqueness of the ID is the way to achieve this unambiguity
>> requirement. In other words, there is no intention to use
>> MIHF_ID for routing, charging, AAA, etc.
>>
>
> I don't think we should open up the discussion wider about what future
> purposes the MIHF ID might have. If you feel strongly that we need to
> define that in order to resolve this comment, then the discussion will
> have to broaden substantialy.
>
I had no intention to broaden the discussion.
>> If the deployment is global, then this unambiguity/uniqueness
>> needs to be global. But if the deployment is local (e.g.,
>> within a home, a municipal, a single operator, or an
>> association of operators), the unambiguity/uniqueness only
>> needs to be local to the deployment scope.
>>
>
> In a sense, any MIHF which can be reached over a routable IP address in
> the Internet is global. In this thread we discussed the MIH support of
> handover between administrative domains. The scenario of HO between
> domains illustrates there is a problem even within a fairly local
> geography, i.e. neighboring or overlapping domains. Do you agree there
> can be a problem in this scenario that the current spec doesn't resolve?
>
By "deployment scope", I mean the entire scope in which the node will
operate, which would naturally include all the roaming and inter-op
networks.
>> We have several options here:
>>
>> 1) Leave the MIHF_ID syntax undefined while expecting the
>> deployment will figure out its most convenient and economic
>> way to keep the uniqueness within its operation scope. (this
>> is my recommendation);
>>
>
> I don't think we can consider the comment resolved this way. Since we
> currently use examples only in the draft, and the comment is asking for
> something to be normative, your suggestion would go directly against the
> comment. We would not satisfy the objection. This would leave us with a
> serious hole in the draft. It would be very hard to get conditional
> approval for the draft from the EC with this hanging over us.
>
I am sure the comment is asking for normative text to define a global
uniqueness. Surely I would like to hear the reaction from the commenter.
>
>> 2) Define that it must use NAIs or FQDNs syntax, but don't
>> force global uniqueness (I can leave with that);
>>
>
> We are being too casual with the term NAI. Some forms of NAI are unique,
> while other forms are non-unique and would break the MIH protocol. If
> the mobile knows it is at home, it could present the username without
> @realm and things should work, but we don't specify this. Also, if the
> MN is using the NAI option for MIHFID and the MN is not at home, it has
> to use user@realm, right? If your mobile is assigned QB@motorola.com,
> then when you are on the Motorola network QB should work. If you go to
> Starbucks, Sprint or a different enterprise, QB just won't work.
>
If the MN is deployed to work among those networks, the MIHF_ID given to
the MN should be unique in that operating scope. This is just like there
is a "Starz Alliance" which contains a list of airlines, and members of
the alliance can enjoy some benefits from all participating airlines.
When you become a member of "Starz Alliance", you get a user ID; This ID
needs to unique only within the "Starz Alliance". To me, arguing for a
globally unique MIHF_ID is equal to arguing for a globally unique
frequent flier numbering system - Sure, it will work but it is just
totally unnecessary.
regards,
-Qiaobing
>
>> 3) Force it to take a global uniqueness (I oppose to this
>> strongly since I don't see the justification for this. Being
>> globally unique means a lot of complexity and restrictions
>> which translate into deployment cost.
>> If we take this route all those local deployment scenarios
>> will be forced to pay a penalty for something they don't need).
>>
> This point was raised in the ad hoc as well, and apparently was not
> resolved during the discussions. So it's good to revisit it and see if
> we can really resolve it. Let's look at the specific suggestions of
> leaving MIHF ID undefined, or using FQDN || username, or FQDN ||
> username@realm, and analyze their complexity and restrictions and
> resulting deployment costs. Doing that should resolve this concern?
>
> BR,
> Michael
>
>
>
>> regards,
>> -Qiaobing
>>
>> Michael G Williams wrote:
>>
>>> Hi Yoshi,
>>>
>>> Some responses below...
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
>>>> Sent: 06 March, 2008 15:40
>>>> To: STDS-802-21@LISTSERV.IEEE.ORG
>>>> Subject: Re: [802.21] Discussion thread for MIHF ID
>>>>
>>>> First, if we check the ABNF syntax of NAI format in RFC 4282, it
>>>> actually can represent IP address ('.' and ':' characters
>>>>
>> are allowed
>>
>>>> with '\' prefix) and IMEI. Said that I believe that we can safely
>>>> restrict MIHF-ID format to be either FQDN or NAI.
>>>>
>>>>
>>>>
>>> Does this mean NAI without the realm? Or with realm?
>>>
>>>
>>>
>>>> Second, I think that requiring global uniqueness for MIHF-ID is too
>>>> much. For example, realm part of NAI should not be needed to
>>>> identify an MN while the MN is within its home AAA domain.
>>>>
>>>>
>>>
>>> Agreed that within a home AAA domain, the administrator should not
>>> issue duplicate NAIs (or FQDNs) so realm would not be needed
>>>
>> there. So
>>
>>> that should also take care of fixed nodes in the network
>>>
>> that have an
>>
>>> MIHF ID.
>>>
>>> What about if the MN wants to get services from MIHF's within a
>>> visited domain? If the MN presents its home NAI without the realm,
>>> there could easliy be collisions with other MN's using the same MIHF
>>> ID when the MN visits another domain. How should those
>>>
>> collisions be handled?
>>
>>>
>>>
>>>> As long as uniqueness of MIHF-ID is maintained by each
>>>>
>> deployment of
>>
>>>> MIH services, it should be sufficient.
>>>>
>>>>
>>> Not sure what scope of uniqueness is being referred to here.
>>> Uniqueness within the AAA or home domain? As pointed out here and
>>> below in the thread, several ID candidates would cause
>>>
>> problems with that.
>>
>>>
>>>
>>>> This is similar to the fact that use of private IP address is not
>>>> prohibited in some deployment of IP-based applications.
>>>>
>>>>
>>> Local / private IP addresses are allocated or derived within the
>>> network where the MN is attached. If we had a scheme where
>>>
>> the MIHF ID
>>
>>> was also allocated to the MN when it attached to the network, that
>>> would be analogous. But our currrent spec doesn't support
>>>
>> something in
>>
>>> the protocol to assign an MIHF ID to a MN, does it?
>>>
>>> It seems so far the comments on this thread have agreed that
>>>
>> FQDN and
>>
>>> NAI with realm would work for MIHF IDs. So we can safely list those.
>>> The final sticking point seems to be around also including the
>>> non-unique NAI without realm. If we do allow NAI without realm, how
>>> does the MIHF in the network deal with two MN's presenting the same
>>> NAI to the CS, IS or ES server?
>>>
>>>
>>> Best Regards,
>>> Michael
>>>
>>>
>>>
>>>
>>>> Yoshihiro Ohba
>>>>
>>>>
>>>> On Wed, Mar 05, 2008 at 08:50:19PM -0600, 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>