Re: [802.21] Discussion thread for MIHF ID
All,
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.
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.
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);
2) Define that it must use NAIs or FQDNs syntax, but don't force global
uniqueness (I can leave with that);
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).
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
>>>
>>>
>>>
>>>
>>>
>
>