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.
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. As long as
uniqueness of MIHF-ID is maintained by each deployment of MIH
services, it should be sufficient. This is similar to the fact that
use of private IP address is not prohibited in some deployment of
IP-based applications.
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
>
>
>
>