Re: [802.21] Discussion thread for MIHF ID
Hi Michael,
On Fri, Mar 07, 2008 at 03:12:43AM -0600, Michael.G.Williams@nokia.com 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?
Both.
>
> >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?
MN in a visited domain should provide its home realm in its MIHF-ID used
in the visited domain.
>
> >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.
For example, the scope of uniqueness can be within a AAA system
consisting of multiple AAA realms under the same roaming alliance.
There can be multiple AAA systems where roaming is not allowed among
them. There is no need to provide uniqueness of MIHF-ID among such
AAA systems.
>
> >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?
I think how MIHF-ID is assigned is a separate issue.
>
> 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?
This points to a AAA system consisting of multiple AAA realms under
the same roaming alliance. Suppose that NAI is used for MIHF-ID. In
this case, two MNs in the same AAA system can have the same username
with different AAA realms, say, MN1="foo@operator1.com" and
MN2="foo@operator2.com".
If the two MNs are in AAA realm "operator1.com", then MN1 can omit the
realm part (MN1's MIHF-ID="foo") while the MN2 should not omit the
real part (MN2's MIHF-ID="foo@operator2.com"). Obviously MN1's
MIHF-ID="foo" is not a global unique identifier, but MN1 and MN2 can
be distinguished within AAA realm "operator1.com".
Yoshihiro Ohba
>
>
> 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
> >>
> >>
> >>
> >>
> >
>
>