Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>   
>>>       
>
>