RE: [802.21] Discussion thread for MIHF ID
Just my 2 cents below:
Instead of trying to come up with a new identifier to be used as MIHFID,
and discussing whether it should be locally or globally unique, why
don't we say that any existing identifier (eg the NAI of a subscription,
corporate or personal email, IP address, etc) can be used as MIHFID.
Most of the identifyers of an MN are anyway globally unique, and there
is no reason to find one which is locally scoped. The IP address can be
a private one, but there is always a public IP address assigned to that
MN on the other side of the NAT, and that can be found out using STUN.
The MN does all these procedures anyway, because finding one or more of
its globally unique identifiers is required by different protocol
stacks. And one of those identifyers could be used as mihfid.
What I am trying to say is that there should be no requirements on how
to construct an mihfid, but just to say that any of the anyway available
(global) identifyers can be used for that purpose (NAI, public IP
address, email, etc). Fqdn or username without realm are probably not
good examples.
- gabor
-----Original Message-----
From: ext Michael G Williams [mailto:Michael.G.Williams@NOKIA.COM]
Sent: Friday, March 07, 2008 5:17 PM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Discussion thread for MIHF ID
Hi QB,
Thanks for your input. The Editor's opinion is always carrying a lot of
weight. Responses below...
BR,
Michael
>-----Original Message-----
>From: ext Qiaobing Xie [mailto:qiaobing.xie@GMAIL.COM]
>Sent: 07 March, 2008 09:41
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: 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.
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.
>
>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?
>
>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.
>
>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.
>
>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>