RE: [802.21] Discussion thread for MIHF ID
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
>>
>>
>>
>>
>