| DocNumber | First Name | Last Name | Comment Number | Comment Date | Comment Type | Starting Page Number | Starting Line Number | Section | Change | Reason | Resolution of Group | Decision of Group |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P802-21/D06.00 | Peretz | Feder | 6028 | 2007/07/14 | Technical, Binding | 63 | 39 | 7.2.2.2 | Delete the Reset primitive, lines 37-39 |
What is the difference between Initialize and Reset primitives? | Accepted | |
| P802-21/D06.00 | Ajay | Rajkumar | 6032 | 2007/07/14 | Technical, Binding | 66 | 14 | 7.3.3 | Link_Configure_Threshold could be issued by multiple MIH users for the same resource. If indications need to be generated by the lower layers for these configured parameters | The indications generated when link layer parameters cross thresholds, include the specific threshold that they have crossed and can thus identify these thresholds and corelate to them. | Rejected | |
| P802-21/D06.00 | Ajay | Rajkumar | 6033 | 2007/07/14 | Technical, Binding | 69 | 8 | 7.3.6.1 | Delete lines 10-14 | No such MIH primitive for configuring time interval of when "Going Down" event is posted. | Accepted | |
| P802-21/D06.00 | Ajay | Rajkumar | 6037 | 2007/07/14 | Technical, Binding | 71 | 24 | 7.3.8.3 | Change text to "The Link Detected event is generated on the MN when the first PoA of an access network is detected." | Sentence not clear | Change text to "The Link Detected event is generated on the MN when a PoA of an access network is detected for the first time." | Accepted-Modified |
| P802-21/D06.00 | Ajay | Rajkumar | 6038 | 2007/07/14 | Technical, Binding | 71 | 40 | 7.3.9.1 | Add "or generated at specified intervals for various parameters". | The indication can be generated periodically or when specific thresholds are crossed | Link_Parameters_Report indicates changes in link parameters that have crossed specified threshold levels. Link_Parameters_Report may also be generated at specified intervals for various parameters. |
Accepted-Modified |
| P802-21/D06.00 | Ajay | Rajkumar | 6040 | 2007/07/14 | Technical, Binding | 71 | 61 | 7.3.9.2 | LINK_PARAM_REPORT is not defined. Also, doesn't account for generation at periodic intervals. | Page 180, Line 12. Change "RSP" to "LINK_PARAM_REPORT" |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6041 | 2007/07/14 | Technical, Binding | 72 | 3 | 7.3.9.3 | Change "This notification is generated" to "This notification is generated for each parameter". | Periodic notification is on a per parameter basis as stated in the text. |
The text already implies it that way. No further change is needed. | Rejected |
| P802-21/D06.00 | Ajay | Rajkumar | 6042 | 2007/07/14 | Technical, Binding | 72 | 17 | 7.3.10 | Delete the indication | This indication does not belong to this draft since no means in being specified how a packet identifier is being passed to the lower layers. If there is a means to pass the identifier outisde of this draft then the same route should be used to send the indication. | There do exist ways of implementing this indication. as such there is no need to delete this indication. | Rejected |
| P802-21/D06.00 | Ajay | Rajkumar | 6044 | 2007/07/14 | Technical, Binding | 73 | 31 | 7.3.11.1 | Delete "It also contains…on the mobile node" Delete "and as an enabler for initiating effective make-before-break handovers" |
There is no such information provided: "It also contains…on the mobile node". The following is an intra-technology event only: "and as an enabler for initiating effective make-before-break handovers" |
Accepted | |
| P802-21/D06.00 | Ajay | Rajkumar | 6049 | 2007/07/14 | Technical, Binding | 76 | 59 | 7.3.14.2.2 | Change CoS value to be a list of values | LINK_PARAM is incomplete (page 180, line 18). CoS value cannot be encoded (e.g. when asking for "CoS Minimum Packet Transfer Delay"). Since the type is specified as a "Cos" minimum (not simply a minimum) then which CoS value is being returned. | Remove all CoS from the LINK_PARAM_GENERAL enum (page 178 L23-30) Editorial typo on page 183 L48 (B2.4) Change QoS List -> QoS Param Add QoS PARAM (see B2.4) after LINK_PARAM_GENERAL in LINK_PARAM_TYPE |
Accepted-Modified |
| P802-21/D06.00 | Ajay | Rajkumar | 6053 | 2007/07/14 | Technical, Binding | 77 | 47 | 7.3.15.1.2 | LINK_ACTIONS should be broken into two types; an action and an attribute. Additionally, a single action should be specified (thus an enumeration would be a better choice over a bitmap). Only have an enumeration of Actions per Link_Action so that the result code is unambiguous |
How will exection time apply when more than one action is specified? (Note: link actions is a bitmap). | Please refer to contribution 21-07-0273-00-0000 for resolution Also refer to comment 6060. |
Accepted-Modified |
| P802-21/D06.00 | Ajay | Rajkumar | 6058 | 2007/07/14 | Technical, Binding | 78 | 25 | Specify the type | No type specified for ScanResponseSet | Specify the data type as LIST (LINK_SCAN_RSP). | Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6060 | 2007/07/14 | Technical, Binding | 78 | 27 | Since Link Actions are not necessarily related to handover results remove reference to "handover results". Only have an enumeration of Actions per Link_Action so that the result code is unambiguous |
LINK_AC_RESULT_CODE definition refers to handover results (see page 177, lines 4-8). Also, it is unclear how the case when multiple link actions were specified but there is only 1 result code is handled? | Change "Handover Result" to "Link Action Result" on page 177 line 4, which is the definition of LINK_AC_RESULT_CODE |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6061 | 2007/07/14 | Technical, Binding | 80 | 36 | 7.4.1.2.4 | Specify that an MIH User "must" provide a response when an indication is received and that no indication is posted if the MIHF is responding directly. | MIH User may respond inidcates that the response may not be generated even if an indication is received | Accepted | |
| P802-21/D06.00 | Ajay | Rajkumar | 6065 | 2007/07/14 | Technical, Binding | 82 | 14 | Make it consistent. Delete Supported Links. All of the commands which contain a request, indication, response and confirm need to have the "MIH transaction identifier" added as one of its parameters for the indication/response. This allows the MIHF to identify and map the response to the corresponding request. For example, if multiple GetInfo commands are pending at a remote MIHF how can we map a given repsonse to the correct request. Could think of it as 3 separate transaction; MIH User ->MIHF; MIHF-> MIHF; MIHF->MIH User Note: We also need a way of subscribing to these "indications" otherwise who do they get delivered to, since these are not the events that come from lower layers? |
Supported MIH Event List is different than that specified in request, indication, response. Also, the information in Supported Links is already included in Link MACs thus it is not needed |
Delete Supported Links. Make the data type for SupportedMIHEventList be made CONSISTENT with that in request, indication and response primitives. |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6069 | 2007/07/14 | Technical, Binding | 95 | 12 | LINK_PARAM_REPORT is not defined. Also, doesn't account for generation at periodic intervals. | by comment 6040 | Superceded | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6071 | 2007/07/14 | Technical, Binding | 96 | 25 | 7.4.12.1 | Delete the indication. Also, for all handover related commands, need to explicitely refer to either network or MN side, rather than "remote" or "peer". Besides, there is no mention on which MIH User gets these indications, nor on what happens if more than one generates a response. We may need a subscription method (similar to events) and should only one be allowed to get the handover messages? |
No means have been specified as to which MIH User these indications should be sent to. | by comment 6042 Event Service does have a subscription model, so the statement "No means have been specified as to which MIH User these indications should be sent to." is not valid. |
Superceded |
| P802-21/D06.00 | Ajay | Rajkumar | 6086 | 2007/07/14 | Technical, Binding | 106 | 32 | If it is referring to QOS_LIST on page 183, line 48, yet QOS_LIST contains everything so a LIST(QOS_LIST) is not needed and a QOS_LIST should be specified. | QOS_PARAM is not defined Same is applicable to the following Page 107, lines 29-30: Page 108, lines 32-33: Page 109, lines 44-45: Page 110, lines 54-55: Page 112, lines 6-7: Page 113, lines 9-10: Page 114, lines 8-9: Page 115, lines 12-13: Page 116, lines 17-18 |
Replace LIST(QOS_PARAM) by QOS_LIST Also please refer to comment 6049. |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6087 | 2007/07/14 | Technical, Binding | 106 | 35 | Change "Lists the reason for aborting/declining the handover request" to "Lists the accpetance status (permit/decline) of the handover request" | Since this primitive is a Query response, handover status could not be abort | Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6089 | 2007/07/14 | Technical, Binding | 107 | 52 | 7.4.19 | Propose that IP configuration method be mandatory and that only one of the IP addresses is provided. Additionally, we want to add IP Configuration method to the Net_HO_Candidate_Query.response (with the same restrictions). |
This request contains more information about resource requirements than the corresponding Net_HO_Candidate_Query.response. In both cases, the network PoS would query the candidates to see if it could support the requested resources (however, in the network initiated handover case, it may have less information, e.g. no IP configuration or address). |
The IP configuratiion methods cannot be made mandatory since that depends on available information. | Rejected |
| P802-21/D06.00 | Ajay | Rajkumar | 6091 | 2007/07/14 | Technical, Binding | 110 | 54 | 7.4.19.3.2 | If is it referring to QOS_LIST on page 183, line 48 then there is no correlation to a specific link. In fact, we have the same comments as previous versions (available resource set, IP configuration method, DHCP address, FA address, Access router address, IP address information status must all be on a per candidate basis). Note: if resources on a candidate are dependent on a particular PoA then all of these parameters need to be on a link and PoA basis. | Available resource set is a LIST(LIST(QOS_PARAM)) but QOS_PARAM is not defined Comment applicable to Page 112, lines 6-7 as well |
Replace LIST(LIST(QOS_PARAM)) by LIST(QOS_LIST) | Accepted-Modified |
| P802-21/D06.00 | Ajay | Rajkumar | 6094 | 2007/07/14 | Technical, Binding | 112 | 50 | Delete the "prepare the new link resource for impending handover" |
The text states that it is used to "prepare" for pending handover and "query" for available resources. It seems to imply the resources are allocated/reserved (prepare) and queried all in one command. If this is true then how do you notify the candidates which are not selected for handover (so they can release resources). | Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6097 | 2007/07/14 | Technical, Binding | 113 | 12 | Refer to page 107, section 7.4.19 for resolution. |
These parameters are not available for network initiated handovers (Net_HO_Candidate_Query.request). If the assumption is that these are indeed available for N2N_HO_Candidate_Query.request then these should be added to Net_HO_Candidate_Query.response/request as well. | by comment 6089 | Superceded | |
| P802-21/D06.00 | Ajay | Rajkumar | 6101 | 2007/07/14 | Technical, Binding | 115 | 42 | Replace Net_HO_Candidate_Query.response with MN_HO_Candidate_Query.response | This statement references the wrong message (Net_HO_Candidate_Query.response rather than MN_HO_Candidate_Query.response) | After receiving the response, the MIHF on the serving network may send an MIH_MN_HO_Candidate_Query response message to the mobile node if a MIH_MN_HO_Candidadte_Query request message was received earlier. |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6105 | 2007/07/14 | Technical, Binding | 117 | 39 | If response is expected then change "may" to "shall" for the generation of the indication. Also, since this is a "network controlled" handover the message should clearly state the target link |
This message appears to be processed by the MN MIHF without any action by the local MIH User. In fact, the corresponding indication "may" be posted (but doesn't have to be). However, the response is generated by the MIH User thus if there is no indication then there can be no response. | Delete this paragraph: "A corresponding indication message (MIH_Net_HO_Commit indication) may be triggered to send to all subscribed MIH User entities in the local stack. The associated parameters for the generated indication are the same as those used in the command request" |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6106 | 2007/07/14 | Technical, Binding | 118 | 16 | The group should take a decision on multiple MIH Users issue. | States that an MIH User must generate a response to the indication while (pg 117, line 39) states that the indication is sent to ALL subscribed MIH Users. This would imply that multiple responses could be generated and there would be no way to correlate them back to the original request since the MIH protocol requires a single response to each request (i.e. a transaction). Additionally, if the MIHF carries out the link actions then how does the MIH User get the status so that it can create the appropriate response. | This is implementation specific issue. | Rejected | |
| P802-21/D06.00 | Ajay | Rajkumar | 6108 | 2007/07/14 | Technical, Binding | 118 | 47 | see previous comment as breaking link action into action (enumeration) and attribute (bitmap) | If there are multiple link actions per link then the LINK_ACTION_RSP does not contain enough information to correlate the status to a particular action (all if has is link and status of action). | by comment 6060 | Superceded | |
| P802-21/D06.00 | Ajay | Rajkumar | 6110 | 2007/07/14 | Technical, Binding | 119 | 47 | Delete "The MN recipient may initiate a handover process and begin the setting up of the new layer 2 connection. Similarly, the network recipient may determine that the handover procedure is in progress to the intended network." | These lines state that the MN may initiate a handover process and begin setting up a L2 connection but, wasn't that the intent of the link actions? In order to send the response we must have completed the actions (so that we can send back their status). |
Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6111 | 2007/07/14 | Technical, Binding | 121 | 24 | Propose that sending indication is a "shall" | Again, it appears that sending the indication is optional and since the response is generated by the MIH User there is the possibility that a response will never be generated. |
Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6115 | 2007/07/14 | Technical, Binding | 123 | 26 | Delete the message | What is the purpose of this message and what can the candidate do with only the MN MIHF ID? |
This message is intended to communicate the intent to commit a handover and is required. | Rejected | |
| P802-21/D06.00 | Ajay | Rajkumar | 6118 | 2007/07/14 | Technical, Binding | 126 | 2 | Change "link identifier" to "source link identifier" and add "target link identifier" parameter so that it can be included in the corresponding N2N_HO_Complete message. | Provide explicit identification to "link identifier" Also for the Page 126, line 49 |
All corresponding messages related to MIH_MN_HO_Complete need to be updated in section-8 as well. | Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6120 | 2007/07/14 | Technical, Binding | 126 | 64 | Delete "mobile initiated". | This can be sent at the completion of either a Network or MN initiated handover. | Modify the sentence as follows: "This indicates the completion of the MIH level mobile initiated handover. A corresponding response is generated" |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6123 | 2007/07/14 | Technical, Binding | 128 | 13 | change to "shall" (i.e. always generates a confirm when a response is received). | The "may" makes it sound optional, | Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6125 | 2007/07/14 | Technical, Binding | 128 | 54 | Suggest replacing current and old link identifiers with "source" and "target" link identifiers (which can be found in the proposed fields of the corresponding MN_HO_Complete request message described above). | This parameter is included only when the corresponding MIH_MN_HO_Complete request was received at the Serving PoS. By "Serving PoS" does it imply the original serving or the current serving (i.e. target PoS)? If it is the former, then the current and old link identifiers are the same (e.g. handover failed) whereas for the latter, the target PoS may not know what the original PoS was. |
Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6126 | 2007/07/14 | Technical, Binding | 129 | 4 | Delete "to the new network Poa" in order to account for a handover failure. | Handover failure not accounted for. | The MIH User invokes this primitive when handover operations to the new network PoA have been completed | Accepted | |
| P802-21/D06.00 | Ajay | Rajkumar | 6128 | 2007/07/14 | Technical, Binding | 131 | 48 | Delete "Upon receipt, the MIHF in the new network may forward this message to the MN." | This message is not forwarded but a response to a MN_HO_Complete request may be sent. | Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6141 | 2007/07/14 | Technical, Binding | 149 | 8 | Remove the sentence | Fragmentation can't be an implementation detail otherwise you would lose interoperability. | Accepted | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6155 | 2007/07/14 | Technical, Binding | 166 | 27 | LinkActionList Set is different from MIH_SAP | It is not different. The .request primitive and the request message have the same parameter | Rejected | ||
| P802-21/D06.00 | Ajay | Rajkumar | 6168 | 2007/07/14 | Technical, Binding | 176 | 29 | See comment above about splitting this into twp types; action and attribute). | Change LINK_ACTIONS to LINK_ACTION to better represent a single action. Currently it is defined as a bitmap. | by comment 6089 | Superceded | |
| P802-21/D06.00 | Ajay | Rajkumar | 6169 | 2007/07/14 | Technical, Binding | 177 | 38 | Replace with the following: Disconnect - turn down traffic channel (implicitly idle) Low power - battery function (radio off and battery saving) Power down - turn off radio |
The following definitions need to be more clear. For example, typical cellular systems have there own power control (RF) algorithms stated. A Link Action does not reset these RF levels. | Change definitions as follows: LINK_LOW_POWER: Cause the link to adjust its RF its battery power level to be low power consumption LINK_POWER_DOWN: Cause the link to power down so as to stop transmitting and enter idle mode or turn off the radio. |
Accepted-Modified | |
| P802-21/D06.00 | Ajay | Rajkumar | 6170 | 2007/07/14 | Technical, Binding | 177 | 4 | Definition should be "Link Action Result" Valid range should only related to Link Actions; None of the action results correlate with any actions |
While this is supposed to be for LINK_ACTION results, the description and specified values are for handover results. | Change "A handover result." to "Link Action Result" | Accepted | |
| P802-21/D06.00 | Junghoon | Jee | 6179 | 2007.07.13 | Technical, Binding | 187 | 26 | B.2.6 | We suggest making an amendment for Section 6.3.4 and adding the Section 6.3.5 using the contribution 21-07-0151. | The IEEE P802.21/D06.00 specifies the data types for IP configuration in the B.2.6. That existing data types needs to be amended concerning the following problems and suggestion. - The IP_MOBILITY_MGMT data type contains redundant information of configuring the IP address which is already defined through the IP_CONFIG_METHODS data type. - The IP_MOBILITY_MGMT data type needs to allocate bits for Proxy Mobile IPv4, Proxy Mobile IPv6, Mobile IPv4 Regional Registration and Hierarchical Mobile IPv6. - There needs a new data type for fast handover protocols like low latency handoffs and fast handover for Mobile IP. |
Please applyi the amendment by referring to the contribution, 21-07-0255-02-IE-MN-FH | Accepted-Modified |