21-05-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: LB #1b Comment Summary Date Submitted: March, 2007 Presented at IEEE session #19, Orlando Authors or Source(s): Inma Carrion Abstract: comments to commentary comments LB-1c

21-05-xxxx IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3

21-05-xxxx Comment #4043: Counter-proposal to the text proposed in ‘suggested remedy’ Note that the term MN is not appropriate when you are defining home/visited networks, the key issue is the subscription not the MN. Also, the correct term for ‘provisioning service provider’ actually is ‘serving network’, this term is widely used in 3GPP and 3GPP2 and we would be more compliant with them if we aligned our terminology. See below for proposed text. Add these definitions to section 3: home network: network managed by the operator with whom the subscriber has a business relationship (subscription) visited network: network managed by an operator other than the subscriber’s home operator and in which the subscriber is receiving service serving network: network that provides IP based data services to the user. The serving network may be a home network or a visited network Then change the text in section from ‘The terms Visited and Home are used to indicate the provisioning service provider or enterprise. Any of the illustrated networks could be both a visited or home network depending on the relation of the operator to the provisioner of the MN.’ to ‘The serving network for the subscriber at a given point of time may be the home network or a visited network.’ Please, change also this text in line 47 section 5.4.2: ‘The model assumes that the provisioning service provider either operates multiple access technologies or allows its user to roam into other networks when a service level agreement (SLA) in support of inter-working has been established.’ to ‘The model assumes that the serving network either operates multiple access technologies or allows its user to roam into other networks when a service level agreement (SLA) in support of inter-working has been established.’ Proposal and comments

21-05-xxxx Comment #4045: Addition to the text proposed in ‘suggested remedy’ Again the term provisioner is confusing. The idea is to have a general statement saying that the network serving the subscriber (MN) may use it’s own MIH server or others’. The text currently in the spec is confusing and restricts all the possible use-cases. Please, consider the change below to make the concept clearer: MIIS could also be available from another overlapping or nearby visited network, using that network's MIIS point of service. The serving network may utilize R3 and R4 interfaces to access other MIH entities. As an example, in figure 3 the home network may access it’s own MIH information server or core operator 1 (visited network) MIH information server. Proposal and comments

21-05-xxxx Comment #4417: Reserved values Related to this comment are the questions of: 1) should an information element in a message be considered incorrect if it contains a ‘reserved’ value? If yes, should the recipient ignore the IE and consider the rest of the message (it would be wise for backward/future compatibility) (This is not explained in the doc); 2) can a ‘reserved’ value be used in the future? (it would be good to clarify it since in the past there have been problems with different understanding of the use of reserved values, and therefore different implementations and lots of IOT problems). Note that it is not the same to specify an IE with some bits ‘reserved’ than as ‘reserved for future use’, when we only specify it as ‘reserved’ there we have the question on whether we can use those values in the future or not. Proposal: Add explanation of handling of ‘reserved’ values or refer to other IEEE specification where this is explained. A proposal could be: An IE shall be considered syntactically incorrect in a message when it contains a ‘reserved’ value. Reserved values can be used in future revisions of the protocol. Proposal and comments