Re: [802.21] Discussion thread for MIHF ID
Michael,
Thanks for bringing up the issue on the list. As I mentioned during the
ad hoc meeting, FQDN and NAI should be sufficient for our
purpose. NAI can be represented either as 'username' or
'username@realm'. In IETF, we also made similar assumptions. Also IMO,
the current text is good since we provide the example of FQDN and NAI.
regards,
-Subir
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
>
>
>
>