RE: [802.21] Discussion thread for MIHF ID
Hi Subir,
This thread is in response to valuable comments against the draft by
Andrew Myles. He presented a large number of thoughtful and valuable
improvements to the spec. I don't think we should just ignore his
comment on MIHF ID and leave the draft the way it is now.
As far as IETF, the MIHF ID is not visible to the mstp transport is it?
So how is it relevant.
Your suggestion of FQDN or NAI without realm has some serious problems
that have been discussed at the ad hoc and in this thread. We need to
address those problems or we will be facing objections in the next
recirc.
Regards,
Michael
>-----Original Message-----
>From: ext Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
>Sent: 07 March, 2008 10:04
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: Re: [802.21] Discussion thread for MIHF ID
>
>I would support to keep the way it is currently in our
>specification. We just give example of FQDN and NAI.
>As I mentioned earlier, this is all along the assumption in
>IETF MIPSHOP. If we change that assumption we will have
>issues in MIPSHOP since the solution draft just completed WG
>last call. Also I really do not understand what is the issue
>here. By using FQDN and NAI , I think we allow everyone to
>satisfy their requirements.
>
>regards,
>-Subir
>
>Qiaobing Xie wrote:
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>