Comment ID,Date,Comment .,Name,Email,Phone,Style,Index .,Classification,Vote,Category,Page,Subclause,Line,Comment,File,Must Be Satisfied,Proposed Change,Resolution Status,Resolution Detail,Other1,Other2,Other3
3251400023,10/02/2007 17:21:22 EDT,650,"Jeffree, Tony",ignore-U1239600001-7dbbfd43@ieee.org,,,2,,,General,,,,"The draft pays lip service to security, yet a large part of the
discussion within 802.11 and ongoing as part of P802.1af is concerned
with optimizing the number of exchanges involved and rapidly
obtaining the necessary information to re-establish prior security
associations/and or make use of previously distributed keys. The
separation of handoff/handover/roaming/discovery concerns from those
of security is unrealistic and calls into question issues that range
from the architectural placement of the handoff function to the
detailed design of messages and information elements. It is
completely unclear how the functions and information provided by this
draft would fit within the framework of the established 802.1X
standard, the EAPOL protocol and its use of EAP, and the P802.1af
amendment. Security of information transfer is required, but a major
issue in handover/roaming/discovery in secured networks is
determining the policy for making tentative decisions on unsecured
information and confirming those decisions later.",,No,,Disagree,The security sub-clause in section 5 has been deleted. All security related issues will be handled by the security Study Group in a future revision of the standard.,,,
3251300023,10/02/2007 17:20:29 EDT,649,"Jeffree, Tony",ignore-U1239600001-7dbbfd43@ieee.org,,,1,,,General,,,," It is entirely unclear what it means to claim conformance to this
standard. There is no conformance clause. There is no PICS (Protocol
Implementation Conformance Statement). There are 216 instances of the
word ""shall"" but a number of these are meta comments on the nature of
the standard itself, including statements that restrict the impact of
the standard such as ""The architectural placement of any MIHF shall
be left for the 3GPP2 standards development organization (SDO).
Figure 10 is for illustrative purposes only and shall not constrain
implementations"" and ""If the MN cannot reach the MIH PoS via the
lower layer (L2) transport mechanisms, then higher layer (L3)
transport mechanisms shall be used."" Other shalls are at a
considerable level of detail and express how a particular action is
to be taken, but not whether the procedure of which the action is a
part is mandatory for a claim of conformance. There is at least one
""shall"" statement that media specific procedures (where defined)
would take precedence, since there is no way of specifying a unique
reference document for each specific media that makes it impossible
to know what should be implemented now and what in the future as
media specific documentation changes. There are 433 instances of the
word ""may"", the use of this word is not defined within the standard
but appears to indicate (as usual) an implementation option. The
provision of 433 explicit implementation options appears excessive.
It would appear to be impossible to assess the level of
interoperability to be expected between two independent
implementations that might claim conformance to this standard.",,No,,Disagree,"The use of shall and may within the draft 802.21 is as per the IEEE Standards Style Manual (Dated January, 2007).  A PICS is not required as part of an IEEE 802 standard.",,,
3193800023,09/17/2007 18:08:47 EDT,648,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,6,Producer,Disapprove,General,193,B-12,24,"Parameters DCD, UCD, SIB, system_parameters are not defined",,Yes,define,Principle,Please refer to contribution 21-07-0317-01-0000-System_Information_IE,,,
3193700023,09/17/2007 18:07:43 EDT,647,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,5,Producer,Disapprove,General,186,,,"Table B-8, supported_LCP values was present in version 6.0
It disappeared from version 7.0 without a comment to remove it!!!!!!!!!!!!!!!!!!!!!!
why?
should be put back",,Yes,put back the text,Agree,,,,
3192900023,09/17/2007 08:47:07 EDT,646,"Olvera, Ulises",ulises.olvera-hernandez@interdigital.com,15149046282,Individual,1,Producer,Disapprove,General,292,Annex L,1,"1) These recommendation should be normative for 802.21, although the actual realization of the recommendation is upto the Technical Standards Organization that implements it.
2) Furthermore, references to specific requirements and suggested amendments are stil not defined. The reference iteself shows ""xxxx"" that denote that these docuements are not available.",,Yes,"1) Simple write ""(Normative)"" at the begining of the section.
2) Either generate the reference and write the appropriate number or do not reference documents that have not been written.",Agree,,,,
3192700023,09/16/2007 23:51:48 EDT,645,"Henderson, Gregory S",gshenderson@rim.com,469 235 6388,Individual,4,Producer,Disapprove,General,208,Annex D,1,XML does not compile,,Yes,"Change <!ENTITY mihbasic ""URL_TO_BE_ASSIGNED"">
to:
<!ENTITY mihbasic ""http://www.mih.org/2006/09/rdf-basic-schema#"">",Agree,URL_TO_BE_ASSIGNED will be updated subsequently,,,
3192600023,09/16/2007 23:51:48 EDT,644,"Henderson, Gregory S",gshenderson@rim.com,469 235 6388,Individual,3,Producer,Disapprove,General,196,Table B14,24,NETWORK_TYPE_INCLUSION does not include values for 3GPP and 3GPP2,,Yes,Define values for these two networks,Disagree,3GPP and 3GPP2 networks have been included in the table. Commenter to come back with any specific inputs if required.,,,
3192500023,09/16/2007 23:51:48 EDT,643,"Henderson, Gregory S",gshenderson@rim.com,469 235 6388,Individual,2,Producer,Disapprove,Technical,196,Table B14,8,"NETWORK_TYP
E_INCLUSION valid range data does not match same data in Tale B13 line 8-26",,Yes,Correct table B14 to match B13,Principle,For table B-13. For a specific Revision Type and define a Technology Standard specific field which could have feature specifc values.  Please refer to contribution 21-07-0422-00-00000,,,
3192400023,09/16/2007 23:51:48 EDT,642,"Henderson, Gregory S",gshenderson@rim.com,469 235 6388,Individual,1,Producer,Disapprove,Editorial,134,7.4.27.2.2,39,Sytax of primitives in text doesn't not match syntax in adjoining description table line 39-65,,Yes,Delete spaces in table syntax,Disagree,this is a convention used throughout. spaces are used in table for better readability,,,
3192300023,09/16/2007 23:46:35 EDT,641,"Kim, Eunah",eakim@etri.re.kr,82-42-860-4820,Individual,4,General Interest,Disapprove,Technical,140,,10,NMS is used for network management and is to be a stand-alone system. It means that having MIH_NMS_SAP for the interface with the NMS doesn't seem to be appropriate.,,Yes,Delete section 7.6,Agree,This applies to the entire draft.,,,
3192200023,09/16/2007 23:46:35 EDT,640,"Kim, Eunah",eakim@etri.re.kr,82-42-860-4820,Individual,3,General Interest,Disapprove,Technical,32,,11,NMS is used for network management and is to be a stand-alone system. It means that having MIH_NMS_SAP for the interface with the NMS doesn't seem to be appropriate.,,Yes,Delete section 5.6.3.2,Agree,,,,
3192100023,09/16/2007 23:46:35 EDT,639,"Kim, Eunah",eakim@etri.re.kr,82-42-860-4820,Individual,2,General Interest,Disapprove,Technical,23,,37,"The definition of NMS (Network Management System) is not defined in section 3. NMS is a term that describes a computer-based software application suite dedicated to the management of networks of NEs (Network Elements). Typically, the NMS provides abstractions (such as signaling links and virtual connections) appropriate to the overall running of a network; that is, it is not exclusively concerned with the details of one NE. Communication between an NMS and NEs is typically executed via an EMS (Element Management System), where the latter may reside on the NE. (http://authors.phptr.com/morris/glossary.html)
According to the above text, NMS is used for network management and seems to be a stand-alone system. It means that having MIH_NMS_SAP for the interface with the NMS in Figure 4 - general MIHF reference model and SAPs doesn't seem to be appropriate. Furthermore, the primitives for NMS are rather to be system functions and implementation specific.",,Yes,Delete MIH_NMS_SAP and Network Management System in Figure 4 and apply it to all related sections,Agree,,,,
3192000023,09/16/2007 23:46:35 EDT,638,"Kim, Eunah",eakim@etri.re.kr,82-42-860-4820,Individual,1,General Interest,Disapprove,Technical,23,,3,"MIH_NET_SAP and MIH_LINK_SAP both specify abstract media-dependent interfaces. MIH_NET_SAP provides transport services over the data plane on the local node and MIH_LINK_SAP specifies the interface between the MIHF and lower layers. When transport services over L2 are used, MIH_NET_SAP becomes equal to MIH_LINK_SAP and is mapped to the real media dependent SAP such as LSAP or MLME_SAP that doesn't belong to data plane. It causes some duplication of SAPs for the transport services over L2 and also shows the inconsistency for the role of MIH_NET_SAP. For transport services over L3, we can use existing NSAP(Network SAP) and/or TSAP(Transport SAP), depending on the decision of MISHOP WG. As these SAPs are located under the MIHF, integration of MIH_NET_SAP and MIH_LINK_SAP would be a good solution.",,Yes,Integrate MIH_NET_SAP and MIH_LINK_SAP into MIH_LOWER_SAP (it can include NSAP and/or TSAP etc) and apply it to all related sections.,Disagree,MIH_NET_SAP is for transport selection only and is better represented separately,,,
3191900023,09/16/2007 23:32:08 EDT,637,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,10,General Interest,Disapprove,Technical,290,K,36,The equation presented for ATDmpdu is not correct. Dividing the ATDmsdu by the number of MPDUs in the MSDU will not yield an average MPDU transmit delay. The average MPDU transmit delay is the sum of the transmit delays of each MPDU divided by the number of MPDUs. The shortest MPDU transmit delay is the first MPDU of the MSDU The longest MPDU transmit delay is the last MPDU of the MSDU. The average MPDU transmit delay is approximately equal to the transmit delay of the middle MPDU.,,Yes,Fix this basic misunderstanding.,Principle,Add summation to delay formula line 38,,,
3191800023,09/16/2007 23:32:08 EDT,636,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,9,General Interest,Disapprove,Technical,289,K,7,"Lines 7-45: The concept of Counters is misused on this page. 802.11 MIB counters are simple incrementing values. The value of any counter at any time is arbitrary. PER, PLR and other usefule parameters cannot be derived from the raw values in any of the MIB counters. Delta values over any time period may be used for the intended purpose here. THat is counter values must be captured at the beginning and end of a period of interest. Subtracting the ending value from the value at the beginning of the period produces a relevant count for that period. This is only true, however, if counter overflow does not occur during the period of interest.",,Yes,Fix this basic misunderstanding.,Principle,,,,
3191700023,09/16/2007 23:32:08 EDT,635,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,8,General Interest,Disapprove,Technical,289,K,4,ACK failure is not related to PLR. ACK failure is a transmit side metric equivalent to packet not received or packet received with error. Packets with failed ACK are simply retransmitted. Many 802.11 links exhibit finite PER with zero PLR. This show the author's limited understanding of these terms.,,Yes,Delete or rewrite this erroneous equation.,Disagree,"This formula is provided as a way for the sender to infer that a packet is lost at the receiver by considering the ACK failure.  Not clear what is meant by the comments ""Many 802.11 links exhibit finite PER with zero PLR""  Note that PER is a theoretical value"
3191600023,09/16/2007 23:32:08 EDT,634,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,7,General Interest,Disapprove,Technical,287,K,21,The number of QoS levels of service is not defined for 2.11 in Table K-1. 802.11 TGk defines Available Admission Capacity as an indicator from an AP to the BSS of the ability of the AP to admit new services at various QoS levels.,,Yes,Use Available Admission Capacity for Supported number of CoS.,Agree,"Add ""available Admission Capacity for Supported number of CoS in table K0-1. Please refer to contribution 21-07-0375  "
3191500023,09/16/2007 23:32:08 EDT,633,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,6,General Interest,Disapprove,Technical,284,K,53,CoS is not included in list of abbreviations,,Yes,Add it there.,Agree,
3191400023,09/16/2007 23:32:08 EDT,632,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,5,General Interest,Disapprove,Technical,287,K,3,Channel utilization has nothing to do with Maximum Link Data rate. Throughput here is curiously defined to be Maximum Link Data rate (P284L61). Channel utilization is defined in 802.11 to mean fraction of time the medium is busy (CCA). These are incompatible terms.,,Yes,Maximum Data Rate in 802.11 terms is the highest available BSS data rate. Fix this.,Disagree,Throughput is intended to reflect the instantaneous bit rate and therefore is closely related to link utilization
3191300023,09/16/2007 23:32:08 EDT,631,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,4,General Interest,Disapprove,Technical,284,K,38,Lines 38-52: The statistical parameters listed on these lines are not descriptive of any channel per se. These statistics are representative of a channel operating at a specific link data rate. That is these parameters can only characterize a channel as a function of a given operating rate. The entire channel is characterized by the set of these parameters for all available link data rates for the particular media. This complicated scenario is true for any set of digital transmission parameters which will always be rate dependent. There is a significant advantage and simplification possible if linke are characterized by analog parmeters like SNR or RSNI.,,Yes,"Either correct this list to indicate that these statistics are only valid on a given channel at a given operating data rate, or simplify the approach to use analog parameters to characterize a link.",Agree,List has been corrected to indicate that the statistics are valid on a given channel at a given operating data rate only. Text has been updated accordingly in the draft.
3191200023,09/16/2007 23:32:08 EDT,630,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,3,General Interest,Disapprove,Technical,284,K,61,"Throughput is a commonly used communications term and it is seldom used the way it is defined here. In this paragraph, Link Throughput is defined as Maximum Link Rate. Using througput in this unusual way is not the best means to promote understanding of MIH common terms.",,Yes,Use Max Link Rate instead of throughput for definition 1 and elsewhere in this annex.,Principle,Throughput is defined as the instantaneous bit rate i.e. number of bits transmitted over a certain time interface.   It is not intended to characterize the link's speed.  Text in the draft has been updated to clarify this.
3191100023,09/16/2007 23:32:08 EDT,629,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,2,General Interest,Disapprove,Technical,284,K,4,"The media dependant native definitions for the MIH common terms and parameters must be normative. Without standardized means to translate parameters from one media to another, the meaning of the MIH terms and parameters will not be understood in a common way.",,Yes,Make the Annex normative,Agree,"To make this mapping normative, the 802.11 spec also needs to make this normative in their spec.  Just saying that this is normative from 802.21 perspective does not really make sense."
3191000023,09/16/2007 23:32:08 EDT,628,"Kwak, Joseph A",joekwak@sbcglobal.net,630-739-4159,Individual,1,General Interest,Disapprove,General,,,,"The 802.21 spec seems to do a good job of defining a mechanism for collecting media dependant data from diverse media and provides the opportunity for Media Independent processing of these data for Media Independent Handover. However, most of the media independent parts seem to be missing. The MIH events defined seem to be media independent, yet the media dependant standard definitions for each media independent event are not included in the standard. For instance the ""Link Going Down"" seems to be a media independent event (common term) which must have a standardized definition in media dependent terms (native terms) for the 802.21 standard to operate. For instance if ""Link Going Down"" is defined as PER < 10E-3 for 802.16 and is defined as ""recently disassociated"" in 802.11, we have a problem in that the MIH event in 802.11 is not an equivalent event in 802.16. This spec refers to ammendments needed in the various media to support MIH, yet when I looked into the referenced document for 802.11 (21-05-0359r2) no such standard definitions in 802.11 terms existed. Without the detailed native definitions for the common terms, no functions can operate in a standard way. It is not clear to me how we may finalize a standard which is so incomplete. Perhaps the work should continue? In its current state the 802.21 document provides a coherent transport mechanism for various yet-to-be-defined IEs which are meant to translate into common MIH terms for use in common MIH functions. How can this work without the detailed media dependant definitions?",,Yes,"Complete the command, event and information defintions for each of the common MIH terms which need translation into media dependent native terms for each of the media identified.",Principle,Annex-L has been updated accordingly
3190800023,09/16/2007 21:41:08 EDT,627,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,36,General Interest,Disapprove,General,193,table b-12,,Encoding/Decoding is not clear for SYSTEM INFORMATION,,Yes,Please see #309,Principle,Please refer to contribution 21-07-0317-01-0000
3190700023,09/16/2007 21:41:08 EDT,626,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,35,General Interest,Disapprove,General,193,table b-12,,Encoding/Decoding is not clear for PARAMETERS,,Yes,Please see #309,Principle,Please refer to contribution 21-07-0317-01-0000
3190600023,09/16/2007 21:41:08 EDT,625,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,34,General Interest,Disapprove,Technical,121,7.4.23 and others,44,"There is no LINK_ACTIONS datatype, it must be LINK_ACTION",,Yes,correct it,Agree,
3190500023,09/16/2007 21:41:08 EDT,624,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,33,General Interest,Disapprove,Technical,118,7.4.22,34,"Network in most cases does not care about the specifics of link actions. The link action set should be optional. In worst case, the parametes inside must be optional for this case.",,Yes,Please see the contribution #308,Principle,Please refer to 21-07-0308-01    (Also refer to contribution 21-07-0320-01  which has changes for resource reservaton scheme to the same primitive)
3190400023,09/16/2007 21:41:08 EDT,623,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,32,General Interest,Disapprove,Technical,184,Table B4,22,There is no information about ACCESS_NETWORK_IDENTIFIER which is an important for network selection,,Yes,"Add ""ACCESS_NETWORK_IDENTIFIER"" as thee first parameter.",Agree,Add Access Network Identifier (HESSID for 802.11) as part of LINK_SCAN_RSP
3190300023,09/16/2007 21:41:08 EDT,622,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,31,General Interest,Disapprove,Technical,184,Table B4,22,"Several locations where ""MAC address"" is used instead of a genric link id or address. MAC is a 802 term, should use a genreal term, which is already defined.",,Yes,correct it,Principle,Change it with LINK_ADDRESS
3190200023,09/16/2007 21:41:08 EDT,621,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,30,General Interest,Disapprove,Technical,125,7.4.24.2.2 and others,16,"Several locations where ""MAC address"" is used instead of a genric link id or address. MAC is a 802 term, should use a genreal term, which is already defined.",,Yes,correct it,Agree,"Target PoA of   MIH_N2N_HO_Commit,  MIH_Net_HO_Commit (done) ( MIH_MN_HO_Commit TargetPoA deleted in Cmt 619)"
3190100023,09/16/2007 21:41:08 EDT,620,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,29,General Interest,Disapprove,Technical,118,7.4.22,1,"For network assisted handovers, Net HO Commit may not know about the PoA specifics. Should include network identifiers.",,Yes,Please see the contribution #308,Principle,Please refer to 21-07-0308-01  (Also refer to contribution 21-07-0320-01  which has changes for resource reservaton scheme to the same primitive)
3190000023,09/16/2007 21:41:08 EDT,619,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,28,General Interest,Disapprove,Technical,122,7.4.24,27,Target PoA is already included in Target Link Identifier. This is redundant.,,Yes,Remove,Agree,
3189900023,09/16/2007 21:41:08 EDT,618,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,27,General Interest,Disapprove,Technical,121,7.4.23,41,Target PoA is already included in Target Link Identifier. This is redundant.,,Yes,Remove,Agree,
3189800023,09/16/2007 21:41:08 EDT,617,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,26,General Interest,Disapprove,Technical,124,7.4.24.1.2 and others,35,"Several locations where ""MAC address"" is used instead of a genric link id or address. MAC is a 802 term, should use a genreal term, which is already defined.",,Yes,correct it,Agree,"a)  Target PoA of   MIH_N2N_HO_Commit,  MIH_Net_HO_Commit (done) ( MIH_MN_HO_Commit TargetPoA deleted in Cmt 619)  b)  Old/New Access Router of  (waiting email)     MIH_Link_UP, MIH_Link_Down,     MIH_Link_HO_Imminent, MIH_Link_Handover_Complete"
3189700023,09/16/2007 21:41:08 EDT,616,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,25,General Interest,Disapprove,Editorial,170,8.6.4.2,59,"MIH_Get_Information response change the table entry from ""(Info Response Binary List TLV)"" to ""(Info Response Binary Data List TLV)""",,Yes,correct it,Agree,
3189600023,09/16/2007 21:41:08 EDT,615,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,24,General Interest,Disapprove,Technical,87,7.4.4.,31,"A general comment related to event-subscription, link-detect and network commit to be used for network guided handovers. As a concept, the network PoS may not be aware or interested in the PoA specifics for handover selection and decision but only the network identifiers are sufficient to make the decisions. The attached usecase provides more information. Specification changes to support this are individually submitted. Note that these changes are useful even if applied individually to each of the primitives",,Yes,Please see the contribution #307,Principle,"Adopt contribution 21-07-0305-02-0000-Event-Subscribe-Update.doc with the following change: remove the LINK_TYPE from LINK_DETECT_CONFIG, since the Link Identifier parameter already provided the link type.  Adopt contribution 21-07-0306-02-0000-Link-Detection-Update.doc with the following change: replace LINK_TYPE with LINK_TUPLE_ID for the LINK_DETECT_INFO, since the Link identifier is required at the MIH level in order for the MIH user to know which link it was reported from; the change in section 7.3.8.3 is not applicable due to updates in Cmt 428.    (Please read editor's note)"
3189500023,09/16/2007 21:41:08 EDT,614,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,23,General Interest,Disapprove,Technical,93,7.4.9,46,Just providing MAC addresses of PoA is insufficient for network selection.,,Yes,Please see the contribution #306 - CHANGE#2,Principle,Adopt contribution 21-07-0306-02-0000-Link-Detection-Update.doc with modification
3189400023,09/16/2007 21:41:08 EDT,613,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,22,General Interest,Disapprove,Technical,73,7.3.12,40,"Why would the link layers(MAC) make handover decisions? Even for intra-technology handovers, there must be logical entities outside of MAC that make these decisions, e.g. SME in 802.11. Presently, there are no interefaces defined between MIHF and these logical entities.",,Yes,,Disagree,The MAC Convergence Gateway Function as defined by TGu provides this functionality for 802.11. Appropriate interfaces are defined in TGu draft. 802.16 deals with this in similar manner as well.
3189300023,09/16/2007 21:41:08 EDT,612,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,21,General Interest,Disapprove,Technical,72,7.3.11,54,"Why would the link layers(MAC) make handover decisions? Even for intra-technology handovers, there must be logical entities outside of MAC that make these decisions, e.g. SME in 802.11. Presently, there are no interefaces defined between MIHF and these logical entities.",,Yes,Discuss.,Disagree,The MAC Convergence Gateway Function as defined by TGu provides this functionality for 802.11. Appropriate interfaces are defined in TGu draft. 802.16s deal with this in similar manner as well.
3189200023,09/16/2007 21:41:08 EDT,611,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,20,General Interest,Disapprove,Technical,71,7.3.10,54,MIH is not the only way through which the higher layers and link layers interact with each other. User place functions don't need MIHF involvement. It is logical and perfectly possible for upper layer buffers to receive frame delivery indications from the link layers.,,Yes,Remove the whole section.,Disagree,"Disagree with removing the section.     1) It is never agreed upon to limit MIHF to only control planes (as shown in Figure 1, Figure 4, Figure 5, etc).    2) Even though most media types already have their own native mechanism for similar indication, this MIH link primitive is a generic primitive. The value for having a generic link primitive that can be mapped to a media-dependent one is well established (the reason behind 802.21 MIH_Link_SAP definition).   "
3189100023,09/16/2007 21:41:08 EDT,610,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,19,General Interest,Disapprove,Technical,72,7.3.10,1,This seems to assume a nonexistent packet identifier common at both higher layers and link layers. TCP/IP layer uses its own sequence numbers which are not visible to MAC layers while MAC layer uses its own sequence numbers for link acknowledgements. What packet identifier is supposed to be used here?,,Yes,Remove Packet Identifier,Principle,"  1) Further clarify that the packet identifier is a container structure whose syntax and semantics will be decided by the upper layer (i.e., the user/subscriber of this event). MIHF and link layer just pass and return it and do not need to understand the syntax and semantics.    2) Consider adding a primitive to show explicitly that this packet identifier is passed along with the outbound data from the upper layer.  "
3189000023,09/16/2007 21:41:08 EDT,609,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,18,General Interest,Disapprove,Technical,70,7.3.8,27,Just providing MAC addresses of PoA is insufficient for network selection.,,Yes,Please see the contribution #306 - CHANGE#1,Principle,Adopt contribution 21-07-0306-02-0000-Link-Detection-Update.doc with modification
3188900023,09/16/2007 21:41:08 EDT,608,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,17,General Interest,Disapprove,General,68,7.3.6.2,44,"Is this a wish list or does any Link layer actually support or intend to support this functionality? The parameters ""Time interval"" and ""Confidence level"" are based on vendor specific implementations.",,Yes,Discuss.,Principle,"Delete the statement:  ""The link connectivity is expected to be available at least for the time specified.""    Delete Confidence level from the parameter list.    The Time-Interval specifies the time interval at which the link is expected to go down.  A non-zero time interval is specified only if there is a high confidence level in the time interval.   A time interval of 0 is specified if there is low-confidence in the computation of time interval.  Additional reason codes for Link_GOING_Down may be added.    This needs to be done throughout the document."
3188800023,09/16/2007 21:41:08 EDT,607,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,16,General Interest,Disapprove,Technical,67,7.3.4.2,41,"How does the link layer know that the IP address needs renewal? This goes against the protocol layering. If it is believed that the PoA provides this information, how does the PoA know that the device needs a IP renewal, since this Link-Up is at L2? It would be reasonable to think that the renewal decision must be left to the higher layers but just provide any necessary and available IP information e.g. IP subnet info of the new interface.",,Yes,Please clarify and remove. Or add IP subnet prefix information of the new interface.,Disagree,Just providing IP Renewal flag is not sufficient. This may be valid when PoA and PoS are co-located.
3188700023,09/16/2007 21:41:08 EDT,606,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,15,General Interest,Disapprove,Technical,87,7.4.4,32,"MIH Event Subscription, as defined, has limited capability for practical uses. It should be possible for event subscription to set parameters for individual events that are being subscribed for. The parameters will be correspondingly be applicable only for that specific event. As an example, link-detect may result in inefficiency due to reporting of not so relevant networks. It should be possible to subscribe to see only specific network identifiers.",,Yes,Please see the contribution #305,Principle,Adopt contribution #305-2 with modification.
3188600023,09/16/2007 21:41:08 EDT,605,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,14,General Interest,Disapprove,Technical,52,6.5.5.2,49,"When more than one PoA container is present, it is important to specify if the there is any meaning to how to the list is populated or if it is random. It is beneficial to the receiver of this information to know this so it can apply this information for network selection and decisions.",,Yes,"Attach an explicit statement to line 49 that ""When more than one PoA Container is provided in this IE, they shall be prioritized in the order of preference from the information server's perspective with first PoA Container as the top priority and with decreasing prority going down the list. This would enable the receiving entity to untilize this information in the same order as provided in this list for network selection or handover decisions.""",Principle,"Attach an explicit statement to line 49 that ""When more than one PoA Container is provided in this IE, they should be prioritized in the order of preference from the information server's perspective with first PoA Container as the top priority and with decreasing prority going down the list.   This would enable the receiving entity to untilize this information in the same way as provided in this list for network selection or handover decisions  "
3188500023,09/16/2007 21:41:08 EDT,604,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,13,General Interest,Disapprove,Technical,52,6.5.5.2,29,"When more than one access network container is present, it is important to specify if the there is any meaning to how to the list is populated or if it is random. It is beneficial to the receiver of this information to know this so it can apply this information for network selection and decisions.",,Yes,"Attach an explicit statement to line 29 that ""When more than one Access Network Container is provided in this IE, they shall be prioritized in the order of preference from the information server's perspective with first Access Network Container as the top priority and with decreasing prority going down the list. This would enable the receiving entity to untilize this information in the same order as provided in this list for network selection or handover decisions.""",Principle,"Attach an explicit statement to line 29 that ""When more than one Access Network Container is provided in this IE, they should be prioritized in the order of preference from the information server's perspective with first Access Network Container as the top priority and with decreasing prority going down the list. This would enable the receiving entity to untilize this information in the same way as provided in this list for network selection or handover decisions."""
3188400023,09/16/2007 21:41:08 EDT,603,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,12,General Interest,Disapprove,Technical,52,6.5.5.2,48,Why is it necessary that this container should have atleast one PoA container? It should be possible to identify the access network and its associated information without knowing the specifics of the PoA present in that access network.,,Yes,Clarify or remove,Principle,"Line-13 PoA Container #1 (pg 53) ..........make this optional  Remove  ""  An Access Network Container shall contain at least one PoA Container and may contain one or more  Vendor Specific Network IEs:  ""  "
3188300023,09/16/2007 21:41:08 EDT,602,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,11,General Interest,Disapprove,Technical,41,6.3.5,11,What is the difference between Link-Up and Link-Handover-Complete?,,Yes,Clarify,Principle,Please refer to contribution 21-07-0430-00-0000
3188200023,09/16/2007 21:41:08 EDT,601,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,10,General Interest,Disapprove,Technical,41,6.3.5,3,Desciption on Link_handover_imminent and its MIH counterpart indicate that the L2 somehow decides that handover is necessary. This goes against the very first MIH design principle set forth in section 5.2.1. Who makes handover decisions? Is this event equivalent to a parameter change if configured or a predictive event that the link may be down soon?,,Yes,Clarify,Principle,Please refer to contribution 21-07-0430-00-0000
3188100023,09/16/2007 21:41:08 EDT,600,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,9,General Interest,Disapprove,Technical,38,6.3.4.1,63,"Define ""link synchronous events"" rather than saying what they are not and just providing examples.",,Yes,Needs a definition,Disagree,This section has been updated
3188000023,09/16/2007 21:41:08 EDT,599,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,8,General Interest,Disapprove,Technical,39,6.3.4.1,15,Failure to transmit data is not same as the lost data.,,Yes,Suggest rewriting this section.,Principle,Please refer to contribution 21-07-0433-00-0000
3187900023,09/16/2007 21:41:08 EDT,598,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,7,General Interest,Disapprove,Technical,39,6.3.4.1,30,"It is incorrect to say that the transmission status can be verified on by higher layer timeouts. Currently, all link layers provide indications for successful transmission of the frames in the L2 buffer.",,Yes,correct it,Principle,Please refer to contribution 21-07-0433-00-0000
3187800023,09/16/2007 21:41:08 EDT,597,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,6,General Interest,Disapprove,Technical,32,5.7.2,44,Is the recommendation valid? 802.11 is not providing any management frame extentions other than for Information services and entity discovery/,,Yes,may be either carried using media specific link services or using higher layer protocols.,Agree,
3187700023,09/16/2007 21:41:08 EDT,596,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,5,General Interest,Disapprove,General,19,5.4.2,1,"This section is grossly disconnected and suffers from lack of relevance from the rest of the specification. Other than section 5.4.3, the terminology or reference points are not used anywhere in the specification.",,Yes,Clarify the use.,Disagree,This clarifies PoA and PoS and provides Reference Points which provides context for the interfaces.
3187600023,09/16/2007 21:41:08 EDT,595,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,4,General Interest,Disapprove,General,15,5.3.2.2,56,Figure 13 is 16 pages away.,,Yes,remove reference or make a reference to a future section,Agree,
3187500023,09/16/2007 21:41:08 EDT,594,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,3,General Interest,Disapprove,Technical,7,3.18,10,"What is the difference between ""MIH PoS"" and ""MIH PoS Network Entity""?",,Yes,Clarify or combine,Agree,Keep MIH PoS (3.18)  Delete MIH PoS Network Entity (3.19)  Rename MIH non-PoS Network Entity to MIH non-PoS (3.21)
3187400023,09/16/2007 21:41:08 EDT,593,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,2,General Interest,Disapprove,General,7,3.16,5,"""MIH protocol entities"" is not defined and not appropriate here.",,Yes,"""MIH Network entities""",Principle,Change:  3.16 MIH discovery protocol - A protocol for discovering MIH protocol entities.  To  3.16 MIH discovery protocol - A protocol for discovering MIH entities.
3187300023,09/16/2007 21:41:08 EDT,592,"Sreemanthula, Srinvias",srinivas.sreemanthula@gmail.com,972-894-5000,Individual,1,General Interest,Disapprove,General,5,2,7,Where are the normative references?,,Yes,Add them.,Agree,
3187100023,09/16/2007 18:16:08 EDT,591,"Levy, Joseph S",joseph.levy@interdigital.com,+1 631 622 4139,Individual,4,Producer,Disapprove,Technical,33,,1,"There are very few (8) ""shalls"" in section 6.0 MIHF Services and the ""shalls"" that are present tend to limit the use of the specification instead of specifying required specified performance.",,Yes,Provide additional requirements which will define MIHF Services.,Disagree,Need to have more specific inputs as to what requirements are missing.
3187000023,09/16/2007 17:59:40 EDT,590,"Levy, Joseph S",joseph.levy@interdigital.com,+1 631 622 4139,Individual,3,Producer,Disapprove,General,,,,"QoS is a critical aspect of MIH, but there are very few normative requirements regarding the use of QoS measures and their uses.",,Yes,"Provide additional normative requirements related to the use of QoS in MIH. e.g. - make some; if not all, of the QoS examples of Annex K and related material normative.",Disagree,"QoS is an important aspect of MIH and that's why MIH provides useful tools in the form of primitives and events in order to make use of measurements available at layers 1 & 2.   The value of the MIH is not in defining new measurements in other technologies but in facilitating the exchange of information available.  While the tools provided by MIH are all normative, the measurements available in other specifications are informative.    "
3186900023,09/16/2007 17:58:08 EDT,589,"Levy, Joseph S",joseph.levy@interdigital.com,+1 631 622 4139,Individual,2,Producer,Disapprove,General,,,,This standard provides a useful set of tools to make MIH work; however it provides very few requirements on how these tools should be used. This will allow for flexible use of this standard; however I believe it allows for too much flexibility and needs to provide standardized methods for the use of these tools.,,No,"Provide required MIH procedures instead of just examples of MIH. This is not intended to limit the flexibility of the tools, just to allow the definition of agreed basic procedures.",Disagree,The MIH_SAP provides primitives and procedures as to how to use the MIH.  If there are any specific aspects that need to be addressed please clarify.
3186800023,09/16/2007 17:47:09 EDT,588,"Levy, Joseph S",joseph.levy@interdigital.com,+1 631 622 4139,Individual,1,Producer,Disapprove,General,,,,"QoS is a critical aspect of MIH, but there are very few normative requirements regarding the use of QoS measures and their uses.",,No,"Provide additional normative requirements related to the use of QoS in MIH. e.g. - make some; if not all, of the QoS examples of Annex K and related material normative.",Disagree,"QoS is an important aspect of MIH and that's why MIH provides useful tools in the form of primitives and events in order to make use of measurements available at layers 1 & 2.   The value of the MIH is not in defining new measurements in other technologies but in facilitating the exchange of information available.  While the tools provided by MIH are all normative, the measurements available in other specifications are informative.    "
3186600023,09/16/2007 16:08:43 EDT,587,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,8,Producer,Disapprove,Technical,105,7.4.19,,"MIH_NET_HO_Candidatate_Query Request should contain only Query_Resource_Flag, not List (as it is now). Network doesn't provide any resources at this point. It can only request MN to provide list of resource IEs the MN is interested to receive. MN will provide the list of resource IEs it is interested to receive.",,Yes,"Remove list. The flag is also self evident, it can be removed totally.",Disagree,The QueryResourceeportFlag is NOT a list.  OK to keep it
3186500023,09/16/2007 16:08:43 EDT,586,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,7,Producer,Disapprove,Technical,77,,,Link_Scan.response specifies MAC_ADDRESS (in Scan Response Set) Scan can be performed for network types without MAC_ADDrESSES,,Yes,change from MAC_ADRESS to LINK_ID.,Principle,change from MAC_ADDRESS to LINK_ADDRESS
3186400023,09/16/2007 16:08:43 EDT,585,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,6,Producer,Disapprove,Technical,118,,,"In *HO_commit*, targetPoa should not be MAC_ADDRESS if network type doesn't support that form of address.",,Yes,"MIH_N2N_HO_Commit.request / .indication and MIH_MN_HO_commit.request / .indication: Target PoA type MAC_ADDRESS, change to LINK_ID.",Principle,Change to LINK_TUPLE_ID
3186300023,09/16/2007 16:08:43 EDT,584,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,5,Producer,Disapprove,Technical,121,7.4.23,,Why there is a separate MAC_ADDRESS field in MIH_MN_HO_Commit.request/indication primitives (and also in MIH_MN_HO_Commit request message)? Why are the Link and PoA differentiated?,,Yes,change the type to LINK_ID,Principle,change the type to LINK_ADDRESS
3186200023,09/16/2007 16:08:43 EDT,583,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,4,Producer,Disapprove,Technical,170,8.6.4.2,59,no Info Response Binary List TLV in Table C2,,Yes,"In chapter 8.6.4.2 MIH_Get_Information response change the table entry from ""(Info Response Binary List TLV)"" to ""(Info Response Binary Data List TLV)""",Agree,
3186100023,09/16/2007 16:08:43 EDT,582,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,3,Producer,Disapprove,Technical,,,,"The info from MN* is informative and so it does not contain the ACTION_EXECUTION_TIME like the NET* messages. Therefore, NET* is using LINK_ACTIONS_REQ and RSP.",,Yes,ACTION_EXECUTION_TIME from NET*,Disagree,This comment was withdrawn. Not very clear what the commenter is asking.
3186000023,09/16/2007 16:08:43 EDT,581,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,2,Producer,Disapprove,Technical,121,,,"On messages MIH_MN_HO_Commit.request and MIH_MN_HO_Commit.indication (7.4.23 and 7.4.23.2) and also in MIH_Net_HO_Commit request (8.6.3.15), there is undefinde type LINK_ACTIONS",,Yes,Should be LINK_ACTION,Agree,"change LINK_ACTIONS to ""LINK_ACTION"""
3185900023,09/16/2007 15:56:25 EDT,580,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,36,General Interest,Disapprove,Editorial,189,B.2.6,24,"""Longitude SHOULD be normalized to within +/- 180 degrees. Positive values are East of the prime meridian and negative (2s complement) numbers are West of the prime meridian.""",,Yes,"""Longitude should be normalized to within +/- 180 degrees. Positive values are East of the prime meridian and negative (2s complement) numbers are West of the prime meridian.""",Agree,
3185800023,09/16/2007 15:56:25 EDT,579,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,35,General Interest,Disapprove,Editorial,175,B.1.1,5,"""No octet is encoded for this data type. This data type is used for to define an optional data type.""",,Yes,"""No octet is encoded for this data type. This data type is used to define an optional data type.""",Agree,
3185700023,09/16/2007 15:56:25 EDT,578,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,34,General Interest,Disapprove,Technical,174,B.1.1,41,"""A one-octet Selector field, followed by a variable length Value field. The Selector value determines the data type. If Selector==i, (i+1)-th data type in the list of data types DATATYPE1,DATATYPE2,[,&] is selected. The Value field is encoded using the encoding rule for the selected data type."" What is the binary encoding of the selector octet? Order ov value? Increasing order or decreasing order?",,Yes,"""A one-octet Selector field, followed by a variable length Value field. The Selector value determines the data type. If Selector==i, (i+1)-th data type in the list of data types DATATYPE1,DATATYPE2,[,&] is selected. The Selector field is encoded in increasing order of significance. The Value field is encoded using the encoding rule for the selected data type.""",Principle,  Please refer to 21-07-0396-01-0000
3185600023,09/16/2007 15:56:25 EDT,577,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,33,General Interest,Disapprove,Technical,174,B.1.1,26,"""Each character is encoded in order of appearance where each bit of each character is encoded in order of significance."" Increasing or decreasing order of significance?",,Yes,"""Each character is encoded in order of appearance where each bit of each character is encoded in increasing order of significance.""",Principle,  Please refer to 21-07-0396-01-0000
3185500023,09/16/2007 15:56:25 EDT,576,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,32,General Interest,Disapprove,Technical,174,B.1.1,21,"""Each bit of a BITMAP(N) value [N=8*i, i=1, 2, &] is encoded as an N/ 8-octet value in order of significance."" Increasing or decreasing order of significance?",,Yes,"""Each bit of a BITMAP(N) value [N=8*i, i=1, 2, &] is encoded as an N/ 8-octet value in increasing order of significance.""",Principle,Please refer to contribution 21-07-0396-01-0000
3185400023,09/16/2007 15:56:25 EDT,575,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,31,General Interest,Disapprove,Editorial,164,8.6.3.12,14,"""This message is used for communication between the MIHF on a MN and the MIHF on network.""",,Yes,"""This message is used for communication between the MIHF on a MN and the MIHF on a network.""",Agree,
3185300023,09/16/2007 15:56:25 EDT,574,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,30,General Interest,Disapprove,Editorial,154,8.6.1.2,6,"""When an MIH network entity broadcasts unsolicited MIH_Capability_Discover response to advertise its MIHF ID and capabilities, Destination ID shall be a broadcast MIHF ID.""",,Yes,"""When an MIH network entity broadcasts unsolicited a MIH_Capability_Discover response to advertise its MIHF ID and capabilities, Destination ID shall be a broadcast MIHF ID.""",Principle,"changed as follows:  When an MIH network entity broadcasts an unsolicited MIH_Capability_Discover response to advertise its MIHF ID and capabilities, Destination ID shall be a broadcast MIHF ID"
3185200023,09/16/2007 15:56:25 EDT,573,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,29,General Interest,Disapprove,Technical,154,8.6.1.2,3,"""Only an MIHF capable network entity shall respond with this message to the received MIH_Capability_Discover request with broadcast MIHF ID or send unsolicited MIH_Capability_Discover response periodically.""",,Yes,"""Only an MIHF capable network entity shall respond with MIH_Capability_Discover to the received MIH_Capability_Discover request with a broadcast MIHF ID, or send unsolicited MIH_Capability_Discover responses periodically.""",Agree,
3185100023,09/16/2007 15:56:25 EDT,572,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,28,General Interest,Disapprove,Editorial,153,8.6.1.1,37,"""and this message is transmitted over control plane using L2 management frame, such as 802.11 management action frame and 802.16 MIH MAC management message.""",,Yes,"""and this message is transmitted over control plane using a L2 management frame, such as a 802.11 management action frame or a 802.16 MIH MAC management message.""",Agree,
3185000023,09/16/2007 15:56:25 EDT,571,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,27,General Interest,Disapprove,Editorial,149,8.2.3.5.2,62,"""When the timer expires without receiving a response message, the requestor may try the combined MIH function discovery and capability discovery procedure using a different transport than previous or terminate the MIH function and capability discovery procedure.""",,Yes,"""When the timer expires without receiving a response message, the requestor may try the combined MIH function discovery and capability discovery procedure using a different transport than previously or terminate the MIH function and capability discovery procedure.""",Agree,
3184900023,09/16/2007 15:56:25 EDT,570,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,26,General Interest,Disapprove,Editorial,149,8.2.3.5.2,47,"""Only MIH network entity shall respond to broadcasted MIH_Capability_Discover request.""",,Yes,"""Only MIH network entities shall respond to broadcasted MIH_Capability_Discover request.""",Principle,"changed sentence to ""Only MIH network entities shall respond to a broadcasted MIH_Capability_Discover request."""
3184800023,09/16/2007 15:56:25 EDT,569,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,25,General Interest,Disapprove,Technical,147,8.2.2.3,,"Figure 24: The state diagram in Figure does not match the description in the text. More specifically, the state diagram does not show that retransmission shall happen only twice. Note that the IEEE SA has ruled that state diagrams are normative, which means that the state diagram must be correct.",,Yes,Update the state diagram to match the text description,Principle,Please look at contribution 21-07-0302-00-0000
3184700023,09/16/2007 15:56:25 EDT,568,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,24,General Interest,Disapprove,Technical,145,8.2.2.1,,"Figure 22: The state diagram in Figure does not match the description in the text. More specifically, the state diagram does not show that retransmission shall happen only twice. Note that the IEEE SA has ruled that state diagrams are normative, which means that the state diagram must be correct.",,Yes,Update the state diagram to match the text description,Principle,Please refer to contribution 21-07-0302-00-0000
3184600023,09/16/2007 15:56:25 EDT,567,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,23,General Interest,Disapprove,Technical,145,8.2.2.1,46,"""retransmitted MIH Response is received due to a lot MIH ACK;"" ""lot""?",,Yes,"""retransmitted MIH Response is received due to a lost MIH ACK;""",Agree,
3184500023,09/16/2007 15:56:25 EDT,566,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,22,General Interest,Disapprove,Editorial,143,8.1,8,"""The MIH Functions in MN and network entities communicate with each other to using the MIH protocol messages specified in this section."" Extra ""to""",,Yes,"""The MIH Functions in MN and network entities communicate with each other using the MIH protocol messages specified in this section.""",Agree,
3184400023,09/16/2007 15:56:25 EDT,565,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,21,General Interest,Disapprove,Editorial,143,8.1,,"Both the term ""MIH Function"" and ""MIH Functions"" are used in this section. If the two terms are syonymous, then be consistent in usage. If the two terms do not refer to the same thing, then please use two terms that are not so close to each other.",,Yes,See comment for proposed resolution,Disagree,'MIH Functions' is used in the plural sense of 'MIH Function'
3184300023,09/16/2007 15:56:25 EDT,564,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,20,General Interest,Disapprove,Editorial,143,8.1,7,"""The IEEE 802.21 standard specifies MIH Function that could be used in mobile nodes and also in entities located in the network."" need either ""a MIH Function"" or ""MIH Functions""",,Yes,"""The IEEE 802.21 standard specifies a MIH Function that could be used in mobile nodes and also in entities located in the network.""",Agree,
3184200023,09/16/2007 15:56:25 EDT,563,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,19,General Interest,Disapprove,Technical,133,7.4.27.1.2,,"The descriptions for Info Query Binary Data List, Info Query RDF Data List and Info Query RDF Schema List indicate that the requests within each category are prioritized from highest to lowest. However, if more than one of these categories are present, how are the categories prioritized? Are the first items in each category that is present have the same priority?",,Yes,Define the priorities of the items in different categories,Principle,"pg 134, line 6: Only 1 type should be specified"
3184100023,09/16/2007 15:56:25 EDT,562,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,18,General Interest,Disapprove,Technical,92,7.4.8,,See my comments about 7.3.6; the same applies here.,,Yes,,Agree,"Delete the statement:  ""The link connectivity is expected to be available at least for the time specified.""    Delete Confidence level from the parameter list.    The Time-Interval specifies the time interval at which the link is expected to go down.  A non-zero time interval is specified only if there is a high confidence level in the time interval.   A time interval of 0 is specified if there is low-confidence in the computation of time interval.  Additional reason codes for Link_GOING_Down may be added.    This needs to be done throughout the document    (See Cmt 556 )"
3184000023,09/16/2007 15:56:25 EDT,561,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,17,General Interest,Disapprove,Editorial,79,7.4.1.1.3,15,"""In the case of remote discovery, this primitive may contain the SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, and SupportedTransportList parameters to enable mutual discovery of each other's capabilities.""",,Yes,"""In the case of remote discovery, this primitive may contain the SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, and SupportedTransportList parameters of the local MIHF to enable mutual discovery of each other's capabilities.""",Agree,
3183900023,09/16/2007 15:56:25 EDT,560,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,16,General Interest,Disapprove,Editorial,79,7.4.1.1.2,8,"""List of supported transport types.""",,Yes,"""List of supported transport types on the local MIHF.""",Agree,
3183800023,09/16/2007 15:56:25 EDT,559,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,15,General Interest,Disapprove,Editorial,79,7.4.1.1.2,5,"""List of supported MIIS query types.""",,Yes,"""List of supported MIIS query types on the local MIHF.""",Agree,
3183700023,09/16/2007 15:56:25 EDT,558,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,14,General Interest,Disapprove,Editorial,79,7.4.1.1.2,2,"""List of supported commands on MIHF.""",,Yes,"""List of supported commands on the local MIHF.""",Agree,
3183600023,09/16/2007 15:56:25 EDT,557,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,13,General Interest,Disapprove,Editorial,78,7.4.1.1.2,64,"""List of supported events on MIHF.""",,Yes,"""List of supported events on the local MIHF.""",Agree,
3183500023,09/16/2007 15:56:25 EDT,556,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,12,General Interest,Disapprove,Technical,69,7.3.6,,"There is a bit of a dichotomy in the definition of this primitive. ""Time Interval"" is defined as ""Time Interval (in milliseconds) in which the link is expected to go down. The link connectivity is expected to be available at least for the time specified."", and yet ""A Link_Going_Down event implies that a Link_Down is imminent within a certain time interval."" Some parts of the primitive state that the link will be valid for Time Interval, while other parts imply that the link can go down any time within Time Interval. I pity the system that assumes that the link will be valid for Time Interval, only to have it yanked away early",,Yes,"Be consistent with what ""Time Interval"" means.",Agree,"Delete the statement:  ""The link connectivity is expected to be available at least for the time specified.""    Delete Confidence level from the parameter list.    The Time-Interval specifies the time interval at which the link is expected to go down.  A non-zero time interval is specified only if there is a high confidence level in the time interval.   A time interval of 0 is specified if there is low-confidence in the computation of time interval.  Additional reason codes for Link_GOING_Down may be added.    This needs to be done throughout the document"
3183400023,09/16/2007 15:56:25 EDT,555,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,11,General Interest,Disapprove,Editorial,39,6.3.4.1,17,"""For example, the occurrence of a handover of a mobile node, from one access network to another will result in the reestablishment of a link layer connection to the target access network."" Extraneous comma.",,Yes,"""For example, the occurrence of a handover of a mobile node from one access network to another will result in the reestablishment of a link layer connection to the target access network.""",Agree,
3183300023,09/16/2007 15:56:25 EDT,554,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,10,General Interest,Disapprove,Technical,35,6.2.5,,"Figure 12, you might want to indicate that the MIH Event Subscription Request/Response and the MIH Command Request/Response do not have to go in the directions they are shown; that the reverse directions are also allowed.",,Yes,Indicate that the reverse directions are allowed.,Disagree,"The text description does not say anything about direction in this figure.  Both the directions are allowed and tthe text  does clarify that...page 34, line 36  "
3183200023,09/16/2007 15:56:25 EDT,553,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,9,General Interest,Disapprove,Editorial,29,5.5.6,9,"""It is noteworthy however that there will be no direct communication between the 3GPP2 PHY and MAC layers with the MIHF."" ""However"" is not necessary, but if present should be set off by commas.",,Yes,"""It is noteworthy that there will be no direct communication between the 3GPP2 PHY and MAC layers with the MIHF."" or ""It is noteworthy, however, that there will be no direct communication between the 3GPP2 PHY and MAC layers with the MIHF."" I prefer the first.",Agree,
3183100023,09/16/2007 15:56:25 EDT,552,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,8,General Interest,Disapprove,Technical,22,5.4.3,1,"The terms ""reference point"", ""reference connection"", and ""link"" are all used to label or name the same idea in this paragraph. This is very confusing when trying to read it.",,Yes,Pick a single term and use it consistently.,Principle,"Change ""Reference Connection"" to ""Reference Point"""
3183000023,09/16/2007 15:56:25 EDT,551,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,7,General Interest,Disapprove,Technical,19,,,"""Communication reference point"" I have a problem using the term ""point"" for something that is a communication link. Communication links, by definition, are not point dimensional, but rather lines. ""Point"" is a good term for a device, but not a link.",,Yes,"""Communication connection reference type""",Disagree,Stick with Reference Points.  This needs to be done throughout the document.    
3182900023,09/16/2007 15:56:25 EDT,550,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,6,General Interest,Disapprove,Technical,20,5.4.2,8,"In Figure 2, you have numbered the communication links according to the classification scheme starting on line 21 of this page. You might alsoi want to number the entities according to the table starting at line 8",,Yes,"Number the entities in Figure 2, according to the list starting on page 20 line 8",Disagree,"The entities are not really numbered. These are just bullets on page 20, line 8...."
3182800023,09/16/2007 15:56:25 EDT,549,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,5,General Interest,Disapprove,Editorial,10,4,43,"""Layer 2 (MAC and LLC)""",,Yes,"""Layer 2 (MAC and/or LLC)""",Agree,
3182700023,09/16/2007 15:56:25 EDT,548,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,4,General Interest,Disapprove,Editorial,7,3.18,15,"""Note for a network entity comprising of multiple interfaces, the notion of MIH PoS is associated with the network entity itself and not with just one of its interfaces.""",,Yes,"""Note that for a network entity comprising of multiple interfaces, the notion of MIH PoS is associated with the network entity itself and not with just one of its interfaces.""",Agree,
3182600023,09/16/2007 15:56:25 EDT,547,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,3,General Interest,Disapprove,Editorial,6,3.15,64,"""As an example, the IEEE 802.11 Lower Layers are the MAC Sublayer and the PHY and the 3GPP Lower Layers are the MAC and UMTS layers.""",,Yes,"""For example, the IEEE 802.11 Lower Layers are the MAC Sublayer and the PHY, while the 3GPP Lower Layers are the MAC and UMTS layers.""",Agree,
3182500023,09/16/2007 15:56:25 EDT,546,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,2,General Interest,Disapprove,Technical,3,1.4,47,"""The mobile node is capable of supporting multiple link-layer technologies, which may be wireless or wired."" This assumption isn't absolute: handovers between 802.11 ESSs would use 802.21 but be limited to a single link layer technology.",,Yes,"""In most cases, the mobile node is capable of supporting multiple link-layer technologies, which may be wireless or wired. However it is possible that the mobile node supports only a single link layer technology, such as 802.11 ESS handovers.""",Agree,"Page 14, Line-36    Change this sentence as follows:  ""The definition of such handover signaling mechanisms is outside the scope of the IEEE 802.21 standard.""    ""IThe definition of such handover signaling mechanisms is outside the scope of the IEEE 802.21 standard except in the case of handovers across ESSs in 802.11."""
3182400023,09/16/2007 15:56:25 EDT,545,"Chaplin, Clint F",clint.chaplin@gmail.com,+1(408)239-3348,Individual,1,General Interest,Disapprove,Editorial,2,1.3,43,"""The framework presents the media-independent handover (MIH) reference models for different link layer technologies."" Seems somewhat awkward",,Yes,"""The framework presents media-independent handover (MIH) reference models for different link layer technologies.""",Agree,
3182300023,09/16/2007 15:32:58 EDT,544,"Colban, Erik A",ecolban@nextwave.com,+1 858 775 2494,Individual,3,User,Disapprove,Technical,5,2,1,"No references are provided despite the fact that this standard is referencing 802.1, 802.3, 802.11, 802.16, and unknown 3GPP and 3GPP2 specifications.",,Yes,"Complete the reference list. Wherever the text references another document, add a reference to the corresponding entry in the reference section.",Agree,
3182200023,09/16/2007 15:32:58 EDT,543,"Colban, Erik A",ecolban@nextwave.com,+1 858 775 2494,Individual,2,User,Disapprove,Technical,31,5.6.2.6,45,"What is ""existing"" and what is ""new"" is relative to the development stage of this standard and the referenced 3GPP/3GPP2 standards.",,No,"Replace ""The existing service primitives as defined in 3GPP/3GPP2 specification may be directly mapped to MIHF services, and hence no new primitives need to be defined in the 3GPP/3GPP2 specification."" by ""Primitives of this SAP are specified in the 3GPP and 3GPP2 specifications."" Also, add references to the particular specifications.",Agree,
3182100023,09/16/2007 15:32:58 EDT,542,"Colban, Erik A",ecolban@nextwave.com,+1 858 775 2494,Individual,1,User,Disapprove,Editorial,30,5.6.2,43,"""For communication between two remote MIHFs, the propagation from the local MIHF to the remote MIHF relies on MIH protocol messages."" The sentence starts by introducing two remote MIHFs but continues by addressing one local and one remote MIHFs. Moreover, the communication is two-way, not only from the local to the remote MIHF.",,No,"Replace the sentence starting on line 43 by: ""Communication between two MIHFs relies on MIH protocol messages.""",Agree,
3182000023,09/16/2007 15:23:06 EDT,541,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,9,Producer,Disapprove,General,282,,,Annex J does not add value to the final spec.,,Yes,"Remove Annex J ""Requirements to support 802.21 by L3 and above transport""",Agree,
3181900023,09/16/2007 15:23:06 EDT,540,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,8,Producer,Disapprove,Technical,150,8.4.1,60,"MIH Protocol header is of fixed length, as indicated in fig 27 on the next page.",,Yes,Correct Figure 26 to show MIH Protocol Header has fixed length of 8 octets.,Agree,
3181800023,09/16/2007 15:23:06 EDT,539,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,7,Producer,Disapprove,Technical,124,7.4.24,,MIH_N2N_HO_Commit does not allow the option of requesting resource reservation at the HO target. This could become a limiting factor in some cases.,,Yes,Add the option that HO resource reservation can be requested at the recipient of MIH_N2N_HO_Commit.,Agree,Please refer to contribution 21-07-0320-02-0000-Resource_Definition
3181700023,09/16/2007 15:23:06 EDT,538,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,6,Producer,Disapprove,General,,,,MIH event subscription should allow the subscriber to set certain conditions or qualifiers. With that only events meeting those conditions or qualifiers will be notified to the subscriber.,,Yes,Investigate if this capability is needed and the best ways to implement it,Principle,"Adopt contribution 21-07-0305-02-0000-Event-Subscribe-Update.doc with the following change: remove the LINK_TYPE from LINK_DETECT_CONFIG, since the Link Identifier parameter already provided the link type."
3181600023,09/16/2007 15:23:06 EDT,537,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,5,Producer,Disapprove,Technical,106,,,The purpose and usefulness of MIH_Net_HO_Candidate_Query command are unclear.,,Yes,Remove all definitions and avoid mentioning of MIH_Net_HO_Candidate_Query command,Disagree,"The name of these Net_HO commands need to change.    "" The Network controller provides a list of candiddate network choices to MN. The MN indicates resources required on each of these candiddate networks. The Network controller then queries each of the candiddate networks for available resources and reports this information back to the MN. Thereafter the Handover Commit happens""  If the above explanation is true it needs to be captured and included in draft.  The name of these commands/messages need to be changed as well."
3181500023,09/16/2007 15:23:06 EDT,536,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,4,Producer,Disapprove,General,42,6.4.1,5,Figure 16 is confusing by showing two unrelated stacks.,,Yes,"Remove the stack marked as ""Remote Entity"". Remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3181400023,09/16/2007 15:23:06 EDT,535,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,3,Producer,Disapprove,General,36,6.3.1,20,Figure 13 is confusing by showing two unrelated stacks.,,Yes,"Remove the stack marked as ""Remote Entity"". Remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3181300023,09/16/2007 15:23:06 EDT,534,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,2,Producer,Disapprove,Technical,32,,,"MIH_NMS_SAP defines the interface between an MIHF implementation and a local Network Management System stack. Depending on the nature of the device, this local NMS stack may vary or may not even exist. Standardizing this interface brings no benefit to the implementation.To the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NMS_SAP,Agree,
3181200023,09/16/2007 15:23:06 EDT,533,"Natarajan, Kadathur S",nat.natarajan@motorola.com,847-632-6303,Individual,1,Producer,Disapprove,Technical,31,,,"MIH_NET_SAP defines the interface between an MIHF implementation and various local transport stacks on the same device. However, it is unclear what compatability benefits standardizing this interface will bring to the implementation. To the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NET_SAP,Disagree,MIH_NET_SAP is required.
3181100023,09/16/2007 14:02:28 EDT,532,"Van Leeuwen, Richard M",rvanleeuwen@motorola.com,+31 30 6001630,Individual,2,Producer,Disapprove,Technical,203,B.2.17,9,Definition for NETWORK_SECURITY is missing.,,Yes,Add the definition for NETWORK_SECURITY.,Principle,Deleted NETWORK_SECURITY_IE  Can be added later if definition is available
3181000023,09/16/2007 14:02:28 EDT,531,"Van Leeuwen, Richard M",rvanleeuwen@motorola.com,+31 30 6001630,Individual,1,Producer,Disapprove,Technical,150,8.4.1,61,"Figure 26 shows the MIH protocol header has a variable length, however Figure 27 shows the MIH protocol header has a fixed length of 8 octets.",,Yes,"Correct Figure 26, showing the MIH protocol header has a fixed length.",Agree,
3180900023,09/16/2007 13:58:33 EDT,530,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,14,General Interest,Disapprove,Technical,33,6,,MIH Handover primitives provide limited handover functionality. 802.21 should either provide complete handover functionality for inter-Tech handovers or delete the existing N2N primitives.,,Yes,Include things like Context Transfer and bearer path setup as part of Handover primitives in N2N Handover functions and other MIH Handover primitives. Define a complete set of handover functionality or delete the existing N2N primitives.,Disagree,No specific contributions available
3180800023,09/16/2007 13:58:33 EDT,529,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,13,General Interest,Disapprove,Technical,33,6,,For Inter-Tech Handover 802.21 needs to define if the handovers would take place with Single radio in operation or dual radio in operation. Solutions needs to be provided for both cases.,,Yes,Discuss specific solution aspects for both for single radio/dual radio case and provide solution for both cases.,Disagree,No specific contributions available
3180700023,09/16/2007 13:58:33 EDT,528,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,12,General Interest,Disapprove,Editorial,186,B.2.5,42,"This is the maximum data transfer rate, not the maximum information transfer rate",,Yes,"Replace ""information"" by ""data""",Agree,
3180600023,09/16/2007 13:58:33 EDT,527,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,11,General Interest,Disapprove,Technical,187,B.2.5,,"Will the different COS_ID be represented consistently across different link types? If not, then maybe a linkType should be added along with COS_ID to clarify the class of service identifier explicitly for that link type",,Yes,"Clarify if COS-ID are consistently represented across all links or are they on a per link basis. If on a per link basis add, the linkType to COS_ID.",Disagree,COS is based on generic ITU defined classes
3180500023,09/16/2007 13:58:33 EDT,526,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,10,General Interest,Disapprove,Editorial,111,7.4.20.3.2,16,Font of parameters in list needs to be made consistent,,Yes,Fix the font. This is there is several other places in draft. Fix this.,Agree,
3180400023,09/16/2007 13:58:33 EDT,525,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,9,General Interest,Disapprove,Technical,108,7.4.20,,Several MIH Handover primitives use CurrentLinkIdentifier as a parameter. This parameter is not required since MIHF and MN implicitly know which link is currently being used.,,Yes,Delete CurrentLinkIdentifier from all MIH Handover primitives. A SourceIdentifer may be included if required wherever appropriate.,Principle,"Change the CurrentLinkIdentifier to SourceLinkIdentifier for MIH_Net_HO_Candidate_Query  response, MIH_MN_HO_Candidate_Query request and response."
3180300023,09/16/2007 13:58:33 EDT,524,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,8,General Interest,Disapprove,Technical,144,8.2.2,,The ACK mechanism is Optional to use and since the State diagrams arre applicable only in this optional case move this section to the Annex.,,Yes,Move section 8.2.2 to Annex,Disagree,This section covers aspects that are important for understanding the behaviour of MIH protocol and hence this needs to be included in main part of specification
3180200023,09/16/2007 13:58:33 EDT,523,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,7,General Interest,Disapprove,Technical,141,7.6,,MIH_NMS_SAP tries to provide details of specific implementation which adds no value to this spec.,,Yes,Delete all references to MIH_NMS_SAP from the spec. Delete references to Network management as well.,Agree,
3180100023,09/16/2007 13:58:33 EDT,522,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,6,General Interest,Disapprove,Technical,137,7.5,,MIH_NET_SAP tries to provide details of specific implementation which adds no value to this spec.,,Yes,Delete all references to MIH_NET_SAP from the spec. Delete references to Network Communication as well,Disagree,MIH_NET_SAP is required.
3180000023,09/16/2007 13:58:33 EDT,521,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,5,General Interest,Disapprove,Technical,19,5.4.2,,"Rename reference points R1..R5, as J1..J5 (or something else), since they overlap with those defined in WiMAX Forum",,Yes,"Rename R1..R5, as J1..J5 throughout the document",Principle,"Change it to RP1, RP2...."
3179900023,09/16/2007 13:58:33 EDT,520,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,4,General Interest,Disapprove,Technical,26,5.5.3,,"In case of 802.11, SME makes intra-technology handover decisions. Clarify the role of SME w.r.t MIH and update figure-7 appropriately",,Yes,Updtae figure-7 and section 5.5.3,Agree,
3179800023,09/16/2007 13:58:33 EDT,519,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,3,General Interest,Disapprove,Technical,282,Annex J,,Delete Annex J as it is redundant and not required in the specification.,,Yes,Delete Annex J,Agree,
3179700023,09/16/2007 13:58:33 EDT,518,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,2,General Interest,Disapprove,Technical,224,Annex F,,Delete Annex F as it is redundant and not required in the specification.,,Yes,Delete Annex F,Disagree,Annex-F is required
3179600023,09/16/2007 13:58:33 EDT,517,"Gupta, Vivek",vivekggupta@ieee.org,5034732456,Individual,1,General Interest,Disapprove,Technical,221,Annex E,,Move References (Bibliography) to section 2 Normative References. Why is this buried at the end instead of being in front.,,Yes,Move all normative references to section2. Consider moving this part to somewhere earlier in draft and delete Annex E,Disagree,As per the IEEE guidelines
3179500023,09/16/2007 13:36:45 EDT,516,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,34,Producer,Disapprove,Technical,34,6.2.5,31,"How does an MIH entity determine if a pairing request from another MiH entity is to be admitted or not authentication-wise ? For example, there doesn't seem to be any link level indication for the MIH entity to check or have reported back if the underlying link has been authenticated or associated such that at least implicitly ""authentication"" can be deduced from the link status for wireless links. Then, in the specific case of L2 MIH over Ethernet, is any PoA trying to contact another one in the same broadcast domain by definition ""authenticated"" ?",,Yes,"802.21 needs to clearly state working assumptions regarding authentication of underlying links and how an MIH entity implementing MIH protocol is expected to behave depending on states XYZ of the underlying access technologies. For example, state that ""any locally originating request is considered authenticated vs. remote requests only when conditions XYZ are met (list may be different per access technology)"". It is ok to say it is out of scope for 802.21, but the implementor needs a clear guideline where to look for a technical solution, otherwise no inter-operability.",Principle,There is work being carried out by Security group to address this.
3179400023,09/16/2007 13:36:45 EDT,515,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,33,Producer,Disapprove,Technical,71,7.3.10,54,"How practical / feasible is ""Link_PDU_Transmit_Status.indication"" ? For example, in W-CDMA if such an indication is generated each and every time an RLC PDU is successfully delivered, there could several hundreds of these per sec ? Another issue I have is that 7.3.10.1 makes an unnecessary reference to ""ARQ module"" which is not true for all access technologies. With HSDPA, MAC-hs ""(ARQ module) doesn't directly reside below the RLC for example, and not even in the same node network-wise (RLC in RNC, MAC-hs in Node B).",,No,Remove the text about the ARQ mobile. Introduce a mechanism where LINK_PDU_Trasnmit_Status is issues following a certain number of PDU deiveries to reduce signalling load on the internal interfaces.,Principle,Text will be updated appropriately
3179300023,09/16/2007 13:36:45 EDT,514,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,32,Producer,Disapprove,Technical,47,6.5.2,2,"""A similar mechanism may be available for IEEE 802.16 for this query"" - is there or isn't there ?",,No,Clearly state if 802.16 provides a mechanism similar to the 802.11u action frames to allow for certain MIH IS exchanges before Authenticated and Associated,Agree,This is supported in 802.16 as well before authentication.
3179200023,09/16/2007 12:18:13 EDT,513,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,31,Producer,Disapprove,Technical,67,7.4.3,9,"LINK_UP.indication contains MAC addresses of old and new access routers in its parameters list. That would probably apply for most LINK_UP indications received from 802 access technologies in certain deployments (but for home routers ?), but what would be the corresponding vales in the case of LINK_UP received for GSM/EGPRS or W-CDMA links where there is no access router ?",,No,"Come up with a more generic parameter list for the LINK_UP indication, maybe something like old / new IP address only ? For cellular, could allocated PDP contexts or some subparameter of it do the job ?",Agree,Change the data type to LINK_ADDRESS. 
3179100023,09/16/2007 12:18:13 EDT,512,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,30,Producer,Disapprove,Technical,181,,57,"Table B.4 ""Threshold"" which is used extensively for link configurations, looks like there is no real mapping relationship to any of the real-life measurements indicated by LINK_PARAM_TYPE for a specific access technology. One example, if LINK_PARAM_TYPE indicates LINK_PARAM_UMTS for use, let's say with RSCP or CPICH_Ec/Io, the 802.21 THRESHOLD sets a value in the range of 0...65535. However, CPICH_RSCP in W-CDMA would be a reported and measured value in the range -120 to -25 dBm (TS 25.133). How does the 802.21 THRESHOLD value map to the CPICH_RSCP measurement? Another example, TrCh BLER configurable as a type in 802.21 which in 3G is reported as 1 out of 64 values log10(measurement in the range of 0.00 to 1.0). Would this fit the 0...65535 range ? Moreover, I am almost afraid that the current draft is in a similar situation w.r.t other access technologies. For example, how would THRESHOLD map to the 802.11 Beacon RSSI ? Or is this described somewhere else in the draft and I skipped over it ?",,Yes,"Define unambiguous mappings between 802.21 link threshold values and parameters (example: THRESHOLD) to the measurements configured through LINK_PARAM_TYPE. Specifically for 2G/3G cellular, please consider the following 2 cases: MN reported measurements for which precisely defined reporting ranges and accuracies exist (see 25.133 and alike) and network-side only measurements (a.k.a from BTS) where no standard defines anything, and mapping of reported measurements like UL TrCh BLER to values for a network-side MIH function may need to make some clever assumptions...",Principle,"In table B-4 page 182, lines 5 and 36, add the following sentence in the Definition column of THRESHOLD_VALUE and LINK_PARAM_VALUE:    ""The format of the media-dependent value is defined in the respective media specification standard  and the equivalent number of bits (i.e. first bits) of this data type is used. In case that there are remaining unused bits in the data type, these are marked as all-zeros ('0').""  "
3179000023,09/16/2007 12:18:13 EDT,511,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,29,Producer,Disapprove,Technical,45,6.4.3.2,30,I don't understand the logic behind classifying Link_Event_subscribe and _Unsubsribe into the MIH command service ? Wouldn't these two be part of Event Service ?,,Yes,Move Link_Event_Subscribe and _Unsubscribe to section 6.3.3,Disagree,These are part of Service management category and not Command Service at the MIH level.  At the link level they are part of Link Commands
3178900023,09/16/2007 12:18:13 EDT,510,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,28,Producer,Disapprove,Technical,62,7.2.3.1,17,"MIH_Event_Subscribe and _Unsubscribe are listed part of Service Management category, but should be part of the Even Service category. This change may affect other sections as well (6.2.1 for example)",,Yes,"I propose to make MIH_Event_Subscribe and _Unsubscribe part of the Event Service rather than part of the generic Service management (like Discovery and Registration with MIH). The reason is that MIH_Event_Subscribe is an integral part of the MIH event notifications mechanism and can anyway not exist on its own when MIH Event Service is not implemented in the MIH entity. General MIH procedures would always start with MIH discovery, followed by optional MIH registration. Subsequently (changed now), if an MIH entity has ES implemented, then ES starts with a subscription to events XYZ followed by the ""reports"" it gets back locally or from a remote peer.",Disagree,These are part of Service management category and group feels that is a better classification.
3178800023,09/16/2007 12:18:13 EDT,509,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,27,Producer,Disapprove,Technical,141,7.6.1.2.2,6,"According to Table B-2 page 176, network error is indicated by code 4, not 3.",,No,Correct to 4,Agree,
3178700023,09/16/2007 12:18:13 EDT,508,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,26,Producer,Disapprove,Technical,140,7.6.1.1.1,27,"It may sound trivial, but ""Initialize"" upon receipt of the MIH_NMS_Initialize.request is not defined.",,No,"Please define (somewhere) the actions that an MIH protocol entity is supposed to follow upon receipt of this primitive through MIH_NMS_SAP. For example, ""MiH entity clears all transactions contexts, deletes all existing registrations to peer MIH entities and so on.""",Principle,MIH NMS SAP has been deleted
3178600023,09/16/2007 12:18:13 EDT,507,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,25,Producer,Disapprove,Technical,32,5.7.2,44,I always thought it is possible to use MiH signalling exchanges through data frames of Ethertype XYZ even in 802.11 State 3 and that the action frames to carry MIH signalling in State 1 are a specific tool to optimize MIH discovery a.k.a MIH IS before authentication and association.,,Yes,"Please state clearly if MIH signalling exchanges using data frames of Ethertype TBD is an option for 802.11 or if it is not. Clearly state to what extent the 2nd available option of using management frames is possible (a.k.a MIH IS only and so on). Alternatively, insert wording here ruling out the possibility of using data frames in 802.11 to carry MIH.",Principle,"5.7.2 Transport Considerations    Change as follows  ""  - Transport of MIH messages over IEEE 802.11 and IEEE 802.16 links is recommended through extensions of media-specific management frames in state 1, and through management or data frames in state 3.    - No assumptions are made in this standard regarding the transport of MIH messages over 3GPP and 3GPP2 access links at L2.  If the MN cannot reach the MIH PoS via the lower layer (i.e. L2) transport mechanisms, then higher layer (i.e. L3) transport mechanisms shall be used.  """
3178500023,09/16/2007 12:18:13 EDT,506,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,24,Producer,Disapprove,Editorial,31,5.6.2,33,"MLME_SAP, C-SAP, MIH_3GLINK_SAP, LSAP, CS_SAP are not shown in Figure 11 page 30. Figure 11 page 30 is misleading with respect to the description of page 30 and 31.",,No,I suggest to replace the 802.3&3GPP2 boxes in Figure 11 by these SAPs. Consider to move text describing mapping of LINK_SAP to access-specific SAPs from Section 7.1 page 59 here.,Agree,
3178400023,09/16/2007 10:24:17 EDT,505,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,6,General Interest,Approve,Technical,90,,24,"[7.4.5.2.2] the parameter ""Response Link Event List"" in MIH_Event_Unsubscribe.confirm does not include status information as specified in the description.",,No,"Change the description of ""Response Link Event List"" from: ""List of MIH events along with their unsubscription status."" To: ""List of successfully unsubscribed link events.""",Agree,
3178300023,09/16/2007 10:24:17 EDT,504,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,5,General Interest,Approve,Technical,198,,38,Table B-15 -Data type for RDF information query: Wrong default value has been specified for MIME_TYPE.,,No,"In both line38 and 37: Change default value for Mime-Type from: ""application/Sparql results+xml"" (which is applicable for query result, but NOT query) to: ""application/sparql-query""",Agree,
3178200023,09/16/2007 10:24:17 EDT,503,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,4,General Interest,Approve,Editorial,103,,19,LINK_SACN -> LINK_SCAN,,No,LINK_SACN -> LINK_SCAN,Agree,
3178100023,09/16/2007 10:24:17 EDT,502,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,3,General Interest,Approve,Technical,149,,42,The state machines do no capture the case of : Unsolicited MIH Capability response (broadcasted message).,,No,"Add to section 8.2.3.5.1, page 149, line 42: Since sending or listening to an unsolicited MIH discovery response is an optional feature and an exception to the way normally the protocol works (a response is sent/received only after receiving/sending a request), this option is not represented in the transaction state machines above",Out of Scope,Comment no longer applicable due to the state machine clause is updated by other comments
3178000023,09/16/2007 10:24:17 EDT,501,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,2,General Interest,Approve,Technical,153,,6,"[8.6] For extendibility of MIH, there is a need to allow defining experimental TLV type values.",,No,21-07-0312-00-0000-extendibility.doc,Agree,
3177900023,09/16/2007 10:24:17 EDT,500,"Famolari, David",fam@research.telcordia.com,732-699-3135,Individual,1,General Interest,Approve,Editorial,13,,19,"[1.5.1]Sentence too complicated and unclear: ""The IEEE 802.21 standard defines the information that helps in network discovery and specifies the means by which such information may be obtained for supported access networks and be made available to the MIH Users.""",,No,"Remove ""for supported access networks"".",Agree,
3177800023,09/16/2007 08:19:02 EDT,499,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,10,Producer,Disapprove,General,15,5,62,"""The destination of an event is established dynamically..""? Does it mean every time, an event is generated, the destination needs to be constructed by the MIH?",,Yes,Change the text to clearly specify how the destaination of event is identified.,Agree,"Delete the word ""dynamically"""
3177700023,09/16/2007 08:19:02 EDT,498,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,9,Producer,Disapprove,General,15,5,62,"What is a ""stack""?",,Yes,"change the ""stack"" to ""node"", and ""remote stack"" to ""remote node""",Principle,"Change ""stack"" in all places.  "
3177600023,09/16/2007 08:19:02 EDT,497,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,8,Producer,Disapprove,General,5,2,1,"MIH is about handover between different access technologies. Yet, there is not even one normative reference. Is the MIH really built from scratch that does not rely on any prior defined technolgy?",,Yes,"Take a look what other 802 standards does, and define the normative reference for MIH.",Agree,
3177500023,09/16/2007 08:19:02 EDT,496,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,7,Producer,Disapprove,Technical,14,5,45,"What does it mean by ""transparent inter-working with legacy equipment""? Does this standard make legacy equipment speak MIH language? ""Interworking"" is different from co-existance. Is this principle trying to say two different requirements?",,Yes,"Define the ""interworking"" or remove it.",Agree,"Change as follows:  ""The standard supports transparent  operation with legacy equipment"""
3177400023,09/16/2007 08:19:02 EDT,495,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,6,Producer,Disapprove,Technical,13,5,57,"In the overview subclause 1.3, it is clearly stated that the handover is not limited to mobile case. Why there is a specific subclause 5.1.9 talking about movement caused handover? Is this going to be different from other type of handover?",,Yes,"Merge the text to subclause 5.1.1, or remove the subclause.",Agree,Delete 5.1.9
3177300023,09/16/2007 08:19:02 EDT,494,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,5,Producer,Disapprove,Technical,118,7,8,The MIH_xxx.request should nevery be used by the MIHF. It is used by the MIH user.,,Yes,Fix the text,Agree,Change this in all places in draft
3177200023,09/16/2007 08:19:02 EDT,493,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,4,Producer,Disapprove,General,1,1,31,The change bar at left side should not appear in this draft.,,Yes,Remove the change bars.,Agree,
3177100023,09/16/2007 08:19:02 EDT,492,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,3,Producer,Disapprove,General,57,6,1,"""Negtwork Communication"" is not a MIHF Service according to the defintion in subclause 5.3.",,Yes,Move this to be a subclause of 6.2.,Agree,
3177000023,09/16/2007 08:19:02 EDT,491,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,2,Producer,Disapprove,General,56,6,1,"""Network management"" is not a MIHF service according to the defintion in subclause 5.3.",,Yes,Move this to be a subclause of 6.2.,Agree,
3176900023,09/16/2007 08:19:02 EDT,490,"Cheng, Hong",chenghong@ieee.org,65505477,Individual,1,Producer,Disapprove,General,33,6,1,"Both the subclause 5.3 and 6 are simply named ""MIHF Services"". It is confusing. The group should come up with better titles to describe the contents.",,Yes,Change the tile of subclause 5.3,Agree,
3176800023,09/16/2007 07:13:12 EDT,489,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,23,Producer,Disapprove,Editorial,173,,1,"Reorganize the Annexes. For example, I find Annex F and G and H valuable and good to keep. However, in order to improve readability of the Annex in general, which contains a wealth of information, may want to consider to collapse information. For example, all normative parts should all go together and then, all informative parts should go together.",,No,"The Annex overall should contain something like 3 parts, 1) normative definitions (former A to D), 2) something like a PICS or protocol conformance configurations (new, see comment in line 24), and 3) informative parts (like Annex F and G and H collapsed into one), a.k.a F becomes F.1 and G becomes F.2, H becomes F.3 and so on.",Principle,"The annex have been updated and re-organized. Once PICS is added, further updtaes may be performed."
3176700023,09/16/2007 07:13:12 EDT,488,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,22,Producer,Disapprove,Technical,,,,"Inter-operability requirements regarding minimum set of mandated MIH functions, SAPs, primitives, maybe depending on the combinations of access technologies and operation scenarios a MN supports are missing in 802.21 and make this specification more of a technical recommendation than an actual specification document. A solution must be found, or this draft spec will never see real-life deployment.",,Yes,"First, introduce something like a PICS somewhere in the Annex, that groups MIH functionality in blocks (Services, Primitive Categories, Transport options) such that an actual protocol-conformance statement can be based on it. Then, as a function of access technology combinations implemented on a MN, define sets of comformant functionality groupings. One example, a MN that has both Ethernet and 802.11 (like a laptop), MIH used for session continutity, must support L2 MIH transport (but doesn't need L3 option), it must support both IS and ES (but CS is optional), it must support the following list of media-specific SAPs XYZ and the following list of local and remote primitives XYZ. Another example, a MN that has both 802.11 and EGPRS, must support L3 IP trasnport option (but doesn't need L2), must support the following SAPs and the following list of primitives. Or, define above minimum MIH protocol sets per access technology if supported in the MN. Like, any MN that has an 802.11 crd in it, in order to claim 802.21 compliance, it must have XYZ. Could do this per access technology and 802.21 complaince overall is determined as a superset of the individual per access requirement. If this comment cannot be resolved, I would recommend to downgrade 802.21 to a Recommended Practice document only.",Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3176600023,09/16/2007 07:13:12 EDT,487,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,21,Producer,Disapprove,Technical,32,5.7.2,47,"Need to state at least a working assumption or list of 2-3 options for technical solution to MIH transport for 3GPP-based cellular technologies. If this specification is to apply to encompass 3GPP cellular, then an implementor must know which options he can use to realize the needed signalling. Independent of which SDO standardizes the solution, there must be at least a limited set of choices available ?",,Yes,"For example, assume and describe here whatever MIPSHOP will produce one day can be used as one realization for IP-based external transport interfaces. Alternatively, describe a means to transport at least a limited set of MIH messages through GMM or GTP messages, like Direct Transfer etc., even if any formal specification would be incumbent to 3GPP one day. needa t least to describe or at least outline the principle of 2-3 technical approaches to guide an implementor. The only other alternative is to entirely remove 3GPP from the list of access technologies that 802.21 can operate with (everywhere in the 802.21 draft specification).",Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3176500023,09/16/2007 07:13:12 EDT,486,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,20,Producer,Disapprove,Editorial,32,5.7.2,44,Change sentence,,No,"""Transport of MIH messages over IEEE 802.11 and IEEE 802.16 can either be realized through transparent transport of MIH frames as Ethertype XYZ through the data plane, or, using management frames."" (is this the way 802.11 and .16 are doing it ?)",Principle,the sentence has been modified and the problem is rectified
3176400023,09/16/2007 07:13:12 EDT,485,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,19,Producer,Disapprove,Editorial,32,5.7.2,35,Remove sentence,,No,"""For example, wireless networks & could be enhanced for carrying the MIH messages."" This is a standard that describes a technical solution, not a conference paper that describes what *could* be done (in theory).",Agree,
3176300023,09/16/2007 07:13:12 EDT,484,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,18,Producer,Disapprove,Editorial,35,6.2.5,16,Figure 12 should be moved to section 6.2.1 because it shows the overall flow of events when using MIH.,,No,Move figure 12 to 6.2.1.,Disagree,Fig 12 is meant to show the registration flow. Some enhancement is made to fig 12 to make this clearer
3176200023,09/16/2007 07:13:12 EDT,483,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,17,Producer,Disapprove,Editorial,33,6.2.1,32,A description of the available options for which transport protocol an MIH node would use to discover MIH peers is missing.,,No,"Introduce a brief description of the L2 transport protocol and the L3 IP-based trasnport protocol options. For example, ""MIH node can acquire list of MIH peers either locally or remotely. Locally can mean a pre-configured list. Remote acquisition can mean making use of the following MIH transport options, X, Y, Z"". Could consider to move test in page 33 lines 6-14 here ?",Principle,
3176100023,09/16/2007 07:13:12 EDT,482,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,16,Producer,Disapprove,Technical,292,,47,The implementor doesn't care what may or may not have been proposed and only wants to know what to build against.,,No,Remove lines 47-48 and replace by a reference or short summary of features provided through the 11u amendment.,Agree,"The specification should contain all the required text and references to group's contributions should be avoided  Remove references to contributions 21-05/350 and 21-05/335, and include the list of the 802.21-specific amendments suggested by the 802.11u and 802.16g amendments to specifications IEEE 802.11 and IEEE 802.16"
3176000023,09/16/2007 07:13:12 EDT,481,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,15,Producer,Disapprove,Technical,292,,42,Reference to Ethertype is missing.,,No,"Either insert the Ethertype for L2 MIH (if one exists already), or remove this section.",Agree,
3175900023,09/16/2007 07:13:12 EDT,480,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,14,Producer,Disapprove,Editorial,282,,1,"What is the value added of Annex J ? Ideally, this section should contain an outline of the L3 transport-solution (a.k.a. MIPSHOP etc) if one exists one day. These requirements to the IETF process are meaningless from IEEE's perspective.",,No,Remove Annex J and insert some references like RFCs if possibly into the normative reference section.,Agree,
3175800023,09/16/2007 07:13:12 EDT,479,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,13,Producer,Disapprove,Technical,194,,38,"Network type and revision presentation for Wireless - UMTS is wrong. For example, there is no MIMO/OFDM in Rel-7. Then, any MS can be Rel-5 compliant without implementing HSDPA. Similar for Rel-6.",,No,"Distinguish between basic W-CDMA features, but remove any reference to releases. 0 - R99 only. 1-HSDPA. 2-HSUPA. 3-MBMS&",Principle,Please refer to contribution 21-07-0422-00-00000  
3175700023,09/16/2007 07:13:12 EDT,478,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,12,Producer,Disapprove,Technical,184,,56,"LINK_POWER_UP ambiguous with EGPRS/W-CDMA ? With EGPRS for example, what does establish L2 link mean ? The MN would register with the SGSN to connect to GPRS, but before it actually allocated a PDP context, nothing can be transmitted. A thing like just establishing an RLC/MAC connection doesn't exist for EGPRS. Same logic applies to W-CDMA.",,Yes,"Define the link establishment as PDP context activation in the case of 3GPP access technologies (even though this excedes L2, it is the only thing that makes sense).",Principle,"The current definition is more clear.  The suggested definition (below) is not very clear.  ""Power up the link and establish the required connections to allow L3 data connectivity (e.g. IP connectivity)""    Make following changes:  1.	Change table B-5 Link Actions DATA_FORWARDING_REQUEST description column to append the text 'Not valid on 3GPP link type'  2.	Change table B-5 Link Actions LINK_POWER_UP description column to append the text 'For 3GPP link type, power up lower layers and establish PDP context'    "
3175600023,09/16/2007 07:13:12 EDT,477,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,11,Producer,Disapprove,Technical,184,,14,"CHANNEL_ID, with respect to what is it defined ? Is this an abritrary frequency that is just ""labelled"" Channel ID, or is it actually tied to an actual frequency ? If yes, does this apply to all access technologies or just to 802.11 ?",,No,"Define an actual relationship between Channel_ID and operating frequencies similar to ARFCN in GSM/W-CDMA. Or, delete it and re-use the existing access technology-specific identifiers like ARFCN.",Principle,"Increase the length to UNSIGNED_INT(2)    Modify the Definition as follows:  ""Channel identifier as defined in the specific link technology (e.g. SDO)""  "
3175500023,09/16/2007 07:13:12 EDT,476,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,10,Producer,Disapprove,Technical,181,,19,LINK_PARAM_UMTS is sort of wrong and needs to be corrected.,,Yes,"Add CPICH_Ec/I0 and CPICH_RSCP which are the 2 most important measurements for the MN. Before writing down a long list here, please have a look into 25.215 and use the measurement names used there&",Principle,"The LINK_PARAM_UMTS list does not represent the most important measurements required from the MN as specified in 3GPP 25.215    Rename the list as ""LINK_PARAM_WCDMA_FDD"" and replace the Description list by the  following elements:  Bit 0: CPICH RSCP  	Bit 1: PCCPCH RSCP	  Bit 2: UTRA carrier RSSI  Bit 3: GSM carrier RSSI  Bit 4: CPICH Ec/No  Bit 5: Transport channel BLER	  Bit 6: UE transmitted power  Bit 7-255: reserved    Similarly, the LINK_PARAM_GSM list does not represent the most important measurements required from the MN as specified in 3GPP 25.008    Merge the LINK_PARAM_GSM and LINK_PARAM_GPRS lists into a single one (e.g. LINK_PARAM_GSM_GPRS) and replace the list by the  following elements:  Bit 0: RxQual  Bit 1: RxLev  Bit 2: Mean BEP  Bit 3: StDev BEP  Bit 4-255: reserved  Acronyms could require definition in section 4    Table B-13 may also need to be updated.  "
3175400023,09/16/2007 07:13:12 EDT,475,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,9,Producer,Disapprove,Editorial,177,,55,"Table B.4 link type ""UMTS"" is meaningless, supposedly W-CDMA FDD is meant.",,No,Change UMTS to W-CDMA FDD. Introduce new identifiers for W-CDMA TDD and TD-SCDMA each (all of which reperesent UMTS technologies).,Principle,Modify the LINK_TYPE Definition as follows:    1: Wireless - GSM/GPRS  2: Wireless - EDGE  3-14: Reserved  23: Wireless - W-CDMA FDD      
3175300023,09/16/2007 07:13:12 EDT,474,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,8,Producer,Disapprove,Technical,177,,27,"In table B.3 Data types for address, 3GPP identifiers are unclear and need to be corrected.",,No,"Define ARFCN, BSIC, GSM vs W-CDMA band by references to 3GPP specifications. Does PSC mean Primary Scrambling Code ? If yes, use the right name of the scrambling code identifier in the RRC specifications, cite it.",Principle,Please refer to contribution 21-07-0424-00-0000    OTHER_L2_ADDRESS can be combined with LINK_ADDRESS
3175200023,09/16/2007 07:13:12 EDT,473,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,7,Producer,Disapprove,Technical,286,,51,"Parts of Annex K, specifically K.2 and K.3 should be mandatory. At least a subset of 4-5 QoS mappings froms access technology A to B must be mandated to make any notion of QoS preservation meaningful.",,Yes,"Recommend to make at least K.2 and K.3 mandatory, eventually moving these out of the Annex to the main part of the specification. Or, choose a subset of 4-5 QoS parameters that must map from A to B, and leave the rest FYI only.",Disagree,Measurements available in the respective technologies are not even mandatory therefore can not make the mapping mandatory.   Measurement examples provided by Annex K have nothing to do with interoperability. There different methods for using MAC layer measurements and making inferences on the current quality of service conditions as seen by the device.    
3175100023,09/16/2007 07:13:12 EDT,472,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,6,Producer,Disapprove,Technical,31,5.6.2,1,"Absence of a media-dependent SAP for GSM/EGPRS. There is only a MIH_3GLINK_SAP, but nothing is defined for GSM/EGPRS cellular, even though both seem to be in scope for 802.21 as part of 3GPP access technologies.",,Yes,"Either introduce at least a formal definition for a GSM/EGPRS media-specific SAP here, or remove GSM/EGPRS from the scope of 802.21 when talking about 3GPP technologies.",Principle,Please refer to contribution 21-07-0414-02-0000
3175000023,09/16/2007 07:13:12 EDT,471,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,5,Producer,Disapprove,Technical,13,5.1.7,36,"This section must be extended to give a clear idea to the implementor how 802.21 works in conjunction with encryption/integrity protection provided by at least the IEEE 802 technologies. While I agree that 802.21 doesn't need to address security aspects involved in mobility, I also think it is too simplistic to say it is ""simply out of scope"". The minimum that 802.21 must describe is where the signalling or some of the services (notably, command service) it provides is dependent on prior security associations, and which MIH components dependent on these being setup. In addition, 802.21 needs to state the working assumptions (and description thereof) how 802.21 would work in presence of 3GPP-based security mechanisms. The assumption that security in the sense of encryption is self-contained in the MAC may be true for IEEE 802, but not necessarily for 3GPP cellular. Technically, even the AAA necessary to setup MAC encryption is beyond the link layer (a.k.a. EAP etc.). In 3GPP W-CDMA, encryption for the user plane is done in the RLC with few exceptions, which qualifies as a link layer. However, in GPRS/EDGE, this would be done in the LLC in the SGSN sitting on top of the RLC/MAC stack in the BSS. Does this still qualify as link layer ?",,Yes,"For example, ""in the specific case of 802.11, state that MIH relies on link-layer security, with the exception of MIH IIS etc that can eventually be sent even in State 1 before authentication through action frames. Clearly state that as far as 802.3 and 802.11 are concerned, 802.21 does not bring it own security mechnism to encrypt for example the MIH protocol exchanges over the air - it exclusively relies on secure links provided between nodes through the underlying technology."" Also, must come up with a description for 5.1.7 where the authentication component of the security solution comes from. For example, ""AAA is supposed to be supplied by the underlying access technology, like EAP-TLS in case of X,Y,Z with 802.11."" Similar, spell out any difference (if) when using MIH L2 trasnport vs. MIH L3 trasnport protocols.Then, come up with a concise description at least for the case of W-CDMA and GPRS/EDGE. This sort of information is partially contained already at the end of sections 5.5.2, 5.5.3, etc, should summarize it here in section 5.1.7.",Principle,Section 5.1.7 has been deleted.
3174900023,09/16/2007 07:13:12 EDT,470,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,4,Producer,Disapprove,Technical,5,2,4,Why is there no normative reference ?,,Yes,Inlcude as a minimum the latest 802.11 roll-up and for example 802.11u as amendment incorporating 802.21 support. Do similar for 802.16-20004/d/e and the 3GPP air interface specifications.,Agree,
3174800023,09/16/2007 07:13:12 EDT,469,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,3,Producer,Disapprove,Editorial,221,,1,Is Annex E needed ?,,No,"Remove Annex E entirely, because it has no nornative or informational value. Consider to move applicable RFCs to Section2 normative references",Disagree,Annex E (informative) Bibliography is a recommendation from IEEE Standards Style Manual. It will remain as long as there are relevant references that the group wants to keep.
3174700023,09/16/2007 07:13:12 EDT,468,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,2,Producer,Disapprove,Editorial,10,4,7,Acronym for 3GPP spelled wrong,,No,"Change to ""3rd Generation Partnership Project"", similar for 3GPP2 one line below",Agree,
3174600023,09/16/2007 07:13:12 EDT,467,"Rudolf, Marian",marian.rudolf@gmx.net,514-933-4812,Individual,1,Producer,Disapprove,Editorial,6,3.15,63,"""UMTS Layer"" is ambiguous",,No,"""the 3GPP lower layers are L1, MAC, RLC and PDCP in the case of W-CDMA FDD/TDD and L1/LAPDm in the case of GSM CS and L1/MAC/RLC in the case of GPRS/EGPRS""",Agree,
3174500023,09/16/2007 06:10:15 EDT,466,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,7,Producer,Disapprove,General,41,,,"The draft is very verbose and inserts too many out-of-scope examples only to mention that they are out of scope. While the intention of assisting comprehension is appreciated, it also adds ambiguity about the scope and makes the definition/specification less focused.",,Yes,"Allow the discussion of applicability of MIH ONLY in the Section 5 and informative annexes. The other sections shall only DEFINE and SPECIFY MIH, without any repetitive examples of applicability in mobility management, etc.",Agree,"Page 41, Line 57  (e.g., MIHF to MAC, or MIHF to PHY)    Page 42, Line 2  (e.g., from upper layer mobility protocol to MIHF, or from policy engine to MIHF)    Page 72, Line 65  (e.g., transport)    Page 73, Line 2  (e.g., cellular, IEEE 802.16e)    Page 73, Line 55  (e.g., cellular, IEEE 802.16e    Page 74, Line 19  (e.g., transport)    Page 98, Line 36  (e.g., L3 Handovers)    Page 95, Line 1  For example, a mobility management entity locally or remotely located from the event origination link may take these events into account  in its decision algorithm.    Page 136, Line 21  (i.e., Info Response Binary Data List, Info Response RDF Data List, Info Response RDF Schema URL and Info Response RDF Schema List)    Page 137, Line 19  (i.e., Info  Response Binary Data List, Info Response RDF Data List, Info Response RDF Schema URL and Info Response RDF Schema List)"
3174400023,09/16/2007 06:10:15 EDT,465,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,6,Producer,Disapprove,Technical,52,,1,"Sub-clause 6.5.5.1: Regarding the size of the ""Length"" field in TLV encoding, it appears that the effort is made to minimise the size of the ""Length"" field, and the encoding of such information as part of the ""Type"" field would be more effective. A 32-bit ""Type"" field is enormous, so it seems reasonable to use 2 bits in the ""Type"" field to indicate the size of the ""Length"" field, representing 1-4 octets respectively for the size of the ""Length"" field. The encoding and decoding of such information seems to be also more efficient than the 3 cases described in the current draft.",,Yes,"Delete cases 1, 2, and 3. On page 51, replace ""The Length field may be interpreted as follows"" by ""The 2 LSB of the Type field are used to indicate the number of octets for the size of the Length field."" On page 51 Table 9, make the necessary adjustments to reflect that the 2 LSB are not used for IE type/ID. Note: LSB is used to allow more efficient computing to allow the masked LSB to be used as desired numeric value withouth shifting. Subsequently, Annex A Table A-1 needs adjustment of the IE ID values.",Disagree,The current mechanism is adequate.
3174300023,09/16/2007 06:10:15 EDT,464,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,5,Producer,Disapprove,Technical,29,,22,Sub-clause 5.6.1: A serv ice primitive describes an interaction (not limited to the information transfer) between a service provider and a service user at a SAP.,,Yes,"Correct definition, by replacing ""specify the information to be exchanged and the format of the information exchanges"" with ""specify the interactions between the service user and provider"".",Agree,
3174200023,09/16/2007 06:10:15 EDT,463,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,4,Producer,Disapprove,Technical,14,,40,"Sub-clause 5.2.1: It is contradictory to state that ""MIHF may do further processing on link layer triggers and other events"" while also stating that ""the definition of such processing is outside the scope of the standard. MIHF shall specify what it does (and processes).",,Yes,"Delete ""MIHF may do further processing on link layer triggers and other events. The definition of such processing is outside the scope of the stanndard.""",Agree,
3174100023,09/16/2007 06:10:15 EDT,462,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,3,Producer,Disapprove,Technical,14,,20,"Sub-clause 5.2.1: It is both unnecessary and inexact to emphasise that MIHF ""offers a unified interface"" to MIH users. This is technically misleading.",,Yes,"Delete ""From that perspective, MIHF offers a unified interface to the MIH Users."" Replace ""The service primitives exposed by this unified interface. . ."" to ""The service primitives defined at this interface. . .""|",Agree,"Delete ""From that perspective, MIHF offers a unified interface to the MIH Users.""   Replace ""The service primitives exposed by this unified interface. . .""   to   ""The service primitives defined by this interface. . ."""
3174000023,09/16/2007 06:10:15 EDT,461,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,2,Producer,Disapprove,Technical,8,,44,Sub-clause 3.44: A serv ice primitive describes an interaction (not limited to the information transfer) between a service provider and a service user at a SAP.,,Yes,"Correct definition, by replacing ""information transfer"" with ""interaction"".",Agree,"Change as follows:  ""3.44 service primitive: Conceptual abstraction describing the interaction between an  upper layer user and the present layer in the provisioning of a service. The abstraction resides in the exclusive  specification of the service provided and not in the means by which the service is provided."""
3173900023,09/16/2007 06:10:15 EDT,460,"Lach, Hong-Yon",hong-yon.lach@motorola.com,33169352536,Individual,1,Producer,Disapprove,Technical,8,,27,"Sub-clause 3.40: A ""protocol data unit"" (PDU) refers to a packet produced by a protocol for exchange between the protocol's peer entities. The upper-layer user data exchanges between layers at a SAP is referred to as a ""service data unit"" (SDU).",,Yes,"Correct definition of ""protocol data unit"". A possible definition is: ""Packet produced by a protocol for exchange between the protocol's peer entities.""",Agree,
3173800023,09/16/2007 03:42:16 EDT,459,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,12,Producer,Disapprove,Technical,127,,32,"The description contains ""This identifies the current link"" for the source link identifier.",,Yes,"Change ""This identifies the current link"" to ""This identifies the source link of the handover"".",Agree,
3173700023,09/16/2007 03:38:14 EDT,458,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,11,Producer,Disapprove,Technical,129,,33,"What does ""current link identifier"" refer to, the source or target link identifier (as specified in the request)?",,Yes,"Either change ""Current Link Identifier to ""Source Link Identifier"" or to ""Target Link Identifier"". Alternatively, remove ""Current Link Identifier"" and add both source and target link identifiers.",Agree,"Change ""Current Link Identifier"" to ""Source Link Identifier""."
3173600023,09/16/2007 03:38:14 EDT,457,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,10,Producer,Disapprove,Technical,128,,57,"What does ""current link identifier"" refer to, the source or target link identifier (as specified in the request)?",,Yes,"Either change ""Current Link Identifier to ""Source Link Identifier"" or to ""Target Link Identifier"". Alternatively, remove ""Current Link Identifier"" and add both source and target link identifiers.",Agree,"Remove ""Current Link Identifier"" and add both source and target link identifiers. (AC: Kind of funny that the request and the response for MIH_MN_HO_Complete has almost identical parameters)"
3173500023,09/16/2007 03:38:14 EDT,456,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,9,Producer,Disapprove,Technical,180,,46,"It appears that CoS values from the LINK_PARAM_TYPE of ""general"" were removed and QOS_LIST (see above comment), defined on page 186 line 26, was added to the list of LINK_PARAM_TYPEs. However, throughput and packet error rate now occur in both types. Additionally, throughput is defined differently; UNSIGNED_INT(2) in LINK_PARAM but UNSIGNED_INT(4) in QOS_LIST.",,Yes,Delete Throughput and Packet Error Rate from QoS list.,Agree,
3173400023,09/16/2007 03:38:14 EDT,455,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,8,Producer,Disapprove,Technical,180,,9,"QOS_LIST is not a link parameter type, Single values have been used for specifying the setting/getting of individual parameters. QOS_LIST is a collection of parameters containing value not types.",,Yes,It is not clear what the intent was for this change. Perhaps it was supposed to be a new type called QOS_LIST_TYPE.,Agree,
3173300023,09/16/2007 03:38:14 EDT,454,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,7,Producer,Disapprove,Technical,150,,60,MIH header is a fixed length (8 bytes).,,Yes,"Remove reference to ""variable octets"" from the figure",Agree,
3173200023,09/16/2007 03:38:14 EDT,453,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,6,Producer,Disapprove,Technical,150,,40,"transaction ID is ""unique among all the pending transactions between a given pair of the sender and receiver"" which is incorrect as both sides may generate the same transaction ID.",,Yes,"Change to ""unique, on a per direction basis, among all the pending transactions between a given pair of the sender and receiver"".",Disagree,"Dont need on ""a per direction basis"""
3173100023,09/16/2007 03:38:14 EDT,452,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,5,Producer,Disapprove,Technical,132,,47,"Additionally, the following is applicable to the above 4 comments. There is some inconsistency between N2N_HO messages and how they identify a given handover. For N2N_HO_Commit we identified the handover by MN MIHF ID while here we are using source and target link identifiers",,Yes,"Either change N2N_HO_Commit to use source and target link identifiers (and always include it in N2N_HO_Complete) or replace source and target link identifiers in N2N_HO_Complete with MN MIHF ID. Alternatively, include MN MIHF ID along with source and target link identifiers in both N2N_HO_Commit and N2N_HO_Complete.",Disagree,N2N functions are between networks and don’t need this
3173000023,09/16/2007 03:38:14 EDT,451,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,4,Producer,Disapprove,Technical,132,,47,"The description of the ""Source Link Identifier"" and ""Target Link Identifier is confusing. For the case where the MN_HO_Complete message is sent to the new target PoS then source and target link identifier are one and the same (At least according to the description).",,Yes,"Change description of ""Source Link Identifier"" to ""Specifies the source link of the handover"". Similarly, change description of ""Target Link Identifier"" to ""Specifies the intendend target link of the handover).",Agree,
3172900023,09/16/2007 03:38:14 EDT,450,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,3,Producer,Disapprove,Technical,131,,54,"The description of the ""Source Link Identifier"" and ""Target Link Identifier is confusing. For the case where the MN_HO_Complete message is sent to the new target PoS then source and target link identifier are one and the same (At least according to the description).",,Yes,"Change description of ""Source Link Identifier"" to ""Specifies the source link of the handover"". Similarly, change description of ""Target Link Identifier"" to ""Specifies the intendend target link of the handover).",Agree,
3172800023,09/16/2007 03:38:14 EDT,449,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,2,Producer,Disapprove,Technical,131,,2,"The description of the ""Source Link Identifier"" and ""Target Link Identifier is confusing. For the case where the MN_HO_Complete message is sent to the new target PoS then source and target link identifier are one and the same (At least according to the description).",,Yes,"Change description of ""Source Link Identifier"" to ""Specifies the source link of the handover"". Similarly, change description of ""Target Link Identifier"" to ""Specifies the intendend target link of the handover).",Agree,
3172700023,09/16/2007 03:38:14 EDT,448,"Feder, Peretz",pfeder@alcatel-lucent.com,+1.201.894-1790,Individual,1,Producer,Disapprove,Technical,130,,12,"The description of the ""Source Link Identifier"" and ""Target Link Identifier is confusing. For the case where the MN_HO_Complete message is sent to the new target PoS then source and target link identifier are one and the same (At least according to the description).",,Yes,"Change description of ""Source Link Identifier"" to ""Specifies the source link of the handover"". Similarly, change description of ""Target Link Identifier"" to ""Specifies the intendend target link of the handover).",Agree,
3172600023,09/16/2007 03:35:02 EDT,447,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,22,General Interest,Disapprove,Technical,111,7.4.20.3.2,48,"(Kenichi) IP Configuration Methods, DHCP Server Address, FA Address, Access Router Address, and IP Address Informaiton Status should be list.",,No,"change those datatype as LIST(datatype). 7.4.20.4.2, 7.4.21.3.2, and 7.4.21.4.2 as well.",Principle,"Change to LIST(datatype) except for IP Configuration Methods. The layer 3 configuration applies to all the PoA candidates, not only one. There can be multiple candidates for DHCP, FA, Access Router for the POA. Multiple IP configuration method is already provided in the datatype of IP_CONFIG_METHODS.   "
3172500023,09/16/2007 03:35:02 EDT,446,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,21,General Interest,Disapprove,Technical,103,7.4.17.2.2,13,(Kenichi) LINK_ACTION_RSP should be LIST(LINK_ACTION_RSP),,No,change it.,Agree,
3172400023,09/16/2007 03:35:02 EDT,445,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,20,General Interest,Disapprove,Technical,102,7.4.17,30,(Kenichi) LINK_ACTION_REQ should be LIST(LINK_ACTION_REQ),,No,change it.,Agree,
3172300023,09/16/2007 03:35:02 EDT,444,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,19,General Interest,Disapprove,Technical,103,7.4.18,33,(Kenichi) MIH_Scan is not needed because it is one of the MIH_Link_Actions.,,No,"Remove Section 7.4.18 and also related section, datatype(MIH_COMMAND_LIST).",Agree,
3172200023,09/16/2007 03:35:02 EDT,443,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,18,General Interest,Disapprove,Technical,220,D,1,(Kenichi) Comment is not correct.,,No,Remove tag and the contents.,Agree,
3172100023,09/16/2007 03:35:02 EDT,442,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,17,General Interest,Disapprove,Editorial,208,D,48,(Kenichi) cardinality should be minCardinality,,No,replace 1 with 1,Agree,
3172000023,09/16/2007 03:35:02 EDT,441,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,16,General Interest,Disapprove,Technical,193,B.2.8,27,(Kenichi) SYSTEM_PARAMETERS is not defined.,,Yes,Define SYSTEM_PARAMETERS.,Agree,Please refer to contribution 21-07-0317-01-0000
3171900023,09/16/2007 03:35:02 EDT,440,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,15,General Interest,Disapprove,Technical,48,6.5.3,41,(Kenichi) SUPPORTED_LCP is not defined as a datatype.,,Yes,Define SUPPORTED_LCP.,Agree,Please refer to 21-07-0191-00-0000
3171800023,09/16/2007 03:35:02 EDT,439,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,14,General Interest,Disapprove,Technical,48,6.5.3,15,(Kenichi) TYPE_IE_ROAMING_PARTNERS should be single ROAMING_PARTNER,,Yes,,Principle,"  -  p48 L15        TYPE_IE_ROAMING_PARTNERS -> TYPE_IE_ROAMING_PARTNER        ROAMING_PARTNERS -> OPERATOR_ID     - p50  L22 Figure 19:        The TYPE_IE_ROAMING_PARTNERS -> TYPE_IE_ROAMING_PARTNER         and add additional ""..."" in a way to identify there can be         multiple TYPE_IE listed.      -p52 L62          Roaming Partners IE -> Roaming Partner IE         and add additiona ""..."" to identify there can be multiple entries.      - p192 L13          Delete the ROAMING_PARTNERS      - p201 L14          Bit 8: TYPE_IE_ROAMING_PARTNER  (remove S).  "
3171700023,09/16/2007 03:35:02 EDT,438,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,13,General Interest,Disapprove,Technical,191,B.2.8,39,(Kenichi) BITMAP(64) should name as REVISION,,Yes,at Table B-12 1:Replace BITMAP(64) with REVISION in the raw of NETWORK_TYPE 2. REVISION data type should be defined. REVISION| BITMAP(64) | BITMAP(64) | | See Table B-13. |,Agree,
3171600023,09/16/2007 03:35:02 EDT,437,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,12,General Interest,Disapprove,Technical,297,M.1,10,The example for IS TLV Query(or Binary-Encoding Query) is not present. Missing additional examples.,,Yes,Delete referencce or create contribution.,Principle,Delete the reference
3171500023,09/16/2007 03:35:02 EDT,436,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,11,General Interest,Disapprove,Technical,297,M.1,8,Example query should be for BINARY_DATA instead of TLV,,Yes,"Change the title to ""Example query for BINARY_DATA",Agree,
3171400023,09/16/2007 03:08:31 EDT,435,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,54,Producer,,Technical,100,,64,"LINK_CONFIG_PARAM allows one to request that a report be generated on a period basis on a per parameter type basis (in addition to crossing thresholds). This creates a very complicated interface. Besides the problem of multiple MIH Users configuring conflicting/overlapping thresholds, there does not appear to be a mechanism for reporting that a particular parameter report is being generated as a result of the periodic timer (e.g. it only reports threshold crossed up/down direction, there is not value for specifying periodic)",,No,see page 66 lines 35-36 and page 71 lines 32-33,Principle,
3171300023,09/16/2007 03:08:31 EDT,434,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,53,Producer,,Technical,94,,60,There is no way for this event to indicate that it was generated as a result of the periodic timer.,,No,"see Page 71, line 32-32",Principle,Please refer to resolution of 429
3171200023,09/16/2007 03:08:31 EDT,433,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,52,Producer,,Technical,78,7.4.1,31,"local MIH User specifying local MIHF capabilities as well as remote MIH User specifying remote MIHF capabilities. For example, what happens if the MIH User specifies something that the MIHF can't support? However, it is possible that the ""Supported IS Query Type List"" and the ""Handover related commands"" may be an exception as this functionality is provided by an MIH User (e.g. receives indications and generates responses). What if more that one remote MIH User exists, which one is responsible for responding to this request?",,No,"Making these parameters optional doesn't solve any problem. If the MIH User doesn't specify them, is it MIHF's responsibility? If not, then there is no possibility of mutually exchanging capabilities. The response, however, did not specify event and command as optional thus we are still left with the problems stated above.",Principle,No change required. This is true in principle but these are implementation specific issues and is not in the scope of this specification.
3171100023,09/16/2007 03:08:31 EDT,432,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,51,Producer,,Technical,75,,59,"LINK_PARAM_TYPE now includes QOS_LIST which is a sequence of parameters that contains actual values and is not a mechanism for asking for a specific value. Similarly, the confirmation is a LINK_PARAM which contains the type and value. However the value is an UNSIGNED_INT2 which is unable to contain a QOS_LIST.",,No,Change QOS_LIST to LINK_PARAM_QOS_LIST. Add LINK_PARAM_QOS_LIST with an enumerated type and a value of 0 requesting the return of QOS_LIST.,Principle,"Within LINK_PARAM_TYPE (pg 180, line 10) change QOS_LIST to  LINK_PARAM_QOS_LIST then define LINK_PARAM_QOS_LIST as an enumeration as  follows    Type Name: LINK_PARAM_QOS_LIST  Derived From: ENUMERATED  Definition: a type to represent QOS_LIST parameters  Valid Range: 0: QOS_LIST (returns QOS_LIST values as defined on pg. 186  line 26)    Change LINK_PARAM to SEQUENCE(LINK_PARAM_TYPE, CHOICE(LINK_PARAM_VALUE,  QOS_LIST))"
3171000023,09/16/2007 03:08:31 EDT,431,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,50,Producer,,Technical,73,,65,"Handover complete is posted following an imminent. However, there is no mechanism for indicating a handover failure.",,No,Add a status code indicating success.,Principle,
3170900023,09/16/2007 03:08:31 EDT,430,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,49,Producer,,Technical,71,,4142,Periodic notification is on a per parameter basis,,No,"Change ""This notification is generated either at a predefined regular interval determined by a user configurable timer or when a specified parameter of the currently active interface crosses a configured threshold."" to ""For each specified parameter, this notification is generated either at a predefined regular interval determined by a user configurable timer or when it crosses a configured threshold.""",Agree,
3170800023,09/16/2007 03:08:31 EDT,429,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,48,Producer,,Technical,71,,3233,LINK_PARAM_REPORT can be generated at periodic intervals but there is no way to indicate this given the current parameters,,No,"Change THRESHOLD_CROSSING_DOWN to enumeration (up, down and no change).",Principle,"Change THRESHOLD_CROSSING_DIRECTION to enumeraed type (ABOVE_THRESHOLD, BELOW_THRESHOLD).  Add REPORT_REASON enumerated type (PERIODIC, ABOVE_THRESHOLD_, BELOW_THRESHOLD)  as well  LINK_PARAM_REPORT will be a sequence of LINK_PARAM and REPORT_REASON.  Delete on page 181, line 52 "".....when no threshold value has been crossed""  "
3170700023,09/16/2007 03:08:31 EDT,428,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,47,Producer,,Technical,70,,64,"The text appears to indicate that a Link Detect event is posted whenever a PoA is detected and has not already been posted in a previous Link Detect event. This is different that what was specified on page 40, lines 21-24.",,No,"Change to ""The Link Detected event is generated on the MN when the first PoA of an access network is detected. This event is not generated when subsequent PoAs of the same access network are discovered during the active connection on that link.""",Agree,
3170600023,09/16/2007 03:08:31 EDT,427,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,46,Producer,,Technical,57,,58,"NET_SAP is not only used for L3. It handles both L2 and L3, just that L2 communication whould be handled by LINK_SAP (via NET_SAP).",,No,"Change ""For transport services over L2 the primitives are specified by the MIH_LINK_SAP"" to ""For transport services over L2, MIH_NET_SAP utilizes the primitives specified by the MIH_LINK_SAP""",Principle,
3170500023,09/16/2007 03:08:31 EDT,426,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,45,Producer,,Technical,44,,4748,Should not reference MN since this is a N2N message.,,No,"Replace with ""Notification from either source or target MIHF to the other (i.e. peer) MIHF indicating the status of the handover completion.""",Agree,
3170400023,09/16/2007 03:08:31 EDT,425,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,44,Producer,,Technical,97,,4446,"Just when is a link handover considered complete (see page 98 line 35-40)? And why do we only report a successful handover? What happens to upper layers that are waiting for a HO complete indication and never receive one? How long should they wait before they consider the handover failed? Page 98 (lines 28-31) states that is ""could"" be posted after a successful MN_HO_Commit or NET_HO_Commit but a MN_HO_Commit doesn't actually perform a handover it simply exchanges messages with a remote MIH User (see page 230, a subsequent Link Action is necessary to perform the handover).",,No,"Add a status (result) the handover complete indication to account for failed handovers (i.e. completed but failed). Alternatively, define a handover failure as Old Link Identifier set to the same value as New Link Identifier.",Agree,Add a status (result) the handover complete indication to account for failed handovers (i.e. completed but failed).
3170300023,09/16/2007 03:08:31 EDT,424,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,43,Producer,,Technical,80,,5051,"If the intent is for two MIHFs to mutually discover each others capabilities then shouldn't the request include the same data that is in the response? Missing LinkMACs and MbbHandoverSupport. Also, why is event and command not optional on the response yet it is optional on the request. With all of the optional parameters, asymmetric request/response, and allowing MIH User(s) to specify MIHF capabilities it is unclear as to this primitives usefullness.",,No,One possibility is to make these MIHF generated primitives,Principle,"Add LinkMACs and MbbHandoverSupport to MIH_Capability_Discover.request and indication primitives.  Make request, resoponse and indication messages consistent (also the Optional parameters)  "
3170200023,09/16/2007 03:08:31 EDT,423,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,42,Producer,,Technical,109,7.4.19,,"why 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).",,No,"Add IP configuration method to Net_HO_Candidate_Query.response (page 106 section 7.4.19.3) as an optional parameter, along with any corresponding optional server address. Alternatively, this information could be removed from Mn_HO_Candidate_Query.",Principle,
3170100023,09/16/2007 03:08:31 EDT,422,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,41,Producer,,Technical,103,7.4.18,,This is redundant as it can be performed using Link Actions.,,No,"Remove this section. (see page 178, lines 23-43 for discussion on whether link scan is a type or attribute)",Agree,
3170000023,09/16/2007 03:08:31 EDT,421,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,40,Producer,,Technical,109,,64,"There is a reference to ""MIH User that is in charge of MN_HO_Candidate_Query request"". Who and how is this defined?",,No,nowhere else in the document do we reference a particular type of MIH user or its function.,Principle,"Change,  ""This primitive is used by MIHF to indicate the receipt of MIH_MN_HO_Candidate_Query request message  from a mobile node to the MIH User that is in charge of executing MIH_MN_HO_Candidate_Query command.""  To  ""This primitive is used by MIHF to indicate the receipt of MIH_MN_HO_Candidate_Query request message  from a mobile node."""
3169900023,09/16/2007 03:08:31 EDT,420,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,39,Producer,,Technical,110,,61,Seems to be an extraneous line.,,No,"Delete the line ""The MIH User receiving this primitive invokes an MIH_N2N_HO_Query_Resources.response primitive.""",Agree,
3169800023,09/16/2007 03:08:31 EDT,419,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,38,Producer,,Technical,113,,19,"Since available resources are on a per candidate link basis there must be the same number of entries in the LIST(LINK_POA_LIST) as there are in LIST(QOS_LIST), i.e. there must be a one-to-one relationship. In fact, the IP configuration method and server addresses should also be on a per candidate basis thus they should be lists as well (however, care is needed to map the server addresses to the IP configuration methods since not all will be present)",,No,"Add a statement requiring that the number of entries in each of the lists (LINK_POA_LIST and QOS_LIST) be the same; Combine Preferred Candidate Link List, Available Resource Set, IP Configuration Methods, DHCP Server Address, FA Address, Access Router Address and IP Address Information Status into a single type and return a list of that type; Further, 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.",Principle,"Please verify:    Update the sentence:  ""On receiving the primitive the MIH User entity which originally initiated the candidate query request may decide to choose the candidate network for handover or abort it based on the list of PoA, available resources, and the IP address related information."""
3169700023,09/16/2007 03:08:31 EDT,418,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,37,Producer,,Technical,112,,5765,"Since available resources are on a per candidate link basis there must be the same number of entries in the LIST(LINK_POA_LIST) as there are in LIST(QOS_LIST), i.e. there must be a one-to-one relationship. In fact, the IP configuration method and server addresses should also be on a per candidate basis thus they should be lists as well (however, care is needed to map the server addresses to the IP configuration methods since not all will be present)",,No,"Add a statement requiring that the number of entries in each of the lists (LINK_POA_LIST and QOS_LIST) be the same; Combine Preferred Candidate Link List, Available Resource Set, IP Configuration Methods, DHCP Server Address, FA Address, Access Router Address and IP Address Information Status into a single type and return a list of that type; Further, 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.",Principle,"(Please verify)  Change Available Resource Set description from   ""A list of available resource for each link.""  to  ""A list of available resources for each PoA in PreferredCandidateLinkList. The order of this list is the same as the PreferredCandidateLinkList.""  "
3169600023,09/16/2007 03:08:31 EDT,417,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,36,Producer,,Technical,111,,4563,"Since available resources are on a per candidate link basis there must be the same number of entries in the LIST(LINK_POA_LIST) as there are in LIST(QOS_LIST), i.e. there must be a one-to-one relationship. In fact, the IP configuration method and server addresses should also be on a per candidate basis thus they should be lists as well (however, care is needed to map the server addresses to the IP configuration methods since not all will be present)",,No,"Add a statement requiring that the number of entries in each of the lists (LINK_POA_LIST and QOS_LIST) be the same; Combine Preferred Candidate Link List, Available Resource Set, IP Configuration Methods, DHCP Server Address, FA Address, Access Router Address and IP Address Information Status into a single type and return a list of that type; Further, 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.",Principle,"Change Available Resource Set description from   ""A list of available resource for each link.""  to  ""A list of available resources for each PoA in PreferredCandidateLinkList. The order of this list is the same as the PreferredCandidateLinkList.""  "
3169500023,09/16/2007 03:08:31 EDT,416,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,35,Producer,,Technical,113,,89,It appears that IP Address Information Status is unnecessary. What does IP Address Information Status do? We already have IP Configuration Methods (along with one or more server addresses). If one of the server addresses is not listed then I think we can figure out that it was not available.,,No,Delete this parameter.,Principle,make this optional
3169400023,09/16/2007 03:08:31 EDT,415,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,34,Producer,,Technical,111,,6263,It appears that IP Address Information Status is unnecessary. What does IP Address Information Status do? We already have IP Configuration Methods (along with one or more server addresses). If one of the server addresses is not listed then I think we can figure out that it was not available.,,No,Delete this parameter.,Principle,Make this optional
3169300023,09/16/2007 03:08:31 EDT,414,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,33,Producer,,Technical,113,,2426,"What does ""This primitive may trigger MIH User to initiate the process to get IP address to be used in the target depending on the received candidate query response"" mean? Seems to be an unrelated statement.",,No,Delete line.,Agree,
3169200023,09/16/2007 03:08:31 EDT,413,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,32,Producer,,Technical,114,,112,"These parameters are not available for network initiated handovers (see page 107, Section 7.4.19, Net_HO_Candidate_Query.request) but, they could be.",,No,,Unresolvable,Comment is not very clear
3169100023,09/16/2007 03:08:31 EDT,412,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,31,Producer,,Technical,115,,28,"States that it ""prepares"" resource for handover. This is just a query, no resources should be allocated and/or reserved (since there is no method for releasing them if the handover doesn't proceed). The N2N_HO_Commit should be used for this purpose.",,No,"Delete ""prepares resources, """,Agree,
3169000023,09/16/2007 03:08:31 EDT,411,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,30,Producer,,Technical,114,,40,"States that it ""prepares"" resource for handover. This is just a query, no resources should be allocated and/or reserved (since there is no method for releasing them if the handover doesn't proceed). The N2N_HO_Commit should be used for this purpose.",,No,"Delete ""prepares resources, """,Agree,
3168900023,09/16/2007 03:08:31 EDT,410,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,29,Producer,,Technical,119,,22,"States that an MIH User must generate a response to the indication while the following paragraph states that MIHF is to carry out the specified actions when a Net_HO_Commit request is received. However, 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.",,No,"That the MIH User upon receiving the Net_HO_Commit.indication, issues the appropriate primitives to carry out the actions specified in the request (i.e. issues MIH_Link_Action primitive). Upon completion, the MIH User constructs the appropriate response and issues a Net_HO_Commit.response. Note: somehow the MIHF needs to know that the actions are in response to a handover request otherwise, it would not know to issue the handover imminent/complete events.",Principle,"Change  ""Upon receipt of the MIH_Net_HO_Commit.request, the MIHF issues""  to  ""Upon receipt of the MIH_Net_HO_Commit.indication, the MIH User issues .."" "
3168800023,09/16/2007 03:08:31 EDT,409,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,28,Producer,,Technical,120,,9,"Since Net_HO_Commit contains actions to effect the handover, and the response has the status of those actions, the link to the old PoS may not be accessible (e.g. break before make) to receive the response until after L3 connectivity has been established on the new link and only if the MN knows the old PoS L3 address thus, the old PoS may not receive this response.",,No,,Principle,"Add the following to clarify:  ""Since Net_HO_Commit contains actions to effect the handover, and the response has the status of those actions, the link to the old PoS may not be accessible (e.g. break before make) to receive the response until after L3 connectivity has been established on the new link and only if the MN knows the old PoS L3 address thus, the old PoS may not receive this response."""
3168700023,09/16/2007 03:08:31 EDT,408,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,27,Producer,,Technical,120,,12,"These lines state that ""the MN may initiate a handover process and begin setting up an 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). If the actions tear down the old link and bring up another, isn't that what a handover is all about?",,No,"It sounds as if the response contains the ""acceptance"" rather than the ""execution"" status of the Link Actions. If this is true (and it should explicitly state this) then there is no way for the entity that sent the Net_HO_Commit request to know if the actions were completed successfully.",Disagree,"The entity can identify if the actions were completed via the the parameter ""Link Action Result List."" See more details at page 178."
3168600023,09/16/2007 03:08:31 EDT,407,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,26,Producer,,Technical,121,,8,"The texts describes this as either an MIH User to MIH User exchange or as a locally initiated handover (i.e. when dst MIHF ID is the local MIHF ID). However, the call flows indicate that it could also be a combination of the two (which is confusing). Page 230 and 231 describe it as an MIH User to MIH User exchange, followed by the issuing of Link Action commands to actually perform the handover. Page 252 shows it as a combination MIH User to MIH User and Link Action commands issued by the MIHF (as opposed to the MIH User). This makes it difficult to know when to post Link HO Imminent and Link HO Complete events. In the first case (MIH User to MIH User exchange followed by separate Link Actions) the MIHF doesn't know when to issue a Link HO Imminent. In the combined case MIHF is in control and can issue the Link HO Imminent just before is executes the Link Actions. The problem with this is that the MN_HO_Commit command does not have any associated Link Actions.",,No,"One way forward is to have MIH User to MIH User exchange take place. This would be followed by an MN_HO_Commit request with the dst MIHF ID equal to the local MIHF ID (i.e. it is a local command). The MN_HO_Commit command could issue to Link HO Imminent at the beginning of the processing of this command. However, we still have a couple of problems. The local MN_HO_Commit command does not have any Link Actions so it would have to be driven by MIHF but it doesn't know whether it should be make before break or break before make. Also, we are still left with the problem of knowing when to issue the Link HO Complete event (e.g. after upper layer handover processing, MIP).",Principle,There is agreement with this principle. Further work required in developing a remedy.    MN_HO_Commit should be used only as a local primitive and not as a remote primitive:  - Need a request and confirm only.  - Don't need Indication and Response primitives (and corresponding MIH messages in section 8)  - The functionality of informing the remote side of handover completion/commitment can be accomplished with MN_HO_Complete  - This is a local primitive only so may need to change the name          
3168500023,09/16/2007 03:08:31 EDT,406,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,25,Producer,,Technical,121,,32,In order to be able to perform a local handover (i.e. replacement for switch command) the destination MIHF ID would not be remote.,,No,"Change that the destination may be local or remote. Also, specify that it sends a MN_HO_Commit.request message to the destination MIHF only when the destination is not local.",Principle,MIH_MN_HO_Commit command now for local only.
3168400023,09/16/2007 03:08:31 EDT,405,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,24,Producer,,Technical,121,,55,In order to be able to perform a local handover (i.e. replacement for switch command) the destination MIHF ID would not be remote.,,No,"Change that the destination may be local or remote. Also, specify that it sends a MN_HO_Commit.request message to the destination MIHF only when the destination is not local.",Principle,MIH_MN_HO_Commit command now for local only.
3168300023,09/16/2007 03:08:31 EDT,404,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,23,Producer,,Technical,122,,21,"The ""Current Link Identifier"" is inconsistent with the other handover messages.",,No,"Change ""Current Link"" to ""Source Link"" for both the name and description.",Agree,
3168200023,09/16/2007 03:08:31 EDT,403,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,22,Producer,,Technical,121,,35,"The ""Current Link Identifier"" is inconsistent with the other handover messages.",,No,"Change ""Current Link"" to ""Source Link"" for both the name and description.",Agree,
3168100023,09/16/2007 03:08:31 EDT,402,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,21,Producer,,Technical,121,,37,"Target PoA is redundant, as it could be included in the Target Link (which is a LINK_TUPLE_ID).",,No,"Delete ""Target PoA"" parameter and include the PoA MAC address in the ""Target Link Identifier"" parameter.",Agree,
3168000023,09/16/2007 03:08:31 EDT,401,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,20,Producer,,Technical,121,,43,"Unclear what ""old link actions"" is referring to, the MN or Network side of link?",,No,"Clarify that the ""old link actions refers to the destination MIHF ID side of the link (e.g. when destination MIHF ID is the Network then the old link action specifies what action the Network should take).",Principle,MN_HO_Commit's actions depend on local node only. Added a clarification:  These local actions are for local node only.
3167900023,09/16/2007 03:08:31 EDT,400,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,19,Producer,,Technical,122,,37,"Need to account for a locally generated MN_HO_Commit request (i.e. with destination MIHF as the local MIHF). Otherwise, it would trigger an indication (and corresponding response), which we don't want.",,No,"Change ""request is received"" to ""request message is received"".",Agree,
3167800023,09/16/2007 03:08:31 EDT,399,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,18,Producer,,Technical,121,,64,"Need to account for a locally generated MN_HO_Commit request (i.e. with destination MIHF as the local MIHF). Otherwise, it would trigger an indication (and corresponding response), which we don't want.",,No,"Change ""request is received"" to ""request message is received"".",Agree,
3167700023,09/16/2007 03:08:31 EDT,398,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,17,Producer,,Technical,122,,42,"States that it ""may"" indicate that the ""MN may have started a handover"" and that it ""may"" send a response. How is the MIH User supposed to know when/if it is to send a response?",,No,"This appears to be related to the issue of which MIH User(s) receive which handover messages, who responds to theses indications",Disagree,This is an implementation issue.
3167600023,09/16/2007 03:08:31 EDT,397,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,16,Producer,,Technical,123,,52,"Does ""Current Link Identifier"" refer to the original or target link?",,No,"Change ""Current"" to either ""Source"" or ""Target"" for bot the name and description, depending on which should be specified.",Agree,"Add sourcelinkActions  Add tragetLinkActions in the MN_HO_Commit_Request    In MN_HO_Commit_Confirm:  Add SourceLinkIdentifier, TargetLinkIdentifier, StatusSourceLink, StatusTargetLink  "
3167500023,09/16/2007 03:08:31 EDT,396,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,15,Producer,,Technical,123,,8,"Does ""Current Link Identifier"" refer to the original or target link?",,No,"Change ""Current"" to either ""Source"" or ""Target"" for bot the name and description, depending on which should be specified.",Agree,"Add sourcelinkActions  Add tragetLinkActions in the MN_HO_Commit_Request    In MN_HO_Commit_Confirm:  Add SourceLinkIdentifier, TargetLinkIdentifier, StatusSourceLink, StatusTargetLink"
3167400023,09/16/2007 03:08:31 EDT,395,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,14,Producer,,Technical,124,,35,"Here ""Target PoA"" is specified as MAC_ADDRESS (as well as in MN_HO_Commit) but the Net_HO_Commit uses LINK_ID.",,No,Change them to LINK-ID consistently,Agree,
3167300023,09/16/2007 03:08:31 EDT,394,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,13,Producer,,Technical,128,,13,"The description contains ""This identifies the current link"" for the source link identifier.",,No,"Change ""This identifies the current link"" to ""This identifies the source link of the handover"".",Agree,
3167200023,09/16/2007 03:08:31 EDT,393,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,12,Producer,,Technical,128,,65,"The ""may"" makes it sound optional.",,No,"Change ""may"" to ""shall"" (i.e. always generates an indication when a request is received and always generates a confirm when a response is received, from peer MIHF).",Agree,
3167100023,09/16/2007 03:08:31 EDT,392,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,11,Producer,,Technical,128,,22,"The ""may"" makes it sound optional.",,No,"Change ""may"" to ""shall"" (i.e. always generates an indication when a request is received and always generates a confirm when a response is received, from peer MIHF).",Agree,
3167000023,09/16/2007 03:08:31 EDT,391,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,10,Producer,,Technical,128,,13,"The description contains ""This identifies the current link"" for the source link identifier.",,No,"Change ""This identifies the current link"" to ""This identifies the source link of the handover"".",Agree,
3166900023,09/16/2007 03:08:31 EDT,390,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,9,Producer,,Technical,127,,32,"The description contains ""This identifies the current link"" for the source link identifier.",,No,"Change ""This identifies the current link"" to ""This identifies the source link of the handover"".",Agree,
3166800023,09/16/2007 03:08:31 EDT,389,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,8,Producer,,Technical,132,,49,Reference to wrong message.,,No,Change N2N_HO_Complete to MN_HO_Complete.,Agree,
3166700023,09/16/2007 03:08:31 EDT,388,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,7,Producer,,Technical,131,,57,Reference to wrong message,,No,Change N2N_HO_Complete to MN_HO_Complete.,Agree,
3166600023,09/16/2007 03:08:31 EDT,387,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,6,Producer,,Technical,131,,64,Resource retention should be included in the message only when the original PoS is sending,,No,"Include ""Resource Retention"" only when the message is sent in the direction from the original to target PoS. This means that it should be in the request/indication when this message is originated from the original PoS and should be in the response/confirm when originated from the target PoS",Agree,"Include ""Resource Retention"" only when the message is sent in the direction from the original to target PoS. This means that it should be in the request/indication when this message is originated from the original PoS and should be in the response/confirm when originated from the target PoS.    Add a separate ResourceRetentionRequest and ResourceRetentionStatus  fields in both of these primitives.  "
3166500023,09/16/2007 03:08:31 EDT,386,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,5,Producer,,Technical,166,,16,"Target PoA is defined as LINK_ID in Net_HO_Commit SAP (Page 124, Line 35; but as PoA TLV here",,No,Change the PoA TLV to fixed type,Principle,Change the PoA TLV to LINK_ID
3166400023,09/16/2007 03:08:31 EDT,385,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,4,Producer,,Technical,179,,27,Definition of LINK_AC_RESULT_CODE does not have a valid range,,No,"Change valid range to 0: success, 1: failure.",Agree,
3166300023,09/16/2007 03:08:31 EDT,384,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,3,Producer,,Technical,174,,20,"What does [N=8*i, i=1,2,&] mean?",,No,"Change description to ""A BITMAP(N), where N must be a multiple of 8, is made up of an N/8 octet values where Bit 0 is the most significant bit of the first octet""",Agree,
3166200023,09/16/2007 03:08:31 EDT,383,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,2,Producer,,Technical,132,,12,The first line references the MN MIHF (which is incorrect) as this is a N2N message,,No,Delete the first line,Agree,
3166100023,09/16/2007 03:08:31 EDT,382,"Rajkumar, Ajay",ajayrajkumar@alcatel-lucent.com,973-386-5249,Individual,1,Producer,,Technical,132,,7,It is the MIH User (not MIHF) that processes this message.,,No,"Change ""MIHF"" to ""MIHF User"".",Agree,"Change ""MIHF"" to ""MIH User""."
3166000023,09/16/2007 02:47:09 EDT,381,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,16,Producer,Approve,Editorial,184,Table B-4,17,Bad' and 'Poor' signal strength are the same in my mind,,No,"Change range 0-24 to 'Poor' and range 25-49 to 'Average', range 50-74 to 'Good' and range '75-100' to 'Excellent'",Agree,
3165900023,09/16/2007 02:47:09 EDT,380,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,15,Producer,Approve,Editorial,144,8.2.1,3,Typo in 'The algorithm defined&may be used to guild the calculation&',,No,Change sentence to ' The algorithm defined&may be used to calculate the value of the retransmission timer.',Agree,
3165800023,09/16/2007 02:47:09 EDT,379,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,14,Producer,Approve,Technical,108,7.4.19.4.2,20,The 'Requested Resource Set' parameter should be Optional because the 'Query Resource Report Flag' in the request or indication can be True or False,,No,Make 'Requested Resource Set' parameter optional in both the response and confirm primitives,Agree,
3165700023,09/16/2007 02:47:09 EDT,378,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,13,Producer,Approve,Technical,107,7.4.19.3.2,25,The 'Requested Resource Set' parameter should be Optional because the 'Query Resource Report Flag' in the request or indication can be True or False,,No,Make 'Requested Resource Set' parameter optional in both the response and confirm primitives,Agree,
3165600023,09/16/2007 02:47:09 EDT,377,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,12,Producer,Approve,Editorial,105,7.4.19.1.1,17,The MIH_Net_HO_Query.request primitive is invoked by an MIH User on a network node. Make this clear in this sentence.,,No,Change text to 'The primitive is invoked by a MIH User on a network node to communicate to a peer MIH User about its intent of handover initiation.',Agree,
3165500023,09/16/2007 02:47:09 EDT,376,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,11,Producer,Approve,Editorial,103,7.4.17.2.2,17,Typo in LINK_SACN,,No,correct to LINK_SCAN,Agree,
3165400023,09/16/2007 02:47:09 EDT,375,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,10,Producer,Approve,Editorial,96,7.4.12.1.2,22,missing bracket in UNSIGNED_INT2),,No,add missing opening bracket - UNSIGNED_INT(2),Agree,
3165300023,09/16/2007 02:47:09 EDT,374,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,9,Producer,Approve,Editorial,71,7.3.9.2,36,"the set of link layer parameters is not specified in 7.3.3, only the primitive is listed there",,No,change text to 'The primitive to set parameter thresholds that could trigger this event is specified in 7.3.3.',Agree,
3165200023,09/16/2007 02:47:09 EDT,373,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,8,Producer,Approve,Editorial,43,6.4.2,,Fig 18 - Local and remote 'stack' are not represented symmetrically. Remote MIHF does not 'sit' between Remote Lower Layers and Remote MIH User,,No,Switch location of Remote MIHF and Remote Lower Layers in Fig 18 to make it symmetrical to the Local 'stack',Agree,
3165100023,09/16/2007 02:47:09 EDT,372,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,7,Producer,Approve,Editorial,41,6.4.1,41,2 sentences (line 41 and 52) say the same thing,,No,Delete one of the 2 sentences,Agree,
3165000023,09/16/2007 02:47:09 EDT,371,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,6,Producer,Approve,Editorial,,N/A,,"Throughout whole document - Incorrect use of 'indefinite articles' like 'a' and 'an'. E.g. the document uses 'an MN' or 'an MIHF' or 'an MIH PoS', this should be corrected to 'a MN', 'a MIHF' and 'a MIH PoS'",,No,Correct use of 'a' and 'an' throughout the whole spec,Disagree,"an MN, an MIH, an HIMF are correct usages."
3164900023,09/16/2007 02:47:09 EDT,370,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,5,Producer,Approve,Editorial,32,5.7.2,33,There is a period in front of the sentence,,No,Remove period (.),Agree,
3164800023,09/16/2007 02:47:09 EDT,369,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,4,Producer,Approve,Editorial,,N/A,,Throughout whole document - need to be consistent in the use of 'Media-Independent...' or 'Media Independent...' wording throughout the whole spec,,No,be consistent - recommend to use 'Media Independent&' (no hyphen),Agree,use no hyphen
3164700023,09/16/2007 02:47:09 EDT,368,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,3,Producer,Approve,Editorial,13,5.1.4,10,&and parameter extraction commands - missing hyphen,,No,add hyphen to 'parameter-extraction',Agree,
3164600023,09/16/2007 02:47:09 EDT,367,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,2,Producer,Approve,Editorial,6,3,,No definition for Access Router but it is extensively used in all the primitives,,No,Define 'Access Router',Agree,
3164500023,09/16/2007 02:47:09 EDT,366,"Meylemans, Marc",marc.meylemans@intel.com,+1 503 712 2726,Individual,1,Producer,Approve,Editorial,5,2,1,No normative references are listed.,,No,"List all normative references or if there are none, then indicate as such.",Agree,
3164400023,09/16/2007 01:46:33 EDT,365,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,8,Producer,Disapprove,Technical,6,3.2,10,"Wouldn't it be useful to reference previously defined definitions for these terms, rather than re-defining them.",,Yes,Normative references should be considered such as the base standards of the media specific technologies.,Agree,
3164300023,09/16/2007 01:46:33 EDT,364,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,7,Producer,Disapprove,Technical,5,2,8,Are there really no normative references for this standard?,,Yes,Normative references should be considered such as the base standards of the media specific technologies.,Agree,
3164200023,09/16/2007 01:46:33 EDT,363,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,6,Producer,Disapprove,Technical,2,,14,"Although this text refers to IEEE 802.15, it appears that there is no interface defined to this technology, within the main part of the standard.",,Yes,"Possibly remove the reference to IEEE 802.15, as it is not specifically defined within this base standard.",Principle,"remove 802.15 from Figure 1 and from page 4, line-14.   Leave it on page 2 where it is used as an example to describe pico cells"
3164100023,09/16/2007 01:46:33 EDT,362,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,5,Producer,Disapprove,Technical,2,,33,"Although this introduction refers to IEEE 802.15, it appears that there is no interface defined to this technology, within the main part of the standard.",,Yes,"Possibly remove the reference to IEEE 802.15, as it is not specifically defined within this base standard.",Principle,"remove 802.15 from Figure 1 and from page 4, line-14.   Leave it on page 2 where it is used as an example to describe pico cells."
3164000023,09/16/2007 01:46:33 EDT,361,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,4,Producer,Disapprove,Editorial,,,,"Strictly speaking references to IEEE 802.21, are self-referential.",,Yes,"Replace ""IEEE 802.21 standard"" with ""this standard""",Agree,
3163900023,09/16/2007 01:46:33 EDT,360,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,3,Producer,Disapprove,Technical,2,,12,Does the scope of this standard include the facilitation of handovers between heterogeneous networks during emergency calls.,,No,Clarification of scope for this aspects would be appreciated.,Principle,Yes
3163800023,09/16/2007 01:46:33 EDT,359,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,2,Producer,Disapprove,Technical,,,,"IEEE 802.11u now supports a native GAS (Generic Advertisment Service) query mechanism, which may provide useful information to the MIHF IS. Comment forwarded by IEEE 802.11u chair on behalf of IEEE 802.11u Ad Hoc Meeting, 30th August 2007.",,No,"Please consider adding new entries to the MIHF IS, based on the updated IEEE 802.11u draft.",Principle,Updated as per list of IEs submitted.
3163700023,09/16/2007 01:46:33 EDT,358,"Mccann, Stephen",stephen.mccann@roke.co.uk,4.42E+11,Individual,1,Producer,Disapprove,Technical,,,,"Since the IEEE 802.11 SME can be considered to be the mobility manager for IEEE 802.11, as opposed to the MLME or the LLC, it appears that Figure 7 is in-correct and requires to be re-drawn. Comment forwarded by IEEE 802.11u chair on behalf of IEEE 802.11u Ad Hoc Meeting, 30th August 2007",,Yes,As described in Comment,Agree,Use TGu MIH contribution (11-2604 rev2) to update the reference diagram and description.
3162300023,09/15/2007 22:08:13 EDT,357,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,17,User,Disapprove,General,316,,,Annex M.6 seems redundant and not adding much value because similar materials have been covered in the example call flows in Annex H and Information Service examples in,,Yes,remove M.6,Agree,
3162200023,09/15/2007 22:08:13 EDT,356,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,16,User,Disapprove,General,282,,,Annex J does not add much value to the spec.,,Yes,"remove Annex J ""Requirements to support 802.21 by L3 and above transport""",Agree,
3162100023,09/15/2007 22:08:13 EDT,355,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,15,User,Disapprove,Technical,203,,1,The missing definition must be filled.,,Yes,Define the missing definition,Principle,Delete Network Security
3162000023,09/15/2007 22:08:13 EDT,354,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,14,User,Disapprove,Editorial,174,,,The entire Annex B is poorly organized. The grouping is not clear nor consistent.,,No,"Investigate how to re-organize the data type definitions, either on a per-premitive, and/or per-message, and/or per-IE basis?",Agree,
3161900023,09/15/2007 22:08:13 EDT,353,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,13,User,Disapprove,Technical,150,8.4.1,60,"MIH Protocol header is of fixed length, as indicated in Figure 27 on the next page.",,Yes,correct figure 26 to show MIH Protocol Header has fixed length of 8 octets.,Agree,
3161800023,09/15/2007 22:08:13 EDT,352,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,12,User,Disapprove,General,144,8.2.2,,"MIH protocol transaction state diagrams only have significance when the MIH level ACK mechanism is used. Otherwise, it is not really necessary since MIH protocol is mostly a transaction-oriented protocol without the ACK. Since MIH level ACK is optional to use, it may be better to move the state diagram discussion to an annex.",,No,suggest to move 8.2.2 to an annex,Disagree,This clause helps in understanding the behavior of MIH Protocol and is hence required in the main body of draft
3161700023,09/15/2007 22:08:13 EDT,351,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,11,User,Disapprove,Technical,124,7.4.24,,MIH_N2N_HO_Commit currently does not allow the option of requesting resource reservation at the HO target. This could become a limiting factor in some cases.,,Yes,add the option that HO resource reservation can be requested at the recipient of MIH_N2N_HO_Commit.,Agree,Please refer to contribution 21-07-0320-02-0000-Resource_Definition
3161600023,09/15/2007 22:08:13 EDT,350,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,10,User,Disapprove,General,,,,"MIH event subscription should allow the subscriber to set certain conditions to qualify the events, so that only those events that meet the conditions will be reported.",,Yes,investigate if this capability is needed and how to best implement,Principle,Please refer to contribution 21-07-0305-02-0000
3161500023,09/15/2007 22:08:13 EDT,349,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,9,User,Disapprove,Editorial,51,6.5.4,25,The sentence is ambiguous.,,No,"Change to ""Functional entities shall discard any received IE with an unrecognizable identifier.""",Agree,
3161400023,09/15/2007 22:08:13 EDT,348,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,8,User,Disapprove,Technical,105,,,"The Purpose and usefulness of MIH_Net_HO_Candidate_Query command are unclear. This command is sent from the serving PoS to the UE, but the UE won't be able to query the candidate networks unless the UE is connected to the candidate networks. That assumption is highly unlikely.",,Yes,remove all definition and mentioning of MIH_Net_HO_Candidate_Query command,Disagree,This command is required. It helps in implementing network controlled handoffs
3161300023,09/15/2007 22:08:13 EDT,347,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,7,User,Disapprove,General,42,6.4.1,5,Figure 16 is confusing by showing two unrelated stacks. Showing one stack would be good enough.,,Yes,"remove the stack marked as ""Remote Entity"" and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3161200023,09/15/2007 22:08:13 EDT,346,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,6,User,Disapprove,Editorial,37,6.3.2,,6.3.2 should be moved after 6.3.3 discussion,,No,move 6.3.2 content to the end or after 6.3.3 discussion.,Agree,
3161100023,09/15/2007 22:08:13 EDT,345,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,5,User,Disapprove,Editorial,36,6.3.1,48,repeated statement,,No,"delete ""MIH events may be local or remote. Remote MIH events originate at a remote MIHF. """,Agree,
3161000023,09/15/2007 22:08:13 EDT,344,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,4,User,Disapprove,General,36,6.3.1,20,Figure 13 is confusing by showing two unrelated stacks. Showing one stack would be good enough.,,Yes,"remove the stack marked as ""Remote Entity"" and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3160900023,09/15/2007 22:08:13 EDT,343,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,3,User,Disapprove,General,33,6.2,,"The concept and procedures for MIHF discovery are not specified in this spec (i.e., no mandatory messages/flows defined for MIHF discovery). This is the right way to do it. Just the text and title in 6.2.3 and 8.2.3.5 may mislead readers otherwise.",,No,De-emphasize MIHF Discovery as separate MIH service management function. Remove 6.2.3 and possibly merge the discussion into general MIH protocol discussion in subclause 8.,Principle,
3160800023,09/15/2007 22:08:13 EDT,342,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,2,User,Disapprove,Technical,32,,,"MIH_NMS_SAP specifies the interface between an MIHF implementation and a local Network Management System stack. Depending on the nature of the device, this local NMS stack may vary or may not even exist. Standardizing this interface brings no benefit to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NMS_SAP,Agree,
3160700023,09/15/2007 22:08:13 EDT,341,"Xie, Qiaobing",qiaobing.xie@motorola.com,847 3728481,Individual,1,User,Disapprove,Technical,31,,,"MIH_NET_SAP specifies the interface between an MIHF implementation and various local transport stacks on the same device. However, it is unclear what compatability benefits standardizing this interface will bring to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NET_SAP,Agree,
3160600023,09/15/2007 18:28:36 EDT,340,"Chin, Kevin A",kevin.chin@microsoft.com,425 703 6210,Individual,1,General Interest,Approve,General,48,,,Misc comments in .USR file.,15474800024-P802.21_Chin_Kevin.USR,No,,Principle,Disagree on the technical comment because LINK_POWER_NORMAL is same as LINK_POWER_UP.  Agree on the editorial comments and Channel Range clarification and example added to table B-12.
3160500023,09/15/2007 00:24:13 EDT,339,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,9,Producer,Disapprove,Technical,193,B.2.8,2,"Data type for system_information should be defined.
Refer to contribution , 21-07-0317-00-0000-System_Information_IE",15472700024-21-07-0317-00-0000-System_Information_IE.doc,Yes,Discuss and adopt 21-07-0317-00-0000-System_Information_IE,Agree,Please refer to contribution 21-07-0317-01-0000
3160400023,09/15/2007 00:21:32 EDT,338,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,8,Producer,Disapprove,Technical,148,8.2.2,13,"There is no transaction state diagram for broadcast MIH_Capability_Discover message.
Refer to contribution, 21-07-0316-00-0000-MIH_Capability_Discovery",15472600024-21-07-0316-00-0000-MIH_Capability_Discovery.doc,Yes,"Discuss contribution, 21-07-0316-00-0000-MIH_Capability_Discovery and adopt it.",Agree,Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3160300023,09/15/2007 00:19:40 EDT,337,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,7,Producer,Disapprove,Technical,46,6.5.1,44,"802.21 MIIS supports static information parameters. However, for pratical network selection, dynamic information elemets could be more helpful sometimes rather than querying through its serving PoA(PoS). Therefore, I suggest 802.21 MIIS provide static and also dynamic information. Refer to contribution, 21-07-0315-00-0000-Dynamic_Information_Support",15472400024-21-07-0315-00-0000-Dynamic_Information_Support.ppt,Yes,"Discuss contribution, 21-07-0315-00-0000-Dynamic_Information_Support",Principle,
3160200023,09/15/2007 00:02:11 EDT,336,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,6,Producer,Disapprove,Technical,145,8.2.2.1,8,"What if a source node can not receive any answer even it sent a REQ? and also what if a destination node can not give any response even if it receives a REQ? Therefore, I suggest all states except INIT should have transition to INIT when the transaction time expires.",,Yes,"Make transition to INIT in all states when the transaction time expires, page 145-146.",Agree,Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3160100023,09/15/2007 00:01:16 EDT,335,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,5,Producer,Disapprove,Technical,138,7.5.1.1,13,MIHF knows only a source MIHF ID and destination MIHF ID. Then how MIHF ID(s) can be changed into source/destination transport address? MIHF knows transport address? It is an MN's local interaction but I think at least 802.21 should mention this in draft.,,Yes,Clarify mapping transport address with MIHF ID.,Principle,  The MIHF does know the transport address.  How the transport address is determined is outside the scope of this draft.  The network MIHF entity may have FQDN as it's identifier  The MN may not have a FQDN.
3160000023,09/15/2007 00:00:07 EDT,334,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,4,Producer,Disapprove,Technical,47,6.5.2,2,"Better wording is recommened for ""A similar mechanism may be available for IEEE 802.16 for this query.'""",,Yes,"Change into "" IEEE 802.16 also allows an MN to query using PKM management message before authentication.""",Agree,
3159900023,09/14/2007 23:51:12 EDT,333,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,3,Producer,Disapprove,Technical,43,6.4,33,"what does that mean by MIH_Command.indication/response in Figure 18?
Does that mean commands can go up to MIH users? Draft needs to clarify command's direction appropriately",,Yes,Clarify if commands are allowed to be sent from MIHF to MIH users.,Disagree,  Commands are NOT sent from MIHF to MIH Users.  For remote commands link layer indications or MIH level indications may be generated at the remote entity.  
3159800023,09/14/2007 23:49:26 EDT,332,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,2,Producer,Disapprove,Technical,17,5.3.3.5,1,"From line1 to 13, the context does not really relate to command service.",,Yes,Delete line 1 to 13,Disagree,These lines are required and help in understanding
3159700023,09/14/2007 23:44:58 EDT,331,"Kim, Yongho",ronnykim@lge.com,82-31-341-0558,Individual,1,Producer,Disapprove,Technical,13,5.1.8,48,"It says 802.21 allows an MN to discover heterogeneous networks through a single connected radio without powering up each radio.
I think 802.21 can only support heterogeneous network discovery by MIIS or command to scan each radio. Discovery to different type of networks without powering up each radio interface depends on each radio specific technology. For example, 802.16e system does not allow a single interface MN to scan different types of networks.
Therefore, I suggest section 5.1.8 be reworded with saying, concurrently scan by powering up each one of the available radios.",,Yes,Reword section 5.1.8,Principle,Please refer to contribution 21-07-0374-02-0000
3159600023,09/14/2007 23:15:41 EDT,330,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,31,General Interest,Disapprove,Technical,200,B2.11,3,"MIFH-ID can be different depending on the access technology. For example, a GSM device could use its IMSI.",,No,"Define a separate Registration ID that is used for the lifetime of the registration and create a new MIFH-ID element as a TLV which defines the ID of the entity. The tag should encode MIHF coding (NAI, GRUU, FQDN, IMSI, MIN, PIN), Length",Principle,"Page 150, secton 8.3.1:  Change as follows:  ""MIHF Identifier (MIHF ID) is an identifier that is required to uniquely identify MIHF entity for delivering the MIH services.""    Add the following sentence at end of first paragraph:  ""For example, MIHF-ID may be an FQDN or NAI of the sender of the registration request"""
3159500023,09/14/2007 23:15:41 EDT,329,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,30,General Interest,Disapprove,Technical,187,B2.6,41,Table B-9 should also include PoA location information such as the WWAN CellID,,No,Add WWAN CellID to the list of entries on B-9,Principle,The draft uses Cell-ID in different places to represent PoA location.    Use Cell-ID as a way to represent PoA location.  Make this change in draft.  Make changes to table 8 and table B-9.
3159400023,09/14/2007 23:15:41 EDT,328,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,29,General Interest,Disapprove,Technical,194,B2.8,1,"The contents of Table B-13 attempts to define Access Technology-specific elements. The information contained in these tables is dated and inaccurate. For instance, the IEEE 802.11 definition does not even incude IEEE 802.11g. It will be impossible for IEEE 802.21 to keep this table current with IEEE 802 amendments, let alone other SDO's such as 3GPP. IEEE 802.21 should provide a generic container that can be defined by the SDO that is responsible for the Access Technology rather than trying to keep this data current. IEEE 802.21 can work with the other SDO's to update the container information as new amendments and protocol versions are produced.",,No,Provide a generic container that will allow Access Technology SDO's be responsible for their own Network Type Representation.,Disagree,  Use an OUI to identify the access technology.  
3159300023,09/14/2007 23:15:41 EDT,327,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,28,General Interest,Disapprove,Technical,195,B2.9.1,12,"The section is titled ""Binary Information Query"". However I believe it defines Info Query Binary Data",,Yes,"Clearly define the InfoQueryBinaryData IE or if it exists add a refernce to it in clause 7 and 8, where it is used.",Agree,Add a reference
3159200023,09/14/2007 23:15:41 EDT,326,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,27,General Interest,Disapprove,Technical,133,7.4.27,8,"If the MIH Get Information primitive must contain at least one query list, that query list must include some required information. Specify the minimal information requried in the query.",,Yes,"The query information should include at a minimum, information related to the current PoA for the MN or a location. This information needs to be include somewhere in the draft - possibly in the protocol definition clause 8.6 or this clause.",Agree,Move this text to below the parameters table.    At least one of the following parameters shall be specified:  - Info Query Binary Data List  - Info Query RDF Data List  - Info Query RDF Schema URL  - Info Query RDF Schema List
3159100023,09/14/2007 23:15:41 EDT,325,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,26,General Interest,Disapprove,Editorial,153,8.6,5,It is very difficult to relate the primitives to the protocol messages.,,Yes,Add a cross-reference for primitives defined in clause 7 indicating which protocol message they refer to. Alternatively add a cross reference in clause 8.6 to sections in clause 7 that define primitives relating to that protocol message.,Agree,
3159000023,09/14/2007 23:15:41 EDT,324,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,25,General Interest,Disapprove,Technical,170,8.6.4.1,1,A request-response mechanism will not scale to accommodate large numbers of MIH-capable mobile nodes.,,Yes,Provide the capability for the MIH-capable mobile node to broadcast information to devices at a PoA in addition to the request/response mechanism.,Principle,"Section 7.4.27:  ""It is assumed that the available information could be broadcast  in access technology specific manner such as in 802.11 and 802.16."""
3158900023,09/14/2007 23:15:41 EDT,323,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,24,General Interest,Disapprove,Technical,170,8.6.4.1,14,"If at least one query is required, there should be some minimum required information that needs to be included in that query.",,Yes,"Specify the minimum information that needs to be included for the query. For example, PoA information, location, etc.",Principle,Move this text to below the parameters table.    Only one of the following parameters shall be specified:  - Info Query Binary Data List  - Info Query RDF Data List  - Info Query RDF Schema URL  - Info Query RDF Schema List  
3158800023,09/14/2007 23:15:41 EDT,322,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,23,General Interest,Disapprove,Editorial,153,8.6,14,It is very difficult to cross-reference the sections where TLV items are defined from where they are specified in the protocol messages.,,Yes,"In the tables that define protocol messages. Include a reference to a clause where the data type, list, etc. is defined.",Principle,
3158700023,09/14/2007 23:15:41 EDT,321,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,22,General Interest,Disapprove,Technical,170,8.6.4.1,16,"The text states that there ""should"" be at least one query.",,Yes,"I believe there has to be at least one query. Therefore the statement should be ""shall""",Principle,Update to: One and only one type shall be specified.
3158600023,09/14/2007 23:15:41 EDT,320,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,21,General Interest,Disapprove,Technical,153,8.6,14,"I assume that the TLV type assignment is normative for this protocol. If so, it should be included in the body of the specification.",,Yes,"If Annex C is normative, make it a clause in the body of the specification.",Disagree,It's better to keep this as Annex
3158500023,09/14/2007 23:15:41 EDT,319,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,20,General Interest,Disapprove,Technical,151,8.4.1.1,21,"The figure description does not line up with the octect header. For example, the first octet has only 7 bits defined with no reserve bit.",,Yes,Add a reserve bit at the endo fo the first octet,Disagree,The bits do line up with octet header and reserve bit is not required
3158400023,09/14/2007 23:15:41 EDT,318,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,19,General Interest,Disapprove,Technical,144,8.2.2,45,"The state machines account for sending and receiving messages. However, they do not account for registration or discovery.",,Yes,"From clause 5, there was a registration and discovery process for initiating an MIH connection. Include these processes as part of the state machine definition.",Disagree,These steps are simple and can be understood separately and need not be part of state machine operation.
3158300023,09/14/2007 23:15:41 EDT,317,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,18,General Interest,Disapprove,Editorial,60,7.2,30,There are a number of SAP primitive definitions in the specification and it is difficult to find the details of a primitive definition in the spec given that it is over 300 pages. This applies to all of clause 7.,,Yes,"Add a column which includes the reference to the clause where the primitive is defined and if possible, a reference to other pertinent normative information. An example of one of these tables is Table 12 on page 62. Include similar changes to clause 7.3 - 7.6",Agree,
3158200023,09/14/2007 23:15:41 EDT,316,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,17,General Interest,Disapprove,Technical,55,6.5.6.3,3,"I assume that the MIIS schema definition is normative. If so, it should not be included in an annex, which is generally intended for additional information.",,Yes,"If annex D is normative, make it a clause in the body of the specification.",Disagree,"It's better to keep this as Annex. Annex can be normative as well, as part of IEEE guidelines"
3158100023,09/14/2007 23:15:41 EDT,315,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,16,General Interest,Disapprove,Technical,53,6.5.5.2,53,"I assume that Component Information Element definitions are a normative part of the standard. Therefore they should not be included in an annex, which is generally intended for additional information.",,Yes,"If annex B is normative, make it a clause in the body of the specification.",Disagree,"It's better to keep this as Annex. Annex can be normative as well, as part of IEEE guidelines"
3158000023,09/14/2007 23:15:41 EDT,314,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,15,General Interest,Disapprove,Technical,50,6.5.4,57,"I assume that Information Element definitions are a normative part of the standard. Therefore they should not be included in an annex, which is generally intended for additional information.",,Yes,"If annex A is normative, make it a clause in the body of the specification.",Disagree,"It's better to keep this as Annex. Annex can be normative as well, as part of IEEE guidelines"
3157900023,09/14/2007 23:15:41 EDT,313,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,14,General Interest,Disapprove,Technical,47,6.5.2,1,"Why does this standard only provide a query mechanism prior to authentication. IEEE 802.21 should support query or broadcast mechanism prior to authentication. For example, future amendments to IEEE 802.11 may all this information to be broadcast as part of a beacon or other data frame.",,Yes,Add a statement to allow the possibility of MIH information to be broadcast prior to L2 authentication.,Disagree,There is already a mechanism in draft to do this.
3157800023,09/14/2007 23:15:41 EDT,312,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,13,General Interest,Disapprove,Technical,34,6.3.4.1,58,"The sentence beginning with ""Since the &"" seems to state that predictive events are not useful.",,Yes,"If that is true, either remove predictive events from the draft or remove this sentence.",Principle,Change sentence as follows:  In case predictive events are incorrect they may be retracted.
3157700023,09/14/2007 23:15:41 EDT,311,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,12,General Interest,Disapprove,Technical,34,6.2.5,54,"What type of authentication is referenced here? There is no security specified for IEEE 802.21. I assume the reference is to link layer security. If it is, please state so or provide an authentication mechanism.",,Yes,Explain type of authentication is referenced in this paragraph.,Agree,"Clarify this as ""link authentication""."
3157600023,09/14/2007 23:15:41 EDT,310,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,11,General Interest,Disapprove,Technical,34,6.2.5,44,How does registration provide authorization to access services? All registration does is place the peers in a state where they can exchange information.,,Yes,Incorporate a security method during the registration process to provide authorisation or remove this sentence from the draft because there is no authorization.,Principle,This will be addressed by a the Security group.
3157500023,09/14/2007 23:15:41 EDT,309,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,10,General Interest,Disapprove,Technical,32,5.7.2,50,How does the MN know that it cannot obtain service? I would assume that discovery of L3 service is out of scope of IEEE 802.21.,,Yes,State that discovery of MIH PoS over L3 is out of scope of IEEE 802.21.,Principle,This is already in the draft
3157400023,09/14/2007 23:15:41 EDT,308,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,9,General Interest,Disapprove,Editorial,32,5.7.2,33,Remove the period from the beginning of the paragraph,,Yes,See comment.,Agree,
3157300023,09/14/2007 23:15:41 EDT,307,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,8,General Interest,Disapprove,Technical,26,5.5.3,37,If MLME-SAP messages are permitted in State 1. They would also be permitted in state 3.,,Yes,Change the text to state that the MIH MLME-SAP message are permitted in all states.,Agree,
3157200023,09/14/2007 23:15:41 EDT,306,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,7,General Interest,Disapprove,Technical,25,5.5.3,40,"The IEEE 802.11 PoA is likely an ESS, not an AP.",,Yes,"Change ""Aps"" to (ESS or BSS)..",Agree,Remove AP in parenthesis.
3157100023,09/14/2007 23:15:41 EDT,305,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,6,General Interest,Disapprove,Technical,18,5.3.4,6,The first sentence of the paragraph states that geographic information can be used to obtain handover candidate information. However the rest of the paragraph goes on to discuss how the information is transported to the MN and how the mechanism is out of scope.,,Yes,"If the intention is to support a mechanism to provide handover candidates by location, state clearly that mechanism is supported but the algorithm for deciding what information to provide is out of scope.",Agree,Add this to next paragraph
3157000023,09/14/2007 23:15:41 EDT,304,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,5,General Interest,Disapprove,Technical,17,5.3.4,53,The text states that the AN is responsible for providing a secure channel for communication of MIH information. However it does not state anything about whether the MN in authorised to obtain that information.,,Yes,There needs to be some form of ensuring that the MN is authorized to obtain the MIH information.,Principle,This will be handled in the Security group.
3156900023,09/14/2007 23:15:41 EDT,303,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,4,General Interest,Disapprove,Technical,15,5.3.1,34,The paragraph mentions that MIH provides a mechanism for MIH Users to query for MIH handover information. The standard should not provent an MIH user from broadcasting information related to MIH handover candidates.,,Yes,"Add the following sentence or something similar to the paragraph: ""An MIHUser may use information from the MIHF service to broadcast information on possible technology handover candidates.""",Agree,
3156800023,09/14/2007 23:15:41 EDT,302,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,3,General Interest,Disapprove,Technical,14,5.2.1,14,"The text in the standard states: ""This standard may contain
recommendations to amend the existing access technology specific standards when modifications of
the lower-layer interfaces may enable or enhance the MIHF"". This is accomplished through liason relationships, not standards specification.",,Yes,Remove the sentence.,Agree,"Delete:    ""The specification of how the MIHF interfaces with the lower layers generally does not fall  within the scope of this standard. Such functionality may already be specified as service access  points (SAPs) within the standards that pertain to the respective link-layer technologies, such as  IEEE 802.1, IEEE 802.3, IEEE 802.11, IEEE 802.16, 3GPP, and 3GPP2. This standard may contain  recommendations to amend the existing access technology specific standards when modifications of  the lower-layer interfaces may enable or enhance the MIHF"""
3156700023,09/14/2007 23:15:41 EDT,301,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,2,General Interest,Disapprove,Technical,13,5.1.8,49,"The IEEE 802.21 information reduces the scanning required to discover and handover to another network. However it does not eliminate the need for the MN to scan prior to handing over to the network. It minimizes scanning, not eliminates it.",,Yes,Modify the second section of the paragraph to state that the protocol minimizes the scanning required to discover and select another network as a handover candidate.,Principle,Please refer to contribution 21-07-0374-02-0000  
3156600023,09/14/2007 23:15:41 EDT,300,"Montemurro, Michael",montem@sympatico.ca,-4031,Individual,1,General Interest,Disapprove,Technical,13,5.1.7,36,The security clause states that information on link security will be made available to a UA for potential handover candidates. However it does not make a statement on security considerations for the IEEE 802.21 primitives or protocol themselves.,,Yes,Add a paragraph in this clause to state the security considerations for the IEEE 802.21 protocol.,Principle,Delete section 5.1.7
3156500023,09/14/2007 18:36:55 EDT,299,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,20,Producer,Disapprove,General,175,,19,This section is a duplicate of the information that is given in 6.5.5. Suggest we delete text on lines 19 through 47 in section B.1.2,,No,Delete text on lines 19-47 in section B.1.2,Principle,Sections 6.5.5 and section 8.5 address similar issue.  Please update these section and remove any redundancy (refer to them).  
3156400023,09/14/2007 18:36:55 EDT,298,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,19,Producer,Disapprove,General,164,8.6.3.12,14,Suggest alternate wording for improved readability and usage description of the message,,No,"Replace text on lines 14-15 with ""This message is used by MIHF in the network to respond to an MIH_MN_HO_Candidate_Query request message from a remote MIHF on the MN.",Agree,
3156300023,09/14/2007 18:36:55 EDT,297,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,18,Producer,Disapprove,General,163,8.6.3.11,41,Suggest alternate wording for improved readability and usage description of the message,,No,"Replace text on lines 41-43 with ""This message is used by a MIHF on the MN to communicate to a MIHF in the network of an intent to initiate handover""",Agree,
3156200023,09/14/2007 18:36:55 EDT,296,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,17,Producer,Disapprove,General,163,8.6.3.10,11,Suggest alternate wording for improved readability and usage description of the message,,No,"Replace text on lines 11-12 with ""This message is used by MIHF on the MN to respond to an MIH_Net_HO_Candidate_Query request message from a remote MIHF in the network",Agree,
3156100023,09/14/2007 18:36:55 EDT,295,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,16,Producer,Disapprove,General,162,8.6.3.9,55,Suggest alternate wording for improved readability and usage description of the message,,No,"Replace text on lines 55-56 with ""This message is used by a network MIHF to communicate to a MIHF on the MN an intent to initiate handover""",Agree,
3156000023,09/14/2007 18:36:55 EDT,294,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,15,Producer,Disapprove,General,152,8.5,32,This section is duplicate of the information that is given in 6.5.5. Suggest we delete this section and add a note to section 8.6 which provides a reference to section 6.5.5. Alternatively we can simplify the text in section 6.5.5 and retain the text in 8.5,,No,"Add text ""See section 6.5.5 for Message parameter TLV encoding"" after line 14 in section 8.6",Principle,Sections 6.5.5 and section 8.5 address similar issue.  Please update these section and remove any redundancy (refer to them).  
3155900023,09/14/2007 18:36:55 EDT,293,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,14,Producer,Disapprove,Technical,151,8.4.1.1,40,Don't see the need for this field. The destination MIHF will either send an explicit ack message (MIH ACK) or MIH response message. In either case the transaction ID will be the same as was received in the MIH Request message. The transaction ID can be used by the source to correlate the messages. Note that receipt of a MIH ACK or the MIH response is implicit indication that the destination received the MIH request. Suggest we make this a reserved field and remove reference to use of ACK-RSP bit from sections 8.,,Yes,"Replace ACK-RSP row in Table 15 with: Field name = Reserved. Size = 1. Description: This field is intentionally kept reserved and set to '0'. Additionally we need to update figure 27 and replace ""Ack Rsp"" with ""Reserved"". Also we need to remove references to setting of Ack-RSP field from 8.2.2.2 lines 41, 46 and 50; 8.2.2 line 61; 8.2.1 line 63.",Disagree,"""Transaction ID is not sufficient for matching a request, a response  or an indication with its acknowledgement.  For example, suppose a  transaction source node sends a request with Transaction ID = X with  ACK-Req bit set.  The transaction destination node may send an  acknowledgment with Transaction ID = X while it may originate a new  request with the same Transaction ID = X.  Without having ACK-Rsp bit,  the transaction source node cannot distinguish the two messages.  ACK-Rsp bit works as the differenciator for such a corner case.""  "
3155800023,09/14/2007 18:36:55 EDT,292,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,13,Producer,Disapprove,Technical,150,8.3.1,16,Configuration of the MIHF is not specified in this standard. Should add text to state that configuration of the MIHF is outside the scope of the standard.,,No,"To end of line 16 add following text ""and not within the scope of this standard.""",Agree,"""The configuration process is outside the scope of the standard."""
3155700023,09/14/2007 18:36:55 EDT,291,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,12,Producer,Disapprove,Technical,148,8.2.2.4,12,"When a time out occurs in RECEIVED state, we should not generate an error.",,Yes,"From line 12 delete text ""and generates an error.""",Principle,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3155600023,09/14/2007 18:36:55 EDT,290,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,11,Producer,Disapprove,Technical,146,8.2.2.2,65,"When a time out occurs in COMPLETED state, we should not report an error. When the source enter this state, it starts a timer in case a re-transmitted MIH response is received due to a lost MIH ack sent by the source node. If no re-transmitted MIH response is received then the destination has successfully received the ACK and the transaction should end. In this case no error has occurred and therefore should not be reported.",,Yes,"From line 65 delete text ""and reports error.""",Agree,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3155500023,09/14/2007 18:36:55 EDT,289,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,10,Producer,Disapprove,General,146,8.2.2.2,49,"For improved readability, handling of a re-transmitted MIH Request message while the destination node is in the RECEIVED state should be described at the end 2nd paragraph.",,No,"Move sentence on line 49 and 50 (i.e. ""In the RECEIVED state&.with an ACK message"") to end of text on line 41",Agree,
3155400023,09/14/2007 18:36:55 EDT,288,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,9,Producer,Disapprove,Technical,146,8.2.2.2,7,The arrow in Fig 23 should show that upon receipt of MIH request message the destination node transits to the RECEIVED state. Delete the additional text/condition for the transition.,,Yes,"Modify arrow text from INIT to RECEIVED to read ""Recv. REQ""",Principle,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3155300023,09/14/2007 18:36:55 EDT,287,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,8,Producer,Disapprove,Technical,145,8.2.2.1,49,"When a time out occurs in COMPLETED state, we should not report an error. When the source enter this state, it starts a timer in case a re-transmitted MIH response is received due to a lost MIH ack sent by the source node. If no re-transmitted MIH response is received then the destination has successfully received the ACK and the transaction should end. In this case no error has occurred and therefore should not be reported.",,Yes,"From line 49 delete text ""and reports error.""",Agree,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3155200023,09/14/2007 18:36:55 EDT,286,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,7,Producer,Disapprove,Technical,145,8.2.2.1,34,In the SENDING state the source node is waiting for either a MIH ACK or a MIH Response,,Yes,"On line 34 replace text ""&for an MIH ACK message"" with ""&for an MIH ACK or MIH Response message.""",Agree,
3155100023,09/14/2007 18:36:55 EDT,285,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,6,Producer,Disapprove,Technical,144,8.2.1,15,Need to add text to say how redundant ACK message are handled by the source MIHF,,Yes,"Add text ""In this scenario the source MIH node may silently discard the duplicate acknowledgements."" to the end of sentence ending with ""&.by the source MIH node.""",Principle,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3155000023,09/14/2007 18:36:55 EDT,284,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,5,Producer,Disapprove,Technical,143,8.2.1,50,Acknowledgement for receipt of MIH message can be received either through a receipt of an explicit MIK_ACK or by setting of the ACK-Rsp bit in corresponding MIH protocol response message,,Yes,"Replace text on lines 50 through 55 with ""The source MIHF may optionally request for an acknowledgement to ensure successful receipt of an MIH protocol message. Either an explicit MIH ACK message or the MIH protocol response message with ACK-Rsp bit set, is used by the destination MIHF to indicate to the source MIHF successful receipt of the MIH protocol message by the destination MIHF. If the MIH protocol message or the acknowledgement to that message (either MIH ACK message or the MIH protocol response message with ACK-Rsp bit set) is lost, the ACK...""",Principle,  Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments  
3154900023,09/14/2007 18:36:55 EDT,283,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,4,Producer,Disapprove,Technical,69,7.3.6.3,26,"For correctness, either a Link_Down or Link_Event_Rollback.indication can be received prior to time expiry.",,No,"Replace sentence ""If Link_Down is NOT&."" with "" If Link_Down or Link_Event_Rollback is NOT&.""",Agree,
3154800023,09/14/2007 18:36:55 EDT,282,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,3,Producer,Disapprove,Technical,66,7.3.3.1.1,8,"For added clarity, add text that states that this message can be used for also specifying the time interval between periodic reporting of link parameters",,No,"Replace line 8 by text ""This primitive is used by the MIHF to configure thresholds and/or specify the time interval between periodic reports for the Link_Parameters_Report indication.""",Agree,
3154700023,09/14/2007 18:36:55 EDT,281,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,2,Producer,Disapprove,Technical,65,7.3.2.2.2,49,It should be made clear that in the case that the operation is not successful (i.e. STATUS is not set to success) that the remaining non essential TLVs should not be present (in the case of MIH messages from a remote entity this can save on resource usage on the airlink). Suggest we add text to the Response Link Event List column to clarify that this is not included if the status indicates failure. This is a global comment (applies to numerous places in the specification). If comment is accepted NW can bring in explicit text changes to be made for remaing sections.,,Yes,"Add text ""This is not included if STATUS is not set to code 0 (success)"" to the description column",Agree,All primitivies in section 7 would need to be examined carefully for this behavior.  This is applicable for MIH Protocol messages.
3154600023,09/14/2007 18:36:55 EDT,280,"Julka, Vibhor",vjulka@nextwave.com,858-449-5105,Individual,1,Producer,Disapprove,Technical,44,6.4.3.1.1,19,MIH_Configure_Link command is not defined. There a MIH_Link_Configure_Threshold specified both for SAP primitives (in section 7) and NIH messages in section 8.,,Yes,Replace all occurrences of MIH_Configure_Link with MIH_Link_Configure_Threshold.,Agree,Add MIH_Link_Action to the table 5
3154300023,09/14/2007 17:39:46 EDT,279,"Zuniga, Juan C",juancarlos.zuniga@interdigital.com,+1(514)9046251,Individual,4,Producer,Disapprove,Editorial,288,,14,Reference to table E-2,,No,Replace reference by table K-2,Agree,
3154200023,09/14/2007 17:39:46 EDT,278,"Zuniga, Juan C",juancarlos.zuniga@interdigital.com,+1(514)9046251,Individual,3,Producer,Disapprove,Technical,288,,20,Table K-2 does not provide a very comprehensive mapping between 802.21 and 3GPP parameters,,Yes,Replace the column that provides the mapping between 802.21 and 3GPP technologies by a different table as defined in 21-07/321r0,Principle,"  Accept the contribution 21-07-0321-00-0000    The link packet error rate is computed on the aggregate classes.  The following parameters mapped to CoS are computed on a per class of service,  (only Transfer Delay and Maximum Transfer Delay)  "
3154100023,09/14/2007 17:39:46 EDT,277,"Zuniga, Juan C",juancarlos.zuniga@interdigital.com,+1(514)9046251,Individual,2,Producer,Disapprove,Technical,141,,1,"Some technologies such as 3GPP require the preparation of resources in the target network before a handover takes place. The N2N Commit messages are very useful for this purpose and can be used when handing over e.g. from/to 3GPP to/from other technologies. However, the format and contents of these messages are not sufficient and some functionality is still needed inside these messages in order for them to be useful for other wireless technologies",,Yes,Include the missing functionalities in the N2N Commit messages as defined in 21-07/320r0,Agree,Keep the TargetPoA
3154000023,09/14/2007 17:39:46 EDT,276,"Zuniga, Juan C",juancarlos.zuniga@interdigital.com,+1(514)9046251,Individual,1,Producer,Disapprove,Technical,293,,47,non existing primitive,,Yes,"replace M-MTM-RSP
(Deregistration) by C-NEM-RSP (Deregistration)",Agree,
3153900023,09/14/2007 16:50:16 EDT,275,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,13,General Interest,Disapprove,Technical,46,6.5.2,60,"""It is important to note that, with certain access networks an MN should be able to obtain IEEE 802.21 related
information elements before the MN is authenticated with the PoA."" - Since this clause mentions security (authentication), it is very important to decide if such a functionality is even needed. If so, then how can be actually make this happen in a secure network. I see STA <=> PoA security at a different layer than the STA <=> MIIS, and as such, I do not see how the (future) security will work.",,Yes,"Group to discuss the requirements and usages of such functions. If these functions do remain in the draft, then securing these may be a very hard problem - the high cost of security may limit such operations.",Disagree,Emergency services and other applications as well may require information to be made available in the un-authenticated  state. This has been discussed extensively in the group over a long period of time.  it is up to deployment to decide how much information they make available in the un-authenticated state.
3153800023,09/14/2007 16:50:16 EDT,274,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,12,General Interest,Disapprove,Technical,26,5.5.3,26,The 802.11 architecture is missing the 802.1X Authenticator port control component.,,Yes,Update the Diagram and description to include the 802.11 Authenticator in consideration. The MIH_NET_SAP should go this interface.,Agree,This can be taken care of by 802.11 (TGu) people as part of updating the 802.11 reference diagram.
3153700023,09/14/2007 16:50:16 EDT,273,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,11,General Interest,Disapprove,Technical,26,5.5.3,26,"The MIHF Scope function block is incorrectly placed in contect of the 802.11 architecture diagram. To quote 802.11-2007 Clause 10.1 ""The exact functions of the SME are not specified in this standard, but in general this entity can be viewed as being responsible for such functions as the gathering of layer-dependent status from the various layer management entities (LMEs), and similarly setting the value of layer-specific parameters."" All MLME functions are genarated 802.11 SME, and as such invoking them from any other layar violates the 802.11 architecture. When the 802.21 plays in the context of the 802.11 SME, then it becomes reasonable for the 802.11 WG to architecturally define 802.11 specific interfaces for 802.21.",,Yes,"Correct the 802.21 architecture. The 802.21 entity must reside inside the 802.11 SME. This way, 802.21 can define mechanisms that can use 802.11 SME components. Likewise, same for 802.16 SME.",Agree,Please refer to TGu draft contribution
3153600023,09/14/2007 16:50:16 EDT,272,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,10,General Interest,Disapprove,Technical,15,5.3.1,36,"""MIH services in mobile nodes facilitate seamless handovers between heterogeneous networks"" - Has this statement been proven to work inter-operably? I believe the goal of this amendment is to provide such an enhancement. However, unless we have at least 2 inter-operable implementations implementing 802.21, we cannot get any guidance on whether this goal is met. And, in extension, it is not proven if the mechanisms defined in this amendment are sufficient for interoperability. This comment is against the entire draft.",,Yes,"Reword the goal accordingly to mention this as a desirable goal - not as an end result. Also, strongly suggest that participants of this standard conduct a plugfest to ensure that this protocol has been established to inter-operate, and hence, be useful.",Disagree,"There is no point in doing the standard if it is only a ""desirable goal""."
3153500023,09/14/2007 16:50:16 EDT,271,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,9,General Interest,Disapprove,Technical,13,5.1.7,39,"""MIH events, commands and information service message exchanges between an MN (Mobile Node) and a
network PoA (Point of Attachment) cannot be secured until the MN has a secure connection with the
network PoA."" - this sentence sounds self-filfulling. Yes - you need security before something can be secured.",,Yes,"This sentence be re-written to better specify what security properties need to be addressed. If none have been specified, then delete this 5.1.7 clause, and be added by future security work.",Principle,Relevant sub clause has been deleted.
3153400023,09/14/2007 16:50:16 EDT,270,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,8,General Interest,Disapprove,Technical,13,5.1.4,1,"""The MIH services defined by the IEEE 802.21 standard, including event, command, and information services,
need to consider network traffic performance objectives and how well they meet the application quality
of service requirements."" sounds like a requirement, and not a description of the 802.21 architecture.",,Yes,Rewrite this clause and other portions of Clause 5 to precisely reflect the 802.21 functions and design.,Principle,Paragraph is deleted.
3153300023,09/14/2007 16:50:16 EDT,269,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,7,General Interest,Disapprove,Technical,12,5,1,"Clause 5 is supposed to be general 802.21 architecture description. However, in multiple locations in this clause, there are references to more specific events in this specification, while there are other sentences that are too generic. Eg. Generic description of handovers in 5.1.2, generic QoS descriptions in 5.1.4, and so on.",,Yes,"Recommend re-writing Clause 5 much like that written for IEEE 802.11. This Clause should be very precise in its scope, and should be the ""executive summary"" of functions defined in this standard",Disagree,The group feels this clause is adequately written.
3153200023,09/14/2007 16:50:16 EDT,268,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,6,General Interest,Disapprove,Technical,7,3.26,42,"""MIHF transaction: A combination of an MIHF Request or Indication message and the corresponding
MIHF Response message (if applicable) that are exchanged between two MIHF peers. It is required to
match each request message that is sent by the initiator with its response message. Acknowledgement messages
associated with this message exchange are also part of the transaction."" - This is describing any exchange. Definition should include the function and result of this MIHF Transaction.",,Yes,Re-write definition to describe the function and results.,Agree,"Change as follows:  ""MIH Transaction: A combination of an MIH Request or Indication message and the corresponding  MIH Response message (if applicable) that are exchanged between two MIH peers. It is required to  match each MIH request message that is sent by the initiator with the corresponding MIH response message.   Acknowledgement messages associated with MIH message exchange are also part of the transaction."""
3153100023,09/14/2007 16:50:16 EDT,267,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,5,General Interest,Disapprove,Technical,6,3.6,28,"""3.6 home network: Network managed by the operator with whom the subscriber has a business relationship
(subscription)"" - This is at adds with the conventional definition of a ""home network"" where the prime attributes are ease-of-usablity, lack-of-IT dept., one/two network nodes, etc.",,Yes,"Raname ""Home Network"" to ""Home Subscriber Network"" in this clause and throughout the draft",Agree,Need to change this across the draft.
3153000023,09/14/2007 16:50:16 EDT,266,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,4,General Interest,Disapprove,Technical,6,3.1,7,"""A Point of Attachment (PoA) being evaluated for switching the link towards"" - reads like an incomplete sentence.",,Yes,Clarify or re-write.,Agree,Change:  3.1 candidate PoA: A Point of Attachment (PoA) being evaluated for switching the link towards.  To  3.1 candidate PoA: A Point of Attachment (PoA) under evaluation to which the link may be switched.
3152900023,09/14/2007 16:50:16 EDT,265,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,3,General Interest,Disapprove,Technical,5,2,1,Are the no Normative References used by this standard? Eg: What about IEEE Standards Terms mentioned in Clause 3 introduction of definitions.,,Yes,Update the Normative Reference list,Agree,This has been updated.
3152800023,09/14/2007 16:50:16 EDT,264,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,2,General Interest,Disapprove,Technical,3,1.3,36,The Diagram does not have any MIH Users - Are the Upper Layers the Users?,,Yes,Include Upper Layers as the MIH Users (as defined in 3.23),Agree,"Change ""Upper Layers"" to ""MIH Users""  Add ( ""e.g."" ) at the starting of next line."
3152700023,09/14/2007 16:50:16 EDT,263,"Sood, Kapil",kapil.sood@intel.com,503-264-3759,Individual,1,General Interest,Disapprove,Technical,2,1.3,33,"""The overall network may include pico cells such as IEEE 802.15, micro cells such as IEEE 802.11, and
macro cells (such as 3GPP, 3GPP2, or IEEE 802.16) with overlapping coverage."" - Where are the terms pico, micro, and macro defined. What do these mean?",,Yes,"Define the terms before they are used. If these are defined in other specifications, then indicate appropriate references.",Disagree,These terms are defined in IEEE disctionary.
3152600023,09/14/2007 14:42:22 EDT,262,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,7,Producer,Disapprove,Technical,203,,9,NETWORK_SECURITY definition missing,,Yes,Add definition,Principle,Delete NETWORK_SECURITY_IE  Can be added later if definition is available
3152500023,09/14/2007 14:42:22 EDT,261,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,6,Producer,Disapprove,Technical,124,,,MIH_N2N_HO_Commit should also allow the option of requesting resource reservation at the HO target.,,Yes,add an option where MIH_N2N_HO_Commit can request reservation of HO resources,Agree,Please refer to contribution 21-07-0320-02-0000
3152400023,09/14/2007 14:42:22 EDT,260,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,5,Producer,Disapprove,Technical,105,,,The need and use of the MIH_Net_HO_Candidate_Query command are not defined.,,Yes,remove MIH_Net_HO_Candidate_Query command,Disagree,"The name of these Net_HO commands need to be updated.    "" The Network controller provides a list of candiddate network choices to MN. The MN indicates resources required on each of these candiddate networks. The Network controller then queries each of the candiddate networks for available resources and reports this information back to the MN. Thereafter the Handover Commit happens""  This explanation needs to be captured and included in draft.  The name of these commands/messages need to be changed as well."
3152300023,09/14/2007 14:42:22 EDT,259,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,4,Producer,Disapprove,Technical,32,,,MIH_NMS_SAP is used to interface between an MIHF and a local Network Mgmt System (NMS) stack. The local NMS stack should be left up to the implementation.,,Yes,remove MIH_NMS_SAP from the standard,Agree,
3152200023,09/14/2007 14:42:22 EDT,258,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,3,Producer,Disapprove,Technical,31,,,"MIH_NET_SAP is used to interface between the MIHF implementation and the transport stacks on a device. This Service Access Point seems unnecessary, adds unneeded constraints on the implementation, and will likely not be tested (validated).",,Yes,remove MIH_NET_SAP from the standard,Agree,
3152100023,09/14/2007 14:42:22 EDT,257,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,2,Producer,Disapprove,Editorial,2,,12,"Word ""han-dovers"" is split across 2 lines and the hyphenation appears to be in wrong position.",,No,Correct,Principle,Also keep in mind that link break is set automatically by FrameMaker.
3152000023,09/14/2007 14:42:22 EDT,256,"Jette, Alan",alj1982@gmail.com,847421-8931,Individual,1,Producer,Disapprove,Editorial,276,,,Page XV: The Table of Contents items H.9.1 and H.9.2 wrap around.,,No,"If possible, correct",Agree,
3151800023,09/14/2007 09:54:24 EDT,255,"Karocki, Piotr",pkar@ieee.org,+48 (601) 474687,Individual,2,General Interest,Approve,Editorial,27,3.29,55,Add abreviation:,,No,... mobile node (MN): Communication ...,Agree,
3151700023,09/14/2007 09:37:45 EDT,254,"Karocki, Piotr",pkar@ieee.org,+48 (601) 474687,Individual,1,General Interest,Approve,Editorial,25,2,1,"If there is no references, please change clause text to ""There is no cited references"". Now it looks like references are missing.",,No,,Agree,
3151600023,09/14/2007 08:30:59 EDT,253,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,8,General Interest,Disapprove,Technical,15,5.1.8,46,"This talks only about wireless power management. Work is under way in 802.3 to define power management features that will interact with the MAC operation - e.g., by changing data rates - what is the relationship between the .21 work and these kinds of features in wired LANs?",,Yes,Show the relationship.,Disagree,802.21 helps in power conservation on mobile devices by providing information about wireless networks which resilts in reduced scanning to discover wireless networks.
3151500023,09/14/2007 08:30:59 EDT,252,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,7,General Interest,Disapprove,Technical,15,5.1.7,36,What is the relationship between this and what is already/is being specified in 802.1 for the provision of security?,,Yes,Show the relationship.,Principle,Section 5.1.7 has been deleted
3151400023,09/14/2007 08:30:59 EDT,251,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,6,General Interest,Disapprove,Technical,15,5.1.5,16,Sounds like you are attempting to re-define mechanisms that already exist in IEEE Std 802.1AB - LLDP.,,Yes,Either use 802.1AB to achieve this result or demonstrate why 802.1AB isn't suitable.,Disagree,802.21 deals with networks that do not fall directly within the scope of IEEE 802 (such as 3GPP/3GPP2).  802.1AB does not handle these other networks. 
3151300023,09/14/2007 08:30:59 EDT,250,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,5,General Interest,Disapprove,Technical,5,2,8,"I cannot believe that a proposed standard such as this, which is intended to specify mechanisms across multiple other standards, has exactly NO normative references. This is laughable, and to me, simply demonstrates that the document is not ready for prime time. Apart from anything else, the standard appears to be trying to re-define the MAC service. Why is there no normative reference to the existing MAC service definition?",,Yes,Determine which of the references in the bibliography should actually be normative references and move them to clause 2. Add any further normative references that are necessary to clause 2.,Agree,References have been updated
3151200023,09/14/2007 08:30:59 EDT,249,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,4,General Interest,Disapprove,Technical,3,1.4,63,"Also subclause 1.5 second para and subclause 1.3 last para on page 2. This is a false assumption in terms of existing 802 architecture. The role of the MAC service in the 802 architecture is to describe the parameters that are conveyed in peer protocol exchanges between systems, not to model local interactions within a single system. The latter is appropriately described either in terms of management interactions with managed objects, or maybe as some kind of local API, but in either case, not as part of the service interface presented at a (sub)layer SAP. In any case, modelling the (sub)layer service interface in such a way that there are distinct SAPs for modelling different protocol (or other local) functions fundamentally misses the point of the concepts of service boundaries and SAPs in the OSI reference model, which is what the 802 architecture is based on. You really should have discussed this with 802.1 experts long before presenting this kind of material for Sponsor ballot.",,Yes,"Fix the modelling so that the standard doesn't play fast and loose with the 802 architecture, and doesn't as a consequence define mechanisms that are potentially incompatible with existing 802 standards.",Disagree,"When the information originates at lower layers of the protocol stack within an MN or network  entity, the MIHF on that entity obtains it locally through the service primitives of the  SAPs that define the interface of the MIHF  ""Delete ----with the lower layers.---"""
3151100023,09/14/2007 08:30:59 EDT,248,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,3,General Interest,Disapprove,Editorial,,,,"It would be useful if, when you generate the PDF, you were to use the ability of Frame Maker to generate ""bookmarks"" in the PDF so that the document can be navigated more easily.",,Yes,Add them.,Agree,Done as suggested
3151000023,09/14/2007 08:30:59 EDT,247,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,2,General Interest,Disapprove,Editorial,,,,The line numbers are positioned such that the change bars overwrite them.,,Yes,Move the line numbers left by a few mm,Agree,Done as suggested
3150900023,09/14/2007 08:30:59 EDT,246,"Jeffree, Anthony A",tony@jeffree.co.uk,-5368,Individual,1,General Interest,Disapprove,Editorial,,,,"The page numbers of the PDF don't line up with the page numbers in the text. For the purposes of these comments, I have used the page numbers of the document, not the PDF.",,Yes,Fix the PDF and/or the text so the page numbers correspond.,Disagree,page number in the text is structured and does not start from the cover page of the document. therefore it is not possible to match the PDF page numbers.
3150600023,09/14/2007 07:15:55 EDT,245,"Ng, Chan-Wah",chanwah.ng@sg.panasonic.com,6565505420,Individual,1,User,Disapprove,Technical,23,,,"This is with regard to the functional architecture (Fig. 4) that shows the MIH-LINK-SAP as being the only interface between MIHF and Link Layer, and the fact that MIH-LINK-SAP primitives are defined. It is unlikely for implementors of separate access technologies to implement the MIH-LINK-SAP defined in this document. It is more likely that the MIHF implementor will implement a mapping function that maps existing native primitives provided by each link layer to the MIH-LINK-SAP primitives. The document also provide no provision for error reporting if a particular MIH-LINK-SAP primitive cannot be mapped using any natively available primitives.",,Yes,"As such, it is more appropriate for the functional architecture itself to contains such mapping functional units that lies in between the MIHF and LLC, which maps the native LLC primitives to the MIH-LINK-SAP primitives and vice versa. It might also be prudent to consider error codes in MIH-LINK-SAP response primitives that indicate the inability to map native primitives to MIH-LINK-SAP primitives.",Principle,Annex-L does exactly that
3150200023,09/14/2007 03:23:37 EDT,244,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,6,Producer,Disapprove,Technical,228,Annex H,1,"MIH deployment model which specifies the location of MIHF PoS and the interactions with the existing system elements on the specific access network like WiMAX, 3GPP are missing. Even though this may be deployment specific according to the operator's preference, it is helpful for the IEEE 802.21 specification reader to utilize the MIHF by recognizing how an MIHF can be deployed by seeing the most general and representative deployment models on the particular networks.",,No,"Please add the following section as H.10.
H.10 MIH deployment model",Disagree,This is outside the scope of this specification
3150100023,09/14/2007 03:22:03 EDT,243,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,5,Producer,Disapprove,Technical,143,8,1,MIH Handover Protocol behavior is missing from the section 8. Media Independent Handover Protocol.,,No,"Please add the following section as 8.3.
8.3 MIH Protocol Steps
8.3.1 Information Query
8.3.2 Resource Availability Check
8.3.3 Resource Preparation
8.3.4 Target Decision and Handover execution
8.3.5 Resource Release",Principle,Add this in section 8.2.  Replace bullet 5 with the proposed bullets and add some text to describe these bullets.  
3150000023,09/14/2007 03:21:12 EDT,242,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,4,Producer,Disapprove,Technical,143,8,1,Please clarify which protocol message is mandatory and which is optional under concerning inter-operability among different vendors developing the IEEE 802.21 compliant systems.,,No,Please mark each protocol message as mandatory or optional. Alternative is to first categorize the functionalities IEEE 802.21's MIHF provides then specify mandatory or optional for each functionality.,Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3149900023,09/14/2007 03:17:04 EDT,241,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,3,Producer,Disapprove,Technical,23,5.5.1,34,"Please clarify the relationship between the MIH_LINK_SAP and its primitives and actual SAPs like LSAP, MLME_SAP, CS_AP, C_SAP, M_SAP and their primitives. For an example, MIH_LINK_SAP specifies Link_Get_parameters primitive. Which primitive can be mapped to that Link_Get_parameters primitive from the actual SAPs like LSAP, MLME_SAP, CS_AP, C_SAP, M_SAP? Same question applies for all the primitives defined on MIH_LINK_SAP.",,No,"Please specify the relationship between the MIH_LINK_SAP and its primitives and actual SAPs like LSAP, MLME_SAP, CS_AP, C_SAP, M_SAP and their primitives.",Agree,SAP descriptions are moved to Annex L which also has mapping between different primitives.
3149800023,09/14/2007 03:16:09 EDT,240,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,2,Producer,Disapprove,Technical,59,7,1,Please clarify which primitive is mandatory and which is optional under concerning inter-operability among different vendors developing the IEEE 802.21 compliant modules.,,No,Please mark each primitive as mandatory or optional or specify that depending on the functionalities through IEEE 802.21's MIHF provides.,Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are defined in clause 7 since they are triggered by primitives."
3149700023,09/14/2007 03:15:28 EDT,239,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,6,Producer,Disapprove,Technical,150,8.4.1,60,"MIH Protocol header is of fixed length, as indicated in fig 27 on the next page.",,Yes,correct figure 26 to show MIH Header has fixed length of 8 octets.,Agree,
3149600023,09/14/2007 03:15:28 EDT,238,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,5,Producer,Disapprove,Technical,105,,,The Purpose and usefulness of MIH_Net_HO_Candidate_Query command are unclear.,,Yes,remove definition and all occurences of MIH_Net_HO_Candidate_Query command,Disagree,"The name of these Net_HO commands need to change.    "" The Network controller provides a list of candiddate network choices to MN. The MN indicates resources required on each of these candiddate networks. The Network controller then queries each of the candiddate networks for available resources and reports this information back to the MN. Thereafter the Handover Commit happens""  The above explanation needs to be captured and included in draft.  The name of these commands/messages need to be changed as well."
3149500023,09/14/2007 03:15:28 EDT,237,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,4,Producer,Disapprove,General,42,6.4.1,5,Figure 16 is confusing by showing two unrelated stacks.,,Yes,"remove the stack marked as ""Remote Entity"" and remove the text ""Local Entity"" from the stack on the left-hand side.",Agree,
3149400023,09/14/2007 03:15:28 EDT,236,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,3,Producer,Disapprove,General,36,6.3.1,20,Figure 13 is confusing by showing two unrelated stacks.,,Yes,"remove the stack marked as ""Remote Entity"" and remove the text ""Local Entity"" from the stack on the left-hand side.",Agree,
3149300023,09/14/2007 03:15:28 EDT,235,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,2,Producer,Disapprove,Technical,32,,,"MIH_NMS_SAP defines the interface between an MIHF implementation and a local Network Management System stack. Depending on the nature of the device, this local NMS stack may vary or may not even exist. Standardizing this interface brings no benefit to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove definition and all occurences of MIH_NMS_SAP,Agree,
3149200023,09/14/2007 03:15:28 EDT,234,"Giesberts, Pieter-Paul",giesberts@motorola.com,31306001619,Individual,1,Producer,Disapprove,Technical,31,,,"MIH_NET_SAP defines the interface between an MIHF implementation and various local transport stacks on the same device. However, it is unclear what compatability benefits standardizing this interface will bring to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove definition and all occurences of MIH_NET_SAP,Disagree,MIH_NET_SAP is required.
3149100023,09/14/2007 03:14:16 EDT,233,"Jee, Junghoon",jhjee@etri.re.kr,8.20E+12,Individual,1,Producer,Disapprove,Technical,2,1.3,14,"There needs to clarify how's wireless link conditions change for mobile users. In the IEEE P802.21/D7.1 draft, similar description is used for both mobile user and stationary user case.",,No,"For mobile users, handovers may occur due to changes in wireless link conditions according to the user's movement across wireless links.",Agree,
3149000023,09/14/2007 02:24:47 EDT,232,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,7,Producer,Disapprove,General,258,H6,,"Given the (obvious) usage of MIH in a FMIP scenario, it behooves the draft to provide some guidance as to how MIH may actually be used in such a situation.",,Yes,Add a call flow for FMIP operation,Disagree,No contribution available.  This is not very different than some of the other flow diagrams in draft.
3148900023,09/14/2007 02:24:47 EDT,231,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,6,Producer,Disapprove,General,143,8.2.1,,"There seems to be arbitrary decisions made regarding the MIH Protocol Acknowledgement operation. For example, why re-transmit only 2 times? Such variables are usually expressed in a MIB. What about the possibility of aggregated Ack messages?",,Yes,Restrict description of MIH Acknowledgement operation to the messages exchange. Implementation details should be left out or else in the Annex,Principle,"Replace    ""The source MIH node may at most make two retransmission attempts in addition to the first attempt  for an MIH protocol message with the same Message-ID and the same Transaction-ID.""    With    The source MIH node shall retransmit an MIH protocol message with ACK-Req bit set until it receives an acknowledgment or the number of retransmissions reaches its maximum value.  The maximum number of retransmissions can be reconfigured depending on implementation.  The default value of maximum number of retransmissions is two (2)."
3148800023,09/14/2007 02:24:47 EDT,230,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,5,Producer,Disapprove,General,71,7.3.10,,"There seems to be limited usefulness of the Link Transmission events due to lack of flexibility. For example, is it possible to specify a specific application data packets? Differentiation between protocol packets (e.g Binding Updates, Shim6 probe messages, etc)",,Yes,Increase the degree of flexibility for usage of the related events.,Disagree,This seems like trying to manage a priority queue and this kind of scheme may not be widely/reaily available.  Further optimization seems difficult.
3148700023,09/14/2007 02:24:47 EDT,229,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,4,Producer,Disapprove,General,34,6.2.5,,"MIH registration is stated to provide for authentication and authorisation, however no specific information is given as to how to incorporate the security aspects.",,Yes,Update section with text on security.,Disagree,Securiy issues would be handled by new group.
3148600023,09/14/2007 02:24:47 EDT,228,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,3,Producer,Disapprove,General,44,6.4.3,,The current Command Service allows for querying of available resources but does not provide any functionality for the reservation of resources by MIH users.,,Yes,Make allowances to enable an MIH user to request for reservation of resources.,Agree,
3148500023,09/14/2007 02:24:47 EDT,227,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,2,Producer,Disapprove,General,40,6.3.5,,There is a lack of a positive predictive MIH event MIH_Link_Going_Up.,,Yes,"Introduce a ""MIH_Link_Going_Up"" type positive predictive event.",Disagree,Difficult to envisage use cases and usefulness of this event. Need some motivation and other details to consider this.
3148400023,09/14/2007 02:24:47 EDT,226,"Koh, Benjamin",jadefox@pacific.net.sg,6565505481,Individual,1,Producer,Disapprove,General,39,6.3.4.1,,There is a lack of a positive predictive link event Link_Going_Up.,,Yes,"Introduce a ""Link_Going_Up"" type positive predictive event.",Disagree,Difficult to envisage use cases and usefulness of this event. Need some motivation and other details to consider this.
3138100023,09/13/2007 16:42:41 EDT,225,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,10,General Interest,Disapprove,Editorial,226,G,1,The title is not descriptive.,,No,"Use ""How to extend MIIS basic schema"" as the title.",Agree,
3138000023,09/13/2007 16:42:41 EDT,224,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,9,General Interest,Disapprove,Technical,208,D,1,"The title is not descriptive. Moreover, some description should be included before the RDF schema file.",,Yes,"Use ""MIIS basic schema"" as the title. Add in the following text as additional description: The remaining text in this section defines the RDF vocabularies for MIIS.",Agree,
3137900023,09/13/2007 16:42:41 EDT,223,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,8,General Interest,Disapprove,Editorial,173,Annexes,1,"Quote from 2007_Style_Menu page 17 last paragraph: Annexes should appear in the order in which they are referenced in the body of the standard (e.g., the first annex mentioned should be Annex A, the second Annex B, and so on). Note that this rule means that normative and informative annexes will be intermixed.",,No,The order of the annex should comply.,Principle,"Agreed, but since text in the body may still change and hence the order in which the annexes are referenced may change too. Will do this in the last version."
3137800023,09/13/2007 16:42:41 EDT,222,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,7,General Interest,Disapprove,Editorial,143,8.1,9,...using the MIH protocol messages specified in this section. Is that a correct reference? or should it be a subclause.,,No,Change 'section' to 'sub-clause' as used in other places. ( Another reference is in page 217 line 58 RDF Schema content.),Agree,changed 'section' to 'subclause'
3137700023,09/13/2007 16:42:41 EDT,221,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,6,General Interest,Disapprove,Editorial,96,7.4.12.1.2,22,Missing a parenthesis for the type of Packet Identifier.,,Yes,UNSIGNED_INT2) -> UNSIGNED_INT(2),Agree,
3137600023,09/13/2007 16:42:41 EDT,220,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,5,General Interest,Disapprove,Technical,95,7.3.14.1.2,58,Parameters for Link_Get_Parameters primitive (LINK_PARAM_TYPE) does not support all the parameters required in MIH_Link_Get_Parameters (p99L12 LINK_STATUS_REQ). Data type LINK_PARAM_TYPE p180L5; LINK_STATUS_REQ p183L13.,,Yes,The parameter for the Link_Get_Parameters should contain Link_Status & Link_Discriptor. See contribution 21-07-303-00-0000.doc,Agree,
3137500023,09/13/2007 16:42:41 EDT,219,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,4,General Interest,Disapprove,Editorial,68,7.3.5.2,14,Inconsistent on table formats for primitive parameters. e.g. P67 L32 v.s. P68 L14.,,No,Make the parameters table format consistent throughout section 7. This applies to annex B also (e.g. B14).,Agree,
3137400023,09/13/2007 16:42:41 EDT,218,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,3,General Interest,Disapprove,Editorial,55,6.5.6.3,7,"Information on how to extend the RDF representation should be included. On the other hand, the Annex should be referenced.",,Yes,Add the following sentence to the end of the paragraph: See Annex D for extending RDF basic schema.,Agree,"added ""See Annex G for how to extend the basic schema"""
3137300023,09/13/2007 16:42:41 EDT,217,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,2,General Interest,Disapprove,Technical,55,6.5.6.3,3,There is only one format provided in Annex D.,,Yes,Have the TLV schema(Type assignment plus the value data type mappings) included in Annex D.,Disagree,The TLV format is adequate
3137200023,09/13/2007 16:42:41 EDT,216,"Cheng, Yuu Heng",yhcheng@research.telcordia.com,17326992185,Individual,1,General Interest,Disapprove,Technical,51,6.5.5,27,"TLV representation for information elements can be confused with later page 152 section 8.5 ""Message parameter TLV encoding"". Especially the type field has different length. Moreover, IEs can be represented either in binary encoding or RDF encoding. Section 6.5.5 should introduce IE binary encoding and RDF encoding.",,Yes,Please see contribution 21-07-304-00-0000-Organize_Section6.5.doc,Principle,Delete section 6.5.6.2 (RDF Schema Propoganda)
3137100023,09/13/2007 16:03:47 EDT,215,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,14,Producer,Disapprove,Technical,178,B.2.4,51,LINK_ID should be LINK_TUPLE_ID to allow connecting to a specific PoA? .,,Yes,Change LINK_ID to LINK_TUPLE_ID.,Agree,
3137000023,09/13/2007 16:03:47 EDT,214,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,13,Producer,Disapprove,Technical,178,B.2.4,29,There is no action type to perform intra-technology handover.,,Yes,"Add the following LINK_ACTION_TYPE: ""LINK_HANDOVER"". Also, add the following entry to Table B-5: ""LINIK_HANDOVER | Cause an intra-technology handover on the specified link. A target PoA may be specified as well.""",Disagree,At the link layer this option is not valid.
3136900023,09/13/2007 16:03:47 EDT,213,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,12,Producer,Disapprove,Technical,205,C,32,Status TLV Data Type should be STATUS instead of ENUMERATED.,,Yes,Change it to STATUS.,Agree,
3136800023,09/13/2007 16:03:47 EDT,212,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,11,Producer,Disapprove,Technical,199,B.2.10.2,56,The default MIME_TYPE value is incorrect.,,No,"Change the second sentence of Definition column to: ""If MIME_TYPE is omitted, MIME type ""application/xml"" is used.""",Agree,
3136700023,09/13/2007 16:03:47 EDT,211,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,10,Producer,Disapprove,Technical,198,B.2.9,43,The default MIME_TYPE value is incorrect.,,Yes,"Change the second sentence of Definition column to: ""If MIME_TYPE is omitted, MIME type ""application/sparql-query"" is used.""",Agree,
3136600023,09/13/2007 16:03:47 EDT,210,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,9,Producer,Disapprove,Technical,198,B.2.9,36,"""When the MIME type is ""application/ sparql-results+xml"", this field contains XML text"". This sentence is out of context.",,Yes,Delete the sentence.,Agree,
3136500023,09/13/2007 16:03:47 EDT,209,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,8,Producer,Disapprove,Technical,174,B,13,Clarification on parsing data types is needed.,,Yes,"Add the following sentence in Annex B: ""This Annex defines data types used in the IEEE 802.21 standard. Any variable-length data type in this specification contains information needed for determining the end of data.""",Agree,
3136400023,09/13/2007 16:03:47 EDT,208,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,7,Producer,Disapprove,Technical,165,8.6.3.14,59,IPAddressInformationStatus should be optional as other IP related attributes are.,,Yes,Mark IPAddressInformationStatus optional,Agree,
3136300023,09/13/2007 16:03:47 EDT,207,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,6,Producer,Disapprove,Technical,164,8.6.3.12,36,IPConfigurationMethods and IPAddressInformationStatus should be optional as other IP related attributes are.,,Yes,Mark IPConfigurationMethods and IPAddressInformationStatus optional,Agree,
3136200023,09/13/2007 16:03:47 EDT,206,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,5,Producer,Disapprove,Technical,151,8.4.1.1,43,"UIR bit usage is not clear. Which entity is supposed to set this bit? If MN is supposed to set this bit, how PoS? can trust that MN is authenticated when the bit is not set? The underlying assumption for the response limiting using this bit to work is not clear.",,Yes,Delete the UIR bit or add more text that answers to those questions.,Principle,TGu needs this feature in current version of draft.  Other issues with this feature could be clarified separately.  Please refer to contribution: 21-07-0373-01-0000
3136100023,09/13/2007 16:03:47 EDT,205,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,4,Producer,Disapprove,Technical,151,8.4.1.1,31,Version field is not useful unless the specification completely specifies how MIHFs can negotiate on a single version.,,Yes,Delete the Version field.,Principle,"This field allows implementations to recognize different versions.   Add the following:  ""  This field is used to specify the version of MIH protocol used.  0: Not to be used  1:  First Version  2 - 15: (Reserved)    The version number will be incremented only when a fundamental incompatibility exists between a new revision and the prior edition of the standard. An MIH node that receives an MIH message with a higher version number than it supports will discard the frame without indication to the sending MIH node.  """
3136000023,09/13/2007 16:03:47 EDT,204,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,3,Producer,Disapprove,Technical,82,7.4.2.1.2,37,It is better to include a list of link identifiers in MIH_Register.request.,,Yes,Adopt 21-07-0226-00-0000-MIH_Registartion_Nits.,Agree,
3135900023,09/13/2007 16:03:47 EDT,203,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,2,Producer,Disapprove,Technical,80,7.4.1.3.1,60,Supported Transport List should not be optional.,,Yes,"Remove ""(Optional)"" from Supported Transport List in MIH_Capability_Discover.{response,confirm} primitives and MIH_Capability_Discover response message.",Agree,
3135800023,09/13/2007 16:03:47 EDT,202,"Ohba, Yoshihiro",yohba@tari.toshiba.com,201-592-0281,Individual,1,Producer,Disapprove,Technical,80,7.4.1.3.1,57,Supported IS Query Parameter Type List should not be optional.,,Yes,"Remove ""(Optional)"" from Supported IS Query Parameter Type in MIH_Capability_Discover.{response,confirm} primitives and MIH_Capability_Discover response message.",Agree,
3135700023,09/13/2007 15:42:30 EDT,201,"Cole, Terry L",terry.cole@amd.com,512-602-2454,Individual,4,General Interest,Disapprove,General,292,L.1,,I do not agree with providing a references to named internal IEEE WG 802.21 documents in the standard.,,Yes,Include the appropriate material in the stadnard. At a minimum explain how to obtain these documents.,Principle,"Delete sections L1 and L2 from this Annex.  Change the title of this Annex to ""Media specific mapping for SAPs""  Elsewhere in the draft it is mentioned that medi aspecific enhancements should be included in draft.   Remove such statements (pg 23 line 52)."
3135600023,09/13/2007 15:42:30 EDT,200,"Cole, Terry L",terry.cole@amd.com,512-602-2454,Individual,3,General Interest,Disapprove,General,8,3.42,,I believe this is already in the IEEE dictionary.,,Yes,Remove definitions already defined in IEEE dictionary.,Agree,Delete this term. (SAP)
3135500023,09/13/2007 15:42:30 EDT,199,"Cole, Terry L",terry.cole@amd.com,512-602-2454,Individual,2,General Interest,Disapprove,General,6,3.1,,I blieve the use of acronyms in the abbreivation to be confusing.,,No,Spell out PoA,Agree,"change ""candiddate PoA"" to ""candiddate Point of Attachment""    Spell out other acronyms in this section as well.  Acronyms need to be spelt out the first time they are used, the acronym can then be used subsequently."
3135400023,09/13/2007 15:42:30 EDT,198,"Cole, Terry L",terry.cole@amd.com,512-602-2454,Individual,1,General Interest,Disapprove,General,6,3.7,,I blieve the use of acronyms in the abbreivation to be confusing.,,No,Spell out MN and PoA in the definition 3.7.,Agree,
3133200023,09/13/2007 13:56:26 EDT,197,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,71,General Interest,Disapprove,Technical,113,742112,53,"Consistency: The MIH_N2N_HO_Query_resources.request and the MIH_N2N_HO_Query_resources.indication contain a CandidateLinkList as an optional parameter. However the MIH_N2N_HO_Query_Resources request message does not have this TLV. How can this information be received in the indication, if it is not contained in the request message?",,Yes,"Either add TLV to message, or remove parameter from primitives.",Agree,Add CandidateLinkList in the request message in section 8.6.3.13 on page 165
3133100023,09/13/2007 13:56:26 EDT,196,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,70,General Interest,Disapprove,Technical,160,8632,49,"Consistency: The MIH_Get_link_Parameters response message contains the Device States Response List, while the MIH_Get_link_Parameters request message has the DeviceStatesRequest marked as optional. Why is it is required in the response message when it was not requested in the request message?",,Yes,"Clarify whether this is a mistake (i.e., add optional to TLV) or it is the function of the remote MIHF to always return the value of the DeviceStatesResponseList, even if one was not requested (add text stating this).",Agree,Make this optional in the response.
3133000023,09/13/2007 13:56:26 EDT,195,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,69,General Interest,Disapprove,Technical,204,,59,Consistency: There is no MIH_N2N_HO_Candidate_Query,,Yes,Change to MIH_N2N_HO_Query_Resources,Agree,
3132900023,09/13/2007 13:56:26 EDT,194,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,68,General Interest,Disapprove,Technical,44,64311,18,Consistency: There is no MIH_Configure_Link,,Yes,Change to MIH_Link_Configure_Thresholds to match clause 8.6.3.3,Agree,
3132800023,09/13/2007 13:56:26 EDT,193,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,67,General Interest,Disapprove,Technical,154,,5,"The broadcasting of this message cannot be consumed by any of the state diagrams in 8.2. New state machines need to be added to permit transmission and reception of this very special case. None of the current state diagrams can be used because they all include the ack/rep bit behavior, which cannot be used in these cases.",,Yes,"Add new state diagrams, or remove this capability and any associated material from the entire draft.",Principle,Please see contributon 21-07-0302-00-0000
3132700023,09/13/2007 13:56:26 EDT,192,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,66,General Interest,Disapprove,Technical,315,,41,"Figure M-3 shows a Mobile node at the center of a coverage area of 40,000 square meters (200m x 200m). If the 19th bit has a resolution of 100 m, then the square cannot be 200m x 200m. Since only the change is to go from corner to corner is represented by hex ""c"" to ""d"" or ""b"" to ""c"".",,Yes,The square should be 100m x 100m with the MN in the center at 50m.,Agree,
3132600023,09/13/2007 13:56:26 EDT,191,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,65,General Interest,Disapprove,General,297,,13,Annex needs to be update for consistency to the rest of the document,,Yes,Change MIH_Information.request/response with MIH_Get_Information.request/response,Agree,
3132500023,09/13/2007 13:56:26 EDT,190,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,64,General Interest,Disapprove,General,296,,4,IEEE Style is not applied,,Yes,"Change ""This table"" to ""Table L-4""",Agree,
3132400023,09/13/2007 13:56:26 EDT,189,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,63,General Interest,Disapprove,General,284,,1,Annex needs to be update for consistency to the rest of the document,,Yes,"page 285 line 27 change MIH configure line to MIH_Link_Configure_Thresholds; line 32 change MIH_Link_Parameter_Report to MIH_Link_Parameters_Report; figure K-1 three changes: 1) MIH_configure_link to MIH_link_configure_thresholds, 2) no more InitAction, 3) no more ExecAction); page 287 line 6 remove link from packet error rate; line 46 remove transfer from CoS Packet Delay Jitter; page 288 line 13 change Table E-2 to K-2; line 40 remove transfer from CoS Packet Delay Jitter;",Agree,
3132300023,09/13/2007 13:56:26 EDT,188,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,62,General Interest,Disapprove,General,282,,45,Consistency for NAT. Does NAT stand for Network address Translation as in line 45 or Network Address Translator as in line 64?,,Yes,Use one method and stay with it.,Agree,
3132200023,09/13/2007 13:56:26 EDT,187,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,61,General Interest,Disapprove,Editorial,282,,45,Consistency Address or address,,Yes,Use one method and stay with it.,Agree
3132100023,09/13/2007 13:56:26 EDT,186,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,60,General Interest,Disapprove,Technical,281,,8,The MIH_N2N_HO_Complete does not cross the R1 and R3 as currently defined,,Yes,Delete R1 and R3,Agree
3132000023,09/13/2007 13:56:26 EDT,185,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,59,General Interest,Disapprove,Technical,281,,6,The MIH_MN_HO_Complete message may be sent to the target POS as per page 228,,Yes,Add R2,Agree
3131900023,09/13/2007 13:56:26 EDT,184,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,58,General Interest,Disapprove,Technical,280,,60,The MIH_N2N_HO_Query_Resources does not cross the R1 and R3 as currently defined,,Yes,Delete R1 and R3,Agree
3131800023,09/13/2007 13:56:26 EDT,183,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,57,General Interest,Disapprove,Technical,280,,52,There is no MIH_Link_Action(s) message corresponding to clause 8.6.3.6,,Yes,Add missing message to list,Agree
3131700023,09/13/2007 13:56:26 EDT,182,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,56,General Interest,Disapprove,Technical,280,,51,There is no MIH_Configure message with this name,,Yes,Change to MIH_Link_Configure_Thresholds to match clause 8.6.3.3,Agree
3131600023,09/13/2007 13:56:26 EDT,181,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,55,General Interest,Disapprove,Technical,276,,50,"There is no HandoverAck parameter or TLV in the MIH_MN_HO_Candidate_Query Response message, so why is it there?",,Yes,Delete both occurrences,Agree
3131500023,09/13/2007 13:56:26 EDT,180,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,54,General Interest,Disapprove,Technical,273,,24,"There are two places where the MIH_Link_Up is used. Neither of which are correct in name or in placement. MIH_Link_Up.indication is from MIHF to MIHF user, not MAC-WLAN to MIHF or PoA-WLAN to PoS-WLAN.",,Yes,Expand the block to properly include the link and MIH primitives,Agree
3131400023,09/13/2007 13:56:26 EDT,179,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,53,General Interest,Disapprove,Technical,272,,40,Why does a MIH_MN_HO_Commit Request message produce a MIH_Net_HO_Commit.indication?,,Yes,Change to MIH_MN_HO_Commit.indication,Agree
3131300023,09/13/2007 13:56:26 EDT,178,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,52,General Interest,Disapprove,Technical,270,,24,"There are two places where the MIH_Link_Up is used. Neither of which are correct in name or in placement. MIH_Link_Up.indication is from MIHF to MIHF user, not MAC-WLAN to MIHF or PoA-WLAN to PoS-WLAN.",,Yes,Expand the block to properly include the link and MIH primitives,Agree
3131200023,09/13/2007 13:56:26 EDT,177,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,51,General Interest,Disapprove,Editorial,268,,34,"Consistency PoS, POS, Pos, Pos, etc.",,Yes,Change Pos to PoS,Agree
3131100023,09/13/2007 13:56:26 EDT,176,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,50,General Interest,Disapprove,General,267,,36,"FNA is used, which is correct for the original RFC 4068. However the newest draft RFC 4068 changed FNA to UNA.",,Yes,"If this annex is going to contain h.7.2 on PMIPv6, then it should update its FMIPv6 data",Agree
3131000023,09/13/2007 13:56:26 EDT,175,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,49,General Interest,Disapprove,Technical,267,,54,"The Link_Action.request is sent to MAC_WiMAX, however the corresponding Link_Down.indication comes from the MAC_WLAN.",,Yes,Change to arrive from the MAC-WiMAX,Agree
3130900023,09/13/2007 13:56:26 EDT,174,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,48,General Interest,Disapprove,Technical,266,,50,"The Link_Action.request is sent to MAC_WLAN, however the corresponding Link_Up.indication comes from the MAC_WiMAX.",,Yes,Change to arrive from the MAC-WLAN,Agree
3130800023,09/13/2007 13:56:26 EDT,173,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,47,General Interest,Disapprove,Editorial,263,,47,MIH_Link_Parameters_Report.indication is not a message between MIHFs,,Yes,Remove period between Report and indication,Agree
3130700023,09/13/2007 13:56:26 EDT,172,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,46,General Interest,Disapprove,Editorial,261,,19,There is no MIN_MN_Commit.request,,Yes,MIH_MN_HO_Commit.request,Agree
3130600023,09/13/2007 13:56:26 EDT,171,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,45,General Interest,Disapprove,General,261,,36,"FNA is used, which is correct for the original RFC 4068. However the newest draft RFC 4068 changed FNA to UNA.",,Yes,"If this annex is going to contain h.7.2 on PMIPv6, then it should update its FMIPv6 data",Agree,
3130500023,09/13/2007 13:56:26 EDT,170,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,44,General Interest,Disapprove,Technical,257,,19,"Two blocks have the same ""Handover Completion and Candidate PoS becomes new serving PoS"" What is the difference?",,Yes,Merge the two blocks into one,Agree,
3130400023,09/13/2007 13:56:26 EDT,169,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,43,General Interest,Disapprove,Editorial,256,,19,There is no MIN_MN_Commit.request,,Yes,MIH_MN_HO_Commit.request,Agree,
3130300023,09/13/2007 13:56:26 EDT,168,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,42,General Interest,Disapprove,Editorial,252,,19,There is no MIN_MN_Commit.request,,Yes,MIH_MN_HO_Commit.request,Agree,
3130200023,09/13/2007 13:56:26 EDT,167,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,41,General Interest,Disapprove,Editorial,231,,1,Many figures are missing the vertical/horizontal lines indicating where the messages and primitives are started and terminated,,Yes,Place blocks in correct drawing software order so that the lines appear.,Agree,
3130100023,09/13/2007 13:56:26 EDT,166,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,40,General Interest,Disapprove,Editorial,228,,47,Consistency with paragraph/bullet convention,,Yes,Add blank link between 9) and 10),Agree,
3130000023,09/13/2007 13:56:26 EDT,165,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,39,General Interest,Disapprove,General,226,,1,Annex needs to be update for consistency to the rest of the document,,Yes,"page 226 line 60, missing list in supported_lcp; missing mobility management",Agree,
3129900023,09/13/2007 13:56:26 EDT,164,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,38,General Interest,Disapprove,General,224,,1,Annex needs to be update for consistency to the rest of the document,,Yes,"page 224 line 35, missing list in supported_lcp; missing mobility management; line 43 & 49 remove transfer from cos_packet_delay_jitter",Agree,
3129800023,09/13/2007 13:56:26 EDT,163,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,37,General Interest,Disapprove,General,208,,1,Annex needs to be update for consistency to the rest of the document,,Yes,page 214 line 2 change cos_packet_transfer_delay_jitter to cos_packet_delay_jitter,Agree,
3129700023,09/13/2007 13:56:26 EDT,162,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,36,General Interest,Disapprove,General,204,,51,Consistency in the use of MIH_Link_Action or MIH_Link_Actions,,Yes,Use one method and stay with it.,Agree,
3129600023,09/13/2007 13:56:26 EDT,161,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,35,General Interest,Disapprove,Technical,203,,9,The heading of this clause is missing definitions. Why was this draft put forward to Sponsor ballot if it is a known fact that there are missing definitions?,,Yes,Remove,Agree,
3129500023,09/13/2007 13:56:26 EDT,160,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,34,General Interest,Disapprove,Technical,200,,50,No bit for MIH_Link_Action(s),,Yes,Add bit for MIH link action command,Agree,
3129400023,09/13/2007 13:56:26 EDT,159,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,33,General Interest,Disapprove,Technical,200,,39,"Consistency problem: bit 1, there is no MIH_Configure_Link",,Yes,Change to MIH_Link_Configure_Parameters,Agree,
3129300023,09/13/2007 13:56:26 EDT,158,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,32,General Interest,Disapprove,Technical,199,,7,There is no INFORMATION_ELEMENT defined. However it may be a consistency problem and should be IE_TYPE on page 196,,Yes,Specify INFORMATION_ELEMENT,Disagree,What is IE_TYPE?  INFORMATION_ELEMENT  IE_TYPE is used by IE Reporting template    No change needed.
3129200023,09/13/2007 13:56:26 EDT,157,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,31,General Interest,Disapprove,Technical,186,,36,Is it the number of classes of service (COS) as the definition states or is it the number of quality of service (QOS)?,,Yes,"If former, then change QOS to COS and the same on line 27",Agree,
3129100023,09/13/2007 13:56:26 EDT,156,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,30,General Interest,Disapprove,Technical,186,,32,Consistency in naming is lacking,,Yes,Add underscore between PACKET and TRANSFER,Agree,
3129000023,09/13/2007 13:56:26 EDT,155,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,29,General Interest,Disapprove,Technical,179,,43,There is no bit for Link_Action command,,Yes,Add bit for link action command,Agree,
3128900023,09/13/2007 13:56:26 EDT,154,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,28,General Interest,Disapprove,General,179,,25,"Bits 3, 4, and 5 are not in the same meaning order as for the MIH_EVENT_LIST",,Yes,Could they be for easy of mapping?,Agree,
3128800023,09/13/2007 13:56:26 EDT,153,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,27,General Interest,Disapprove,Technical,175,,54,The number of octets (27) is not correct using the numbers contained on the next page.,,Yes,Change 27 to 29 and 26 to 28,Agree,
3128700023,09/13/2007 13:56:26 EDT,152,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,26,General Interest,Disapprove,Editorial,175,,49,Consistency LINK-ID or LINK_ID,,Yes,Change to LINK_ID,Agree,
3128600023,09/13/2007 13:56:26 EDT,151,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,25,General Interest,Disapprove,Technical,215,,34,"Value of TYPE_IE_POA_MAC_ADDRESS is 10000302 here, while it is 10000200 in Table A-1 page 173",,Yes,Consistently use one value,Agree,
3128500023,09/13/2007 13:56:26 EDT,150,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,24,General Interest,Disapprove,Technical,173,,41,No Mobility Management line item or coding,,Yes,Consistently add or remove Mobility management from entire document,Agree,
3128400023,09/13/2007 13:56:26 EDT,149,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,23,General Interest,Disapprove,Technical,214,,39,"Name is missing ""list"" to agree with page 173, Table A-1: TYPE_IE_LIST_SUPPORTED_LCP",,Yes,"add missing ""list"" to the name",Agree,
3128300023,09/13/2007 13:56:26 EDT,148,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,22,General Interest,Disapprove,Editorial,161,8635,37,Consistency throughout the document as to whether it is MIH_Link_Actions or MIH_Link_Action,,Yes,pick one method and use consistently,Agree,
3128200023,09/13/2007 13:56:26 EDT,147,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,21,General Interest,Disapprove,Editorial,144,821,3,"guild is a noun, not a verb, so what is ""to guild""?",,Yes,Change guild to guide,Principle,"changed sentence to: ""The algorithm defined in IETF RFC 2988 may be used to calculate the value of the retransmission timer."""
3128100023,09/13/2007 13:56:26 EDT,146,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,20,General Interest,Disapprove,Editorial,143,821,53,"Consistency with the ""an"" before ""MIH""",,Yes,change a to an,Agree,
3128000023,09/13/2007 13:56:26 EDT,145,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,19,General Interest,Disapprove,Editorial,143,81,8,"""& each other to using ...""",,Yes,Change to to by,Principle,"changed sentence to: ""The MIH Functions in MN and network entities communicate with each other using the MIH protocol messages specified in this subclause."""
3127900023,09/13/2007 13:56:26 EDT,144,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,18,General Interest,Disapprove,Editorial,139,75112,13,OCTECT_STRING?,,Yes,OCTET_STRING,Agree,
3127800023,09/13/2007 13:56:26 EDT,143,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,17,General Interest,Disapprove,Editorial,138,75112,24,OCTECT_STRING?,,Yes,OCTET_STRING,Agree,
3127700023,09/13/2007 13:56:26 EDT,142,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,16,General Interest,Disapprove,Technical,122,742322,30,"Old link actions uses the LINK_ACTIONS type (which does not exist). Perhaps just deleting the ""S"" it is the LINK_ACTION type. If so, it does not include a link identifier, so which is the old link? There are only current link and target link identifiers in the primitive as parameters.",,Yes,Change old to current,Agree,
3127600023,09/13/2007 13:56:26 EDT,141,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,15,General Interest,Disapprove,Technical,121,742312,44,"Old link actions uses the LINK_ACTIONS type (which does not exist). Perhaps just deleting the ""S"" it is the LINK_ACTION type. If so, it does not include a link identifier, so which is the old link? There are only current link and target link identifiers in the primitive as parameters.",,Yes,Change old to current,Agree,
3127500023,09/13/2007 13:56:26 EDT,140,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,14,General Interest,Disapprove,Technical,119,742224,25,"This subclause is about the MIH_Net_HO_Commit.indication primitive, not the MIH_Net_HO_Commit.request.",,Yes,Change MIH_Net_HO_Commit.request to MIH_Net_HO_Commit request message,Agree,
3127400023,09/13/2007 13:56:26 EDT,139,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,13,General Interest,Disapprove,Technical,110,742024,61,The first sentence states that it invokes MIH_N2N_HO_Query_Resources.response primitive. Why?,,Yes,MIH_MN_HO_Candidate_Query.response primitive is more appropriate in response to a MIH_MN_HO_Candidate_Query.indication primitive,Agree,
3127300023,09/13/2007 13:56:26 EDT,138,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,12,General Interest,Disapprove,Technical,108,741942,23,The type and description for the Handover status do not agree. There are no reasons given in the HANDOVER_STATUS on page 202,,Yes,Align text with TYPE or change type to align with description.,Agree,"Change text to ""Indicates the MN accepted or declined the handover request."""
3127200023,09/13/2007 13:56:26 EDT,137,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,11,General Interest,Disapprove,Technical,83,74222,29,"The text include ""local MIHF"", however the registration is between a local and remote MIHF. How then can it be the local MIHF? There seems to be some confusion on whether the local and remote MIHFs are paired or whether the MIHF user is registered with its local or remote MIHF.",,Yes,"Clarify the function of the Register feature (i.e., does it pair local and remote MIHFs or does it pair MIHF Users with local or remote MIHFs?)",Agree,"Change as follows on pg 83 line 27    ""  Registration request code. Depending on the request code, the  MIH User can choose to either register or re-register with the  remote MIHF  """
3127100023,09/13/2007 13:56:26 EDT,136,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,10,General Interest,Disapprove,Editorial,71,7391,14,Sentence is missing punctuation,,Yes,Add period,Agree,
3127000023,09/13/2007 13:56:26 EDT,135,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,9,General Interest,Disapprove,Editorial,61,7222,42,"There is only one Primitive listed in Table 11, however the text is in plural form.",,Yes,"Change ""primitives are"" to ""primitive is""",Agree,
3126900023,09/13/2007 13:56:26 EDT,134,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,8,General Interest,Disapprove,Technical,61,7221,34,Table 10 states air interface for Link_Get_Parameters. However this document's purpose applies to wired and wireless.,,Yes,"Change ""air interface"" with medium",Agree,
3126800023,09/13/2007 13:56:26 EDT,133,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,7,General Interest,Disapprove,Technical,57,67,5,"This paragraph leads me to understand that the MIH_LINK_SAP is used for transport services when using L2 and MIH_NET_SAP when transport service is L3. However the text for MIH_NET_SAP includes a parameter to select whether L2 or L3 are chosen as transport method. If MIH_NET_SAP is used for L3 only, then there is no need for this parameter. If there is a need for the parameter then the text of this clause 6.7 needs to be changed to reflect the meaning of this parameter. Or could one think that MIH_NET_SAP is called to carry messages either layer 2 or 3 and above. While MIH_LINK_SAP provides the mechanisms to send the MIH messages at layer 2, it would be MIH_NET_SAP that uses it if MIHF requests to send over layer 2.",,Yes,"If MIH_NET_SAP is used for L3 only, then there is no need for this parameter and should be deleted throughout the document. If there is a need for the parameter then the text of this clause 6.7 needs to be changed to reflect the meaning of this parameter.",Principle,Resolved in other comments (cmt 427)
3126700023,09/13/2007 13:56:26 EDT,132,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,6,General Interest,Disapprove,Technical,53,6552,12,There is no Mobility Management IE in this container.,,Yes,Add Mobility Management IE,Agree,
3126600023,09/13/2007 13:56:26 EDT,131,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,5,General Interest,Disapprove,Technical,52,6552,60,Network System ID IE does not exist.,,Yes,Change to Access Network AUX ID,Agree,
3126500023,09/13/2007 13:56:26 EDT,130,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,4,General Interest,Disapprove,Technical,50,653,33,Figure 19 shows an expanded view of the second network (Operator_2). However the expanded view contains Operator_1,,Yes,Change Operator_1 to Operator_2,Agree,
3126400023,09/13/2007 13:56:26 EDT,129,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,3,General Interest,Disapprove,Technical,44,64311,20,"Table 5 does not include the MIH_Link_Actions as a command. Throughout the document there appears to be a problem differentiating between MIH_Scan and MIH_Link_Actions. If both are needed then clearly include both in all relevant, tables, TLVs, IEs, and clauses.",,Yes,"If both are needed then clearly include both in all relevant, tables, TLVs, IEs, and clauses.",Out of Scope,MIH_Scan is deleted by other comment
3126300023,09/13/2007 13:56:26 EDT,128,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,2,General Interest,Disapprove,General,10,4,6,"IEEE Style is not applied to the this clause as per IEEE Standards Style Manual 2007, 10.6 page 17",,Yes,Format according to IEEE Standards Style Manual (use lower case),Agree,
3126200023,09/13/2007 13:56:26 EDT,127,"Cypher, David",david.cypher@nist.gov,1 301 975 4855,Individual,1,General Interest,Disapprove,General,2,,52,Consistency in the capitalization of service. Three bullets and in the first two service is lower case. In the third it is upper case.,,Yes,Use one method and stay with it.,Agree,Pick lower case.
3117200023,09/12/2007 17:25:38 EDT,126,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,4,Producer,Disapprove,Editorial,210,B.2.7,57,Values 65 to 127 are not valid values for IPv6 prefix. Should that be noted somewhere?,,No,,Agree,
3117100023,09/12/2007 17:19:19 EDT,125,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,3,Producer,Disapprove,General,210,B.2.7,43,"Type name IP_CONFIG_STATUS carries values which are temporary failures, not intended to persist (ie to be solved asap).
How would an IS carry up-to-date information of these temporary statuses? If the information is outdated, that may cause trouble.",,No,Get rid of this type by removing it.,Principle,"Remove IP_CONFIG_STATUS from IS query, but leave it for other cases (CS). This is already the case in the draft."
3117000023,09/12/2007 17:10:19 EDT,124,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,2,Producer,Disapprove,Technical,210,B.2.7,21,"A STA with IPv6 interface does not need to know whether the link supports stateless, stateful or manual configuration. Configuration always starts with stateless and may continue with stateful or may fall back to require manual in case no unique interface ID generation was possible.",,No,"Remove bits 11, 12 and 13 from IP_CONFIG_METHODS type name.",Disagree,These bits are required
3116900023,09/12/2007 17:02:42 EDT,123,"Bajko, Gabor",gabor.bajko@nokia.com,18587176650,Individual,1,Producer,Disapprove,Technical,208,b.2.6,3,"types CIVIC_LO_METHOD and GEO_LO_METHOD do not have any added value for the STA. The only value for CIVIC_LO_METHOD (manual) virtually does not exist any more.
Table B-10 duplicates what is already defined in IETF.",,No,"Remove CIVIC_LO_METHOD (line 57, p207)
Remove reference to table B-10, line 3 (p208)
Remove GEO_LO_METHOD (line 9, p208)
Remove reference to table B-10, line 36 (p208)
Remove Table B-10.",Principle,Leave Table B-10
3115000023,09/12/2007 08:16:53 EDT,122,"Barr, John R",barr@ieee.org,847-576-8706,Individual,1,User,Disapprove,General,124,7.4.24,,MIH_N2N_HO_Commit does not allow the option of requesting resource reservation at the HO target. This could become a limiting factor in some cases.,,Yes,Add the option that HO resource reservation can be requested at the recipient of MIH_N2N_HO_Commit.,Agree,Please refer to contribution 21-07-0320-02-0000-Resource_Definition.
3114900023,09/12/2007 02:37:36 EDT,121,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,17,Producer,Disapprove,General,316,,,"Annex M.6 seems redundant and not adding any value, given that similar materials have been covered in the example call flows in Annex H and Information Service examples in",,Yes,remove M.6,Agree,
3114800023,09/12/2007 02:37:36 EDT,120,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,16,Producer,Disapprove,General,282,,,Annex J does not add value to the final spec.,,Yes,"remove Annex J ""Requirements to support 802.21 by L3 and above transport""",Agree,
3114700023,09/12/2007 02:37:36 EDT,119,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,15,Producer,Disapprove,Technical,203,,1,Missing definition must be filled.,,Yes,Define the missing definition,Principle,Delete NETWORK_SECURITY_IE  Can be added later if definition is available
3114600023,09/12/2007 02:37:36 EDT,118,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,14,Producer,Disapprove,Editorial,174,,,The entire Annex B is poorly organized. The grouping is not on a clear and consistent basis.,,No,"Investigate how to re-organize the data type definitions, either on a per-premitive, and/or per-message, and/or per-IE basis?",Agree,
3114500023,09/12/2007 02:37:36 EDT,117,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,13,Producer,Disapprove,Technical,150,8.4.1,60,"MIH Protocol header is of fixed length, as indicated in fig 27 on the next page.",,Yes,correct figure 26 to show MIH Protocol Header has fixed length of 8 octets.,Agree,
3114400023,09/12/2007 02:37:36 EDT,116,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,12,Producer,Disapprove,General,144,8.2.2,,"MIH protocol transaction state diagrams only have some significance when the MIH level ACK mechanism is used. Otherwise, MIH protocol is mostly a transaction-oriented protocol. Since MIH level ACK is optional to use, it may be better to move the state diagram discussion to an annex.",,No,suggest to move 8.2.2 to an annex,Disagree,"Keep it in main body since this is an option, but not something redundant."
3114300023,09/12/2007 02:37:36 EDT,115,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,11,Producer,Disapprove,Technical,124,7.4.24,,MIH_N2N_HO_Commit does not allow the option of requesting resource reservation at the HO target. This could become a limiting factor in some cases.,,Yes,add the option that HO resource reservation can be requested at the recipient of MIH_N2N_HO_Commit.,Agree,Please refer to contribution 21-07-0320-02-0000-Resource_Definition
3114200023,09/12/2007 02:37:36 EDT,114,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,10,Producer,Disapprove,General,87,,,MIH event subscription should allow the subscriber to set certain conditions or qualifiers. With that only events meet those conditions or qualifiers will be notified to the subscriber.,,Yes,investigate if this capability is needed and how to best implement,Principle,"Adopt contribution 21-07-0305-02-0000-Event-Subscribe-Update.doc with the following change: remove the LINK_TYPE from LINK_DETECT_CONFIG, since the Link Identifier parameter already provided the link type."
3114100023,09/12/2007 02:37:36 EDT,113,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,9,Producer,Disapprove,Editorial,51,6.5.4,25,sentence is ambiguous,,No,"Change to ""Functional entities shall discard any received IE with an unrecognizable identifier.""",Agree,
3114000023,09/12/2007 02:37:36 EDT,112,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,8,Producer,Disapprove,Technical,106,,,The Purpose and usefulness of MIH_Net_HO_Candidate_Query command are unclear.,,Yes,remove all definition and mentioning of MIH_Net_HO_Candidate_Query command,Disagree,"The name of these Net_HO commands need to change.    "" The Network controller provides a list of candiddate network choices to MN. The MN indicates resources required on each of these candiddate networks. The Network controller then queries each of the candiddate networks for available resources and reports this information back to the MN. Thereafter the Handover Commit happens""  This explanation needs to be captured and included in draft.  The name of these commands/messages need to be changed as well."
3113900023,09/12/2007 02:37:36 EDT,111,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,7,Producer,Disapprove,General,42,6.4.1,5,Figure 16 is confusing by showing two unrelated stacks.,,Yes,"remove the stack marked as ""Remote Entity"" and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3113800023,09/12/2007 02:37:36 EDT,110,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,6,Producer,Disapprove,Editorial,37,6.3.2,,should be moved after 6.3.3 discussion,,No,move 6.3.2 content to the end or after 6.3.3 discussion.,Agree,
3113700023,09/12/2007 02:37:36 EDT,109,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,5,Producer,Disapprove,Editorial,36,6.3.1,48,repeated statements,,No,"delete ""MIH events may be local or remote. Remote MIH events originate at a remote MIHF. """,Agree,
3113600023,09/12/2007 02:37:36 EDT,108,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,4,Producer,Disapprove,General,36,6.3.1,20,Figure 13 is confusing by showing two unrelated stacks.,,Yes,"remove the stack marked as ""Remote Entity"" and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3113500023,09/12/2007 02:37:36 EDT,107,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,3,Producer,Disapprove,General,33,6.2,,"The concept and procedures for MIHF discovery are only discussed but are not specified in this spec (i.e., no mandatory messages/flows defined for MIHF discovery). This is the right way to do it. Just the text and title in 6.2.3 and 8.2.3.5 may mislead readers otherwise.",,No,De-emphasize MIHF Discovery as separate MIH service management function. Remove 6.2.3 and possibly merge the discussion into general MIH protocol discussion in subclause 8.,Agree,
3113400023,09/12/2007 02:37:36 EDT,106,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,2,Producer,Disapprove,Technical,32,,,"MIH_NMS_SAP defines the interface between an MIHF implementation and a local Network Management System stack. Depending on the nature of the device, this local NMS stack may vary or may not even exist. Standardizing this interface brings no benefit to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NMS_SAP,Agree,This would apply to the entire draft.
3113300023,09/12/2007 02:37:36 EDT,105,"Eastwood, Lester F",les.eastwood@motorola.com,1-847-538-4360,Individual,1,Producer,Disapprove,Technical,31,,,"MIH_NET_SAP defines the interface between an MIHF implementation and various local transport stacks on the same device. However, it is unclear what compatability benefits standardizing this interface will bring to the implementation. In the contrary, it would impose needless constraints to the implementation.",,Yes,remove all definition and mentioning of MIH_NET_SAP,Disagree,MIH_NET_SAP is required.
3113000023,09/11/2007 17:47:21 EDT,104,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,7,Producer,Disapprove,General,282,,,Annex J does not add value to the final spec.,,Yes,Remove Annex J,Agree,
3112900023,09/11/2007 17:47:21 EDT,103,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,6,Producer,Disapprove,Technical,150,8.4.1,60,"MIH Protocol header is of fixed length, as indicated in figure 27.",,Yes,Change figure 26 to show MIH Protocol Header has fixed length of 8 octets.,Agree,
3112800023,09/11/2007 17:47:21 EDT,102,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,5,Producer,Disapprove,Technical,106,,,The Purpose and usefulness of MIH_Net_HO_Candidate_Query command are unclear.,,Yes,Either remove the MIH_Net_HO_Candidate_Query command or better describe its usage.,Disagree,"The name of these Net_HO commands need to change.    "" The Network controller provides a list of candiddate network choices to MN. The MN indicates resources required on each of these candiddate networks. The Network controller then queries each of the candiddate networks for available resources and reports this information back to the MN. Thereafter the Handover Commit happens""  This explanation needs to be captured and included in draft.  The name of these commands/messages need to be changed as well."
3112700023,09/11/2007 17:47:21 EDT,101,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,4,Producer,Disapprove,General,42,6.4.1,5,Figure 16 is confusing. It shows two unrelated stacks.,,Yes,"Remove ""Remote Entity"" stack and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3112600023,09/11/2007 17:47:21 EDT,100,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,3,Producer,Disapprove,General,36,6.3.1,20,Figure 13 is confusing.,,Yes,"Remove ""Remote Entity"" stack and remove text ""Local Entity"" from the stack on the left-hand side.",Agree,
3112500023,09/11/2007 17:47:21 EDT,99,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,2,Producer,Disapprove,Technical,32,,,MIH_NMS_SAP defines the interface between an MIHF implementation and a local Network Management System stack. It imposes constraints to implementations without any clear benefits. The local NMS stack may not even exist depending on the implementation.,,Yes,Remove MIH_NMS_SAP,Agree,
3112400023,09/11/2007 17:47:21 EDT,98,"Noens, Richard H",rick.noens@motorola.com,18475761163,Individual,1,Producer,Disapprove,Technical,31,,,MIH_NET_SAP defines the interface between an MIHF implementation and various local transport stacks on the same device. It imposes constraints to implementations without any clear benefits.,,Yes,Remove MIH_NET_SAP,Disagree,MIH_NET_SAP is required.
3112300023,09/11/2007 17:46:47 EDT,97,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,26,Producer,Disapprove,Technical,192,B.2.7,51,"I do not see a way for a mobile node to use MIIS to determine whether the network supports voice service. The table entry for NETWORK_CAPABILITIES indicates QoS. However, this is not specifying whether QoS is just over the access link--which is insufficient for voice or whether voice service is provided by the network--meaning end-to-end QoS is supported.",,Yes,Clarify the text.,Out of Scope,The QoS is specified for access link and is not end to end.  Specific Application level services are out of the scope.  Vendor Specific IEs can be used to specify this.
3112200023,09/11/2007 17:46:47 EDT,96,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,25,Producer,Disapprove,Technical,72,7.3.11.1,59,"The purpose of this primitive is unclear. The text indicates this event is generated when a ""native link layer or switch decision has been made and its execution is imminent"". This does not make sense to me. If the mobile node's L2 mobility manager can make this decision to go to a new PoA, why must MIH be informed? This is **not** needed for intra-technology handover (as is stated on p73L1-4) since the L2 mobility manager would not handover between networks, only within its current network (otherwise it would risk losing the L3 connection altogether).",,Yes,Remove this primitive or clarify its purpose.,Principle,Please refer to contribution 21-07-0430-00-0000-link-sync-events
3112100023,09/11/2007 17:46:47 EDT,95,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,24,Producer,Disapprove,Technical,71,7.3.9,13,"The text states that a Link_Parameters_Report indicates changes in link parameters that have crossed specific thresholds. However, it is unclear as to when this report is generated and for the purpose it's being generated.
Is this report supposed to be generated whenever link parameters have crossed a threshold even when there may be another PoA in the current network for which the mobile node could perform an L2 transition assuming the PoA would facilitate a link wherein the parameters would not cross the theshold(s)? If so, then the L2 mobility manager in the mobile node should consume this report and it should not be sent up to MIHF.
If the report is supposed to indicate that link parameters have crossed a threshold for the **best** link the mobile node's L2 mobility manager can find thus indicating that MIHF should consider roaming to another network, then that would be an appropriate use of this primitive.",,Yes,Clarify the text.,Principle,The first part of comment pertaining to when the report is generated has been clarified in the draft. (Please refer to TGu draft contribution for MIH mapping 11-07-2604-00-0000u-mac-state-generic-convergence-function-version2).  The second part of comment does not need any further clarification.  (since L2 manager can also be on the netwok side...)  
3112000023,09/11/2007 17:46:47 EDT,94,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,23,Producer,Disapprove,Technical,70,7.3.8,32,"The text states that Link_Detected indicates that a new ""type of link"" has been detected for use. The term ""type of link"" has not been defined and thus the text is unclear. Does ""type of link"" mean a link to a different network, another PoA in the current network, or something else? Hopefully it's referring to a link in a different network.
If it's referring to another PoA in the current network, then the Link_Detected event will be sent to the higher layers constantly (e.g., whenever a new AP is detected in a WLAN). This does not help inter-technology handover.",,Yes,Clarify the text.,Disagree,The type of link is referring to a link from different network.  (Please refer to TGu draft contribution for MIH mapping 11-07-2604-00-0000u-mac-state-generic-convergence-function-version2). Added clarification.
3111900023,09/11/2007 17:46:47 EDT,93,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,22,Producer,Disapprove,Technical,69,7.3.6.3,25,"The text does not state that the link going down notification is delivered when the last possible L2 connection to a specified network is about to be broken. From the definition in the text, a possible interpretation is that a link going down event will be generated whenever an STA makes a transition from 1 AP to another; this is out-of-scope for 802.21 which is facilitating inter-technology and intra-technology (when these are between different networks--e.g., different SSIDs in WLANs) handovers.",,Yes,Clarify the text.,Principle,Refer to TGu draft 
3111800023,09/11/2007 17:46:47 EDT,92,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,21,Producer,Disapprove,Technical,67,7.3.5,64,"The text states that the link down notification is delivered when a L2 connection is broken on the specified link and no more packets may be sent on the specified link. From this definition, it appears that a link down event will be generated whenever an STA makes a transition from 1 AP to another; this is out-of-scope for 802.21 which is facilitating inter-technology and intra-technology (when these are between different networks--e.g., different SSIDs in WLANs) handovers.
The text in 7.3.5.4 also states that this event may be passed to the MIH user which is interested not in L2 transitions, but in handover between networks.",,Yes,Correct the text to state that link down is generated whan all possible L2 links to a given network are down.,Principle,Added clarifying text.  (Please also refer to TGu draft contribution for MIH mapping 11-07-2604-00-0000u-mac-state-generic-convergence-function-version2)
3111700023,09/11/2007 17:46:47 EDT,91,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,20,Producer,Disapprove,Technical,67,7.3.4,17,"The text states that the link up notification is delivered when a layer 2 connection is established on the specified link interface. However, the primitive includes the MAC addresses of the access router, IPRenewal flag and Mobility Management Support. The latter two parameters are clearly above L2 and the L2 link up may not even know about them. The term access router is not defined, but if it is the default gateway (router), then the L2 link up indication would not know about it either.",,Yes,"Define the link up primitive such that it is a L2 primitive that only includes L2 parameters or as an L3 primitive with L3 parameters (ie., provide layer separation).",Disagree,These two parameters are optional and links which dont support these parameters can ignore these.
3111600023,09/11/2007 17:46:47 EDT,90,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,19,Producer,Disapprove,Technical,53,6.5.5.2,25,The contents of PoA System Information IE are not defined within the 802.21 specification.,,Yes,Remove the IE or add the definition.,Disagree,The definition is already in there (page 193 in draft D7.1)
3111500023,09/11/2007 17:46:47 EDT,89,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,18,Producer,Disapprove,Technical,53,6.5.5.2,25,The PoA channel range is an important characteristic of the network and should be included in the TYPE_IE_CONTAINER_NETWORK.,,Yes,Move or add this information into TYPE_IE_CONTAINER_NETWORK.,Principle,Added the channel range parameter from Network level to PoA level as well in the Table  
3111400023,09/11/2007 17:46:47 EDT,88,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,17,Producer,Disapprove,Technical,53,6.5.5.2,25,"The location used in the information model is for the PoA. For 802.11 networks this is not the correct information for the following reasons:
1. The mobile node should not care about the location of the PoA. The mobile should only care about whether RF coverage is obtainable at a specific location.
2. Many operators will be unwilling to provide actual location (e.g., latitude and longitude) for a PoA. As such, there will be no location information in many MIIS databases.",,Yes,Delete the PoA location.,Disagree,PoA location is essential to determining the availabiility of coverage in an area.  If an operator is not willing to provide this information they can just include NULLs.    
3111300023,09/11/2007 17:46:47 EDT,87,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,16,Producer,Disapprove,Technical,53,6.5.5.2,25,Why does the mobile node need to know the IP address of the PoA? Should this be the IP address of the PoS? I can understand why the IP address of the PoS is useful--it's the peer entity of the MIHF in the MN.,,Yes,Change to IP address of PoS.,Agree,Done as suggested
3111200023,09/11/2007 17:46:47 EDT,86,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,15,Producer,Disapprove,Technical,53,6.5.5.2,25,"The PoA Container does not need to contain the PoA MAC address (at least for 802.11 networks). This is easily obtained using WLAN primitives given the mobile node knows the desired network. Since it is not needed, it is just extra information to get out of sync between the access network and the MIIS.",,Yes,Delete the PoA MAC address.,Disagree,The idea was to obtain this information before making the radio connection.   Once the radio connection has been made this information can be esaily obtained.
3111100023,09/11/2007 17:46:47 EDT,85,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,14,Producer,Disapprove,Technical,52,6.5.5.2,48,"There should be a way to indicate that the network itself is mobile. For example, consider a network on a ship, airplane or bus.",,Yes,Add this capability.,Disagree,The use case for this is not clear. How would the user use this information?
3111000023,09/11/2007 17:46:47 EDT,84,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,13,Producer,Disapprove,Technical,52,6.5.5.2,48,The TYPE_IE_CONTAINER_NETWORK should contain the means to discover the country and regulatory domain in which the network is operating.,,Yes,Add this capability.,Principle,Added another IE for this.
3110900023,09/11/2007 17:46:47 EDT,83,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,12,Producer,Disapprove,Technical,52,6.5.5.2,48,The TYPE_IE_CONTAINER_NETWORK should contain the means to discover the 802.11u HESSID.,,Yes,Add this capability.,Principle,Added the capability as per  TGu draft contribution for MIH mapping 11-07-2604-00-0000u-mac-state-generic-convergence-function-version2
3110800023,09/11/2007 17:46:47 EDT,82,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,11,Producer,Disapprove,Technical,52,6.5.5.2,48,"The TYPE_IE_CONTAINER_NETWORK should contain the means to discover the frequency bands supported by the network (e.g., 2.4-GHz, 3.7-GHz, 2.5-GHz, 5.2-GHz, etc.)",,Yes,Add this capability.,Disagree,The capability already exists in draft in Table B-13.
3110700023,09/11/2007 17:46:47 EDT,81,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,10,Producer,Disapprove,Technical,52,6.5.5.2,48,"The TYPE_IE_CONTAINER_NETWORK should contain means to discover the location of the network (or more specifically, the RF coverage of the network).",,Yes,Add this capability.,Disagree,This can be determined from the PoA location. It is very difficult to determine the RF coverage area and be able to represent it accurately.
3110600023,09/11/2007 17:46:47 EDT,80,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,9,Producer,Disapprove,Technical,50,6.5.3,1,"The location used in the information model is for the PoA. For 802.11 networks this is not the correct information for the following reasons:
1. The mobile node should not care about the location of the PoA. The mobile should only care about whether RF coverage is obtainable at a specific location.
2. Many operators will be unwilling to provide actual location (e.g., latitude and longitude) for a PoA. As such, there will be no location information in many MIIS databases.",,Yes,"Change the location information such that it is providing the RF coverage area of the network and not the location of specific PoAs.
Note that this is not just a comment about Figure 19, but has ramifications for other clauses in the document.",Disagree,PoA location is essential to determining the availabiility of coverage in an area.  If an operator is not willing to provide this information they can just include NULLs.
3110500023,09/11/2007 17:46:47 EDT,79,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,8,Producer,Disapprove,Technical,50,6.5.3,1,The information model proposed in Figure 19 is overly complicated as far as 802.11 networks go.,,Yes,,Disagree,The group feels that the model is not so complicated. Please suggest ways of simplification
3110400023,09/11/2007 17:46:47 EDT,78,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,7,Producer,Disapprove,Technical,44,6.4.3.1.1,10,"This comment applies to this clause as well as to the document in general. The text describes the following:
1. MIH_Get_Link_Parameters: get the status of a link.
2. MIH_Configure_Link: configure a link.
3. MIH_Net_HO_Candidate_Query: Network may initiate handover and send a list of suggested networks and ...
The text continually switches between the terms ""link"" and ""network"". The scope of MIH is roaming between ""networks"", whether it is inter-technology or intra-technology (e.g., roaming between two different WLANs having different SSIDs). Roaming within a network is an L2 event and is outside the scope of 802.21--yet the text continually refers to ""links""--which is a connection to a single PoA, not a ""connection"" to a network. Thus the text is confusing and misleading--the reader cannot determine what 802.21 is really trying to accomplish.",,Yes,"Use the terms ""link"" and ""network"" precisely throughout the document.",Disagree,"In the document, the term ""link"" refers to a logical connection between the MN and an access network. When instantiated to a ""real"" link, it mapps to the connection between the MN and a PoA of the access network. The term ""network"" refers to an access network. The document is  consistent on this usage."
3110300023,09/11/2007 17:46:47 EDT,77,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,6,Producer,Disapprove,Technical,26,5.5.3,39,"The text states, ""...before a station has associated and authenticated with an AP, whereas the LSAP may ..."". Chronologically, a STA authenticates before it associates.",,Yes,Switch the order of associate and authenticate in the referenced text.,Agree,Done as suggested
3110200023,09/11/2007 17:46:47 EDT,76,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,5,Producer,Disapprove,Technical,26,5.5.3,1,"The reference model for 802.11 is incorrect. The model shows that MIHF is connected to the MLME SAP. In 802.11, primitives are provided to the SME and the MIHF should have its interface to the SME. The SME is responsible for layer 2 transition between APs and should not provide, for example, a link-down indication everytime the STA re-associates to a new AP. Rather the MIHF should only receive a link-down indication when the STA become disassociated from the ESS (or is about to become disassociated from the ESS). This is because MIH is concerned about roaming between networks and NOT L2 transition.",,Yes,Correct the figure and the resulting reference model text.,Principle,Incorporate the new reference diagram from  the draft contribution for MIH mapping 11-07-2604-00-0000u-mac-state-generic-convergence-function-version2.
3110100023,09/11/2007 17:46:47 EDT,75,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,4,Producer,Disapprove,Technical,6,3,57,"The text states the definition of link switch as, ""The process by which a mobile node changes the link that connects it to the network. Changing link implies changing the remote link endpoint and therefore the point of attachment of the mobile node.""
By definition, this is out-of-scope for 802.21; from the 802.21-PAR: ""This standard defines extensible 802 media access independent mechanisms that enable the optimization of handover between heterogeneous 802 systems and may facilitate handover between 802 systems and cellular systems"". Link switch that takes place between PoAs in the same access network is thus out-of-scope.
The definition of handover (definition 3.3) is based on this definition of link switch.",,Yes,Change the definition to be consistent with the 802.21 PAR.,Disagree,"The definition of a term (link switch, handover) in this section does NOT define the scope of the standard.   802.21 primarily deals with vertical handovers and not horizontal handovers.  For description of scope of this standard please refer to clause 1.1 and 1.3 (second paragraph)"
3110000023,09/11/2007 17:46:47 EDT,74,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,3,Producer,Disapprove,Technical,3,1.3,1,"The figure caption indicates that ""Figure 1 shows the placement of the MIHF within the mobility management protocol stack of an MN or network entity"". However, the protocols listed upper layers are not mobility management protocols. The intent of the figure (based on the caption) appears to be to describe the control plane, but the figure itself describes the data plane.",,Yes,"Clarify the figure or the caption. If the caption is clarified, then a figure should be added which shows the mobility management architecture that 802.21 specification is based upon.",Principle,"""Figure 1 shows the placement of the MIHF within the mobility management protocol stack of an MN or network  entity."" Removed Mobility Management from the above sentence."
3109900023,09/11/2007 17:46:47 EDT,73,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,2,Producer,Disapprove,Technical,,General,,I do not see a way for the network to command a mobile node to power up or down a specific radio interface.,,Yes,Add this capability.,Disagree,"The MIH_Link_Actions (page 102, sub clause 7.4.17 draft D7.1 ) primitive in the current draft provides this capability."
3109800023,09/11/2007 17:46:47 EDT,72,"Myles, Andrew F",andrew.myles@cisco.com,+61 2 94407860,Individual,1,Producer,Disapprove,Technical,,General,,"I do not see a way for the network to query a mobile node to determine what radios it has present (e.g, GSM, 802.11) and whether or not they are powered up.",,Yes,Add this capability.,Disagree,"The MIH_Get_Link_Parameters primitive in the draft (pg 98, subclause 7.4.15, draft D7.1) addresses this.  If you invoke MIH_Get_Link_Parameters with no link identifier, it shall return back the available links on the MN.  You can then query the power up state of each individual link."
3106700023,09/11/2007 12:03:15 EDT,71,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,9,Producer,Approve,Editorial,268,H.7.1,9,"Insert ""The"" before ""Following handover flow refers..."" (not proper English).",,No,"Change to ""The following handover flow refers...""",Agree,
3106600023,09/11/2007 12:01:48 EDT,70,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,8,Producer,Approve,Editorial,198,B.2.9,13,"""if a container is listed..."" should be capitalized to match the other list items.",,No,"Change to ""If a container is listed...""",Agree,
3106500023,09/11/2007 11:59:47 EDT,69,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,7,Producer,Approve,Editorial,164,8.2.2,50,"Insert ""The"" before ""Following conventions are used..."" (not proper English).",,No,"Change ""The following conventions are used...""",Agree,
3106400023,09/11/2007 11:58:02 EDT,68,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,6,Producer,Approve,Editorial,71,7.3.9.1,14,"There's a period missing at the end of ""...for various parameters"".",,No,"Change to ""...for various parameters.""",Agree,
3106300023,09/11/2007 11:56:53 EDT,67,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,5,Producer,Approve,Editorial,67,7.3.5.1,65,"There's a period missing at the end of ""...on the specified link"".",,No,"Change to ""...on the specified link.""",Agree,
3106200023,09/11/2007 11:55:31 EDT,66,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,4,Producer,Approve,Editorial,32,5.7.2,33,"There's an extra period at the beginning of "".There are two kinds of transport..."".",,No,"Change to ""There are two kinds of transport...""",Agree,
3106100023,09/11/2007 11:53:29 EDT,65,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,3,Producer,Approve,Editorial,16,5.2.3.5,22,"There's a period missing at the end of ""...layer 3 handover"".",,No,"Change to ""...layer 3 handover.""",Agree,
3106000023,09/11/2007 11:51:13 EDT,64,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,2,Producer,Approve,Editorial,11,4,14,"""Network management system"" should be capitalized to match the other acronyms.",,No,"Change to ""Network Management System"".",Agree,
3105900023,09/11/2007 11:49:56 EDT,63,"Heubaum, Karl F",kheubaum@yahoo.com,5123015385,Individual,1,Producer,Approve,Editorial,3,,35,"(note this refers to page iii, line 35) ""Michael HogHooghi"" should be spelled ""Michael Hoghooghi"" (he's a former co-worker).",,No,"Change to ""Michael Hoghooghi"".",Agree,
3104200023,09/10/2007 15:30:09 EDT,62,"Kiernan, Brian G",brian.kiernan@interdigital.com,610 878-5637,Individual,1,Producer,Approve,General,292,Annex L,24,"The stated scope and purpose of 802.21 is to define extensible media access independent mechanisms to facilitate handovers between and among IEEE 802 systems as well as certain external systems. This document only partially addresses that stated purpose. For example, the informative Annex L specifically identifies the need for certain amendments to several IEEE 802 technologies. These recommended amendments are identified by contribution numbers and, as such, may not be readily available to the Standards user, nor is there any indication that these proposed amendments have actually been adopted by the specific technology, therefore calling into question both the viability of and the ability to implement the proposed 802.21 standard.",,No,"The annex should be made Normative and the specific suggested changes for each identified technology should be detailed in the Annex. Action should be taken by the 802.21 WG to get these amendments included in the respective technology standards, preferably before publication of the 802.21 standard.",Principle,The annex has been made normative and changes for different technologies have been added. Changes to other technology standards is dependent on those standards and their own individual timelines.
3099200023,09/10/2007 07:08:58 EDT,61,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,35,Academic,Disapprove,Technical,280,Annex I,3,Why is this annex only informative. Doesn't the standard provide normative information which message can be exchanged via which reference point?q,,No,make annex normative,Agree,Done as suggested
3099100023,09/10/2007 07:08:58 EDT,60,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,34,Academic,Disapprove,Technical,148,8.2.3.1,24,"Table 14: IP is not a transport protocol. Simply stating that one should use an IP-based transport is to unspecific as it allows to use any (even a self-written, non standardized) transport protocol to be used. Be more specific regarding allowable transport protocols or be precise and state that an IP-based network architecture is assumed. But in the latter case, the title of the third column is not correct.",,Yes,Clarify or rephrase / be more precise.,Principle,Remove section 8.2.3.1
3099000023,09/10/2007 07:08:58 EDT,59,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,33,Academic,Disapprove,Technical,148,8.2.3.1,24,Clause includes media-spefic mappings but should not do so. Simply state that transport options for various technologies are defined in Annex xxx. Include one Annex per technology.,,Yes,Delete Table 14 and move contents to media specfic annex,Principle,Remove section 8.2.3.1
3098900023,09/10/2007 07:08:58 EDT,58,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,32,Academic,Disapprove,Technical,147,8.2.2.3,40,Text states that max. 2 retransmissions are allowed but the state machine does reflect this,,Yes,Adjust state machine.,Agree,Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3098800023,09/10/2007 07:08:58 EDT,57,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,31,Academic,Disapprove,Technical,146,8.2.2.2,54,Text states that max. 2 retransmissions are allowed but the state machine does reflect this,,Yes,Adjust state machine.,Agree,Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3098700023,09/10/2007 07:08:58 EDT,56,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,30,Academic,Disapprove,Technical,145,8.2.2.1,34,The text states a transition from SENDING to INIT after two (unsuccessful) retransmission but the state machine does not reflect this.,,Yes,Adjust state machine.,Agree,Please refer to contribution 21-07-0302-01-0000-StateMachineSBComments
3098600023,09/10/2007 07:08:58 EDT,55,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,29,Academic,Disapprove,Technical,61,7.2.2.2,41,"There are two media-dependent SAPs, i.e.: MIH_LINK_SAP and MIH_NET_SAP. Annex L provides a mapping of the associated service primitives to a set of technologies, but only for MIH_LINK_SAP. Why is there no corresponding mapping for MIH_NET_SAP ?",,Yes,"If a mapping of 802.21 service primitives to a specific technology is provided, it should be complete. Either delete all references to a specific technology until a complete mapping is done by the corresponding group (and then add a corresponding annex as an amandment to 802.21) or indicate that there is no mapping for certain service primitives.",Principle,The MIH_NET_SAP is not media dependent. Hence there is no mapping required between MIH_NET SAP and other media specific technology.
3098500023,09/10/2007 07:08:58 EDT,54,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,28,Academic,Disapprove,Editorial,60,7.2.2.1,58,Rows should be grouped / sorted by service category.,,Yes,Re-order rows of Table 10,Agree,
3098400023,09/10/2007 07:08:58 EDT,53,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,27,Academic,Disapprove,Technical,60,7.2.2.1,53,Keep the main part of the standard technology independent and do not reference all / a range of tables in Annex L for technology specific mapping. Simply say that such a mapping is found in Annex L.,,Yes,"Replace this paragraph with: ""The primitives defined as part of the MIH_LINK_SAP are described in Table10. Annex L contains their mapping to several specific link technologies. """,Agree,
3098300023,09/10/2007 07:08:58 EDT,52,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,26,Academic,Disapprove,Technical,59,7.1,15,"items a) through e) contain a mapping of the MIH_LINK_SAP to media-dependent / technology specific SAPs. There are two issues with this. First, such a mapping of 802.21 functionality to a specific technology is very beneficial but should be included in a (possible normative) Annex. Second, such a mapping should be structured by ""technology"" and not by the name of the SAPs.",,Yes,Delete items a) through e) and move their contents to a (normative) Annex. There should be one Annex per technology containing any technology-specific information which is reqired to make 802.21 work with / adapt to the specific technology.,Agree,Move items [a] through [e] to Annex-L.  Make Annex-L normative.
3098200023,09/10/2007 07:08:58 EDT,51,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,25,Academic,Disapprove,Technical,49,6.5.3,17,Emphasize that this is only an example,,Yes,"Start paragraph with: ""As an example, Figure 19 shows ....""",Agree,
3098100023,09/10/2007 07:08:58 EDT,50,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,24,Academic,Disapprove,Technical,48,6.5.3,13,"Ref. to table 8, access-network-aux-id: The table sould not contain any mandatory values for a technologie, i.e. that this IE shall contain the SSID for an 802.11 network. Nevertheless, it is a good idea to have such information somewhere but a normative annex (one for each considered technology) which contains such mandatroy values would be better. Having this, the main chapters of the standard are kept technology-independent and the reader has a single point where technology specific values for certain parameter or IEs are assumed. Besides, if a (new) technology supports 802.21 in the future by adding new service primitives / functionality, there is only a single place in the 802.21 standard which need to be revised.",,Yes,Delete ref to 802.11 and create an annex as suggested,Principle,"This is just an example.  Change text: ""As an example for IEEE 802.11 this refers to the SSID"""
3098000023,09/10/2007 07:08:58 EDT,49,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,23,Academic,Disapprove,Technical,41,6.4.1,59,"""Whenever applicable the IEEE 802.21 standard shall use existing media-specific link commands for interaction with specific access networks. New link commands, if required, shall be defined as recommendations to link
layer technology standards."" This sentence introduces a media-dependent (!) aspect of 802.21 even though .21 shoulde be media-independent. 802.21 should define ""generic"" link-commands as it does e.g. in table 7. The adaption of such genric commands to the actual technology should be done by the working group responsible for the specific technology ... and of course one should use existing commands for this.",,Yes,delete the sentences,Principle,"  Change sentences to as follows:  ""Whenever applicable the IEEE 802.21 standard encourages use of existing media-specific link commands for interaction with specific access networks. New link commands, if required, are defined as recommendations to different link layer technology standards."""
3097900023,09/10/2007 07:08:58 EDT,48,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,22,Academic,Disapprove,Editorial,40,6.3.5,41,Would be nice to have the MIH events in Table 4 ordered according / sorted by their type. Order of types should be according to items / paragraphs 1) through 5) of this section 6.3.4.1,,No,reorder table entires,Agree,
3097800023,09/10/2007 07:08:58 EDT,47,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,21,Academic,Disapprove,Editorial,39,6.3.4.1,50,Would be nice to have the link events in Table 3 ordered according / sorted by their type. Order of types should be according to items / paragraphs 1) through 5) of this section,,No,reorder table entires,Agree,
3097700023,09/10/2007 07:08:58 EDT,46,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,20,Academic,Disapprove,Editorial,33,6.2.2,45,"Final layout by IEEE editorial team will result in tables to ""float"".",,No,"Replace ""The following set of service primites"" with ""The set of service primitves listed in Table 2 ....""",Agree,
3097600023,09/10/2007 07:08:58 EDT,45,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,19,Academic,Disapprove,Technical,32,5.7.2,41,"The three items make a normative assumtion or even standardize how MIH messages should be carried via a SPECIFIC technology. This is not within the scope of the standard. Apart from this, listing only a few technologies includes always the danger of missing other current or upcoming technologies. The nice thing about .21 is its technology independence.",,Yes,Delete the three items or (preferably) move them to an informative annex.,Agree,
3097500023,09/10/2007 07:08:58 EDT,44,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,18,Academic,Disapprove,Editorial,32,5.7.2,33,Sentence starts with a period (.).,,No,Delete leading period,Agree,
3097400023,09/10/2007 07:08:58 EDT,43,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,17,Academic,Disapprove,Technical,31,5.6.2.6,41,There is no need to make an exception for 3GPP and 3GPP2 and specify for this technology a speperate SAP. The correct interface would be MIH_LINK_SAP.,,Yes,Delete section 5.6.2.6,Principle,Do not delete this section.  Please make changes as per contribution 21-07-0414-02-0000-3GSAP  
3097300023,09/10/2007 07:08:58 EDT,42,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,16,Academic,Disapprove,Technical,30,5.6.1,1,Fig 11 conflicts with Figures 9 and 10 for 3GPP and 3GPP2. Fig 11 correctly includes the MIH_LINK_SAP whereas the latter two illustrate an MIH_3GLINK_SAP,,Yes,Change Fig. 9 and 10,Principle,Please refer to contribution 414-02
3097200023,09/10/2007 07:08:58 EDT,41,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,15,Academic,Disapprove,Technical,25,5.5.2,1,"Applies to all technology specific reference models (up to 5.5.5): As the adaption of the MIH functionality to a specific technology is not within the scope of 802.21, these subclauses should be moved into an informational annex. A normative reference model should be defined by the by the corresponding group responsible for the underlying technology.",,Yes,,Disagree,""" As the adaption of the MIH functionality to a specific technology is not within the scope of 802.21""    The adoption part is not within scope of 802.21.   But 802.21 needs to specify what is the normative way for these standard technologies to interface with 802.2 1 and this needs to be included in a normative way in the current specification.  "
3097100023,09/10/2007 07:08:58 EDT,40,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,14,Academic,Disapprove,Technical,27,5.5.5,45,"The actual adaptation of the MIH_LINK_SAP was previously stated not to be within the scope of 802.21 but within the scope of the underlying technology. Nevertheless, Section 5.5.5 introduces MIH_3GLINK_SAP as an MIH specific SAP which is also the case for Fig. 9 in which the SAP is gray shaded and hence illustrated to be part of 802.21.",,Yes,"Use the name MIH_LINK_SAP. Possibly include any ""adaptation"" layer / SAP and state (if appropriate) that no additional protocol enhancements are required but that existing service primitves can directly mapped to the MIH_LINK_SAP.",Principle,Please refer to contribution 414-02  
3097000023,09/10/2007 07:08:58 EDT,39,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,13,Academic,Disapprove,Technical,27,5.5.4,37,C_SAP and M_SAP provide services defined by MIH_LINK_SAP but the MIH_LINK_SAP is not illustrated in Fig. 8,,Yes,Include MIH_LINK_SAP in Fig. 8,Disagree,Figure 8 is an 802.16 SAP diagram.  MIH_LINK_SAP is an abstract SAP and it maps to C_SAP and M_SAP in case of 802.16 network.  There is no need to show MIH_LINK_SAP in this figure.
3096900023,09/10/2007 07:08:58 EDT,38,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,12,Academic,Disapprove,Technical,21,5.4.3,2,Figure 3 alludes that MIH Reference points do not exist accross the Internet but only within coupled operator networks.,,Yes,"include, e.g., an operator-4 core which is connected to the internet and label the arrows to/from the internet cloud with corresponding reference points.",Disagree,Figure -3 is just an illustrative example and it's quite difficult to include the above suggestion in this example.  This example has no bearing on other deployment scenarios (which may include MIH Ref Points going across the internet).  
3096800023,09/10/2007 07:08:58 EDT,37,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,11,Academic,Disapprove,Editorial,17,5.3.4,36,missing comma after last word in line,,No,"""and its representation,""",Agree,
3096700023,09/10/2007 07:08:58 EDT,36,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,10,Academic,Disapprove,Editorial,17,5.3.4,32,incoherent usage of singular or plural,,No,"either: ""A user and network policy"" or ""user and network POLICIES""",Agree,
3096600023,09/10/2007 07:08:58 EDT,35,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,9,Academic,Disapprove,Technical,13,5.1.4,1,"Section 1.3 states that HO policies are not within the scope of 802.21. Given so, why have MIH services to consider network traffic performance and how well they meet the application's need. This evaluation is part of the ""handover decision making entity"" and the MIH services to do, as far as I understand, only provide input to such an entity.",,Yes,Clarify or rephrase paragraph,Agree,"Delete:    ""The MIH services defined by the IEEE 802.21 standard, including event, command, and information services,  need to consider network traffic performance objectives and how well they meet the application quality  of service requirements."""
3096500023,09/10/2007 07:08:58 EDT,34,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,8,Academic,Disapprove,Editorial,12,5.1.4,64,missing comma,,No,"insert a comma after networks: "".... target networks, in order ...""",Agree,
3096400023,09/10/2007 07:08:58 EDT,33,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,7,Academic,Disapprove,Technical,12,5.1.2,27,"sentence defines ""service continuity"" but the definition is not aligned with 3.43",,Yes,Align definition or do not re-define it in this paragraph,Agree,Delete clause 3.43
3096300023,09/10/2007 07:08:58 EDT,32,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,6,Academic,Disapprove,Technical,12,5.1.1,15,"handover decision making does not always require both, mobile node and network infrastructure",,Yes,"insert ""may"": .... decision making MAY involve ...",Agree,
3096200023,09/10/2007 07:08:58 EDT,31,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,5,Academic,Disapprove,Editorial,12,5.1.1,10,"incoherent usage of ""single"" vs ""double"" quotation marks",,No,"replace 'hard' / 'soft' by ""hard"" / ""soft""",Agree,
3096100023,09/10/2007 07:08:58 EDT,30,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,4,Academic,Disapprove,Technical,6,3.8,37,"there are two definitionf for the same thing: a/ ""higher layers"" and b/ ""MIH Users""",,Yes,"There might be ""higer layers"" which do not use the MIH functionality. Therefore, delete the definition of higher layers and include the aspects of the higher layer definition in the definition of MIH users, i.e. state there that MIH users can also be those higher (protocol) layers which use MIH functionality",Agree,Remove the definition of higher layers.
3096000023,09/10/2007 07:08:58 EDT,29,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,3,Academic,Disapprove,Editorial,7,3.18,15,"use correct plural of MN, i.e.: MNs",,No,"delete apostrohpe ""MN's""",Agree,
3095900023,09/10/2007 07:08:58 EDT,28,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,2,Academic,Disapprove,Editorial,6,3.14,59,"singular or plural should be used (""changing link implies ..."")",,No,"Change either to ""changing A LINK implies"" or to ""changing LINKS implies""",Agree,
3095800023,09/10/2007 07:08:58 EDT,27,"Emmelmann, Marc",emmelmann@ieee.org,+49 -- 30 -- 314 24580,Individual,1,Academic,Disapprove,Editorial,6,3.8,38,"no capitalization of ""internet protocoel (IP)""",,No,"change to: ""Internet Protocol (IP)""",Agree,
3093600023,09/06/2007 13:47:55 EDT,26,"Zeira, Eldad",eldad.zeira@interdigital.com,16316224134,Individual,1,Producer,Disapprove,Technical,304,Annex K,,Annex K is informative and does not enforce uniform mapping of QOS parameters by different vendors. Preventing unpredictable behavior will require vendor - specific solutions which will complicate testing and delay market acceptability.,,Yes,Tables K-1 and K-2 and the corresponding text in annex-K should be completed to allow clear and uniform interpretation and be made mandatory.,Disagree,The mapping of QoS parameters does not relate to behavior prediction.   Measurement examples provided by Annex K have nothing to do with interoperability. There different methods for using MAC layer measurements and making inferences on the current quality of service conditions as seen by the device.  Annex K examples cannot be made mandatory since measurements provided by specs like 11k are not mandatory
3089000023,09/04/2007 16:19:39 EDT,25,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,9,Government/Military,Disapprove,Editorial,50,,,"In the list of PoA on the bottom right, the first element should state Operator_2, not Operator_1",,No,,Agree,
3088900023,09/04/2007 16:19:39 EDT,24,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,8,Government/Military,Disapprove,Editorial,187,,34,COS_ID is valid between 0-255 therefore it needs to be set as UNSIGNED_INT(1).,,No,,Agree,
3088800023,09/04/2007 16:19:39 EDT,23,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,7,Government/Military,Disapprove,Editorial,182,,57,Battery level is a percentage and should use the PERCENTAGE type,,No,,Disagree,"PERCENTAGE type won't be able to represent ""-1"" special case."
3088700023,09/04/2007 16:19:39 EDT,22,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,6,Government/Military,Disapprove,Editorial,121,,43,typo,,No,replace LINK_ACTIONS w/ LINK_ACTION,Agree,
3088600023,09/04/2007 16:19:39 EDT,21,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,5,Government/Military,Disapprove,Technical,118,,,The parameters in the primitives cannot be filled properly upon receiving an MIH_Link_Detected. MIH_Link_Detected provides the Link identifier (LINK_TUPLE_ID) of the detected link. The PoA indicated is the detected PoA.It does not provides the current link identifier,,No,Include current link identifier in the commit request and use the information from the link detected for the targetPoA.,Agree,
3088500023,09/04/2007 16:19:39 EDT,20,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,4,Government/Military,Disapprove,Technical,118,,,The parameter TargetPoA does not have a proper type in the request and indication primitives. TargetPoA is defined as LINK ID but the definition of LINK ID is to contain the address of an MN only.,,Yes,Update the definition of LINK ID to indicate that the link address could be the address of an MN or a PoA,Principle,Use LINK_TUPLE_Id instead
3088400023,09/04/2007 16:19:39 EDT,19,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,3,Government/Military,Disapprove,Editorial,102,,17,typo,,No,change LINK_SACN to LINK_SCAN,Agree,
3088300023,09/04/2007 16:19:39 EDT,18,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,2,Government/Military,Disapprove,Technical,102,,,"the request for the MIH_Link_Action does not allow to set actions for multiple links. The request contains the LinkActionsList parameter of type LINK_ACTION_REQ. Both the variable name and the description suggest that multiple links can be controlled. However the response contains Link Actions Response of type Link Actions Response which is not a list. Also, the Scan Response Set contains a list of MAC address and signal strength. This has to be linked to the link_id specified in the Link Actions Response.",,Yes,Change the types to list for action request and response. Include Scan response as part of the action response.,Agree,
3088200023,09/04/2007 16:19:39 EDT,17,"Golmie, Nada",nada.golmie@nist.gov,301 975 4190,Individual,1,Government/Military,Disapprove,Technical,98,,,"The request contains DeviceStatesRequest parameter of type DEVICE_STATES_REQ. The type is a bitmap allowing to request different state information. However the response contains Device States Response List of type DEVICE_STATES_RSP. The type is a choice, thus containing only one element",,Yes,"Define Device States Response List as
LIST (DEVICE_STATES_RSP)
",Agree,
3088000023,09/03/2007 16:49:33 EDT,16,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,8,General Interest,Disapprove,Technical,149,8.2.3.4,16,"The MIH protocol relies on the underlying mechanisms (I.e., the lower layers) to provide fragmentation and reassembly. However, many such underlying technologies do not provide this function, e.g. IEEE 802.3.",,Yes,"If fragmentation/reassembly is needed for proper operation of MIH, then it must be provided as a function within the protocol. If not, then eliminate all references to fragmentation, and ensure that the maximum message size (SDU) submitted by MIH to any allowable lower layer does not exceed the maximum frame size supported by those layers (i.e., determine an acceptable maximum SDU that will work with any allowable MAC).",Principle,"Change  ""  In all cases, the MIH protocol relies on the underlying transport mechanism to provide fragmentation and  reassembly services.  ""    to  ""MIH Protocol does not provide fragmentation and reassembly services""  "
3087900023,09/03/2007 16:49:33 EDT,15,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,7,General Interest,Disapprove,Technical,143,8.1,16,"The text states that the MIHF demands that the service management procedures of Clause 6 be performed prior to initiating any MIH protocol procedures. However, there are no conformance requirements in Clause 6 for these ""service management procedures"", I.e., no statement of exactly what procedures *shall* be implemented by a conformant device. Thus, the service management requirement is ambiguous.",,Yes,"Include a formal specification of the required service management procedures, either here or in Clause 6. Include a PICS proforma for these procedures, to ensure that all necessary functions are properly implemented.",Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3087800023,09/03/2007 16:49:33 EDT,14,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,6,General Interest,Disapprove,Editorial,3,1.4,50,"The text states that the definition of MIHF has no implications on the way the function is implemented. This is clearly not true; if it is, then the definition is irrelevant.",,No,Correct the text.,Agree,"Changed to:   ""The MIHF is a logical entity, whose definition is independent of its deployment location which may be on the mobile node or in the network"""
3087700023,09/03/2007 16:49:33 EDT,13,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,5,General Interest,Disapprove,Technical,3,1.3,31,"Figure 1 gives examples of upper layers (IP, etc.) and lower layers (802.3, etc.) but does not show where LLC fits into the architecture.",,Yes,"Indicate the architectural placement of the MIH Function with respect to LLC (I.e., is it above or below LLC). Adjust the text to correspond to the new figure.",Disagree,"LLC is specifically an IEEE 802 entity and it is valid only for IEEE 802 technologies and is not applicable for other technologies such as 3GPP/3GPP2. Hence it is not shown in this figure, but is shown in other figures for other specific link layer technologies that it is valid for in section 5 (figures 6, 7 etc.)"
3087600023,09/03/2007 16:49:33 EDT,12,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,4,General Interest,Disapprove,Technical,59,7,,"In numerous places in this clause, conformance requirements (I.e. ""shall"" statements) are given, for example, on page 54, line 62, subclause 7.3.1.2.4. Clause 7 is a *service specification*, not a protocol specification. It defines a set of abstract primitives used by layer entities within a given device to intercommunicate. Internal implementation details are not a proper subject for the conformance requirements of a standard. It is not necessary for a conformant device to use internal layering as defined in this (or any) standard; indeed, there may not be any defined or exposed interfaces corresponding to the service primitives defined here. Thus, while this clause may be useful in defining the information manipulated within a system, conformance to this clause is not necessary for interoperability.",,Yes,"Delete all ""shall"" statements and conformance requirements for this clause and all service specifications.",Disagree,"The term, ""shall"", as per the IEEE Standards Style Manual (Dated January, 2007) clause 13.1, is used properly.  The 802.21 protocol requires interaction with entities (e.g. above and below) through service access points (SAP).  To accomplish this requirements on behavior must be specified.   The use of the words, shall, are necessary to describe this behavior.  There are no requirements placed on the implementation of the SAP or coding of the information as is the current practice within the IEEE 802."
3087500023,09/03/2007 16:49:33 EDT,11,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,3,General Interest,Disapprove,Technical,143,8,,"The MIH protocol is inadequately specified. In particular, the state machine is overly simplified, and none of the state variables are rigorously or formally defined.",,Yes,"Include a formal specification of the MIH protocol, either as a completely defined state machine (in the manner of IEEE 802.3), a reference code specification (in the manner of IEEE 802.1), or a formalized language (in the manner of IEEE 802.11).",Agree,Please see contributon 21-07-0302-00-0000
3087400023,09/03/2007 16:49:33 EDT,10,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,2,General Interest,Disapprove,Technical,143,8,,No conformance requirements are provided for this protocol.,,Yes,Include a PICS proforma for this clause.,Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3087300023,09/03/2007 16:49:33 EDT,9,"Seifert, Rich",rich@richseifert.com,408-395-5700,Individual,1,General Interest,Disapprove,Technical,143,8,,"This clause purportedly specifies a protocol, yet there are no conformance requirements specified. In particular, there is no statement anywhere that the given state machine *shall* be implemented, or that messages exchanged *shall* conform to the formats provided.",,Yes,"Provide a requirement that the protocol be implemented, together with a list of specific conformance behaviors for the protocol.",Disagree,"A Protocol Implementation Conformance Statement (PICS) Proforma cannot contain any information that is not already present in   normative text.  Therefore including a PICS Proforma would be redundant.  Duplication of information within a standard has a   tendency to cause inconsistencies.   A PICS Proforma covers only conformance, not interoperability.  Clause 8 describes the formats of messages used to exchange information.  The description of when these messages are used are   defined in clause 7 since they are triggered by primitives."
3087200023,09/03/2007 02:30:39 EDT,8,"Williams, Michael G",michael.g.williams@nokia.com,650 823 0165,Individual,1,Producer,Disapprove,Editorial,2,,17,"Starting with ""Another possibility"" the text drifts away from the subject of the paragraph (facilitating handover) So a new paragraph is needed to introduce the important second topic.",,No,"Insert a new paragraph and replace the single sentence starting at ""Another possibility"" with the following text. Then leave the remaining text after the sentence to follow the replacement text.
The IEEE 802.21 supports another important aspect of optimized handover, link adaptation. A user may choose an application which requires a higher data rate than available on the current link, necessitating a link adaptation to provide the higher rate, or necessitating a handover if the higher rate is unavailable on the current link. After a handover from one point of attachment to another, the new link may provide different bandwidth or different transmission conditions (for example delay). These new conditions may affect protocols during and after the transition. Rapid notification of the changes is essential to optimizing the adaptation to the new conditions.",Agree,
2998500023,08/24/2007 10:31:14 EDT,7,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,7,Producer,Disapprove,General,194,,21,"Table B-13.
This table mixes chalk and cheese. WMM is not an IEEE 802.11 protocol, but a proprietary protocol of the WFA SIG which is almost the same, but not quite.
Similar comments related to WPA. and CWG.",,Yes,"Replace with 802.11 terminology.
(WFA should be able to communicate their compliance levels using vendor-specific signalling).",Principle,Removed WFA specified parameters/values.  Added another bit specifying security. Bit 12 RSN is supported.    
2998400023,08/24/2007 10:31:14 EDT,6,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,6,Producer,Disapprove,Technical,174,B.1.1,22,"""Each bit of a BITMAP(N) value
[N=8*i, i=1, 2, &] is encoded as an N/
8-octet value in order of significance.""
I dont' think this is unambiguous.
Does it mean that the lowest numbered such octet is first or last.
Likewise references to ""network byte order"" later on have no normative definition.",,Yes,"I recommend a conventions subclause before B.1.1 that defines unambigously:
1. The ordering of bits in an octet (most or least significant is B0?)
2. The ordering of octets in a multi-octet integer (is the lowest numbered octet least or most significant?)",Principle,  Please refer to contribution 21-07-0396-01-0000
2998300023,08/24/2007 10:31:14 EDT,5,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,5,Producer,Disapprove,Technical,151,8.4.1.1,15,"I haven't yet found any statement about conventions regarding endianness of frame format drawings.
Are the ver(4) bits the least significant or the most significant of the first octet.",,Yes,Add a subclause defining conventions for PDU structures/drawings in this standard. (See 802.11-2007 7.1.1 for an example).,Agree,Added the bit ordering in the figure
2998200023,08/24/2007 10:31:14 EDT,4,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,4,Producer,Disapprove,Technical,144,8.2.1,,"It is not clear whether there is some limit on the number of unacknowledged (outstanding) messages.
This has implications for the duplicate detection buffer size at the receiver.",,Yes,"Either negotiate a window size, or set it to 1.",Disagree,There is no limit on number of acknowledged messages
2998100023,08/24/2007 10:31:14 EDT,3,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,3,Producer,Disapprove,Technical,144,8.2.1,29,"""If a newly arrived MIH protocol message is found to carry the same Transaction-ID of an earlier arrived
message, the destination MIH node shall consider the new message as a retransmitted copy of the earlier
arrived message.
This couples a loose spec ""is found to"" with a normative requirement.",,Yes,"Either provide a normative requirement for the number of past messages that need to be recorded for the purposes of duplicate detection, or loosen the normative requirement.",Principle,"Replace  ""If a newly arrived MIH protocol message is found to carry the same Transaction-ID of an earlier arrived message, the destination MIH node shall consider the new message as a retransmitted copy of the earlier arrived message. In such a case, the destination MIH node shall respond with an acknowledgement message even though an acknowledgement message may have been sent earlier for the same MIH message. This is to safeguard against the cases wherein the first acknowledgement message may have been lost and not received by the source MIH node. However, the destination MIH node shall not process this duplicate retransmitted message if it has already done so. If a destination MIH node receives an MIH protocol message with no ACK-Req bit set then no action is taken with respect to the acknowledgement functionality. ""        WITH  ""The destination MIH node shall respond with an acknowledgement message for duplicate MIH messages (messages with same transaction-ID) that have the ACK-Req bit set. However, the destination MIH node shall not process these duplicate messages if it has already done so.  If a destination MIH node receives an MIH protocol message with no ACK-Req bit set then no action is taken with respect to the acknowledgement functionality.   "
2998000023,08/24/2007 10:31:14 EDT,2,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,2,Producer,Disapprove,Technical,144,8.2.1,14,"""The source MIH node may at most make two retransmission attempts in addition to the first attempt
for an MIH protocol message with the same Message-ID and the same Transaction-ID.""
What's special about ""two""? Why this embedded magic number?
This depends on the properties of the link, and couples the protocol to assumptions about the medium.",,Yes,Make this number a property of the link type.,Principle,"Replace    ""The source MIH node may at most make two retransmission attempts in addition to the first attempt  for an MIH protocol message with the same Message-ID and the same Transaction-ID.""    With    The source MIH node shall retransmit an MIH protocol message with ACK-Req bit set until it receives an acknowledgment or the number of retransmissions reaches its maximum value.  The maximum number of retransmissions can be reconfigured depending on implementation.  The default value of maximum number of retransmissions is two (2)."
2997900023,08/24/2007 10:31:14 EDT,1,"Stephens, Adrian P",adrian.p.stephens@intel.com,+44 1223 763457,Individual,1,Producer,Disapprove,Technical,143,8.2.1,47,"""When the MIH transport is reliable, the acknowledgement mechanism
may not be used"". In my experience, different readers understand different things by ""may not"". Some read is as ""shall not"", others as ""need not"".
This is a potential interoperability issue.",,No,"replace ""may not"" with ""need not"" or wording with similar intent - e.g. ""... reliable, the MIFH may choose not to use the acknowledgement mechanism""",Agree,"""When the MIH transport is reliable, the acknowledgement mechanism is optional based on carrier requirements."