| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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