{"text_format":"1","workbook":"xlsx","n_sheets":8,"sheets":["Comments","Progress-Status","Categories","Detailed Status","To-Do","Historical Status","CAD","Sheet1"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":3,"comments":1,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Comments","index":0,"n_rows":664,"n_cols":22,"rows_kept":664,"cut":false,"hidden":false,"merged":[]}
["Comment ID","Comment #","Name","Style","Index #","Vote","Affiliation","Category","Page","Sub-clause","Line #","Comment","File","Proposed Change","Must Be Satisfied?","Disposition Status (Accepted, Rejected, Revised)","Disposition Detail","Category","Notes","Editor Status DONE, Ready, N/A)","Editor Notes","Assignee"]
[null,null,"Kivinen, Tero",null,42,"No","Wi-SUN Alliance","Editorial",1,"Frontmatter",16,"Update copyright year. ",null,"Change 2024 to 2025.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,314,"No","Qorvo","Editorial",3,"Abstract",2,"Strange space at end of line",null,"remove it","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"ZAKAIB, LARRY",null,659,"Yes","Spark Microsystems","Editorial",3,"Abstract",11,"Replace \"allowing at least\" with \"extending beyond\"",null,"replace \"allowing at least\" with \"extending beyond\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"ZAKAIB, LARRY",null,660,"Yes","Spark Microsystems","Editorial",3,"Keywords",19,"Add low energy UWB PHY, LE UWB PHY",null,"add low energy UWB PHY, LE UWB PHY","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,43,"No","Wi-SUN Alliance","Editorial",3,"Frontmatter",23,"Update copyright year. ",null,"Change 2024 to 2025.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,44,"No","Wi-SUN Alliance","Editorial",8,"Frontmatter",4,"Add Vice-chairs, and other WG officials. ",null,"Add Vice chairs (Phil Beecher, Ann Krieger), Working Group Technical Editor (Tero Kivinen), Secretary (Joerg Robert). ","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,45,"No","Wi-SUN Alliance","Editorial",8,"Frontmatter",5,"Add task group officials. ",null,"Add TG chair, vice-chair, secretary, technical editor.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,315,"No","Qorvo","Editorial",9,"Introduction",25,"Blank numbered line",null,"delete it","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,46,"No","Wi-SUN Alliance","Technical",13,"2",14,"I do not think we need IETF RFC 1951 DEFLATE as normative reference. ",null,"Move this to bibliography.","No","Rejected","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"N/A"]
[null,null,"Kivinen, Tero",null,47,"No","Wi-SUN Alliance","Editorial",14,3.2,10,"The CSPRNG acronym is not used in the draft. ",null,"Remove CSPRNG from acronym list.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,145,"Yes","STMicroelectronics","Editorial",14,3.2,14,"HRP-SDEV is high-rate pulse repetition frequency UWB PHY based sensing device",null,"remove the second \"UWB\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,48,"No","Wi-SUN Alliance","Editorial",14,3.2,19,"We are avoiding NHL because of trademarks or similar, are there possibility that we end up similar problems with NBA? ",null,"Consider using some other acronym.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,49,"No","Wi-SUN Alliance","Editorial",14,"3.2",20,"OWR is already defined in the base standard, remove from here. ",null,"Remove OWR from the list.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,316,"No","Qorvo","Editorial",15,3.2,1,"the \"sensing\" in the definition should be \"UWB sensing\"",null,"change \"sensing\" to \"UWB sensing\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,317,"No","Qorvo","General",15,"5.2.5",9,"Is RSS a special application space on its own? I think not, it is more a subset of ranging/RTLS.  If we had someone to draft it, I can think of some broader special application spaces that might be worth adding here, (e.g., real time location, access control, sensing).  In the absence of that I propose to delete all of 5.2.5.",null,"Delete all of 5.2.5","Yes",null,null,null,null,"Suggested Assignment","Ben?  or seek volunteers to do "]
[null,null,"VERSO, BILLY",null,318,"No","Qorvo","Editorial",15,"5.2.5",11,"The word \"mobile\" would be a better choice here vs \"portable\" since we may be locating thing not being carried.",null,"Change \"portable\" to \"mobile\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,319,"No","Qorvo","Technical",15,"5.2.5",13,"\"Time structures for communication are defined by the upper layer using the UWB ranging service.\" is not clear in meaning anything.",null,"Delete the sentence.","Yes",null,null,null,null,"Suggested Assignment","Ben?  or seek volunteers to do "]
[null,null,"Kivinen, Tero",null,50,"No","Wi-SUN Alliance","Editorial",16,"6.6.1",5,"This is first use of RPA, expand here. ",null,"Expand RPA here.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,51,"No","Wi-SUN Alliance","Technical",16,"6.6.1",5,"The text included is not enough to cover the transmission of the compact frames. For example when source addresses are not present the sender is assumed to be coordinator, and when the destination address is not present then destination shall be either coordinator or broadcast. ",null,"Remove changes from section 6.6.1, move the more complete text of how to transmit compact frames in the 10.xx. ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Kivinen, Tero",null,52,"No","Wi-SUN Alliance","Technical",16,"6.6.2",9,"The text included is not enough to cover the recipient filters of the compact frames. For example there is no frame version number that can be checked, and as the destination address is not present the step 3 might trigger depending on the macImplictBroadcast value. ",null,"Remove changes from section 6.6.2, move the more complete text of how to receive compact frames in the 10.xx. ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,320,"No","Qorvo","Technical",16,"6.6.2",9,"\"The RPA is marked as resolved\", is not clear, I think it should refer to the place where the RPA resolution process is described, with reference to IRK etc.",null,"Change to \"… the RPA fields are resolved according to the process described in 10.39.11.1.2.1\" (which is the private addresses clause, which itself should be reviewed to see if it specifies the RPA resolution process sufficiently well, unambiguously, etc.).","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"PANPAN, LI",null,254,"Non-Voter","Huawei","Technical",16,"6.6.3.4",18,"This paragraph mentioned three times about the AIFS value being xxx, but we see both \"is\" and \"shall be\" and \"equal to\". Should keep consistent, say \"The value of AIFS shall be xxx\" or \"The value of AIFS is equal to xxx\" or something suitable. ",null,"As in comment","Yes",null,null,null,null,"Assigned",null,"Ben"]
[null,null,"PANPAN, LI",null,255,"Non-Voter","Huawei","Technical",16,"6.6.3.4",18,"Too long sentence.",null,"Separate with period before \"otherwise\".","Yes",null,null,null,null,"Assigned",null,"Ben"]
[null,null,"Kivinen, Tero",null,53,"No","Wi-SUN Alliance","Technical",16,"6.6.3.4",25,"This text does not belong here, move it to 10.45.2 where the SSBD algorithm is described. Techincal",null,"Move text to 10.45.2 as it does not belong here. The text in 10.45.2 can say that isRetrnamissionAttempt shall be set to TRUE if packet is retransmission as descibed in 6.6.3.4 and macSsbdPersistence is enabled.","Yes",null,null,null,null,"Assigned",null,"Larry"]
[null,null,"PANPAN, LI",null,256,"Non-Voter","Huawei","Technical",16,"6.6.3.4",25,"Three \"when\"s seem redundant",null,"Change it to \"When the SSBD channel access method, described in 10.45, is used, macSsbdPersistence is enabled, and the packet is a retrasmission, …..\"","Yes",null,null,null,null,"Assigned","I think make Tech and assign to Larry, so I don't mess it up.  I think, it could be a simpler set isRetransmissionAttempt TRUE for all retransmisssions (false otherwise).","Larry"]
[null,null,"VERSO, BILLY",null,321,"No","Qorvo","Technical",16,"6.6.3.4",25,"The paragraph is a single sentence which reads poorly.  Maybe it would be enough to have the simpler sentence, as per the proposed change. ",null,"Replace the paragraph with: \"When the packet is a retransmission, isRetransmissionAttempt shall be set to TRUE when invoking SSBD.","Yes",null,null,null,null,"Assigned",null,"Larry"]
[null,null,"VERSO, BILLY",null,633,"No","Qorvo","Technical",20,"8.2.7.3",6.5,"For non-interleaved MMS ranging, the MLME-RX-ENABLE.request needs to include the start time in ranging counter units and the clock offset information to enable the blind RX of the fragments that are invisible until ",null,"Update the MLME-RX-ENABLE.request primitive accordingly.","Yes",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"Kivinen, Tero",null,54,"No","Wi-SUN Alliance","Editorial",21,"8.3.2.2",6,"This is first use of MMS outside tables, expand it here. ",null,"Expand MMS here.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,55,"No","Wi-SUN Alliance","Editorial",21,"8.3.2.2",6,"This is first use of NBA, expand it here. ",null,"Expand NBA here.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,322,"No","Qorvo","Technical",21,"8.3.2.2",6,"I think the TxTimeSpecified parameter should also be RCTU_TIME in the UWB driven case.  If we delete the \"NBA\" from the sentence the \"MMS UWB\" can cover both  cases..",null,"Delete the \"NBA\" from the sentence.","Yes",null,null,null,null,"Assigned",null,"Billy"]
[null,null,"Kivinen, Tero",null,56,"No","Wi-SUN Alliance","Technical",21,"8.3.2.3",9,"Listing Rx/Tx Start/End markers for all eight Rifs is quite repetitive. ",null,"Change them to be array of unsigned integers. This is conceptual interface, so having Type of \"Array of eight Unsigned Integers\" is fine (similar than what is used for RangingStsFom).","No",null,null,null,null,"Suggested Assignment","Billy"]
[null,null,"MAMAN, MICKAEL",null,146,"Yes","STMicroelectronics","Editorial",21,"8.3.2.3",9,"typo : received instead of reveived",null,"change 16 time for RxRif1-8MarkerStart and RxRif1-8MarkerEnd","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,147,"Yes","STMicroelectronics","Technical",21,"8.3.2.3",9,"simplify the table of RangingReportDescriptor with 4 tables of size 8",null,"merge  RxRif1-8MarkerStart into  RxRifMarkerStart[8], RxRif1-8MarkerEnd into RxRifMarkerEnd[8], TxRif1-8MarkerStart into  TxRifMarkerStart[8], TxRif1-8MarkerEnd into TxRifMarkerEnd[8]","Yes"]
[null,null,"PAKROOH, POORIA",null,227,"No","Qualcomm","Technical",21,"8.3.2.3",9,"What is the reference for the RifMarker startand end time?",null,"In Table 8-28, specify the reference for the RifMarker startand end time","Yes",null,null,null,null,"Suggested Assignment","Xiliang"]
[null,null,"ZAKAIB, LARRY",null,661,"Yes","Spark Microsystems","Editorial",21,"8.3.2.3",9,"Correct the typo \"reveived\" with \"received\" in all occuraances in Table 8-28",null,"Change \"reveived\" to \"received\" everywhere in  Table 8-28","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,148,"Yes","STMicroelectronics","Technical",24,"8.3.3",4,"In DataRate element of the TXOptions, the range is between 0-7 in IEEE802.15.4 whereas for OQPSK PHYs the range is between 1-8 In table 67",null,"change the valid range of DataRate element to 0-8","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"PAKROOH, POORIA",null,228,"No","Qualcomm","Technical",25,"8.3.3",1,"Why is \"SensREceive\" needed? It is not used anywhere else in the draft. Monostatic involves single device. We are not defining any other parameters for monostatic",null,"Remove \"SensReceive\" from Table 8-29.","Yes"]
[null,null,"KREBS, ALEX",null,107,"Yes","Apple","Editorial",25,"MCPS-DATA.request","10-25","HeaderIeList and other paramters are ambigious in the font chosen between I as in Information and l as in lowercase.",null,"Change font for this and possibly more primitives (including p.39 l.17, p.40 l.15)  such that I and l are rendered differently","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,57,"No","Wi-SUN Alliance","Editorial",26,"8.3.4",11,"This is first use of IRK, expand it here. ",null,"Expand IRK here.","No","Accepted",null,null,null,"DONE"]
[null,null,"Kivinen, Tero",null,60,"No","Wi-SUN Alliance","Technical",26,"8.3.4",11,"Does both SrcAddrMode and DstAddrMode need to be NONE, or COMPACT? ",null,"Add text explaining whether it is valid to have SrcAddrMode of NONE, and DstAddrMode of COMPACT. Specify whether it is needed that both SrcAddrMode and DstAddrMode to be COMPACT for SourceIrk and DstAddr contain the IRK.","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,323,"No","Qorvo","Technical",26,"8.3.4",11,"This is covering the RPA prand/hash/IRK compact frame addressing, but has omitted a mechansim/discussion of specifying addrees for those compact frames using public  addresses",null,"Add method for specifying compact frame public addressing.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Kivinen, Tero",null,59,"No","Wi-SUN Alliance","Editorial",26,"8.3.4",12,"The CompatFrameId should be underlined also. ",null,"Underline CompactFrameID as it is part of new text.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,324,"No","Qorvo","Editorial",26,"8.3.4",12,"CompactFrameID is not underlined but it is added text.",null,"Make CompactFrameID underlined.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,58,"No","Wi-SUN Alliance","Editorial",26,"8.3.4",16,"This is not first use of MMS, do not expand it here. ",null,"Remove expansion of MMS.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,325,"No","Qorvo","Editorial",26,"8.3.4",16,"\"UWB multi-millisecond (MMS)\" should be \"multi-millisecond (MMS) UWB\" as uses elsewhere.",null,"Change to \"multi-millisecond (MMS) UWB\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,61,"No","Wi-SUN Alliance","Editorial",27,"8.3.4",3,"CompactSecurityParams range field refers to Table 8-XX. ",null,"Refer to table 2.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,62,"No","Wi-SUN Alliance","Technical",27,"8.3.4",3,"The SourceIrk field valid range is \"128-bit identity\". That does not really specify valid range, on the other hand there is no real valid range for it. ",null,"Replace the Valid range for SourceIrk with \"-\".","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,149,"Yes","STMicroelectronics","Editorial",27,"8.3.4",3,"wrong reference to Table 8-XX",null,"change Table 8-XX to Table 2","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,326,"No","Qorvo","Editorial",27,"8.3.4",4,"Second last row of Table 1, CompactSecurityParams, valid range says \"As defined in Table 8-XX\" but it should be Table 2.",null,"Change \"Table 8-XX\" to \"Table 2\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,327,"No","Qorvo","Editorial",27,"8.3.4",4,"Second last row of Table 1, CompactSecurityParams, has no description text.",null,"add \"A structure specifying Compact frame security parameters\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PAKROOH, POORIA",null,229,"No","Qualcomm","Technical",27,"8.3.4",7,"What are the possible values for \"CompactMessageVersion\"?",null,"Specify the possible values for \"CompactMessageVersion\".","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,328,"No","Qorvo","Technical",27,"8.3.4",9,"This note does not make sense. The CompactMessageContent is a set of octets which by definition has no structure/subfields etc. The text here should say what the MAC needs to do with CompactMessageContent, it is insufficient specification of the MAC functionality to say it may have content that may need processing. \"See 10.39.11 for details.\" is insufficient to cover what is required here since CompactMessageContent parameter and its handling are not mentioned/specified in that clause, either. ",null,"Change the language to specify exactly what the MAC is to do with the set of octets supplied in this primitive's CompactMessageContent parameter.  If it simply just sends them then let's say that, otherwise we should be more spefific about what we expect the MAC to with this string of octets.  Perhaps a more structured input and description should be added.  The SMC TLV field (defined later) suggests that the support of particular messages is someting decided/done above the MAC.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Kivinen, Tero",null,63,"No","Wi-SUN Alliance","Editorial",27,"8.3.4",11,"Do not use \"See xxx\". ",null,"Replace with \"as specified in 10.39.11\" or similar as recommended by WG style manual.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,64,"No","Wi-SUN Alliance","Technical",27,"8.3.4",12,"This table duplicate most of the fields of the Table 8-2 SecurityParameterDescriptor, which is already part of the MCPS-DATA.request. ",null,"Remove this table, and use security parameters of the standard SecurityParams parameter. ","Yes",null,null,null,null,"Assigned",null,"Billy"]
[null,null,"Rolfe, Benjamin",null,284,"Yes","BCA","Technical",27,"8.3.4",null,"Notes are informative, and shall not contain reqiurements.  In this case \"may\" is misused, to state a posibility rather than an optional requirement. Sigh.",null,"Change \"Note that the CompactMessageContent may contain different subfields that may require different handling\" to \"Note that the CompactMessageContent might contain different subfields that require different handling ",null,null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Kivinen, Tero",null,65,"No","Wi-SUN Alliance","Technical",28,"8.3.4",1,"The KeySource seems to be described incorrectly. KeySource is normally not the originator of the received frame or to be used transmitting the frame. It is used to find the associated key from the security tables, and it is included in the auxiliary security header, but does not necessarely match the originator of the frame. ",null,"If this is trying to be the originator of the frame then use some different name than KeySource. Remove the whole table 2, and CompactSecurityParams, and use standard SecurityParams, which already have SecurityLevel, KeyIndex, and KeySource fields.","Yes"]
[null,null,"MAMAN, MICKAEL",null,150,"Yes","STMicroelectronics","Technical",28,"8.3.4",1,"SecurityLevel 0x00 with no security is missing",null,"change valid range of SecurityLevel to 0x00-0x07","Yes"]
[null,null,"VERSO, BILLY",null,329,"No","Qorvo","Editorial",28,"8.3.4",1,"Given that SecurityLevel, KeyIndex, KeySource are already present in SecurityParams structure in base standard.  It would be more unified approach to reused these for compact frame security.",null,"Integrate the descriptions for compact frame security into the base standard SecurityParams and delete the separate CompactSecurityParams parameter.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,66,"No","Wi-SUN Alliance","Technical",28,"8.3.4",2,"The KeyIndex has valid range of 0x00-0x07, but I think the Key ID of the Secured Compact Frame is four bit field, thus correct range is 0-15. ",null,"Change range to 0x00-0x0f.","Yes"]
[null,null,"VERSO, BILLY",null,330,"No","Qorvo","Editorial",28,"8.3.5",11,"\"This is then the reference time ...\" could be clearer.",null,"Change to \"The TxRangingCounter value is then the reference time …\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,151,"Yes","STMicroelectronics","Technical",30,"8.3.6",1,"Missing Frametype parameter in order to validate or not the compactFrameDescriptor in the MCPS-DATA.indication",null,"add a line in Table 8-32 FrameType | Enumeration | DATA_FRAME, MULTIPURPOSE_FRAME, COMPACT_FRAME | Specifies the frame type received","Yes",null,null,null,null,"Assigned",null,"Billy"]
[null,null,"Kivinen, Tero",null,67,"No","Wi-SUN Alliance","Technical",30,"8.3.6",11,"How does one know whether the SrcAddr or DstAdddr parameter is used? ",null,"Add reference to the table or location that enumerates which CompactFrameIDs use SrcAddr and whch use DstAddr.","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,331,"No","Qorvo","Technical",30,"8.3.6",12,"\"either the SrcAddr or DstAddr parameters contain the IRK\" is a little vague. I expect witch is used will be based on which of  SrcAddrMode or DstAddrMode parameter values is COMPACT.  If that is the case then for clarity we should state that. ",null,"Change to say \"… then depending on the CompactFrameID conveyed in the CompactFrameDescriptor, and which of SrcAddrMode or DstAddrMode values is COMPACT, either the SrcAddr or DstAddr parameters contain the IRK ...\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Kivinen, Tero",null,68,"No","Wi-SUN Alliance","Technical",30,"8.3.6.",13,"SrcAddr and DstAddr cannot contain 128-bit IRK, so how is that stored there. ",null,"I think the IRK would be contained in the SourceIrk of the CompcatFrameDescriptor. If so specify so.","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"KREBS, ALEX",null,108,"Yes","Apple","Technical",30,"8.3.6.",13,"SrcAddr has been renamed to SourceIRK in CompactFrameDescriptor",null,"Change SrcAddr to SourceIRK (as done on p.26)","Yes",null,null,null,null,"Suggested Assignment","Billy"]
[null,null,"KREBS, ALEX",null,109,"Yes","Apple","Technical",30,"8.3.6.",19,"64 us is too aggressive for mandatory support.",null,"Change Range column to include 128, and change description to \"value of 128 us is mandatory\" and \"values of 16 us, 32 us and 64 us is optional.\" and change Default column to 128.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Kivinen, Tero",null,69,"No","Wi-SUN Alliance","Technical",31,"9.2.1",8,"Instead of making special case for securing compact frames it would be better to use standard security processing to protect those frames. ",null,"Remove all changes to section 9, and replace the compact frames with alternate format described in the document 15-25-0173, ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,332,"No","Qorvo","Technical",31,"9.2.1",8,"Why cannot \"macSecurityEnabled\" apply to compact frames also? On TX side we have SendFrameType to identify the frame type and on the receive side we have the Compact Frame type and  Compact Frame ID of Secured to identify the secured frame.",null,"Remove/don’t amend the first paragraph of 9.2.1, and replace secCompactFrameSecurityEnabled with macSecurityEnabled where it is used","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,333,"No","Qorvo","Technical",31,"9.2.1",9,"Reading the pre-existing part of this paragraph coming from the base standard, there is a notion of a device that does not implement security…. Do we want 4ab devices without security?  If not we should state that the EMDEV shall support security.",null,"Add statement somewhere that the HRP-EMDEV shall support securing of MAC frames, including compact frames as used for MMS UWB control and reporting .","No",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,334,"No","Qorvo","Technical",31,"9.2.1",10,"Since we have a Compact Frame ID for the Secured frame (it's #17 in Table 10), is the CompactFrameID parameter in the MCPS-DATA.request set to 17 or to the ID of the unsecured frame type  ID  (#0 to 16, and 30?)… We need to think about and specify how Compact frames that are secured are presented to the MAC in MCPS-DATA.request and delivered in MCPS-DATA.indication.",null,"Add description in in MCPS-DATA.request and in MCPS-DATA.indication, and in clause 9 as to make this interface specification clear","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,70,"No","Wi-SUN Alliance","Technical",31,"9.2.12",27,"What shall the device do if someone tries to secure those frames in table 24? ",null,"Add text saying that this procedure shall return error if the compact frame given in input is of one in table 24.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,335,"No","Qorvo","Technical",31,"9.2.12",27,"Is there something about the non-eligible frames that makes them unsuitable for securing, if not why disallow it, if there is a technical reason then please state it. (I think it is because the slot index is used to give a frame number). ",null,"Allow securing for all compact frame types, or, add technical reason why the ineligible frames are ineligible","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,336,"No","Qorvo","Technical",31,"9.2.12",27,"Might be worth considering adding some frame counter mechanism to allow securing of the ineligible frames, to avoid rogue elements using them for some type of attack.",null,"Add optional SEC frame counter field into the Secure frame to allow for securing of frames sent before the ranging slot structure is established. ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"PANPAN, LI",null,257,"Non-Voter","Huawei","Editorial",31,"9.2.12",28,"Redundant \"other\"",null,"Remove \"other\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PANPAN, LI",null,258,"Non-Voter","Huawei","Technical",32,"9.2.12",1,"This sentence is general description of the inputs to secure procedure, so no need to give the exact terminology. Why not change \"SecurityLevel, KeySource, KeyIndex\" into \"security level, key source, key index\"? Also change in the following three bullets.",null,"As in comment","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"PANPAN, LI",null,259,"Non-Voter","Huawei","Editorial",32,"9.2.12",9,"\"the secured frame\" should be changed to \"the frame is secured\".",null,"As in comment","Yes","Rejected","\"the outpits are the status and …. the secured frame\" is correct.",null,null,"N/A"]
[null,null,"Kivinen, Tero",null,71,"No","Wi-SUN Alliance","Technical",32,"9.2.12",22,"As there are compact frames that allows setting fields used as a frame counter how does the system make sure it never reuses any of the frame counters? ",null,"Instead of using block/round/slot indexes to generate frame counter use the same frame counter that is already used by the normal frames.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,72,"No","Wi-SUN Alliance","Technical",32,"9.2.12",31,"What about the Message ID field? It is not included at all, meaning anybody can see it and change it at will. ",null,"Include Message ID in the Private Payload Fields.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,73,"No","Wi-SUN Alliance","Technical",32,"9.2.12",32,"This step does not do the validations done in the step f) in 9.2.3 i.e., that the secAeadAlgorithm is supported and that the length of the key matches what is required by the algorithm. It also does not give the secAeadAlgoithm from the secCompactFrameKeyDescriptor to the encryption process. ",null,"Add the missing validations and give the secAeadAlgorithm support.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,337,"No","Qorvo","Technical",32,"9.2.13",37,"There is only one compact frame type eligible for desecuring and that is the Secured Compact frame, with Compact Frame ID value of 17.",null,"Change the paragraph to say only the Secured Compact frame, with Compact Frame ID value of 17, is eligible for desecuring.  ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,74,"No","Wi-SUN Alliance","Technical",32,"9.2.13",38,"The device has know of knowing what the actual compact frame type inside the secured compact frame is before it has processed the security control field. ",null,"Remove sentence starting at line 38.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"LI, HuanBang",null,123,"Yes","NICT","General",33,"9.2.13",1,"The intention of this sentence is to tell that the procedures in 9.2.4 or 9.2.5 shall be used for those frame types listed in Table 24. However, 'the sentence doesn't clearly show the point.",null,"modify the sentence to clearly describe the intention.","Yes",null,null,null,null,"Assigned","Rojan Volunteered email 8 April,\nHuan-Bang volunteered email 2 April\n(I think comment is not right)","Rojan, Huan-Bang"]
[null,null,"PANPAN, LI",null,260,"Non-Voter","Huawei","Editorial",33,"9.2.13",1,"Redundant \"other\"",null,"Remove \"other\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,338,"No","Qorvo","Technical",33,"9.2.13",3,"Suggest to merge this into first paragraph of the subclause",null,"The input is the Secured Compact frame, with Compact Frame ID value of 17, to be desceured","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"PANPAN, LI",null,261,"Non-Voter","Huawei","Editorial",33,"9.2.13",4,"\"if the status is SUCCESS the unsecures Compact frame\" should be changed to \"if the status is SUCCESS, the Compact frame is unsecured\". Also, here we see \"status\" while other places we see \"Status\". Figure out which one we should use and change all of them.",null,"As in comment","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,339,"No","Qorvo","Technical",33,"9.2.13",9,"Probably don't need separate variable for compact frame security, indeed maybe we should mandate that security support is required for EMDEV, i.e. perhaps step (a) is not needed beyond that we have received Compact Frame ID value of 17.",null,"Use macSecurityEnabled or always just process Compact Frame ID value of 17.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,75,"No","Wi-SUN Alliance","Technical",33,"9.2.13",15,"The term \"frame eligible for security\" is not exact. ",null,"Specify that if secured compact frame id in the security control field is not listed in table 23, then procedure shall return error.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,76,"No","Wi-SUN Alliance","Technical",33,"9.2.13",18,"The process in the 10.39.11.1.2.3 might end up in the RPA which is marked resolved, but which do not have extended address associated to it. ",null,"Add error case where the source address cannot be obtained because the macIrkDescriptorElement structure does not contain macIrkAssociatedEui.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,77,"No","Wi-SUN Alliance","Technical",33,"9.2.13",24,"How does this step know what values the ranging slot, ranging round and rounding block have? Are they in some pib attribute? ",null,"Specify where the unsecuring process can find the information needed to calculate the nonce.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,78,"No","Wi-SUN Alliance","Technical",33,"9.2.13",27,"Again the Message ID is missing. ",null,"Add Message ID to the Private Payload fields.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,79,"No","Wi-SUN Alliance","Technical",33,"9.2.13",28,"This does not take in to account the secAeadAlgorithm in the secCompactFrameKeyDescriptor. ",null,"Add text for secAeadAlgorthm.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,80,"No","Wi-SUN Alliance","Technical",33,"9.2.13",34,"Why use separate CompactSecurityParams when there is already SecurityParameterDescriptor that has same fields. ",null,"Remove CompactSecurityParams structure and use standard SecurityParameterDescriptor instead.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,81,"No","Wi-SUN Alliance","Technical",34,"9.3.2.4",8,"Using this construct will have same issues about the replay protection that TSCH has, i.e., if packet is retransmitted then there is no way to detect that retransmitted frame is same packet than before. ",null,"Add similar text than what is done for TSCH in the 9.1 when using compact frames.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,82,"No","Wi-SUN Alliance","Technical",34,"9.3.2.4",10,"The order of Block Index, Round Index and Slot Index seems to assume little endian format, but section 9.3.1.3 specifies that all integers are sent in most-significant-octet-first order. ",null,"Change the order to match the most-significant-octet-first order.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,83,"No","Wi-SUN Alliance","Technical",34,"9.3.2.4",16,"How is the recipient supposed to decrypt the secured one-to-one poll frame containing the block index and round index field if it does not know what block index and round index is used to encrypt the frame. ",null,"There is no way of decrypting the frame unless the nonce is known by the recipient device, thus it can't decrypt the one-to-one compact frame to find indexes to calculate the frame counter to generated the AEAD nonce. Remove all changes to section 9, and replace the compact frames with alternate format described in the document 15-25-0173, which uses standard secured frames and is more efficient than compact frames for unsecured frames, and transmits the frame counter in the frames for secured frames thus does not have this problem. ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"LI, HuanBang",null,124,"Yes","NICT","Editorial",36,"9.5.11",6,"In Table 3, the columns \"description\" of each row are ended differently with 'comma', 'period', or none.",null,"unifiy to 'period'.","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,340,"No","Qorvo","Technical",36,"9.5.11",6,"secCompactFrameKeyID has range 0-255 in Table 3, but KeyIndex field in Table 2 has range 0 to 7, while Key ID field within Secured Control field has a size of 4 bits which would cover a range of 0 to 15.  I am not sure if these are all related, but I think at least some of them are, so field size and value ranges should be aligned.",null,"Check/align the key ID and key index field sizes and ranges as appropriate.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,84,"No","Wi-SUN Alliance","Editorial",36,"9.5.11",7,"This should be secCompactFrameKeyId not secCompactFrameKeyID. ",null,"Fix last d to lowercase.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,85,"No","Wi-SUN Alliance","Technical",36,"9.5.11",7,"Here the range is 0-255, but I think the frames only include four bits for this field. ",null,"Change to 0-15.","No",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,86,"No","Wi-SUN Alliance","Technical",36,"9.5.11",7,"Do not use the same name secAeadAlgorithm than what is already used in other tables. ",null,"Change secAeadAlgorithm to secCompactAeadAlgorithm.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,341,"No","Qorvo","Editorial",37,"10.21.6.1.2",5,"Heading number unnecessary indented.",null,"Align all similar to left margin","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,342,"No","Qorvo","Technical",37,"10.21.6.1.2 ",29,"For the controlee/controller association, the MLME-ASSOCIATE.request needs to provide the address of the controller device.  The CoordAddrMode,\nCoordPanId, and CoordAddress can be reused for this.  But this reuse should be indicated in the text.",null,"Add Table 10-104 rows from base standard to show the necessary edits, i.e., to change \"coordinator\" to \"coordinator/controller\" in the descriptions of CoordAddrMode and CoordAddress parameters.","Yes","Revised","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx","ASSOC",null,"Ready"]
[null,null,"VERSO, BILLY",null,343,"No","Qorvo","Editorial",38,"10.21.6.1.2",1,"ControllerCapabilityInformation could be removed from MLME-ASSOCIATE.request parameters and instead reuse the CapabilityInformation field to have different meaning for controller association vs coordinator association, this would read better since the capability information being signalled in the association request is the controlee's capabilities not the controller's, so the field is misnamed",null,"Delete ControllerCapabilityInformation from Table 10-104 and re-use the CapabilityInformation field, to have different description for when ControllerAssociation is TRUE.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,344,"No","Qorvo","Technical",38,"10.21.6.1.2",1,"ControllerCapabilityInformation for MLME-ASSOCIATE.request  (in Table 10-104) says it is a bitmap as defined in 10.41.4.1, which I think would be clearer if it was actually referring to the bitmap format figure it was meaning.  I think it should be a bitmap containing the field in Figure 187.  The clause reference on its own does not suffice.",null,"Refer to Figure 187 directly, and add to its description that as well as being a field in the over the air message that is it also the format of the capability information bitmap parameter of the MLME-ASSOCIATE.request ","Yes",null,null,"ASSOC",null,"Assigned",null,"Larry"]
[null,null,"VERSO, BILLY",null,345,"No","Qorvo","Technical",38,"10.21.6.1.2",1,"I think we need a SessionID parameter to provide the value to place in the Session ID field of the Controller Association Request command frame ",null,"Add a SessionID parameter into Table 10-104 ","Yes",null,null,"ASSOC",null,"Assigned",null,"Larry"]
[null,null,"VERSO, BILLY",null,346,"No","Qorvo","Technical",39,"10.21.6.1.3",1,"ControllerCapabilityInformation for MLME-ASSOCIATE.indication  (in Table 10-105) says it is a bitmap as defined in 10.41.4.1, which I think would be clearer if it was actually referring to the bitmap format figure it was meaning.  I think it should be a bitmap containing the field in Figure 187.  The clause reference on its own does not suffice.",null,"Refer to Figure 187 directly, and add to its description that as well as being a field in the over the air message that is it also the format of the capability information bitmap parameter of the MLME-ASSOCIATE.indication ","Yes","Revised","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx","ASSOC",null,"Ready"]
[null,null,"VERSO, BILLY",null,347,"No","Qorvo","Editorial",39,"10.21.6.1.3",1,"ControllerCapabilityInformation could be removed from MLME-ASSOCIATE.indication parameters and instead reuse the CapabilityInformation field to have different meaning for controller association vs coordinator association, this would read better since the capability information being signalled in the association frame is the controlee's capabilities not the controller's, so the field is misnamed",null,"Delete ControllerCapabilityInformation from Table 10-105 and re-use the CapabilityInformation field, to have different description for when ControllerAssociation is TRUE.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,348,"No","Qorvo","Technical",39,"10.21.6.1.3",1,"I think we need a SessionID parameter to provide the value from  the Session ID field of the received Controller Association Request command frame ",null,"Add a SessionID parameter into Table 10-105","Yes",null,null,"ASSOC",null,"Assigned",null,"Larry"]
[null,null,"VERSO, BILLY",null,349,"No","Qorvo","Technical",39,"10.21.6.1.3",1,"This is the first use of the word \"session\".  In the base standard \"session\" only appears within the text of the ARC IE for Session ID and there where other than the field name it is a \"ranging session\", with a defintiion given as \"A group of ERDEVs engaged in a continuous ranging procedure that is characterized by a specific initial set of parameters is called a ranging session.\", the 4z MAC does not use the Session ID it is just conveyed in the IE.   \"Session\" is clearly a higher layer protocl construct. In FiRa protocols (for instance) build upon 4z, it mostly talks about UWB session (a term now currently used a lot in 4ab), sometimes ranging session, sometimes TWR session, sometimes HUS session.  Since the 4ab MAC is not really aware of sessions as such, I think we should try to avoid using of it except where needed to talk about Session ID.",null,"Since the 4ab MAC is not maintaining sessions (several of which might be being managed simultaneously by the upper layer protocols) we should consider whether we should be talking about them in 4ab. I would be in favour of a review of this and removing as much mention of Session as possible, unless it is really needed to be used as part of the MAC functional definition. Where we talk about Session then it should be in the context of higher layer protcol usage of the MAC and clearly not the 4ab MAC itself maintanining or running the session(s). ","Yes",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"VERSO, BILLY",null,350,"No","Qorvo","Editorial",41,"10.21.6.1.5",1,"Blank numbered line, it is actually the line the table is on but it is running onto the next page.",null,"Fix it","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PANPAN, LI",null,262,"Non-Voter","Huawei","Technical",41,"10.21.6.1.5",5,"I guess \"TRUE\" should be changed to \"FALSE\"?",null,"As in comment","Yes","Rejected","Doc 15-25-0178-00-04ab-d02-miscellaneous-comment-resolutions-i.docx",null,null,"N/A"]
[null,null,"Kivinen, Tero",null,87,"No","Wi-SUN Alliance","Editorial",42,"10.29.6.6",12,"This is first use of HRP-ARDEV, expand it here. ",null,"Expand HRP-ARDEV here.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PAKROOH, POORIA",null,230,"No","Qualcomm","Technical",42,"10.29.6.6",12,"It seems that this chart only applies to non-iterleaved mode.",null,"Change line 12 to: \"The non-interleaved MMS UWB ranging packets specified for the HRP-ARDEV in 16.2.11, can be used for DS-TWR with  message sequence as per Figure 3.\"","Yes","Revised","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,351,"No","Qorvo","Technical",42,"10.29.6.6",14,"Figure 3 MSC is very sparse, it is missing the Control phase messages that should precede each of the MMS UWB packets, (e.g.as shown in Figure 43), would be good to include the RX enables, and any other setup stages either in the figure but at least covered in some text describing the figure.  The current text and description is so minimal that it is hardly worth having the figure. ",null,"Delete the figure and text, or make it more useful by adding the missing steps for control phase packets etc and describing them in the text.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"TIAN, BIN",null,304,"No","Qualcomm","Technical",44,"10.29.9.2.3",1,"In Table 5, the description for SoundingImphaseValue and SoundingQuadrature Value is \" A relative measurement or the receive signal strenghth\". The term \"Receive signal strength\" generally is refer to receive signal power, not the amplitude, and its value can not be negative.  Use use the term Inphase value for an tap in CIR ",null,"as in the comment","Yes"]
[null,null,"MAMAN, MICKAEL",null,152,"Yes","STMicroelectronics","Editorial",44,"10.29.9.2.3",5,"typo on UNSUPPORTED_ATTRIBUITE",null,"change to UNSUPPORTED_ATTRIBUTE","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,153,"Yes","STMicroelectronics","Editorial",44,"10.29.9.2.3",6,"typo on SoundingList. Now it is SoundingListSet",null,"change to SoundingListSet","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,154,"Yes","STMicroelectronics","Editorial",44,"10.29.9.2.3",8,"typo on SoundingList in the title. Now it is SoundingListSet",null,"change to SoundingListSet","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,155,"Yes","STMicroelectronics","Editorial",44,"10.29.9.2.3",9,"typo on SoundingList in the NOTE. Now it is SoundingListSet",null,"change to SoundingListSet","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,156,"Yes","STMicroelectronics","Editorial",44,"10.29.9.2.3",10,"typo on SoundingList. Now it is SoundingListSet",null,"change to SoundingListSet","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,157,"Yes","STMicroelectronics","Editorial",45,"10.29.9.2.3",1,"typo on SoundingList in the title. Now it is SoundingListSet",null,"change to SoundingListSet","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,352,"No","Qorvo","Technical",45,"10.32.1 ",15,"Use of \"IEs such as\" in the definition of the RCM makes it a vague definition open to misinterpretation.  RCM previously had a very specific meaning.  We should delete the 3 words to leave a clear specification of which IEs have to be present in order for the frame to be considered an RCM. ",null,"Delete: \"IEs such as \".","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Mickael"]
[null,null,"PANPAN, LI",null,263,"Non-Voter","Huawei","Editorial",45,"10.32.1",23,"Add \"fields\" after \"these\"",null,"As in comment","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,353,"No","Qorvo","Technical",45,"10.32.1 ",25,"The statement here that is a little vague and really is not needed, since this handling is all the domain of the higher layer.",null,"Change the end of the paragraph starting from the sentence: \"If a device receives RCMs with different contents, …\"  to: \"The higher layer is responsible for processing, and acting on, the RCM content.\"","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"PANPAN, LI",null,264,"Non-Voter","Huawei","Technical",46,"10.32.2",3,"Change \"a whole number of ranging rounds\" to \"a number of whole ranging rounds\"",null,"As in comment","Yes","Rejected","Doc 15-25-0178-00-04ab-d02-miscellaneous-comment-resolutions-i.docx",null,null,"N/A"]
[null,null,"KREBS, ALEX",null,110,"Yes","Apple","Editorial",46,"Ranging block and round structure",13,"e.g. and etc. are redundant.",null,"replace by \"e.g., UWB sensing packet or data packets.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Rolfe, Benjamin",null,285,"Yes","BCA","Technical",46,"10.32.2",15,"\" it may be advantageous\" is an informative statement, not an optional requirement. This is stating a possiblity, not quite a recommendation. The correct word is \"can\".",null,"Chante \"may\" to \"can\"",null,"Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"Rolfe, Benjamin",null,286,"Yes","BCA","Technical",46,"10.32.2",18,"\" it may be advantageous\" is an informative statement, not an optional requirement. This is stating a possiblity, not quite a recommendation. The correct word is \"can\".",null,"Chante \"may\" to \"can\"",null,"Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,354,"No","Qorvo","Technical",46,"10.32.2",28,"Is there something in the RCM to indicate which slot it is being sent in, so that for example if a devices receives and RCM not sent in slot zero, after missing the initial RCM, that it knows where slot zero is to correctly synchronise to the ranging block/round etc.  I don't see this in the ARC IE or AC IE, so I think that maybe this is broken as an idea.  The ARC IE is part of the base standard so we probably cannot add a slot # field in it, but we can do so in the AC IE, in which case this text can say \"RCM using AC IE\" and state that the slot# field is present for this purpose.",null,"Add slot number field to the AC IE, and modify this text to say \"RCM using AC IE\", which \"shall have the slot number field included if RCM are being sent in slots other than slot zero\".","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"KREBS, ALEX",null,111,"Yes","Apple","Editorial",47,"Overview",4,"comma missing",null,"change text to \"mode, and\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PANPAN, LI",null,265,"Non-Voter","Huawei","Technical",47,"10.32.3.1",6,"Here only mention the difference between block-based and interval-based mode, with mentioning hyper block mode. Although intuitively hyper block mode should be same with block mode, but better clarify.",null,"As in comment","Yes",null,null,null,null,"Assigned",null,"Panpan, Youngwan"]
[null,null,"VERSO, BILLY",null,355,"No","Qorvo","Editorial",47,"10.32.3.5",16,"Figure and 5 split onto two lines.",null,"Join figure to 5 with non breaking space.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,356,"No","Qorvo","Editorial",48,"10.32.3.5",29,"Extra bracket at end of line.  The \"to one\" could be after the \"field value\" rather than later in this sentence.  ",null,"Remove extra bracket. Move \"to one\" to be after \"field value\".","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,357,"No","Qorvo","Technical",48,"10.32.3.5",42,"The sentence here is hard to understand… and variables m and p have not been mentioned in previous paragraphs…. ",null,"I don't know what is trying to say, but please re-phrase and expand the paragraph make it clear.  ","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"LI, HuanBang",null,125,"Yes","NICT","General",49,"10.32.3.5",2,"Figure 6' is not cited in the text.",null,"Citation of Figure 6 can be added at the end of Line 28 of Page 48 like 'as shown in Figure 6'.","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,358,"No","Qorvo","Technical",49,"10.32.3.5",2,"Figure 6 is not referenced in the text.  ",null,"Either add text to describe/explain what Figure 6 is showing or delete the figure","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,359,"No","Qorvo","Editorial",49,"10.32.3.5",4,"This is not the first time PAN has been used, and format of expansion is not matching the normal way to do it.",null,"Delete \"(Personal Area Network)\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,360,"No","Qorvo","Editorial",49,"10.32.3.5",7,"\"Controller\"",null,"change to \"controller\" and check for other cases","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,361,"No","Qorvo","Editorial",49,"10.32.3.5",7,"\"scheduling IE\"",null,"change to \"Scheduling IE\" and check for others cases","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,362,"No","Qorvo","Editorial",49,"10.32.3.5",7,"Repetition of \"hyper block advertisement (HBA)\"",null,"change to \"HBA\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,363,"No","Qorvo","Editorial",49,"10.32.3.5",14,"\"Enhanced Ranging Round IE (ERR IE), described in 10.32.9.11,\" is expanded but this is not first time ERR IE has appeared in the text.. ",null,"change to \"ERR IE (10.32.9.11)","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,364,"No","Qorvo","Editorial",50,"10.32.3.5",6,"scheduling IE",null,"change to Scheduling IE","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,365,"No","Qorvo","Technical",50,"10.32.3.5",7,"I am not sure what this is \"the address of the network\" is, this term does not appear elsewhere in 4ab or the base standard.  Is it the PAN, i.e., the PAN ID, or what?  Please clarify, or delete.",null,"delete \"or the address of the network it belongs to\"","Yes",null,null,null,null,"Suggested Assignment","Youngwan (Hyper block mode)"]
[null,null,"VERSO, BILLY",null,366,"No","Qorvo","Editorial",50,"10.32.3.5",13,"\"The very first round (round 0) of the Hyper Block 0 has five slots and the RCM with the HBS IE is sent in the very first slot (slot 0) of the round 0 of each Hyper Block.\"",null,"change to \"The very first round, i.e., round zero, of hyper block zero has five slots and the RCM with the HBS IE is sent in the very first slot (slot zero) of round zero of each hyper block.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,367,"No","Qorvo","Editorial",50,"10.32.3.5",17,"hyper Block.",null,"change to \"hyper block.\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LI, HuanBang",null,126,"Yes","NICT","Editorial",51,"10.32.3.5",1,"Use of 'The' at the beginning of the sentence: 'The Figure 9 …'  is not necessary.",null,"Delete 'The'.","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,368,"No","Qorvo","Editorial",51,"10.32.3.5",1,"The Figure 9 shows",null,"change to \"Figure 9 shows\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,369,"No","Qorvo","Editorial",51,"10.32.3.5",3,"Ranging Block Description List Fields",null,"change \"Fields\" to \"fields\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LI, HuanBang",null,127,"Yes","NICT","Editorial",51,"10.32.3.5",4,"… are set one …' should be '… are set to one …'.",null,"make change.","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,370,"No","Qorvo","Editorial",51,"10.32.3.5",4,"RSTU is used as block duration units, so the Ranging Block Duration Units field is set to two (0b10) based on Table 9.",null,"change to \"The Ranging Block Duration Units field is set to two, indicating that the block duration is specified in RSTU,(as specified in Table 9).\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,371,"No","Qorvo","Editorial",51,"10.32.3.5",6,"I don't think we need to give all the numbers in decimal, hex and binary in the text description or in Figure 9.",null,"Simplify to decimal representation only, and, add indication/note to say that the third row of each field is giving the \"field value\" .","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,158,"Yes","STMicroelectronics","Technical",52,"10.32.8.2",5,"MLME-SET.request instead of MLME-STS.request",null,"change to MLME-SET.request","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,372,"No","Qorvo","Technical",53,"10.32.9.3",17,"The statement \"In the case of hyper block mode, only the least significant 8 bits are used to specify the block index.\"  Could be a little more clear, if it instead quotes the allowed value range as per the proposed change.",null,"Change the sentence to say, \"In hyper block mode, the Round Index field is used to specify the block index, and this shall be limited to the range 0 to 255. When not in hyper block mode the full 16-bit field allows for a round index range of 0 to 65535.\"","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,373,"No","Qorvo","Editorial",53,"10.32.9.10",26,"RCM messages",null,"change to RCMs","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,374,"No","Qorvo","Technical",54,"10.32.9.10",3,"Is it correct that \"The Scheduling List Length field indicates the length in octets of the Scheduling List field.\", it seems more likely that it would the number of elements in the list rather than the number of octets, since thew field is only 4 bits, sixteen octets seems a little small given that for instance, Figure 13, Scheduling List field element format seems to have 19 octets in a single element.",null,"State this field it is the number of elements, and not the length in octets.","Yes",null,null,null,null,"Suggested Assignment","Youngwan (Scheduling IE)"]
[null,null,"VERSO, BILLY",null,375,"No","Qorvo","Editorial",54,"10.32.9.10",5,"schedules one slot to a device",null,"Consider changing this and all similar to \"assigns a slot to a device\", or similar.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,376,"No","Qorvo","Editorial",54,"10.32.9.10",5,"Would be helpful to cross reference to the figure that gives the format",null,"Add \"using the Scheduling List field element format given in as Figure 11\".. And add similar forward references in the paragraphs beginning on lines: 6, 11, 14,17, 23 of this page.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,88,"No","Wi-SUN Alliance","Editorial",57,"10.32.9.10",19,"This is first use of RIF outside the tables, expand it here. ",null,"Expand RIF here.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,89,"No","Wi-SUN Alliance","Editorial",58,"10.32.9.10",4,"This is first use of MSR, not on the line 5. ",null,"Move the expansion of MSR from line 5 to line 4.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LEE, HONGWON",null,118,"No","LG Electronics","Technical",58,"10.32.9.10",12,"The Meaning in Table 8 includes detailed values, increasing in multiples of 8 from the Block Scheduling Bitmap Length field value minus 1. However, when the Block Scheduling Bitmap Length field value is 6, the corresponding value is 196, which does not align with the expected multiple-of-8 progression. Therefore, it would be more appropriate for the value to be 192 when the Block Scheduling Bitmap Length field value is 6",null,"Change \"Block Scheduling Bitmap field is 196 bits long\" in the Meaning column to \"Block Scheduling Bitmap field is 192 bits long\"","Yes",null,null,null,null,"Assigned",null,"Hongwon"]
[null,null,"VERSO, BILLY",null,377,"No","Qorvo","Technical",61,"10.32.9.12",1.1000000000000001,"Table 9 row 1 is incorrectly talking about the \"Ranging Block Description List Length field\" when I believe it should be talking about the Ranging Block Duration field",null,"In first row of Table 9 (below headings) description of Ranging Block Duration Units field value zero, change \"Size of Ranging Block Description List Length field is one octet, and the Ranging Block Description List field units are in numbers of ranging rounds\" to \"The size of the Ranging Block Duration field is one octet and its units are ranging rounds\"","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,378,"No","Qorvo","Technical",61,"10.32.9.12",1.2,"Table 9 row 2 is incorrectly talking about the \"Ranging Block Description List Length field\" when I believe it should be talking about the Ranging Block Duration field",null,"Change description of Ranging Block Duration Units field value of one to: \"The size of the Ranging Block Duration field is two octets and its units are ranging slots\"","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,379,"No","Qorvo","Technical",61,"10.32.9.12",1.2,"Table 9 row 3 is incorrectly talking about the \"Ranging Block Description List Length field\" when I believe it should be talking about the Ranging Block Duration field",null,"Change description of Ranging Block Duration Units field value of two to: \"The size of the Ranging Block Duration field is three octets and its units are RSTU\"","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,380,"No","Qorvo","Editorial",63,"10.32.9.12",9,"MMS packet FORMAT is specified in 16.2.11",null,"add \"format\" after MMS packet ","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,90,"No","Wi-SUN Alliance","Editorial",63,"1 ine 5",null,"This is not first use of the HRP-ARDEV, do not expand here. ",null,"Remove expansion of HRP-ARDEV.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"TIAN, BIN",null,305,"No","Qualcomm","Editorial",64,"10.39.1",1,"clause 0 should be clause 16",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,381,"No","Qorvo","Editorial",64,"10.39.1",1,"Ref to Clause 0, should be Clause 13",null,"Change to \"Clause 13\"","No","Accepted",null,null,null,"DONE"]
[null,null,"TIAN, BIN",null,306,"No","Qualcomm","Technical",64,"10.39.1",3,"In \"MMS packet exchange, and, where O-QPSK PHY shares a common clock source\",  \"and, where\" is not proper.  Break into two sentences.  ",null,"as in the comment","Yes",null,null,null,null,"Suggested Assignment","See CI#383, with proposed resolution that fixes this if Accepted.  This one can be REVISED with CI#383 resolution disposition"]
[null,null,"VERSO, BILLY",null,382,"No","Qorvo","Editorial",64,"10.39.1",3,"\"at the appropriate times\" is on line 7….. For clarify this phrasing should also appear on line 3.",null,"After \"to initiate switching into UWB for the MMS\nUWB packet exchange\" add \"at the appropriate times\"\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,383,"No","Qorvo","Technical",64,"10.39.1",3,"This says \"… and, where O-QPSK PHY shares a common clock source with the UWB PHY, …\" however elsewhere the standard says that the O-QPSK PHY for NBA \"shall be derived from the same clock reference as the UWB PHY\", so there is no need to say have this \"where phase since it has to have a common clock source\"",null,"Delete: \", where O-QPSK PHY shares a common clock source with the UWB PHY\".","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"PAKROOH, POORIA",null,231,"No","Qualcomm","Technical",64,"10.39.1",6,"Why is HRP UWB Phy is mentioned as an example? UWB driven MMS only uses HRP UWB PHY. ",null,"Change line 6 to : \"Here HRP UWB PHY described in Clause 16 is employed for..\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,384,"No","Qorvo","Editorial",64,"10.39.1",10,"For clarity should say this is the ranging phase, and maybe we don't need the word \"concept\"",null,"Change “… illustrate the core MMS UWB ranging transmission concept for …” to “… illustrate the ranging phase transmission for …”",null,null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,91,"No","Wi-SUN Alliance","Editorial",64,"10.39.1",12,"This is not first use of RIF, do not expand here. ",null,"Remove expansion of RIF.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,159,"Yes","STMicroelectronics","Technical",64,"10.39.1",17,"The value A in ms is linked to macMmsRcpPollNSlots and macMmsRcpRespNSlots. Missing information about macMmsRangingSlotDuration",null,"add \" and macMmsRangingSlotDuration to a value of 600 RSTUs\" after both to a value of two.","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"MAMAN, MICKAEL",null,160,"Yes","STMicroelectronics","Technical",65,"10.39.2",12,"The report phase is also optionnal for interleaved one-to-one ranging ",null,"change \"and a report phase\" by \"and an optionnal report phase\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"PAKROOH, POORIA",null,232,"No","Qualcomm","Technical",65,"10.39.2",15,"Report phase is optional",null,"Change line 12 to: \".., and an optional report phase,..\"\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,385,"No","Qorvo","Editorial",65,"10.39.2",16,"\"initialization, setup\" are mentioned like phases here but not elsewhere, and we have an \"initialization and setup\" clause that does not call itself a phase.",null,"Review use of \"\"initialization, setup\" and try to make sure they are not called phases.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,386,"No","Qorvo","Editorial",65,"10.39.2","1900-01-17","Possibly good to add forward cross-references to the clauses describing the functions/phases mentioned here, and in the paragraph following.",null,"Add cross refereences to functions/phases mentioned in the two paragraphs beginning on lines 16 and 18 respectively.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,387,"No","Qorvo","Editorial",65,"10.39.2","1900-01-19","Ref to clause 0, should be Clause 13",null,"Change to \"Clause 13\"","No","Accepted",null,null,null,"DONE"]
[null,null,"KREBS, ALEX",null,112,"Yes","Apple","Editorial",65,"MMS UWB ranging overview",19,"where is clause 0?",null,"define what clause 0 is, or replace clause 0 by a reference to where clause 0 is","Yes","Revised","Change reference to\"Clause 13\"",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,388,"No","Qorvo","Technical",65,"10.39.2",21,"I think the ranging round may be bigger than these three phases, and indeed we have cases where there are multiple such triplets as sub-rounds in a single ranging round.  In this figure showing the three \"ranging phases\", rather than show this as a ranging round just show the three phases without the upper rectangle. ",null,"Remove upper rectangle \"ranging round\" from Figure 26.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,389,"No","Qorvo","Editorial",65,"10.39.2",31,"\"as appropriate\"",null,"change to \"as appropriate\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,390,"No","Qorvo","Technical",65,"10.39.2",34,"Given that NBA channel 2 is somewhat special being the default for the initialisation, (and the only channel allowed for advertising packets), which I believe to be because it is not occupied by UNII3 Wi-Fi channels, ....  should special measures be recommended / taken to keep this channel somewhat free from NBA ranging traffic.",null,"Maybe exclude this channel from default channel switching, map and/or include some statement recommending it be reserved for init phase packets and not used (by default) for control phase?","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"KREBS, ALEX",null,113,"Yes","Apple","Editorial",65,"Overview",35,"Sentence can be misunderstood as a restriction to not chose default parameters.",null,"Replace by \"to negotiate a ranging configuration between initiator and responders.\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,391,"No","Qorvo","Technical",65,"10.39.3.1",36,"I think some of the parameters in the referenced table 31 are not really MAC level parameters, but are rather \"mms protocol parameters\" that the MMS Higher Layers in each device needs to know to drive the MAC appropriately. These NHL configurations are agreed via in band or OOB mechanisms.  The macMmsNbInitChannel and macMmsNbInitMode fall into this category. e.g., the MMS NHL knowing the mmsNbInitChannel, should set the phyCurrentChannelInfo appropriately before sending/receiving the init channel messages. etc.",null,"Separate mac PIB attributes, and mms NHL protocol control variables, and update this clause accordingly.\n","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex\n\nI can take for now, to make outline proposal for group consideration before progessing.  Unless someone else wants to step up","Billy"]
[null,null,"VERSO, BILLY",null,392,"No","Qorvo","Technical",65,"10.39.3.1",36,"macMmsNbInitChannel should be NHL protocol control variable, PHY channel is selected by phyCurrentChannelInfo",null,"Change macMmsNbInitChannel to mmsNbInitChan parameter to be known by NHL, and update text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC","Billy"]
[null,null,"VERSO, BILLY",null,393,"No","Qorvo","Technical",66,"10.39.3.1",1,"macMmsNbInitMode should be NHL protocol control variable, O-PQSK PHY config (for TX) is select modes is selected by MCPS-DATA.request TxOptions parameter DataRate (see p25 L#3)",null,"Change macMmsNbInitChannel to mmsNbInitChan parameter to be known by NHL, and update text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC","Billy"]
[null,null,"VERSO, BILLY",null,394,"No","Qorvo","Technical",66,"10.39.3.1",1,"Instead of \"set by the higher layer\" ",null,"change to \"pre-agreed by higher layers\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,395,"No","Qorvo","Technical",66,"10.39.3.2",11,"Instead of \"configured\" ",null,"change to \"pre-agreed\"","Yes",null,null,null,null,"Assigned","NHL vs MAC","Billy"]
[null,null,"VERSO, BILLY",null,396,"No","Qorvo","Technical",66,"10.39.3.2",17,"macMmsNbInitSlotDuration should be NHL protocol control variable, transmission times (slot boundaries) are determined by when the NHL submits the MCPS-DATA.request with the frame to transmit, (and TxTimeSpecified = RSTU_TIME)",null,"Change macMmsNbInitSlotDuration to mmsNbInitSlotDuration parameter to be known by NHL, and update text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,397,"No","Qorvo","Technical",66,"10.39.3.2",18,"I reckon it is the NHL that decides to turn on the RX to receive the response.",null,"change \"shall\" to \"should\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"MAMAN, MICKAEL",null,161,"Yes","STMicroelectronics","Technical",66,"10.39.3.2",22,"If the initiator intends to proceed to the control phase, the Start of Ranging Compact frame Message Control field shall be set to zero, one or two, with the Startup Status field set as SUCCESS. There is no Startup Status field for zero and two configuration ",null,"reverse two and one.\"if the initiator intends to proceed to the control phase, the Start of Ranging Compact frame Message Control field shall be set to zero, two or one with the Startup Status field set as SUCCESS.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"KREBS, ALEX",null,114,"Yes","Apple","Editorial",66,"Session initialization",23,"\"zero, one, or two\" can be misunderstood",null,"change to \"zero, or one, or two\"","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,398,"No","Qorvo","Editorial",66,"10.39.3.2",24,"as \"SUCCESS\" -  editor to consider changing to descriptive values rather than this style.",null,"Editor to rework TABLE 25 values and use, review how things are done in base standard.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,399,"No","Qorvo","Technical",66,"10.39.3.2",25,"This is a long sentence.  Since all compact frames are delevered/sent via MCPS-DATA, the initiator/responder(s) being talked about are mostly already the next higher layer.",null,"Review the paragraph (and clause), from this point of view and change accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"MAMAN, MICKAEL",null,162,"Yes","STMicroelectronics","Technical",66,"10.39.3.2",28,"the field are not always present. Add this condition",null,"line  28 \"shall be passed to higher layer if present\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,400,"No","Qorvo","Editorial",67,"10.39.3.2",4,"extra \".\" at the end of the line",null,"delete the extra \".\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,401,"No","Qorvo","Technical",67,"10.39.3.2",5,"I reckon it is the NHL that decides to turn on the RX to receive the Start of Ranging.",null,"change \"shall\" to \"should\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,402,"No","Qorvo","Technical",67,"10.39.3.2",11,"I reckon it is the NHL that decides to take the action specified here. ",null,"change \"shall\" to \"should\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,403,"No","Qorvo","Technical",67,"10.39.3.2",14,"I reckon it is the NHL that decides to take the action specified here. ",null,"change \"shall\" to \"should\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,404,"No","Qorvo","Editorial",67,"10.39.3.2",16,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"A successful initialization process\" to \"Successful initialization\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,163,"Yes","STMicroelectronics","Editorial",67,"10.39.3.2",17,"typo in the figure for ADV POLL legend",null,"change adverting by advertising","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,405,"No","Qorvo","Technical",67,"10.39.3.2",21,"The paragraph is hard to understand, I think a word is missing. Maybe \"before\" is needed between \"10.39.3..3\" and \"transmitted\", but I think better to have this final phrase at the start of the paragraph.",null,"Change it say \"Before transmitting the Start of Ranging Compact frame, if coordination is active, ... \" and delete \"transmitting the Start of Ranging Compact frame\" at the end of the paragraph.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"MAMAN, MICKAEL",null,164,"Yes","STMicroelectronics","Technical",67,"10.39.3.2",28,"The process is the same after receiving Start of Ranging compact frame and not Advertising confirmation compact frame",null,"change \"Advertising confirmation\" by \"Start of Ranging\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,406,"No","Qorvo","Editorial",67,"10.39.3.2",28,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"process … is...\" to \"activities … are...\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,407,"No","Qorvo","Editorial",67,"10.39.3.2",30,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"A successful initialization process\" to \"Successful initialization\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"TIAN, BIN",null,310,"No","Qualcomm","Technical",68,"10.38.5",26,"\"May\" is used in RIF transmission and receive. Need to clarify that if phyUwbMmsRifNumberFrags>0, the transmitter shall transmit RIF segement.  ",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,165,"Yes","STMicroelectronics","Technical",69,"10.39.3.3",8,"the NB Acquisition compact frame is only sent in the aOqpsk5g8AquisitionChan. If the channel is jammed , the initiator is blocked. This initialization channel for acquisition compact frame should have a backup channel.",null,"open discussion to add a backup channel for acquisition compact frame. The higher layer may change aOqpsk5g8AquisitionChan to a backup channel.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,408,"No","Qorvo","Technical",69,"10.39.3.3",12,"Since the Acquisition frame \"UWB Per-Session Info\" field encoding allows for this field to be omitted, the statement here in not true.",null,"Change \"include\" to \"may include\"","Yes",null,null,null,null,"Suggested Assignment","Youngwan (Coordination)"]
[null,null,"CHITRAKAR, ROJAN",null,18,"No","Huawei","Technical",69,"10.39.3.3",20,"What is the Control phase referenced here? Or is it meant to the Initiatlization and Setup Phase",null,"Replace \"control phase\" with \"Initiatlization and Setup Phase\"","Yes"]
[null,null,"VERSO, BILLY",null,409,"No","Qorvo","Editorial",69,"10.39.3.3",20,"At the end of this line \"frame\" should be plural.",null,"Change to \"frames\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,166,"Yes","STMicroelectronics","Editorial",69,"10.39.3.3",21,"typo in the figure for ADV POLL legend",null,"change adverting by advertising","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LI, HuanBang",null,128,"Yes","NICT","Editorial",69,"10.39.3.3",23,"Use of 'The' at the beginning of the sentence: 'The Figure 30 …'  is not necessary.",null,"Delete 'The'.","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,410,"No","Qorvo","Editorial",69,"10.39.3.3",25,"\"doesn’t\" is a little informal in terms of language for a standard.",null,"Change to \"that doesn’t have any relationship with\" to \"has no relationship with\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,411,"No","Qorvo","Editorial",69,"10.39.3.3",30,"\"so to announce\" remove the \"so\"",null,"Change to \"to announce\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,412,"No","Qorvo","Editorial",70,"10.39.3.3",9,"\"the\" is not needed.",null,"change \"The Initiator X sends\" to \"Initiator X sends\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,413,"No","Qorvo","Technical",70,"10.39.3.4",20,"Another comment said macMmsNbInitSlotDuration should be NHL protocol control variable, assuming that is the case then this paragraph should change accordingly.",null,"Change to \"Updates to the mmsNbInitSlotDuration agreed by the next higher layers may be signalled on the initialization channel using the Advertising Poll Compact frame or Public Advertising Poll Compact frame.\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,414,"No","Qorvo","Editorial",71,"10.39.3.5",4,"To improve readability change to use bracketed clause reference rather than \"is defined in\".",null,"Change start or paragraph to: \"The Advertising Response Compact frame (10.39.11.3.2) and Start of Ranging Compact frame (10.39.11.3.3) both contain common fields:...\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"PAKROOH, POORIA",null,233,"No","Qualcomm","Technical",71,"10.39.3.5",15,"Selected NB channels should a subset of the proposed ones by Responder to ensure interoperability.",null,"Change to: \"The initiator shall set the value of the NB Channel Map field of the Start of Ranging Compact frame such that the selected channels are a subset of channels selected in the NB channel map field of the Advertising Response compact frame.\" ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,167,"Yes","STMicroelectronics","Technical",71,"10.39.3.5",16,"Note that at least one mutually supported channel between the initiator and the responder is required to start a ranging session. How to ensure it? May be make CH2 mandatory",null,"open to discussion to make the default channel mandatory","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,415,"No","Qorvo","Technical",71,"10.39.3.5",22,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"Change 1st & 2nd sentence of paragraph to \"In addition to the common ranging configuration fields, the initiator provides synchronization information in the Start of Ranging Compact frame. If the Starting Block Index field is present in the Start of Ranging Compact frame, the value of the Time Offset field indicates to the time difference between ...\".","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,416,"No","Qorvo","Technical",71,"10.39.3.5",29,"I reckon it is the NHL that is acting here, so lets say the same thing without the \"shall\" that are on both lines 29 and 30.",null,"Change \"shall set\" to \"sets\", and on the next line change \"shall apply\" to \"applies\", and I think these two sentences would read better if they were combined together using \"and the\" to replace \". The\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,417,"No","Qorvo","Technical",71,"10.39.3.5",31,"This reads like there may only one index, so I think it should be plural \"indexes\" to indicate that there are many indexes used.  Also ",null,"Change to \"indexes used …\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,418,"No","Qorvo","Technical",71,"10.39.3.5",31,"This is the first reference to channel switching.  I am a little confused about where the channel switch occurs, i.e., when there are multiple ranging rounds per ranging block, where the initiator is having different ranging rounds to range to different responders, if the switch only happens per block does the initiator and all the responders stay on the same NB channel for the whole block?  ",null,"Rather than try to clarify it here maybe instead delete \"during the first and all following ranging blocks\" and make sure the protocol is clear in 10.39.8.4.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"TIAN, BIN",null,307,"No","Qualcomm","Technical",71,"10.39.3.6",33,"Instead of \"may\", Contention based protocol like LBT shall be mandatory,",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,419,"No","Qorvo","Technical",71,"10.39.3.6",41,"I reckon it is the NHL that decides to turn on the RX to receive the response,  so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall listen\" to \"listens\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,420,"No","Qorvo","Technical",71,"10.39.3.6",44,"Since the NHL provides involves the MCPS_DATA.request to send the response, it is probably the NHL that is providing the randomness, could change shall to should by maybe we can just omit the \"shall\"",null,"change \"the initiator shall randomly select\" to \"the initiator randomly selects\" and change \"transmit\" to \"transmits\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,421,"No","Qorvo","Technical",71,"10.39.3.6",47,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall listen\" to \"listens\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,422,"No","Qorvo","Technical",71,"10.39.3.6",49,"Says \"listen … in the initialization slot at the end of the CAP\", which could mean the the final slot of the cap, but figures show this coming after the CAP, .",null,"Change to say \"slot immediately following the CAP\"","Yes",null,null,null,null,"Suggested Assignment","Rojan (Contention-based initialization)"]
[null,null,"VERSO, BILLY",null,423,"No","Qorvo","Technical",72,"10.39.3.6",10,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall send\" to \"sends\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,424,"No","Qorvo","Editorial",72,"10.39.3.6",15,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"process\" to \"interactions\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,168,"Yes","STMicroelectronics","Editorial",72,"10.39.3.6",17,"typo in the figure for ADV POLL legend",null,"change adverting by advertising","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LI, HuanBang",null,129,"Yes","NICT","Editorial",72,"10.39.3.6",20,"In the caption of Figure 32, it would be better to replace 'comma' with a word of 'with' like that in the caption of Figure 33.",null,"make change.","Yes",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Rolfe, Benjamin",null,287,"Yes","BCA","Editorial",73,"10.34.3.6",7,"Is \"may attempt\" really what we mean here?  We are allowing such an attempt.  If the attemprt is succesful a frame is captured. If it is unsuccessful there is no capture?  Why do we need to say \"attempt\" - seems like it is allowed to capture the frame.",null,"Delete \"attempt\"",null,null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,425,"No","Qorvo","Editorial",73,"10.39.3.6",13,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"process\" to \"interactions\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"MAMAN, MICKAEL",null,169,"Yes","STMicroelectronics","Technical",73,"10.39.3.6",16,"what is the RPA Hash of the advertising confirmation compact frame when two or more responders are selected?",null,"add \"In this case, the RPA Hash field of each Start of Ranging Compact frame shall be calculated as specified in 10.39.11.1.2.1 using the IRK of the initiator.\"","Yes"]
[null,null,"VERSO, BILLY",null,426,"No","Qorvo","Technical",73,"10.39.3.6",16,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall send\" to \"sends\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"Rolfe, Benjamin",null,288,"Yes","BCA","Editorial",73,"10.34.3.6",19,"\"may attempt\" again.  We are allowing it to capture Acquisition Compact frames. Don't need \"attempt\" (we can presume that it tries really, really sincerely). ",null,"Delete \"attempt\"",null,null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kivinen, Tero",null,92,"No","Wi-SUN Alliance","Editorial",74,"10.39.3.6",19,"This is not first use of IRK, do not expand here. ",null,"Remove expansion of IRK.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,427,"No","Qorvo","Editorial",74,"10.39.3.6",8,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"process\" to \"interactions\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,428,"No","Qorvo","Editorial",74,"10.39.3.6",10,"A similar key to that in Figure 34, explaining the frame compact frame message naming shorthand, should be included here in Figure 35.",null,"Include key to frames in Figure 35 (like the one in Figure 34).",null,null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,429,"No","Qorvo","Editorial",74,"10.39.3.6",18,"I have reviewed the usage of the word \"process\" and propose to change some of them including this one. ",null,"Change \"setup process\" to \"setup interactions\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,430,"No","Qorvo","Editorial",74,"10.39.3.6",22,"A similar key to that in Figure 34, explaining the frame compact frame message naming shorthand, should be included here in Figure 36.",null,"Include key to frames in Figure 36 (like the one in Figure 34).","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,431,"No","Qorvo","Technical",74,"10.39.3.6",25,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall listen\" to \"listens\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,432,"No","Qorvo","Technical",75,"10.39.3.7.1",4,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall transmit\" to \"transmits\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,433,"No","Qorvo","Technical",75,"10.39.3.7.1",13,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall discontinue\" to \"discontinues\" and change \"cease\" to \"ceases\".","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,434,"No","Qorvo","Editorial",75,"10.39.3.7.1",16,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Change \"The initialization process using...\" to \"Session initialization using\".","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,435,"No","Qorvo","Editorial",75,"10.39.3.7.1",17,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Change \"… is same as in the process described in ...\" to \"… is same as described in...\".","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,436,"No","Qorvo","Editorial",75,"10.39.3.7.1",18,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Change \"The initialization process using...\" to \"Session initialization using\".","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,437,"No","Qorvo","Editorial",75,"10.39.3.7.1",20,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Delete \"for initialization process\".","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,438,"No","Qorvo","Technical",75,"10.39.3.7.1",21,"Initialsiation is an optional procedure so \"may\" should be used here.",null,"Change to say \"To establish a ranging session, HRP-ARDEVs may engage in an initialization and setup stage….\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,439,"No","Qorvo","Technical",75,"10.39.3.7.1",29,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall listen\" to \"listens\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,440,"No","Qorvo","Technical",75,"10.39.3.7.1",32,"Is this NHL or MAC, let's avoid the distinction.",null,"change \"shall use\" to \"uses\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,441,"No","Qorvo","Technical",75,"10.39.3.7.1",35,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall listen\" to \"listens\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,442,"No","Qorvo","Technical",75,"10.39.3.7.1",37,"Is this NHL or MAC, let's avoid the distinction.",null,"change \"shall use\" to \"uses\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,443,"No","Qorvo","Editorial",76,"10.39.3.7.1",5,"A similar key to that in Figure 34, explaining the frame compact frame message naming shorthand, should be included here in Figure 38.",null,"Include key to frames in Figure 38 (like the one in Figure 34).","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,444,"No","Qorvo","Editorial",76,"10.39.3.7.1",6,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Change figure title to \"An example of session initialization using with public addresses\"","No","Revised","Change figure title to \"An example of initialization using public addresses\"",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,445,"No","Qorvo","Editorial",76,"10.39.3.7.1",13,"I really don't like the capatilised values, here I think this style is not used anwhere in the base standard.  Prefer to used more readable text and no such constants.  Can still refer to Table 25 to give te actual number values used in the field to signal the status.",null,"Editor to review this usage, and see what is done in the base standard, and consider changing this line and others linek it to say something like: \"if the Startup Status field indicates rejection due to duplicate address or acceptance with a new address then the responders actions are as follows:\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,446,"No","Qorvo","Editorial",77,"10.39.3.7.1",6,"\"the\" is missing",null,"change to \"After the ranging session is\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,447,"No","Qorvo","Technical",77,"10.39.3.7.1",9,"Is this NHL or MAC, let's avoid the distinction.",null,"change \"shall be used\" to \"are used\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,448,"No","Qorvo","Technical",77,"10.39.3.7.2",25,"I reckon it is the NHL that doing this, so propose to rewrite to say the same thing without the \"shall\". ",null,"change \"shall be\" to \"is\" here and on lines 30 and 33.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Hongwon"]
[null,null,"VERSO, BILLY",null,449,"No","Qorvo","Editorial",78,"10.39.3.8",29,"Another use of capatilised values, where I prefer to use more readable text and no such constants.",null,"Editor to review this usage, and consider changing this line to say something like: \"if the Response Status field indicates acknowledgement of the proposed long term parameters, …\"","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,450,"No","Qorvo","Technical",78,"10.39.3.8",32,"I think some of the parameters in the referenced table 31 are not really MAC level parameters, but are rather mmsParameters that the MMS Higher Layers in each device needs to know to drive the MAC appropriately. ",null,"If we have a separate class of mms parameters that are really variables used by the NHL then this line will have to change to refer to them also.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,451,"No","Qorvo","Technical",78,"10.39.3.9",35,"The phrase \"supported message control commands\" appears 3 times in the draft, all 3 assocaited with SMC TLVs field, but \"message control commands\" is an undefined term.",null,"Could either define \"message control commands\", or perhaps it should replaced by \"Message ID field values\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,452,"No","Qorvo","Technical",78,"10.39.3.9",37,"While TLV is flxible, I assume there is some minimum required set that is needed, which should be clarified.  Also, it seems this field is only present in frames sent in the optional initialsisation phases, so it is potentially problematic.  Most likely the contributers of the message definitions know which sets go with which sort of functionality, so a better chance of vendors interworking might be promoted by deleting the SMC TLV field and instead nominating the message set needed by operational category like one-to-one, one-to-many, and the various flavours thereof, and coding each category as a bit in a bitmap. .",null,"List a manditory set of frames that need to be supported irresperctive, and/or consider an alternative way to speficy groups/sets of commands that are needed for particulatr cases to promote interworking.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,453,"No","Qorvo","Technical",79,"10.39.3.9",3,"Message Control has been reduced to 4 bits and a 4-bit Message Version has been added to use the other 4 bits.  Should message version also be mentioned on this line as as part of the SMC TLV field?",null,"Update lines 3 and 5 to include mention Message Version if this is appropriate.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,454,"No","Qorvo","Technical",79,"10.39.3.9",6,"Since the secure compact frame enbcapsulates some of the others frames, it may be worth noting that to use the secured version the unsecured version must also be listed…. But …. What if we only want to support the secured version. Maybe we insterad need a 2-bit flag to say for each type whether the secured or unsecured version is to be used.",null,"Add a a 2-bit flag to allow for each SMC TLVs field message to also say whether the secured or unsecured version is to be used…. ","Yes",null,null,null,null,"Suggested Assignment","Rojan (Security) + Alex (SMC TLVs)"]
[null,null,"CHITRAKAR, ROJAN",null,19,"No","Huawei","Technical",79,"10.39.4",7,"Is this subclause also applicable for non-interleaved mode?",null,"Add clarification that this subclause is not applicable for non-interleaved mode","Yes"]
[null,null,"VERSO, BILLY",null,455,"No","Qorvo","Technical",79,"10.39.4.1",10,"I think macMmsRcpPollNSlots and macMmsRcpRespNSlots are more in the class of mms contol parameters that the NHL in each device needs to know to drive the MAC appropriately. In this case the SHALL on line 11 is problematic.",null,"Separate thhese into mms NHL protocol control variables, and update this clause accordingly.\nChange the \"shall set\" here to \"should use\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"Shellhammer, Steve",null,293,"No","Qualcomm","Technical",79,"10.39.4.1",18,"What is the expected behaviour when the responder does not receive Poll? In this case, there is no point for the responder to send the response compact frame.",null,"Add this sentence in line 18: \"If the responder does not receiver the Poll, it shall skip sending the response Compact frame.\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,456,"No","Qorvo","Technical",79,"10.39.4.1",18,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"On line 18 change \"shall continue\" to \"continues\" and change \"enter\" to \"enters\" on line 19. Then on line 19 change \"shall also continue\" to \"also continues\" and change \"enter\" to \"enters\" on line 20. ","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"Rolfe, Benjamin",null,289,"Yes","BCA","Editorial",79,"10.39.4.1",24,"\"may optionally\" is redundant. May describe an optional behavior.",null,"Delete \"optionally\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,457,"No","Qorvo","Technical",79,"10.39.4.1",28,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"In this paragraph change three occuranced of \"shall update\" to \"updates\", and two occurances of \"shall use\" to \"use\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"SUN, LIHSIANG",null,301,"Yes","MediaTek","Technical",79,"10.39.4.1",39,"There shold be some contraint on what cannot be changed in the updated long term parameter, such that initiator is able to verify the responder is using the updated parameter \n\ne.g. the config cannot be changed from a TWR to a OWR (from initiator) with measurement Report request set to 0",null,"as in comment","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Pirhonen, Riku",null,266,"Yes","NXP Semiconductors","Technical",80,"10.39.4.1",2,"In case of UWB driven MMS, the MMS UWB packet has SYNC+SFD fragment, which can be used to estimate carrier frequency offset. Sending separate Poll and Control packets is not always needed and in that case control phase duration can be set to 0 to indiate that there are no separate physical poll and response frames. ",null,"Add text: In case of UWB driven MMS the SYNC+SFD fragment of UWB MMS packet can be used for carrier frequency offset estimation. If there is no other reason to send a dedicated poll and response frame, macMmsRcpPollNSlots and/or macMmsRcpRespNSlots can be set to 0 to indicate zero length control phase and the SYNC+SFD fragment of the UWB MMS packet serves as the poll or the response. ","No",null,null,null,null,"Assigned","Carl had this before","Billy, Carl"]
[null,null,"Aldana, Carlos",null,3,"No","Meta","Technical",80,"10.39.4.2",6,"There is no baseline coex mechanism for NB channel access using O-QPSK","Change the \"may\" to a \"shall\" to be consistent with ETSI 303687 and adopt changes described in document 15-407-07","Change the \"may\" to a \"shall\" to be consistent with ETSI 303687 and adopt changes described in document 15-407-07","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"TIAN, BIN",null,308,"No","Qualcomm","Technical",80,"10.39.4.2",6,"channel access shall use contention based protocol for better coexistence. Certain exemption condition may be considered for low duty cycle operation",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"TIAN, BIN",null,309,"No","Qualcomm","Technical",80,"10.38.4.2",9,"Mutliple channel access in different NB channels within the same slot can be allowed to increase the chance of transmission",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"CHITRAKAR, ROJAN",null,20,"No","Huawei","Technical",80,"10.39.5",17,"Is this subclause also applicable for non-interleaved mode?",null,"Add clarification that this subclause is not applicable for non-interleaved mode","Yes"]
[null,null,"MAMAN, MICKAEL",null,170,"Yes","STMicroelectronics","Technical",80,"10.39.5",19,"Optionnally the order between the Initiator and the responder can be reversed. Then In the ranging phase, the responder may transmit the HRP UWB PHY MMS packet (described in 16.2.11), and the Initiator may start transmitting its HRP UWB PHY MMS packet offset by 600 RSTU from the start into the ranging phase.",null,"add text page 81 line 2. \"Optionnally in the ranging phase, the responder may transmit the HRP UWB PHY MMS packet (described in 16.2.11), and the Initiator may start transmitting its HRP UWB PHY MMS packet offset by 600 RSTU from the start into the ranging phase. This option is signaled by the reversed_fragment parameter described in 10.38.11.1.3.8\". A new bit \"reversed_fragment\" can be added in Figure 65 to indicate this configuration. A new DCN will be provided and will detail the full changes","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"MAMAN, MICKAEL",null,171,"Yes","STMicroelectronics","Technical",80,"10.39.5",19,"Optionnally, the responder may start transmitting its HRP UWB PHY MMS packet offset by 600 RSTU from the reception of the first fragment instead of the start into the ranging phase. This new option reduces the energy consumption of the interleaved MMS by avoiding the need to send the report",null,"add text page 81 line 2. \"Optionnally in the ranging phase, the responder may start transmitting its HRP UWB PHY MMS packet offset by 600 RSTU from the start of the HRP UWB PHY MMS packet received from the initiator.This option is signaled by the MMS_Sync parameter described in 10.38.11.1.3.8\". A new bit \"MMS_Sync\" can be added in Figure 65 to indicate this configuration. A new DCN will be provided and will detail the full changes","Yes",null,null,null,null,"Assigned",null,"Pooria, Mickael"]
[null,null,"VERSO, BILLY",null,458,"No","Qorvo","Technical",80,"10.39.5",19,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"initiator shall transmit\" to \"initiator transmits\", and change responder text part of the sentence to \"and for one-to-one interleaved MMS UWB ranging, the responder starts transmitting its …\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,459,"No","Qorvo","Editorial",80,"10.39.5",21,"\"from the start into the ranging phase\"",null,"change to \"from the start of the ranging phase\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,460,"No","Qorvo","Technical",80,"10.39.5",24,"macMmsRpDuration should be an NHL protocol control variable, since it is the NHL that is providing the report frames and dictating the time of sending, it should be the one specifying the TX time of the report so it should be basing this on the agreed mmsRpDuration, and its role, and the phases.",null,"Change macMmsRpDuration to mmsRpDuration parameter to be known by NHL, and update text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,461,"No","Qorvo","Technical",80,"10.39.5",28,"Is it a \"ranging round\" or a sub-round? Maybe just avoid this distinction",null,"Change \"the ranging round is completed at this time\" to \"this MMS UWB ranging exchange finished\", ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,462,"No","Qorvo","Technical",81,"10.39.6",10,"macMms1stReportNSlots and macMms2ndReportNSlots should be NHL protocol control variables, since it is the NHL that is providing the report frames dictating the time of sending, the NHL rather than the MAC needs to manage all these phase durations rather than trying to have the MAC aware of the NHL protocol phases.",null,"Change macMms1stReportNSlots and macMms2ndReportNSlots to mms1stReportNSlots and mms2ndReportNSlots parameters to be agreed/known by NHLs, and update the text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,463,"No","Qorvo","Technical",81,"10.39.6",12,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"the responder shall transmit a report packet\" to \"the responder transmits its report packet\", and on line 13 change two occurances of \"shall transmit\" to \"transmits\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,464,"No","Qorvo","Technical",81,"10.39.6",19,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"shall be\" to \"is\", and \"shall transmit\" to \"transmits\".","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,465,"No","Qorvo","Technical",81,"10.39.6",21,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"shall be\" to \"are\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,466,"No","Qorvo","Editorial",81,"10.39.6",24,"\"if poll Compact frame\"",null,"change to \"if a poll Compact frame\"","No","Accepted",null,null,null,"DONE"]
[null,null,"PAKROOH, POORIA",null,234,"No","Qualcomm","Technical",82,"10.39.7",3,"The benefits of Noninterleaved MMS mode are not justified properly. On the other hand, there are several disadvantages relative to the interleaved mode, such as longer duration for the ranging, limitations due to channel coherence time, and market fragmentation.",null,"Remove Non-interleaved MMS mode, specifically subclause 10.39.7 and other ralted subclauses.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"PAKROOH, POORIA",null,235,"No","Qualcomm","Technical",82,"10.39.7",4,"Clarify that this mode is optional for ARDEVs. ",null,"Add a sentence in line 4 \"Support of Non-interleaved mode is optional for ARDEV devices.\"\n","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"SUN, LIHSIANG",null,298,"Yes","MediaTek","Technical",82,"10.39.7",6,"Suggest the spec to have some requirment to say if which report message control is used for which non-interleaved mode   ",null,"as in comment","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"TIAN, BIN",null,311,"No","Qualcomm","Technical",82,"10.39.7",7,"In the non-interleaved modes, why not moving the responder NB transmission immediately after the Initiator transmission so that Initiator knows that responder is ready for followijng UWB excahnge.  In the ranging subround 2 or later, no NB transmission is needed. Mutliple NB transmission may lead to different frequency and time reference ",null,"as in the comment","Yes"]
[null,null,"CHITRAKAR, ROJAN",null,21,"No","Huawei","Technical",82,"10.39.7",9,"\"A non-interleaved ranging round may consist of one, two, three or four sub-rounds or a hybrid sub-round.\"\nWhat does \"Hybrid sub-round\" mean here? This is the only occurance of the term.",null,"Either clarify the meaning of hybrind sub-round or replace with the actual number of sub-rounds required for the hybrid mode.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"CHITRAKAR, ROJAN",null,26,"No","Huawei","Technical",82,"10.39.7",9,"What about the Report phase? Is it in a separate sub-round or included in the last sub-round.",null,"Clarify the location of the Report phase for the various non-interleaved modes.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"CHITRAKAR, ROJAN",null,22,"No","Huawei","Technical",82,"10.39.7",10,"Each of the ranging methods OWR, SS-TWR, DS-TWR with 3 or 4 MMS packets deserves to be described in separate sub-clauses, or at least separate paragraphs.",null,"Describe each of the ranging methods: OWR, SS-TWR, DS-TWR with 3 or 4 MMS packets in separate sub-clauses, or at least separate paragraphs.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"CHITRAKAR, ROJAN",null,23,"No","Huawei","Technical",82,"10.39.7",11,"What's the use case for hybrid mode? It is not clear if the SS-TWR and OWR is performed between the same initiator and responder?",null,"Add a figure and related description for hybrid mode.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"SUN, LIHSIANG",null,297,"Yes","MediaTek","Technical",82,"10.39.7",11,"DS-TWR with four packets. Suggest to clarify in this case subround 3 is from responder and subround 4 is initiator",null,"as in comment","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"CHITRAKAR, ROJAN",null,24,"No","Huawei","Technical",82,"10.39.7",12,"\"The mode is signaled by the Non-Interleaved Mode parameter described in 10.39.11.1.3.9.\"\nWhich frame? SOR, POLL or both?",null,"Describe the Compact frame that may be used to signal non-interleaved mode.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"MAMAN, MICKAEL",null,172,"Yes","STMicroelectronics","Technical",82,"10.39.7",14,"In the hybrid or OWR mode, How the OWR sub-round transmission can de defined by macMmsRcpPollNSlots and macMmsRcpRespNSlots?",null,"Please Clarify","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"SUN, LIHSIANG",null,296,"Yes","MediaTek","Technical",82,"10.39.7",14,"\"In the hybrid mode, the OWR sub-round transmission can be either from the initiator to the responder or from the responder to the initiator, which is defined by macMmsRcpPollNSlots and macMmsRcpRespNSlots.\" \n\nBut macMmsRcpPollNSlots and macMmsRcpRespNSlots is used for interleaved SS-TWR, how it is reused to configure direction for OWR subround?",null,"as in comment","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"VERSO, BILLY",null,467,"No","Qorvo","Technical",82,"10.39.7",14,"It is wrong to refer to part of the hybrid mode as a \"OWR sub-round transmission\" it is part of the Hybrid DS-TWR.",null,"Change \"OWR sub-round transmission\" to \"non-interleaved sub-round transmission\"","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"CHITRAKAR, ROJAN",null,25,"No","Huawei","Technical",82,"10.39.7",15,"It is not clear how the OWR sub-round transmitter is determined based on macMmsRcpPollNSlots and macMmsRcpRespNSlots",null,"Describe how the OWR sub-round transmitter is determined based on macMmsRcpPollNSlots and macMmsRcpRespNSlots","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"VERSO, BILLY",null,468,"No","Qorvo","Technical",82,"10.39.7",16,"It is not clear to me how vairables mmsRcpPollNSlots and mmsRcpRespNSlots, can define this.  Both will need to have agreed values for the preceding interleaved exchange so how can they define the direction for the final sub-round?  It would be more sensible to have the direction defined simply by which side is the initiator, which then would also send this final message.  Failing that have a separate parameter specify it.",null,"Delete clause 10.39.7","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"MAMAN, MICKAEL",null,173,"Yes","STMicroelectronics","Technical",82,"10.39.7",24,"Missing figure for UWB-Driven MMS UWB",null,"Please add a new figure","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"SUN, LIHSIANG",null,295,"Yes","MediaTek","Technical",82,"10.39.7",null,"How OWR direction is configured? RcpPollSlots and RcpResponseSlots does not seem to have value 0? ",null,"please clarify","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"TIAN, BIN",null,312,"No","Qualcomm","Technical",83,"10.39.8.1",3,"O-QPSK PHY may be used in the report phase",null,"as in the comment","Yes"]
[null,null,"VERSO, BILLY",null,469,"No","Qorvo","Technical",83,"10.39.8.2",11,"Since it looks like several NB channels starting at channel #50 don't overlap with 20 MHz WiFi, if this is the case maybe these should have some special extra weighting in the hopping algorigm?",null,"Is it worth having special treatment or special usage for these?","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"LI, HuanBang",null,130,"Yes","NICT","General",83,"10.39.8.3",13,"In this paragraph, 'device' and 'radio' are used for the same meaning. It would be better to unify the word.",null,"make change.","Yes"]
[null,null,"PAKROOH, POORIA",null,236,"No","Qualcomm","Technical",83,"10.39.8.3",13,"NB coexistence with other technologies in UNII-3 and UNII-5 bands needs to be addressed by defining a mandatory channel access mechanism for NB operation in UNII-3/5, with clear guidance for the implementers.\nA good option is the LBT mechanism proposed and evaluated in DCN 15-24-212/r5.",null,"1. Adopt a mandatory coexistence mechanism for NB operation in UNII-3 and UNII-5 bands. \n\n2. Define specific parameters for NB (such as LBT with ED threshold value, CCA duration, etc.)such that they are clear to the implementers.\n\nA good proposal is presented and evaluated in DCN 15-24-212/r5. \n\nAdd the following text from DCN 15-24-212/r5 following:\n\"A NB capable device operating in UNII-3 or UNII-5 band shall measure its NB transmission duty cycle.\nFor a NB capable device, if its NB transmission duty cycle is more than 2.5%, it shall perform listen-before-talk (LBT) before any NB transmission. Otherwise, LBT is optional.\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"QIAN, BIN",null,271,"No","Huawei","Technical",83,"10.39.8.3",13,"Since WiFi is disallowed to operate in 6GHz band in China, 5GHz UNII 3 band becomes very important for Wi-Fi in China. Therefore, it is better to mandate a coexistence mechanism between NB and Wi-Fi devices in 5GHz UNII 3 band even if this mandatory requirement is not specified in the regulations. ",null,"Change the sentence to \"If LBT is required before a transmission, either for regulatory reasons or as a coexistence mechanism, then the device shall perform CCA before each O-QPSK PHY transmission.\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Shellhammer, Steve",null,292,"No","Qualcomm","Technical",83,"10.39.8.3",13,"NB coexistence with other technologies in UNII-3 and UNII-5 bands needs to be addressed by defining a mandatory channel access mechanism for NB operation in UNII-3/5, with clear guidance for the implementers.\nA good option is the LBT mechanism proposed and evaluated in DCN 15-24-212/r5.",null,"Adopt a mandatory coexistence mechanism for NB operation in UNII-3 and UNII-5 bands. A good proposal is presented and evaluated in DCN 15-24-212/r5. \n\nAdd the following text from DCN 15-24-212/r5:\n\"A NB capable device operating in UNII-3 or UNII-5 band shall measure its NB transmission duty cycle.\nFor a NB capable device, if its NB transmission duty cycle is more than 2.5%, it shall perform listen-before-talk (LBT) before any NB transmission. Otherwise, LBT is optional.\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Rolfe, Benjamin",null,290,"Yes","BCA","Technical",83,"10.39.8.3",14," The behavior defined in this clause already exists in the standard, though it might not be clear to the reader this is so. Clarify that the methods defined in the standard as Random access methods (6.3.2) can be used to achieve the described behavior. Provide an example using SSBD that meets the timing constraints stated.",null,"Change \"then the device shall perform CCA before\" to \"then one of the channel access methods defined in 6.4.3 shall be used, with CCA mode 1 or 3 used, configured to meet the following constraints:\"  "]
[null,null,"TIAN, BIN",null,313,"No","Qualcomm","Technical",83,"10.39.4.2",16,"Details of LBT scheme need to be defined such like the energy detection threahold,",null,"as in the comment","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,470,"No","Qorvo","Technical",83,"10.39.8.2",16,"This talks about skipping for a ranging round, maybe it should be just \"for the current ranging exchange\", or might imagine the device later in the ranging round, having some ranging sub-rounds allocatged to range to another device and as this is some ms later it may well be successful.",null,"change to \"for the current ranging exchange\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Aldana, Carlos",null,10,"No","Meta","Technical",83,"10.39.8.3",20,"How long is the CCA duration?  Please add text that specifies it","I recommend  at least 18us so that it is consistent with latest ETSI 303687","I recommend  at least 18us so that it is consistent with latest ETSI 303687","Yes"]
[null,null,"Aldana, Carlos",null,11,"No","Meta","Technical",83,"10.39.8.3",20,"What should the EDT be?  Please specify","For channels 50 to 249, I recommend to use the latest compromise in 6 GHz which is max( –85 dBm, min( –65 dBm/MHz, –72 dBm/MHz – Ptx ) ), where Ptx is the transmit power in dBm.   For channels 0 to 49,  the phyCcaEdThreshold is set to -67 dBm/MHz - Ptx.","For channels 50 to 249, I recommend to use the latest compromise in 6 GHz which is max( –85 dBm, min( –65 dBm/MHz, –72 dBm/MHz – Ptx ) ), where Ptx is the transmit power in dBm.   For channels 0 to 49,  the phyCcaEdThreshold is set to -67 dBm/MHz - Ptx.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Aldana, Carlos",null,12,"No","Meta","Technical",83,"10.39.8.3",20,"In Figure 45, if the response  is sent within 18us, LBT is not necessary. ","Add a packet extension to either the end of the first packet or the beginning of the second packet to reduce the gap to less than 18us.","Add a packet extension to either the end of the first packet or the beginning of the second packet to reduce the gap to less than 18us.","Yes"]
[null,null,"Aldana, Carlos",null,13,"No","Meta","Technical",83,"10.39.8.3",22,"Change the \"may\" to a \"shall\" to enable a baseline NB coex mechanism","Change the \"may\" to a \"shall\" to be consistent with ETSI 303687 and adopt changes described in document 15-407-07","Change the \"may\" to a \"shall\" to be consistent with ETSI 303687 and adopt changes described in document 15-407-07","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"LI, HuanBang",null,131,"Yes","NICT","Technical",83,"10.39.8.3",22,"This mechanism should be an optional feature. Decision on using it or mot should be made according to local regulation.",null,"change 'shall' to 'may'","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"PAKROOH, POORIA",null,237,"No","Qualcomm","Technical",83,"10.39.8.3",22,"Sentence is unclear. What does \"according to regulatory constraints\" mean? ",null,"Change to :\"LBT shall be applied to channel numbers 0 to 249.\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"KREBS, ALEX",null,115,"Yes","Apple","Technical",83,"10.39.8.3",14,"The European Commission (EC) has announced on Feb 7 2025 that [B1] lacks technology neutrality therefore cannot be used to provide a presumption of conformity for NBFH equipment. Therefore 15.4ab devices following the depicted procedure cannot be used for harmonized spectrum access in Europe. Since the EC approval process typically takes 1 year or longer from the time of submission and no submission of a corrected draft of EN 303 687 after [B1] has made so far and no submission is announced or can be expected within the time scope of TG4ab, the invalid section needs correction.",null,"Replace all content of subsection 10.39.8.3 by: If LBT is required before a transmission, either for regulatory reasons or as a coexistence mechanism, then then one of the channel access methods defined in 6.3.2 or 10.45 with CCA mode 1 or 3  shall be applied by initiator and responder independently in each transmission slot, even if the same channel is used in consecutive slots. If LBT is not required, the same methods may be used to improve coexistence with other spectrum users.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,471,"No","Qorvo","Technical",84,"10.39.8.4",3,"I don't think it is clear where the channel switch occurs, i.e., it seems to be once per ranging block, but what happens when there are multiple ranging rounds involving same or different devices.  Initiator may use different rounds to range to different responders, if the switch only happens per block does the initiator and all the responders stay on the same NB channel for the whole block?  ",null,"This should be clarified, i.e. stated whether the initiator & multiple responders stay on same channel for the possible multiple ranging rounds and sub-rounds in single ranging block in one to many cases, interleaved and not, or if they switch for each interaction.  Ideally some example figures should be added to clarify it.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,174,"Yes","STMicroelectronics","Technical",84,"10.39.8.4.1",10,"the channel switching mechanism dynamically switch among the coordinated channels on each successive ranging round but not block.",null,"change \"block\" by \"round\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Aldana, Carlos",null,14,"No","Meta","Technical",84,"10.39.8.4.1",15,"if channel switching is disabled, how do we ensure that the channel that is chosen is not an 802.11 primary channel?","Prohibit single channel configuration which overlaps with 802.11 primary channels.   If we do this, we would prevent collisions from 802.11 beacons, probe requests, and probe responses","Prohibit single channel configuration which overlaps with 802.11 primary channels.   If we do this, we would prevent collisions from 802.11 beacons, probe requests, and probe responses","Yes"]
[null,null,"MAMAN, MICKAEL",null,175,"Yes","STMicroelectronics","Technical",84,"10.39.8.4.2",21,"How all 250 O-QPSK channels can be marked as blocked? At least CH2 and/or CH3 should be available.",null,"add \"The macMmsNbChannelAllowList shall at least contain channels 2 and 3\".","No",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Aldana, Carlos",null,15,"No","Meta","Technical",84,"10.39.8.4.2",22,"if all NB channels are occupied, we should migrates towards UWB driven MMS","Change the \"may\" to a \"shall\"","Change the \"may\" to a \"shall\"","Yes"]
[null,null,"VERSO, BILLY",null,472,"No","Qorvo","Technical",85,"10.39.8.4.3",5,"This is only talking about one initiator and one responder, the other cases should be included too... is there one seed for all nodes in a group so they all follow the hopping, or separate pair for each par of communicating devices. This is complex to specify correctly, and is probably in the domain of the NHL anyway (which knows what is going) to correctly set phyCurrentChannelInfo for the next message it wants to TX or RX.",null,"Probably good to also capture the general operation of  switching protocol in these more complex cases. ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,473,"No","Qorvo","Editorial",85,"10.39.9.1",12,"\"divides\" is wrong since the parameters are plural it should be \"divide\" singular",null,"change \"divides\" to \"divide\", and also \"specifies\" to \"specify\" on line 14","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,474,"No","Qorvo","Technical",85,"10.39.9.1",19,"The figure 46 is showing one-to-many poll and then POLL in next sub-round, is this same of different poll, The text about the figure does not talk about this being same or different.",null,"Make clarify what the poll is in second ranging sub-round in both the figure and the text description.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,475,"No","Qorvo","Technical",85,"10.39.9.1",23,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here, also the \"number of fragments ... shall be adjusted\" is problematic since it does not explicilty specify the MAC adjusts adjustment.  In practice  think probably the MMS UWB packet configuration is picked and then the RpDuration is set to be sufficiently big.",null,"Change sentence to \"In one-to-many MMS ranging, the same ranging phase duration mmsRpDuration, applies for each ranging sub-round in the ranging round, this is chosen to be suffficent for the MMS UWB packets being used.\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,476,"No","Qorvo","Editorial",85,"10.39.9.1",23,"capitalisation of \"In One-to-Many MMS Ranging\"",null,"change to \"In one-to-many MMS UWB ranging\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,477,"No","Qorvo","Technical",85,"10.39.9.1",31,"\"follows the same mechanism\" is insufficient to describe it.  Does the switch happen per NB TX, per sub-round, per round or when?  This is not clear in the referenced clause.  In one-to-many case this may be quite complex for all nodes to know what channel is to be used.",null,"Make it clear when the channel switch is to be done. And how it works with multiple nodes.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Rolfe, Benjamin",null,283,"Yes","BCA","Technical",86,"10.39.9.2",8,"Short-term parameters shall not be exchanged between the initiator and the responders is difficult to verify and may not be what we intend to say. It seems to contradict 10.39.3.8. At best this is unnecessary. There are probably a great many things that should not be exchanged between initiator and responder, such as elephants and wet puppies. It is not appropriate to specify what is not exchanged, only what is exchanged. Then there is the question of what to do if one receives short-term parameters when not expected. As stated this prohibits what is specified in 10.29.3.8, which is likely not what is intended. ",null,"Delete sentence "]
[null,null,"VERSO, BILLY",null,478,"No","Qorvo","Technical",86,"10.39.9.2",8,"Since \"shall not\" is hard to verify, the sentence \"Short-term parameters shall not be exchanged between the initiator and the responders\" probably should be changed.  Also the since this is in control of the NHL a \"shall\" is perhaps the wrong thing to say.  Actually I reckon what is meant here is that the Short-term parameters cannot be changed since the One-to-many Poll Compact frame with a Message Control field value of five, does not include the fields that would allow it.",null,"Replace the sentence with: \"This Compact frame format does not include the fields to request short term parameter changes\" ","Yes",null,null,null,null,"Suggested Assignment","BinQ (Contention-based 1toM ranging)"]
[null,null,"Rolfe, Benjamin",null,278,"Yes","BCA","Technical",86,"10.39.9.3",21,"\"The responders shall be capable of a fixed reply time of sufficient precision.\" does not (properly) specify a requirement without defining what \"sufficient\" in measurable quantaties. This is not defined in this amendment nor in the base standard.  Note that 10.29.6.5 of IEEE Std 802.15.4-2024 informs the implementer \"The accuracy of the resultant range will depend on how fine a control the responding device has on the transmit time of its response message, where every 1 ns error in TOF translates to approximately 30 cm range error.\" ",null,"Delete sentence (incomplete requirement)"]
[null,null,"VERSO, BILLY",null,479,"No","Qorvo","Technical",86,"10.39.9.3",21,"It is not really within one ranging slot. The current default value of macMmsRangingSlotDuration is 600 RSTU == 500 μs, and MMS fragment TX spacing is not based on slots in any case, it is fixed at 1ms irrespective of slot size used by the application for scheduling purposes.",null,"change \"one ranging slot\" to \"one milisecond\".","Yes",null,null,null,null,"Suggested Assignment","BinQ (Time-efficient 1toM ranging)"]
[null,null,"VERSO, BILLY",null,480,"No","Qorvo","Technical",86,"10.39.9.3",22,"This line is not clear. Is limited to \"two fragments\", given that there are clearly six fragments shown in Figures 48 and 49.  I assume it means two transmitted per device this should be clarified.  However it seems a very artificial limit and I am not sure why it is here, why not allow it for all MMS packet configurations, the benifit of this Time-efficiency is more pronounced for longer packets. Also for the UWB driven case this limit does not even allow for 1xRSF + 1xRIF to be included in addtion to the mandatory SYNC+SFD fragment. The limititation is not needed. Since the mode is already optional (by line 24) it can be optional how many fragments to support too.",null,"Delete this sentence.","Yes",null,null,null,null,"Suggested Assignment","BinQ (Time-efficient 1toM ranging)"]
[null,null,"VERSO, BILLY",null,481,"No","Qorvo","Editorial",86,"10.39.9.3",22,"SYNC+SFD is a shorthand for what is described elsewhere as \"SYNC and SFD\", should used a unified term.",null,"Change \"SYNC+SFD\" to \"the SYNC and SFD fragment\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,482,"No","Qorvo","Technical",86,"10.39.9.3",33,"This line is unclear. The previous line is talking about the case of only one responder, which must be the final sub-round. So there should not be a subsequent sub-round. I am not sure what fix is, but it needs a better descriptio. Perhaps a figure with 3 or 5 responders, covering one or two ranging rounds, each with required numbe of sub-rounds each, could be used to appropriately clarify where the one-to-many pole with message control 9 or 10, and the one-to-many poll with message control zero are to be used.",null,"Improve text and consider a figure, to clarify where the different poll messages are to be used.","Yes",null,null,null,null,"Suggested Assignment","BinQ (Time-efficient 1toM ranging)"]
[null,null,"VERSO, BILLY",null,483,"No","Qorvo","Technical",86,"10.39.9.3",34,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"shall be\" to \"is\".","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,484,"No","Qorvo","Technical",87,"10.39.9.3",8,"There will obviously be some small variability in this response scheduling since they will be timed from the poll RX time (which has some error) using in the local clock of each responder.  To reflect this, the part of the sentence beginning \"with the fragments..\" could be made into a separate sentence, as per proposed change.",null,"Make the sentence end into a separate sentence as follows: \"The response packets from responders one and two are nominally offset from the initiator's packet by 400 and 800 RSTU, respectively.","Yes",null,null,null,null,"Suggested Assignment","BinQ (Time-efficient 1toM ranging)"]
[null,null,"VERSO, BILLY",null,485,"No","Qorvo","Editorial",87,"10.39.9.3",14,"We don't need this mouthful \"HRP UWB PHY MMS packet\" when \"MMS UWB packet\" is used elsewhere.",null,"change to \"MMS UWB packet\"","No","Accepted",null,null,null,"DONE","changed all occurances"]
[null,null,"VERSO, BILLY",null,486,"No","Qorvo","Technical",87,"10.39.9.3",18,"These three MAC PIB \"...NSlots\" attributes should be NHL protocol control variables, since it is the NHL that is providing the report frames dictating the time of sending, the NHL rather than the MAC needs to manage all these phase durations rather than trying to have the MAC aware of the NHL protocol phases.",null,"Change to parameters to be agreed/known by NHLs, and update the text accordingly.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,487,"No","Qorvo","Technical",87,"10.39.9.3",19,"To avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here:",null,"Change \"shall transmit\" to \"transmits\", here and for the five additional occurances in the paragraph as it continues into p.88","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"PAKROOH, POORIA",null,238,"No","Qualcomm","Technical",88,"10.39.9.4",20,"Several drawbacks for this \"multiple RSF\" mode.\n 1. If multiple responders are at different ranges, which is a common case in ranging, it becomes almost impossible to retrieve the signal from the farther responder, as it could be burried under the cross-correlation sidelobe of the closer responder. In such scenarios, the time efficient one to many can be employed insted of multi transmission per slot. \n\n2. Also, the initiator needs to do multiple corss correlation to separate signals from different responders, elading to undesired complexity incraese. ",null,"Remove the \"multiple RSF transmissions per slot\" feature/functionality. Specifically remove subclause 10.39.9.4.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,488,"No","Qorvo","Editorial",88,"10.39.9.4.1",23,"extraneous ' after slot,",null,"remove it ","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,176,"Yes","STMicroelectronics","Technical",89,"10.39.8.4.3",3,"The procedure for multiple RSF transmissions in a slot is divided into three phases, the control phase, the ranging phase, and the measurement report phase. However in Figure 53 there is several Ranging phases and report phases",null,"please clarify. Two options i) change \"divided into three phases\" by \"composed of three different three phases ii) change Figure 53","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"LEE, JAEGOOK",null,119,"Yes","Samsung","Editorial",89,"10.39.9.4.2",5,"A paragraph seems missing after \"In the control phase, the initiator sends a ~\"",null,"Restore the missing part.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"LI, HuanBang",null,132,"Yes","NICT","Editorial",89,"10.39.9.4.2",5,"The line is wrongly broken.",null,"make change.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,489,"No","Qorvo","Editorial",89,"10.39.9.4.2",6,"seems <CR> at end of line has made a new paragraph of what should be the sams sentence.",null,"delete <CR> to make line 6 be a continuation of line 5","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,177,"Yes","STMicroelectronics","Technical",89,"10.39.8.4.3",24,"In this case the SYNC+SFD is sent only by the initiator. The responder does not follow figure 205.",null,"two options: add SYNC SFD for responder or delete this sentence.","No",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,490,"No","Qorvo","Editorial",89,"10.39.9.4.3",24,"SYNC+SFD is a shorthand for what is described elsewhere as \"SYNC and SFD\", should used a unified term to call this \"the SYNC and SDF fragment\"",null,"Change \"SYNC+SFD\" to \"SYNC and SFD\", on lines 24, 26 and 27.","No","Accepted",null,null,null,"DONE"]
[null,null,"LI, HuanBang",null,133,"Yes","NICT","Editorial",91,"10.39.10.1",12,"comma is put at a wrong location.",null,"modify as 'To illustrate this, …'.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,491,"No","Qorvo","Editorial",92,"10.39.10.2",1,"\"O-\" on its own.",null,"Used non-breaking \"-\"","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,178,"Yes","STMicroelectronics","Technical",93,"10.39.10.2",23,"The time A can also depend on the MMS order between the initiator and the responder",null,"change to \"depending on the slot size, the order and number of slots allocated to the ranging control phase poll and response.\"","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"MAMAN, MICKAEL",null,179,"Yes","STMicroelectronics","Technical",94,"10.39.10.2",7,"Optionnally, the MMsRangingRXOnTime can be set 600 RSTU from the Ranging TxTime according to MMS_Sync parameter",null,"Optionnally, the MmsRangingRxOnTime can be set 600 RSTU from the RangingTxTime according to MMS_Sync parameter","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"MAMAN, MICKAEL",null,180,"Yes","STMicroelectronics","Technical",94,"10.39.10.2",12,"Optionnally, the RangingTxTime can be set 600 RSTU from the MmsRangingRxOnTime according to MMS_Sync parameter",null,"Optionnally, the RangingTxTime can be set 600 RSTU from the MmsRangingRxOnTime according to MMS_Sync parameter","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"MAMAN, MICKAEL",null,181,"Yes","STMicroelectronics","Technical",94,"10.39.10.2",15,"The time A can also depend on the MMS order between the initiator and the responder",null,"change to \"might be different depending on the slot size, the order and number of slots allocated to this part of the control phase.\"","Yes",null,null,null,null,"Assigned",null,"Mickael"]
[null,null,"LI, HuanBang",null,134,"Yes","NICT","Editorial",94,"10.39.10.2",37,"A hyphen is lossed between 'O' and 'QPSK'.",null,"wirrten as O-QPSK.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,492,"No","Qorvo","Editorial",94,"10.39.10.2",37,"\"O PQSK\" missing the hyphen \"-\".",null,"change to \"O-QPSK\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,493,"No","Qorvo","Technical",95,"10.39.10.2",12,"Could add about clock offset correction for the SS-TWR calcualtion",null,"Add at end of line, \", with the clock offset from the MCPS-DATA.indication that delivered the O-QPSK response frame\"","Yes","Revised","Doc 15-25-0178-00-04ab-d02-miscellaneous-comment-resolutions-i.docx",null,null,"READY"]
[null,null,"VERSO, BILLY",null,494,"No","Qorvo","Technical",95,"10.39.11.1.2.1",29,"Especially as line 39 says the generartion of RPA prand is out of scope of this standard, to avoid the distinction of NHL or MAC and whether \"shall\" is approptiate we should change the language used here.  ",null,"Change \"shall use\" to \"uses\", and on next line \"shall communicate\" to \"communicates\"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"Kivinen, Tero",null,93,"No","Wi-SUN Alliance","Editorial",95,"10.39.11.1.2.1",30,"This is not first use of IRK, do not expand here. ",null,"Remove expansion of IRK.","No","Accepted",null,null,null,"DONE"]
[null,null,"Kivinen, Tero",null,94,"No","Wi-SUN Alliance","Technical",95,"10.39.11.1.2.1",35,"This method does not allow cryptographic algorithm agility, i.e., changing the algorithms in the future. ",null,"Include a method to specify secAeadAlgorithm as specified in the Table 9-9.","Yes"]
[null,null,"MAMAN, MICKAEL",null,182,"Yes","STMicroelectronics","Technical",95,"10.39.11.1.2.1",37,"Higher layer methods may be used to synchronize generation and application of RPA prand values between the initiator and the responder. The method to set or update the RPA PRand is missing. The Higher layer can set or update the RPA Prand PIB with MLME-SET.request primitive in the macIrkDescriptorElement for the associated macIrkEntry IRK stored.  ",null,"add at the end of the paragraph the following text \"The Higher layer can set or update the RPA Prand PIB with MLME-SET.request primitive in the macIrkDescriptorElement for the associated macIrkEntry IRK stored.\"","yes","Revised","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,495,"No","Qorvo","Technical",96,"10.39.11.1.2.1",7,"\"... using one or more IRKs that the receiver assumes...\" seems a little vague for a procedure.  Probably should refer to the PIB structure where the UL sets the IRK and relevant PRAND to use for the resolving of incoming frames",null,"Update the text to describe the RPA resolution process with reference to the macIrkDescriptor (if this is the appropriate attribute).  Consider whether a flow chart or other diagram is needed to clarify.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,496,"No","Qorvo","Technical",96,"10.39.11.1.2.2",16,"This sub-clause contains 5 shall statements, which would be bettter changed avoid the distinction of NHL or MAC. Especially I don't think we want to specify MAC mechanisms to generate random numbers, or keep track of what the NHL is doing in the protocol potentially over multiple sessions in parallel.",null,"change \"shall use\" to \"uses\", and \"shall be\" to \"is\", and delete the sentence on line 27.",null,"Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,497,"No","Qorvo","Editorial",96,"10.39.11.1.2.2",19,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"Change \"random address during the MMS initialization process\" to \"random addressed during MMS initialization\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,498,"No","Qorvo","Technical",96,"10.39.11.1.2.2",27,"This \"shall be able\" seems a little strange. It is the NHL that uses MCPS-DATA.request to send the Acquisition Compact frame and provide this address, so it is in control of this. This sentence is not needed. ",null,"Delete the sentence on line 27.","Yes",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Suggested Assignment","Hongwon (Public addressing)"]
[null,null,"Kivinen, Tero",null,95,"No","Wi-SUN Alliance","Technical",96,"10.39.11.1.2.3",36,"This text is confusing and mixed extended addresses and key source fields in a way which is hard to understand. ",null,"Change the text to say that devices are always identified using the extended address of the originator or destination, but the key id mode of 0x03 is used, where each key is identified with 64-bit KeySource which matches the owner of the key. I.e., use term KeySource when talking about the key identifier.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,499,"No","Qorvo","Technical",97,"10.39.11.1.2.3",5,"This sentence says mapping of extended address to the IRK are not defined in this standard, but we have added macIrkDescriptorElement which seems to allow for mapping between IRK and extended address, so I am not sure if this statemet is correct..",null,"Probably should revise the statement to add some description about this mapping, and/or reference where it is described..","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"CHITRAKAR, ROJAN",null,27,"No","Huawei","Technical",97,"10.39.11.1.3.1",16,"The Message Version field doesn't seem to be used in any Compact frame. If it is not used anywhere, its existence is not justified.",null,"Organize the applicable Compact frame variants (e.g., the O2M Poll Compact frame) into various Message Versions based on their intended use, e.g., a basic version, a version used for contention based O2M, a version for time-efficient O2M etc.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,500,"No","Qorvo","Editorial",97,"10.39.11.1.3.1",18,"\"value of shall be\"",null,"change to \"value shall be\"","No","Revised","Change \"Unless otherwise stated the Message Version field value of shall be zero.\" to \"The Message Version field value shall be zero.\"",null,null,"DONE","No non-zero values are specified anywhere in this standard"]
[null,null,"VERSO, BILLY",null,501,"No","Qorvo","Editorial",97,"10.39.11.1.3.2",23,"Title abbriviation mnemonic should be SMC TLVs since that is what the field is called in the frames where it is used",null,"change \"TLV\" to \"TLVs\" in the clause title.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,502,"No","Qorvo","Editorial",97,"10.39.11.1.3.2",25,"Would be good to also reference clause 10.39.3.9 where the mechanism is outlined.",null,"Add the reference","No","Accepted",null,null,null,"DONE"]
[null,null,"SUN, LIHSIANG",null,299,"Yes","MediaTek","Technical",98,"10.39.11.1.3.2",2,"\"The SMC Values field is a list of valid Message Control field values …\"",null,"suggest change to Message ID field values","Yes",null,null,null,null,"Assigned","I think technical. I have comment on SMC which I probably suggested assigning to Alex.  (Also the word \"valid\" not needed. )","Alex"]
[null,null,"VERSO, BILLY",null,503,"No","Qorvo","Technical",98,"10.39.11.1.3.2",2,"Should this \"list of valid Message Control field values\" be \"list of valid Message ID field values to include both the Message Control and Message Version fields\"",null,"change \"Message Control\" to \"Message ID\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,504,"No","Qorvo","Technical",98,"10.39.11.1.3.4",18,"I am wondering wherher macMmsNbChannelAllowList should be in the MAC or NHL.  I think perhaps it should be MAC, with the MAC provding some primitive with state to set the next hop channel, the NHL then knowing it is appropriate to now hip to next channel (because it has reached end of ranging round or block etc, would invole the primitive. Given we are switching between NB and UWB it may be better for the HNL to be in control of setting phyCurrentChanelInfo at the approipriate time for the protocol.\n",null,"Add primitive to provide the NB channel switch info. This would involve adding new clause 10.39.12 \"MAC management service primitives for NBA channel switching\" to contain the primitive. Updating to clause 10.39.8.4 to refer to new primitive(s) and incluide a statement that the next higher layer is responsible for setting phyCurrentChanelInfo after invoking the primitive.  Finally in this clause 10.39.11.1.3.4 add appropriate text and cross reference to 10.39.8.4 or a subclause there of.    ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,505,"No","Qorvo","Technical",98,"10.39.11.1.3.4",18,"I assume that the NHL will receive the frame with the channel map field and validate/decode it and the NHL will be the entity responsible for actually writing the new updatedmacMmsNbChannelAllowList at the appropriate time. The text should state this responsibility explicitly. ",null,"Add a statement to say it is the next higher layer's responsibility to process messages containing Channel Map field (all three flavours) and write the updatred updatedmacMmsNbChannelAllowList at the appropriate time. ","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,183,"Yes","STMicroelectronics","Technical",99,"10.39.11.1.3.4",3,"add \"bits: in Figure 60",null,"add \"Bits:\" in the upper left corner","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"SUN, LIHSIANG",null,300,"Yes","MediaTek","Technical",99,"10.39.11.3.6",5,"Response Status field's presence is determined based on whether the preceding poll frame requests long-term parameter change.\n\nIn this case this Response Status field is not needed because the Response frame itslef is an ack and responder needs to comprehend the Poll frame befre sending Response frame",null,"as in comment","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"MAMAN, MICKAEL",null,184,"Yes","STMicroelectronics","Technical",99,"10.39.11.1.3.4",11,"add \"bits: in Figure 61",null,"add \"Bits:\" in the upper left corner","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"PAKROOH, POORIA",null,239,"No","Qualcomm","Technical",100,"10.39.11.1.3.6",19,"This is not an \"affine\" set, what is the reason for naming this NbChannelAffineSet\"? Rename it to NbChannelStepSet or some other name.",null,"Rename all instances of NbChannelAffineSet  to NbChannelStepSet or some other name.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"LI, HuanBang",null,135,"Yes","NICT","Technical",101,"10.39.11.1.3.7",15,"The sentence started from 'the resultant code index ...' doesn't provide enough detailed information for code selection.",null,"add detailed description for code selection.","Yes",null,null,null,null,"Assigned","Huan-Bang volunteered via email","Huan-Bang"]
[null,null,"VERSO, BILLY",null,506,"No","Qorvo","Technical",102,"10.39.11.1.3.7",1,"This table caption is a bit confusing: \"SYNC & SHR fragment\" vs the reference to it a few lines before mentioning SYNC and SDF fragment.  This table covers the code for the initial SYNC and SFD fragment used in UWB driven MMS and also the code used for the SHR preamble code of any UWB packets (Compact frames or Data frames) employed in the MMS control and/or report phases, i.e. as referenced on p101 line 15 and on p107 line 4 respectively.",null,"Change table caption to the simpler: \"UWB preamble code index selection\" and change the heading of the RH column in the table to the more explicit. \"Code index (ci) to use for the SYNC and SFD fragment in UWB driven MMS UWB ranging packets, and to use for the preamble (SHR) of UWB packets employed in the control and report phases of UWB driven MMS UWB ranging.\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"PAKROOH, POORIA",null,240,"No","Qualcomm","Technical",102,"10.39.11.1.3.7",2,"Replace \"SYNC & SHR\" with \"SYNC and SFD\", or \"SHR\"",null,"In the first row of Table 13, replace \"SYNC & SHR\" with \"SYNC and SFD\", or \"SHR\"","Yes"]
[null,null,"MAMAN, MICKAEL",null,185,"Yes","STMicroelectronics","Technical",102,"10.39.11.1.3.7",3,"The code for SYNC & SHR is now the same as the MMS code index for lenghth-127 and length-91 ternary code. Previously it was length-91 ternary code for both ",null,"add a line in table 13: 9-24 |ci = ((Sequence Code Index field value - 1) modulo 8) + 25","yes"]
[null,null,"VERSO, BILLY",null,507,"No","Qorvo","Technical",103,"10.39.11.1.3.7",5,"There is no N_MSR field in the Ranging PHY Configuration field, it was changed to RSF Fragment Length",null,"Change \"N_MSR\" to \"RSF Fragment Length\" here on line 5, and also in the left hand column heading of Table 16.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,508,"No","Qorvo","Editorial",104,"10.39.11.1.3.9",4,"While a bit like an cross check there is no need to say \"seven octet\" when the filed figure already shows it is 56 bits.",null,"Delete \"seven-octet\", and look for other double definitions that can similarly be removed","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,509,"No","Qorvo","Technical",104,"10.39.11.1.3.9",5,"is it worth rearanging to place 8-bit fields first so that they are byte octet alinged and pairs of 4-bit fields next, etc. to make software handling that little bit more efficient.",null,"Consider.  Then rearrange if worth it.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,510,"No","Qorvo","Technical",104,"10.39.11.1.3.9",5,"\"encodes the value of\" appears a number of times in the description of the fiels of this figure. I believe compact frames with this field are passed through MCPS-DATA.request primitive, so I assume it is the NHL that sets the value to put in this field, i.e. MAC does not automaticallty populate it. If macMmsRangingSlotDuration, was a NHL variable (as I have proposed in another comment then it makes sense for NLH to signal the value wishes to use for a forthcoming ranging round.  In reception then the receiving NHL can choose to accept or not, and update its own slot duration variable.",null,"I think in general there is some confusion in the spec regarding these over the air message fields and how they are described.  Key to solving this is to bottom out what is passed via MCPS-DATA primitives and the respective roles of MAC and NHL in forming the content of the transmitted frames.Here we should change \"encodes ... \"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,511,"No","Qorvo","Technical",104,"10.39.11.1.3.9",6,"\"encodes the value of macMmsRangingSlotDuration\" is little confusing in meaning since it is unclear about NHL and MAC involvement. I think it is NHL and we make the clear.",null,"Change \"encodes the value of macMmsRangingSlotDuration\" to \"signals the slot duration the sender wishes to use .\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,512,"No","Qorvo","Technical",104,"10.39.11.1.3.9",8,"\"encodes the value of macMmsRangingRoundDuration\" is little confusing in meaning since it is unclear about NHL and MAC involvement. I think it is NHL and we make the clear.",null,"Change \"encodes the value of macMmsRangingRoundDuration\" to \"signals the ranging round duration the sender wishes to use.\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,513,"No","Qorvo","Technical",104,"10.39.11.1.3.9",10,"\"encodes the value of macMmsRangingBlockDuration\" is little confusing in meaning since it is unclear about NHL and MAC involvement. I think it is NHL and we make the clear.",null,"Change \"encodes the value of macMmsRangingBlockDuration\" to \"signals the ranging block duration the sender wishes to use\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,514,"No","Qorvo","Technical",104,"10.39.11.1.3.9",14,"Change wording to avoid the distinction of NHL or MAC, I think it is NHL that should be settng the phyCurrentChannelInfo to select the physical layer radio channel to use for next the transmission.",null,"change \"shall be\" to \"is\"",null,null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"VERSO, BILLY",null,515,"No","Qorvo","Technical",105,"10.39.11.1.3.9",5,"\"encodes the duration of macMmsRcpPollNSlots\" is little confusing in meaning since it is unclear about NHL and MAC involvement. I think it is NHL and we make the clear.",null,"Change \"encodes the duration of macMmsRcpPollNSlots used by\" to \"signals the number of slots the sender wishes to be used by ...\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"Pirhonen, Riku",null,267,"Yes","NXP Semiconductors","Technical",105,"10.39.11.1.3.9",7,"The minimum value for macMmsRcpPollNSlots can be 0",null,"change the range from 1 - 15 to 0 - 15","No",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Ben"]
[null,null,"VERSO, BILLY",null,516,"No","Qorvo","Technical",105,"10.39.11.1.3.9",8,"\"encodes the duration of macMmsRcpRespNSlots\" is little confusing in meaning since it is unclear about NHL and MAC involvement. I think it is NHL and we make the clear.",null,"Change \"encodes the duration of macMmsRcpRespNSlots used by\" to \"signals the number of slots the sender wishes to be used by ...\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"MAMAN, MICKAEL",null,186,"Yes","STMicroelectronics","Technical",105,"10.39.11.1.3.9",9,"one to many Response compact frame instead of Poll",null,"change Poll by Response","yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"Pirhonen, Riku",null,268,"Yes","NXP Semiconductors","Technical",105,"10.39.11.1.3.9",10,"The minimum value for macMmsRcpRespNSlots can be 0",null,"change the range from 1 - 15 to 0 - 15","No",null,"Doc 15-25-0179-00-04ab-lb213-lhf-needing-confirmation-or-discussion.docx",null,null,"Assigned",null,"Riku"]
[null,null,"VERSO, BILLY",null,517,"No","Qorvo","Technical",105,"10.39.11.1.3.9",11,"encodes the duration of macMmsRpDuration",null,"change to \"encodes the ranging phase duration\"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,518,"No","Qorvo","Technical",105,"10.39.11.1.3.9",11,"encodes the duration of macMms1stReportNSlots",null,"change to \"encodes the duration of the first reporting period of the reporting phase\"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,519,"No","Qorvo","Technical",105,"10.39.11.1.3.9",13,"seems to be spefifgying both TX and RX activity of NHL with SHALL and I think this was already covered elsewhere.(p80 L24)",null,"Delete the sentence",null,null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"VERSO, BILLY",null,520,"No","Qorvo","Technical",105,"10.39.11.1.3.9",20,"encodes the duration of macMms2ndReportNSlots",null,"change to \"encodes the duration of the second reporting period of the reporting phase\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"SUN, LIHSIANG",null,303,"Yes","MediaTek","Technical",105,"10.39.11.1.3.9",22,"MrpThirdSlots is not used by \"either the initiator or the responder\" for transmission based on Figure 50",null,"change to initiator","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,521,"No","Qorvo","Technical",105,"10.39.11.1.3.9",22,"encodes the duration of macMms3rdReportNSlots",null,"change to \"encodes the duration of the third reporting period of the reporting phase\"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,522,"No","Qorvo","Technical",105,"10.39.11.1.3.9",22,"encodes the value of macMmsNonInterleavedMode",null,"change to \"encodes the interleaving mode to be used \"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,523,"No","Qorvo","Editorial",105,"10.39.11.1.3.9",25,"The Non-interleaved Mode field is badly named since it signals both interleaved and non-interleaved modes",null,"Rename to interleaving selection, to include the non interleaved and interleaved and hybrid modes.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,524,"No","Qorvo","Technical",105,"10.39.11.1.3.9",28,"For interleaving modes, I think rather then talking about interleaved/non-interleaved sub-rounds, it would be mor logical to talking about interleaved and non-interleaved SS-TWR and DS-TWR, Hybrid DS-TWR, and OWR which by definition is not interleaved.",null,"Redefining values in Table 19 based on ranging algorithm:\n0 is SS-TWR (A single interleaved sub-round).\n1 is OWR ranging (a single non-interleaved sub-round)\n2 is SS-TWR (2x non-interleaved sub-rounds)\n3 is DS-TWR (3x non-interleaved sub-rounds)\n4 is DS-TWR (4x non-interleaved sub-rounds)\n5 is DS-TWR (1x interleaved sub-round and 1 non-interleaved)","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"VERSO, BILLY",null,525,"No","Qorvo","Technical",105,"10.39.11.1.3.9",29,"Looking at the list we are missing DS-TWR using interleaved packets, This is like #4 using 4 packets, but taking half the time.",null,"Add 6: DS-TWR using 2 interleaved sub-rounds.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"Aldana, Carlos",null,16,"No","Meta","Technical",106,"10.39.11.1.3.10",2,"4 octets seems excessive.  Can we make it more compact?","Change resolution to a larger value","Change resolution to a larger value","Yes"]
[null,null,"VERSO, BILLY",null,526,"No","Qorvo","Editorial",106,"10.39.11.1.3.10",2,"I reckon we could merge this and next field (10.39.11.1.3.11) into a single defintion of what a Time offset is, units and range are same.  Or better still since the description is so short, moving it inline.",null,"Consider either merging these or integrarting the text into where they are used, rather than referenceing such a small paragraph. SOR Time Offset seems easy to say directly in the couple of places it's used.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Aldana, Carlos",null,17,"No","Meta","Technical",106,"10.39.11.1.3.11",7,"4 octets seems excessive.  Can we make it more compact?","Change resolution to a larger value","Change resolution to a larger value","Yes"]
[null,null,"VERSO, BILLY",null,527,"No","Qorvo","Editorial",106,"10.39.11.1.3.12",13,"\"channel switching function\"",null,"change to channel switching protocol","No",null,null,null,null,"Assigned","Look at other places this appears","Editor"]
[null,null,"VERSO, BILLY",null,528,"No","Qorvo","Technical",106,"10.39.11.1.3.13",17,"I think macMmsControlPhaseMode and value of macMmsReportPhaseMode should be NHL protocol control variables and not MAC variables.",null,"on line 17 change \"defines the value of macMmsControlPhaseMode which corresponds to\" to \"signals\" and on line 20, similarly, replace \"defines the value of macMmsReportPhaseMode which corresponds to\" with \"signals\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"SUN, LIHSIANG",null,294,"Yes","MediaTek","Technical",107,"10.39.11.1.3.13",3,"\"When When UWB modulation is selected for the control and/or the report phase, the SHR preamble code used for these UWB packets is determined based on the Sequence Code Index field as per Table 13\"\n\nIf sequence code index is 9~24, it does not seem right length 127 SHR is used for 1.95Mbps UWB PPDU",null,"Clarify if sequence code index is 9~24, in MMS packet  length 127 code is used, But in ctrl/report UWB packet SHR, length 91 code is used","Yes"]
[null,null,"LI, HuanBang",null,136,"Yes","NICT","Technical",107,"10.39.11.1.3.13",5,"According to the description that when the Control Phase Config field is set to 14, the Report Phase Config field can be set to either 14 or 15. This should be modified to a description like the Report Phase Config field shall be set to the same value as Control Phase Config field is set. ",null,"modify the sentence.","Yes"]
[null,null,"PAKROOH, POORIA",null,241,"No","Qualcomm","Technical",107,"10.39.11.1.3.13",8,"This sentence is unclear. Please clarify what is meant by \"shall match the PHY in use in the current MMS UWB mode\"",null,"Please clarify what is meant by \"shall match the PHY in use in the current MMS UWB mode\"","Yes"]
[null,null,"MAMAN, MICKAEL",null,187,"Yes","STMicroelectronics","Technical",108,"10.39.11.1.3.14",4,"The Management PHY configuration field can also be included in the message content field of the compact frame",null,"add \"or in the message content field of the compact frame\"","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"MAMAN, MICKAEL",null,188,"Yes","STMicroelectronics","Technical",108,"10.39.11.1.3.14",7,"The Management MAC configuration field can also be included in the message content field of the compact frame",null,"add \"or in the message content field of the compact frame\"","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"MAMAN, MICKAEL",null,189,"Yes","STMicroelectronics","Technical",108,"10.39.11.1.3.14",10,"The Ranging PHY configuration field can also be included in the message content field of the compact frame",null,"add \"or in the message content field of the compact frame\"","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"MAMAN, MICKAEL",null,190,"Yes","STMicroelectronics","Technical",108,"10.39.11.1.3.14",13,"The MMS Number of Fragments field can also be included in the message content field of the compact frame",null,"add \"or in the message content field of the compact frame\"","yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,529,"No","Qorvo","Technical",109,"10.39.11.1.3.15",16,"This field looks like a better home for the signalling the interleaving ranging mode currently placed in MAC Configuration and also talking about ranging modes OWR, SS-TWR, DS-TWR etc.   It is really NHL that is really implementing the ranging protocol and sending the packets involved at the appropriate time.",null,"Move it to here, if that makes sense.  And possibly merge them if there is cross over.","Yes",null,null,null,null,"Assigned",null,"Riku"]
[null,null,"VERSO, BILLY",null,530,"No","Qorvo","Technical",110,"10.39.11.2",8,"The Secured Compact frame itself, is not lised as eligible (or not eligible) for securing.  It is inside the ranging block but proably should say that it is not eligible.",null,"State that the secured frame itself shall not be iteratively/recursively secured into another secured frame.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,531,"No","Qorvo","Technical",110,"10.39.11.2",9,"The criteria for securing seems to be whether the slot index is available, to act as the nonce.  For the ineligible frames we could we optionally include a nounce frame counter, e.g. using the Secured Control field reserved bit 15 to signal its presence. Would take no additional space when not needed.  Number could be continmued as slot inex when slotted mode is established.  ",null,"Consider allowing this, to make a more rounded spec","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,532,"No","Qorvo","Technical",110,"10.39.11.2",9,"Vendor specific frames are not covered here, they could be used in slotted mode or not.  Woulld be good to have a way to secure therm.  Vendor specific IE can be secured in 15.4 data frames.  It is very likely that vendor specifc compact frames will have content that also needs to be secured. Such securing is a normal function of the MAC so it should really be done here.",null,"Add mechanism incorporate vendor specific frames into thise securing process.  Possibly will need have option to include RPA hash and other fields into the vendor specific frames to allow for this, which might be a good thing to allow common handling in the MAC.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,533,"No","Qorvo","Editorial",110,"10.39.11.2",13,"\"mechanism described in 10.39.11.1.3.2\" but there is no mechanism defined there just the field format.",null,"Correct text say this is a cross reference to the SMC TLV field, and add a reference to clause 10.39.3.9 where the mechanism is outlined.","No","Revised","Changed mechanism reference to 10.39.3.9, and reference the SMC TLV field (10.39.11.1.3.2) in  10.39.3.9.",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,534,"No","Qorvo","Technical",111,"10.39.11.3",1,"That compact frame encoding does not lend itself to streamlined message parsing because each Compact Frame ID and Message ID is a separate message with different layout.  Before it is too late let's consider whether it could/should be improved.",null,"Consider whether there is a better way. (I plan to prepare a submission with some suggestions to help the group in this consideration.)","No",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"VERSO, BILLY",null,535,"No","Qorvo","Editorial",111,"10.39.11.3",10,"The Message ID field was split into two 4-bit fields, Message Version field and Message Control field, defined in clause 10.39.11.1.3.1.  For expediency all the individual Compact frame Content Field format figures were not changed. And the text repitedly says \"Message Control field (within the Message ID field)\" which is a bit clunky.",null,"Update all Compact Frame Content field format figures to have the two fields of Figure 56, Format of the Message ID field, and removing \"Message ID\" everywhere.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"CHITRAKAR, ROJAN",null,28,"No","Huawei","Technical",111,"10.39.11.3.1",10,"The Message ID field is not described. Applicable for all sub-clauses describing Compact frames.",null,"Add description or reference for the Message ID field in all sub-clauses describing Compact frames.","Yes"]
[null,null,"VERSO, BILLY",null,536,"No","Qorvo","Technical",111,"10.39.11.3.1",14,"This statement is an optimisation of what can be sginalled in SMV TLVs.  Question: Should we have similar optimisations/statements for other frame transmissions, in similar terms of expected support.",null,"Consider whether this is a good thing to do and add the appropriate statements as needed, for one to many and other flavours of message or field inclusions.","No",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"MAMAN, MICKAEL",null,191,"Yes","STMicroelectronics","Technical",111,"10.39.11.3.1",17,"In the advertising poll compact frame, the presence bitmap is always 2 as the supported OQPSK modulation modes is present and the SMC TLVs can be not present",null,"set 2 octets for presence bitmap in figure 73 and add 0 for SMC TLVs","Yes"]
[null,null,"VERSO, BILLY",null,537,"No","Qorvo","Technical",111,"10.39.11.3.1",24,"in the interest of saving space there seems little point in having a presence bitmap if all it is doing is saying whether the SMC TLVs field is present. The length of the SMC TLVs field already has to be inferred from the length of the frame, (which is not stated but perhaps should be), so its presence can be similarly inferred.  And probably handiest to put the SMC TLVs field  at the end of the frame too.",null,"Remove the presence bitmap (saving 2 octets) and move SMC TLVs field to the end, and add a statemet to say that the SMC TLVs field length can be determined from the frame length.","No",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,538,"No","Qorvo","Editorial",112,"10.39.11.3.2",11,"Perhaps this statement should come before the statemenet on line#8.",null,"Move it to before paragraph on line 8, with the (within the Message ID field) wording moving too. ","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,539,"No","Qorvo","Editorial",112,"10.39.11.3.2",15,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"8\" to \"7\" in Figure 75. ","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,540,"No","Qorvo","Editorial",113,"10.39.11.3.2",1,"Figure 76, field \"Supported O-QPSK Modulation Modes\" octet length is missing \"/\"",null,"Change \"01\" to \"0/1\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,541,"No","Qorvo","Technical",113,"10.39.11.3.2",1,"Would be good to put the SMC TLVs field at the end, and look to do the same in any other frames containing it, since remaining Message Content would then all be SMC TLV structures.",null,"Move SMC TLVs field to the end of the message.","No",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,542,"No","Qorvo","Technical",113,"10.39.11.3.2",17,"Would be good to say that the SMC TLVs field length can be determined from the frame length.",null,"add a statemet to say that the SMC TLVs field length can be determined from the frame length.","Yes",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,543,"No","Qorvo","Technical",114,"10.39.11.3.3",2,"I think from line 2 should be a new paragraph, also it should not be a note, since it ie mandating behaviour.",null,"Make into a separate parargaraph without the \"note\".","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,544,"No","Qorvo","Technical",114,"10.39.11.3.3",3,"the term \"eligible responder\" is used here (also appears later in te std in 6 places), but it is not really explained.  Maybe we don't need the word \"eligible\" here at all.",null,"Explain what it is or delete word \"eligible\", in ALL SIX places that \"eligible responder\" is used, i.e., change all six to simple \"responder\".","Yes",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,545,"No","Qorvo","Technical",114,"10.39.11.3.3",13,"I think we could say here that this as an RPA HASH, rather than above on line 2. (And do the same on line 25 too).",null,"On lines 13 and 24, change the phrase \"identifies the address of a responder\" to \"is an RPA Hash field value generated using the RPA Prand field value from the initiator's Advertising Poll Compact frame and the IRK of the responder\".  And remove the sentence from line 2.","Yes",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,546,"No","Qorvo","Editorial",114,"10.39.11.3.3",14,"The field has such a short description it could be here directly.",null,"Consider moving the field definition inline, here and on line 1 of following page, and anywhere else it is used.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,547,"No","Qorvo","Technical",115,"10.39.11.3.3",7,"In the MCPS-DATA.request, the NHL provides the IRK of the receiving device via the DstAddr and/or the IRK of the transmitting device in the SourceIrk paramete, so it is the NHL that is making this choice depending on which it provides?  The wording here does not reflect how the primitive is used",null,"Reword to say something like: RPA Hash field shall be calculated as specified using the IRK supplied in the MCPS-DATA.request.  For a single responder the DstAddr parameter provides responders IRK, otherwise the initiator's IRK provided by the SourceIrk parameter is used.","Yes",null,null,null,null,"Suggested Assignment","Rojan + Alex?"]
[null,null,"MAMAN, MICKAEL",null,192,"Yes","STMicroelectronics","Technical",115,"10.39.11.3.4",10,"missing value \"one\" for Message Control field of start of ranging compact frame",null,"add \"one\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,548,"No","Qorvo","Editorial",115,"10.39.11.3.4",10,"\"shall be one of the values: zero, or two.\" is missing \"one\"",null,"Change \"zero, or two.\" to \"zero, one or two.\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,549,"No","Qorvo","Editorial",115,"10.39.11.3.4",15,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"8\" to \"7\" in Figure 82","No","Accepted",null,null,null,"DONE"]
[null,null,"CHITRAKAR, ROJAN",null,29,"No","Huawei","Technical",116,"10.39.11.3.3",6,"Startup Status field sounds a bit weird.",null," Change \"Startup Status field' to \"Initialization Status field\", or simply \"Status field\".","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,550,"No","Qorvo","Technical",116,"10.39.11.3.3",9,"Values REJECT_WITH_ADDR_DUP, and ACCEPT_WITH_NEW_ADDR are not discussed in referenced clause 10.39.3.2, seems they are only used in public SOR.",null,"We should have a separate status parameter / table defintiion for \"Public Start Status\" for that usage and have them here. There is no reason to have a common table,which forces one to keep talking about the values that don't apply. ","Yes",null,null,"PUB",null,"Assigned",null,"Hongwon"]
[null,null,"VERSO, BILLY",null,551,"No","Qorvo","Editorial",116,"10.39.11.3.4",10,"The Table 25—Values of the Startup Status field is using ugly looking names a bit like an enumeration.",null,"Consider replacing with short no capitalised descriptions.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,552,"No","Qorvo","Editorial",117,"10.39.11.3.4",21,"blank numbered line",null,"remove it","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,193,"Yes","STMicroelectronics","Technical",118,"10.39.11.3.5",11,"Now one-to-one poll compact frame can convey long term operating parameters",null,"add \"or long-term\" after short-term","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,553,"No","Qorvo","Technical",118,"10.39.11.3.5",15,"In the MCPS-DATA.request, the NHL provides the IRK of the receiving device via the DstAddr and/or the IRK of the transmitting device in the SourceIrk paramete, so it is the NHL that is making this choice depending on which it provides?  The wording here does not reflect this.",null,"Reword to say something like: RPA Hash field shall be calculated as specified using the IRK supplied in the MCPS-DATA.request.  For a single responder the DstAddr parameter provides responders IRK, otherwise the initiator's IRK provided by the SourceIrk parameter is used. And... Similarly review/revise similar statements on RPA Hash and IRKs for all compact frame descriptions where similar statements are made.","Yes",null,null,"RPA",null,"Assigned",null,"Alex"]
[null,null,"CHITRAKAR, ROJAN",null,30,"No","Huawei","Technical",118,"10.39.11.3.5",25,"Can all the existing O2O Poll message variants also be used for non-interleaved mode? To avoid confusion (for the responder) with interleaved mode, it may be better to define new variants for non-interleaved mode even if the content of the frames are the same.",null,"Define new variants of O2O Poll compact frames to be used for non-interleaved mode and describe their usage in subclause 10.39.7.","Yes"]
[null,null,"QIAN, BIN",null,272,"No","Huawei","Technical",118,"10.39.11.3.5",26,"The reason for having all-zero Message Content may not be clear to readers not involved in the standard development",null,"Change the sentence to \"When the Message Control field value is zero the Message Content field shall consist of two octets with the value of zero as shown in Figure 87 to assist CFO estimation\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,554,"No","Qorvo","Editorial",119,"10.39.11.3.5",1,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,194,"Yes","STMicroelectronics","Technical",119,"10.39.11.3.5",7,"the last reserved bit of the poll control field can be used to indicate the presence of the presence bitmap",null,"change \"reserved\" in bit 7 by \"presence bitmap presence\". Add the size 0 for the presence bitmap in Figure 88. Add page 102 line 4 the presence bittap presence field when set to one indicates thet the presence bitmap field is present.","yes"]
[null,null,"VERSO, BILLY",null,555,"No","Qorvo","Technical",120,"10.39.11.3.5",17,"\"Either the NB Channel Map field or the NB Channel field may be present, but not both. \"... Given that they are mutually exclusive. We can save having the NB Channel Present bit in the presence bitmap and reuse the NB Channel Map Present field to also signal presence of the NB Channel field. (I have already identified a need for another presence bit, see my comment on p121-L12",null,"Rationalise to a single bit, to indicate that channel specification info is present in the message. Which type then being determined by the value of the Long-Term Parameters Update field.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,556,"No","Qorvo","Technical",120,"10.39.11.3.6",26,"I guess this means in the MCPS-DATA.request, DstAddr mode is NONE and the SrcAddMode is COMPACT so tyhat the device sused the SourceIrk parameter",null,"Say something about this IRK being supplied by the SourceIrk parameter in the MCPS-DATA.request.\nSimilarly review/revise similar statements on RPA Hash and IRK for all compact frame descriptions where similar statements are made.","Yes",null,null,"RPA",null,"Assigned",null,"Alex"]
[null,null,"CHITRAKAR, ROJAN",null,31,"No","Huawei","Technical",120,"10.39.11.3.6",30,"Can all the existing O2O Response message variants also be used for non-interleaved mode? To avoid confusion with interleaved mode, it may be better to define new variants for non-interleaved mode even if the content of the frames are the same.",null,"Define new variants of O2O Response compact frames to be used for non-interleaved mode and describe their usage in subclause 10.39.7.","Yes"]
[null,null,"QIAN, BIN",null,273,"No","Huawei","Technical",120,"10.39.11.3.6",30,"The reason for having all-zero Message Content may not be clear to readers not involved in the standard development",null,"Change the sentence to \"When the Message Control field value is zero the Message Content field shall consist of five octets with the value of zero as shown in Figure 91 to assist CFO estimation\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,557,"No","Qorvo","Editorial",121,"10.39.11.3.6",5,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,558,"No","Qorvo","Technical",121,"10.39.11.3.6",5,"The format Figure 92,can could cover all the cases with a single format definition, i.e., set the presence octet to all 0 and allow 4 padding octets, and give exactly same content as Figure 91. Even if there is good reason for having as sepcial frame for the figure 91 case. We could still allow the more general encodeing to also have that same ability by deleting the paragraph on line 20, and allowing for up to 4 padding bytes. ",null,"Consider reducing to a single format, or, allowing for the Figure 91 format to also reduce to a five 0x00 octets when the other fields are not needed.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,559,"No","Qorvo","Technical",121,"10.39.11.3.6",12,"This line says \"The Response Status field is present and set to LTP_ACK if the responder acknowledges the long-term operating parameters included in the preceding poll frame\"... Essentially the presence of the field is the ACK signal, but how do we know whether this field is present or not?  We could add a bit to the presence bitmap, or, make it always present,and have two values defined in the table, but since it is only a yes/no signal I think we could just allocate one bit for the signal (in the presence bitmap?). ",null,"Add an LTP ACK bit into the presence bitmap. (It may need extension to a third octet to do this, but I think NB Channel Present bit could be merged into NB Channel Map Present field since they are mutually exclusive, and that would free a bit to do this ACK.).","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,560,"No","Qorvo","Editorial",121,"10.39.11.3.6",14,"Table 27—Values of the Response Status field is using ugly looking names a bit like an enumeration.",null,"Consider replacing with short no capitalised descriptions.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,561,"No","Qorvo","Technical",121,"10.39.11.3.6",22,"Should the Response Status field be mentioned here also? I guess it could be on it's own?",null,"Add \"Response Status field\" into this list.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"MAMAN, MICKAEL",null,195,"Yes","STMicroelectronics","Technical",121,"10.39.11.3.6",23,"the One-to-one Response Compact frame with Message Control field value of one can be used only for Response status",null,"add \" or response status\"","yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"CHITRAKAR, ROJAN",null,32,"No","Huawei","Technical",122,"10.39.11.3.7",12,"What happens if the Initiator encounters some error during timing measurements? How does it  indicate the error condition? The comment is also applicable for other variants of the Report frame.",null,"Use an impossible value (e.g., 0) of the Round-trip Time to indicate an error in the measurement.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,562,"No","Qorvo","Technical",122,"10.39.11.3.7",15,"\"Its presence can be inferred from the frame length.\", base standard does not use \"inferred\" but says \"determined\" also I note in this case we could also determine the length of the passthrough data from the frame length.  If that was true in all cases we would not need a length octet in the pass thorough field.",null,"(I belive it is true in all 10 cases where there is passthough data). So change the statement for each of these to say: \"The presence and length of the pass through data can be determined from the frame length\", and then we can probably delete 10.39.11.1.3.3.","Yes",null,null,null,null,"Suggested Assignment","Rojan or Alex?"]
[null,null,"CHITRAKAR, ROJAN",null,34,"No","Huawei","Technical",122,"10.39.11.3.7",16,"The usage of Message control one should be explained.",null,"Add description to explain that Message control one is used for DS-TWR.","Yes"]
[null,null,"MAMAN, MICKAEL",null,196,"Yes","STMicroelectronics","Technical",122,"10.39.11.3.7",20,"This text is specific to non interleaved MMS. It could be extended to any DS-TWR",null,"Add \"In non-interleaved mode\", before the definition of Round-trip Time and Reply Time field. Extention with \"RMARKER selected\"","yes"]
[null,null,"CHITRAKAR, ROJAN",null,33,"No","Huawei","Technical",122,"10.39.11.3.7",24,"What happens if the Initiator encounters some error during timing measurements? How does it  indicate the error condition? The comment is also applicable for other variants of the Report frame.",null,"Use an impossible value (e.g., 0) of the Reply Time to indicate an error in the measurement.","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"SUN, LIHSIANG",null,302,"Yes","MediaTek","Technical",122,"10.39.11.3.7",24,"The Reply Time field description does not seem to work for non interleaved mode 4",null,"as in comment","Yes"]
[null,null,"VERSO, BILLY",null,563,"No","Qorvo","Editorial",123,"10.39.11.3.8",16,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"CHITRAKAR, ROJAN",null,35,"No","Huawei","Technical",124,"10.39.11.3.8",11,"A report variant of Figure 98 that includes \"Round-trip time\" field is also required.",null,"Add the report variant (Message control three) of Figure 98 that includes \"Round-trip time\" field is also required.","Yes"]
[null,null,"CHITRAKAR, ROJAN",null,36,"No","Huawei","Technical",124,"10.39.11.3.8",11,"The usage of Message control two should be explained.",null,"Add description to explain that Message control two is used for DS-TWR.","Yes"]
[null,null,"MAMAN, MICKAEL",null,197,"Yes","STMicroelectronics","Technical",124,"10.39.11.3.8",20,"This text is specific to non interleaved MMS. It could be extended to any DS-TWR",null,"Add \"In non-interleaved mode\", before the definition of Round-trip Time and Reply Time field. Extention with \"RMARKER selected\"","yes"]
[null,null,"CHITRAKAR, ROJAN",null,37,"No","Huawei","Technical",124,"10.39.11.3.9",24,"Can all the existing O2M Poll message variants also be used for non-interleaved mode? To avoid confusion (for the responder) with interleaved mode, it may be better to define new variants for non-interleaved mode even if the content of the frames are the same.",null,"Define new variants of O2M Poll compact frames to be used for non-interleaved mode and describe their usage in subclause 10.39.7.","Yes"]
[null,null,"MAMAN, MICKAEL",null,198,"Yes","STMicroelectronics","Technical",124,"10.39.11.3.9",27,"Now one-to-many poll compact frame can convey long term operating parameters",null,"add \"or long-term\" after short-term","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"QIAN, BIN",null,274,"No","Huawei","Technical",125,"10.39.11.3.9",8,"The reason for having all-zero Message Content may not be clear to readers not involved in the standard development",null,"Change the sentence to \"When the Message Control field value (within the Message ID field) is zero the Message Content field shall be formatted as shown in Figure 101 to assist CFO estimation\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"MAMAN, MICKAEL",null,199,"Yes","STMicroelectronics","Technical",125,"10.39.11.3.9",14,"This one-to-many Poll Compact frame is used for basic one-to-many ranging with responder report",null,"add \"This one-to-many Poll Compact frame is used for basic one-to-many ranging with responder report\"","Yes",null,null,null,null,"Suggested Assignment","Jinjing"]
[null,null,"MAMAN, MICKAEL",null,200,"Yes","STMicroelectronics","Technical",125,"10.39.11.3.9",24,"This one-to-many Poll Compact frame is used for basic one-to-many ranging with responder report",null,"add \"This one-to-many Poll Compact frame is used for basic one-to-many ranging with responder report\"","Yes",null,null,null,null,"Suggested Assignment","Jinjing"]
[null,null,"MAMAN, MICKAEL",null,201,"Yes","STMicroelectronics","Technical",127,"10.39.11.3.9",16,"The One-to-many Poll Compact frames with the Message Control field values (within the Message ID field) of seven and eight are used for basic one-to-many ranging when operating parameters are updated.",null,"add \"The One-to-many Poll Compact frames with the Message Control field values (within the Message ID field) of seven and eight are used for basic one-to-many ranging when operating parameters are updated.\"","Yes"]
[null,null,"VERSO, BILLY",null,564,"No","Qorvo","Editorial",128,"10.39.11.3.9",1,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,565,"No","Qorvo","Editorial",129,"10.39.11.3.9",11,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,202,"Yes","STMicroelectronics","Technical",130,"10.39.11.3.9",2,"This one-to-many Poll Compact frame is used for Time-efficient one-to-many ranging",null,"add in line 1 \"The One-to-many Poll Compact frames with the Message Control field values (within the Message ID field) of nine and ten are used for Time-efficient one-to-many ranging\"","Yes"]
[null,null,"QIAN, BIN",null,275,"No","Huawei","Technical",130,"10.39.11.3.10",4,"The reason for having all-zero Message Content may not be clear to readers not involved in the standard development",null,"Change the sentence to \"When the Message Control field value is zero, the Message Content field shall be formatted as shown in Figure 113 to assist CFO estimation\"","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,566,"No","Qorvo","Editorial",131,"10.39.11.3.10",10,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,203,"Yes","STMicroelectronics","Technical",131,"10.39.11.3.10",15,"the One-to-many Response Compact frame with Message Control field value of one can be used only for Response status",null,"add \" or response status\"","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"VERSO, BILLY",null,567,"No","Qorvo","Technical",131,"10.39.11.3.10",15,"Should the Response Status field be mentioned here also?",null,"Add \"Response Status field\" into this list.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"CHITRAKAR, ROJAN",null,38,"No","Huawei","Technical",131,"10.39.11.3.10",22,"Can all the existing O2M Response message variants also be used for non-interleaved mode? To avoid confusion with interleaved mode, it may be better to define new variants for non-interleaved mode even if the content of the frames are the same.",null,"Define new variants of O2M Response compact frames to be used for non-interleaved mode and describe their usage in subclause 10.39.7.","Yes"]
[null,null,"VERSO, BILLY",null,568,"No","Qorvo","Technical",131,"10.39.11.3.10",23,"See my comment on p121 L#12, LTP_ACK could be done with just a bit in the presence bitmap rather than a whole octet,",null,"Also amend this paragraph and Figure 114 accordingly  if that is done, for my comment on p121 L#12. Padding may need to be include up to 4 octets in that case","Yes",null,null,null,null,"Suggested Assignment","Rojan"]
[null,null,"MAMAN, MICKAEL",null,204,"Yes","STMicroelectronics","Technical",132,"10.39.11.3.11",17,"change \"0x10\" by two",null,"change \"0x10\" by two","Yes"]
[null,null,"VERSO, BILLY",null,569,"No","Qorvo","Editorial",132,"10.39.11.3.11",19,"Management MAC Configuration field defined in 10.39.11.1.3.9, is 56 bits (7 octets) .",null,"Change Management MAC Configuration field octer size from \"0/8\" to \"0/7\" in Figure 88","No","Accepted",null,null,null,"DONE"]
[null,null,"CHITRAKAR, ROJAN",null,39,"No","Huawei","Technical",133,"10.39.11.3.11",10,"A report variant of Figure 117 that includes \"Round-trip time\" field is also required.",null,"Add the report variant (Message control three) of Figure 117 that includes \"Round-trip time\" field is also required.","Yes"]
[null,null,"CHITRAKAR, ROJAN",null,40,"No","Huawei","Technical",133,"10.39.11.3.11",10,"The usage of Message control two should be explained.",null,"Add description to explain that Message control two is used for DS-TWR.","Yes"]
[null,null,"MAMAN, MICKAEL",null,205,"Yes","STMicroelectronics","Technical",133,"10.39.11.3.11",10,"Non-interleaved MMS ranging has been defined for one-to-one ranging but not for one-to-many ranging. Clarification is need for one-to-many ranging for a correct usage of one-to-many responder report compact frame with the Message Control field values (within the Message ID field) of two",null,"remove line 10-22 or change definition","Yes"]
[null,null,"CHITRAKAR, ROJAN",null,41,"No","Huawei","Technical",134,"10.39.11.3.12",7,"The usage of Message control one should be explained.",null,"Add description to explain that Message control one is used for DS-TWR.","Yes"]
[null,null,"MAMAN, MICKAEL",null,206,"Yes","STMicroelectronics","Technical",134,"10.39.11.3.12",8,"This one-to-many Initiator Report Compact frame is used for Time-efficient one-to-many ranging",null,"add in line 1 \"The One-to-many Initiator Report Compact frames with the Message Control field values (within the Message ID field) of one is used for Time-efficient one-to-many ranging\"","Yes"]
[null,null,"MAMAN, MICKAEL",null,207,"Yes","STMicroelectronics","Technical",134,"10.39.11.3.12",21,"Non-interleaved MMS ranging has been defined for one-to-one ranging but not for one-to-many ranging. Clarification is need for one-to-many ranging for a correct usage of one-to-many responder report compact frame with the Message Control field values (within the Message ID field) of two. For example, how to select the RMARKER for DS-TWR",null,"remove line 20-3 or change definition","Yes"]
[null,null,"MAMAN, MICKAEL",null,208,"Yes","STMicroelectronics","Editorial",135,"10.39.11.3.13",23,"repetiion of specified in ",null,"remove \"specified in\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,209,"Yes","STMicroelectronics","Technical",135,"10.39.11.3.13",28,"Why we need to define en Advertising Data fields and it can not be included in a SMC TLVs if the higher layer defines its content.",null,"remove line 28 and 29, remove advertising Data in Figure 124, remove lines 1-3 and move lines 4-8 as an example of SMC TLVs field for advertising Data","Yes",null,null,null,null,"Assigned",null,"Hongwon"]
[null,null,"MAMAN, MICKAEL",null,210,"Yes","STMicroelectronics","Technical",136,"10.39.11.3.13",13,"\"The length of the SMC TLVs field can be inferred from the frame length.\" is not valid",null,"remove \"The length of the SMC TLVs field can be inferred from the frame length.\"","Yes",null,null,null,null,"Assigned",null,"Hongwon"]
[null,null,"VERSO, BILLY",null,570,"No","Qorvo","Editorial",136,"10.39.11.3.13",13,"inferred",null,"change to \"determined\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,571,"No","Qorvo","Editorial",137,"10.39.11.3.15",15,"Status field in figure 128 should be named \"Startup Status\", also it would be good to reference 10.39.3.7 where its use is described.",null,"Change Status field name to \"Startup Status\" in Figure 128, and in text desceiption add a reference 10.39.3.7 where its use is described.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,572,"No","Qorvo","Technical",138,"10.39.11.3.18",11,"My understanding is that the acquisition compact frame is used to advertise current usage,(not specifying or reqesting any particular action), so it should be talking about stuff currently in ongoing use. The language could be changed to reflect this more clearly by saying as much as possible that the field being described \"indicates\" xxxx \"is being used\".  Currently \"indicates\" is used in some places and \"specifies\" in others, which is a little confusing.",null,"language could be changed to reflect this more clearly by saying as much as possible that the field being described \"indicates\" xxxx \"is being used\".","No",null,null,"Coord",null,"Assigned",null,"Youngwan"]
[null,null,"Kivinen, Tero",null,96,"No","Wi-SUN Alliance","Editorial",138,"10.39.11.3.18",12,"This should be under 10.39.11.3.17, but only five levels of heading is supported, so it cannot be moved to be subheading of 10.39.11.3.17. ",null,"Perhaps move all compact frames used in MMS up one layer.","No","Revised","Change these to 10.39.11.3.17.1, 10.39.11.3.17.2 and 10.39.11.3.17.3 respectively",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,573,"No","Qorvo","Editorial",138,"10.39.11.3.18",12,"looks 10.39.11.3.18 and 10.39.11.3.19 and 10.39.11.3.20 should be sub-clauses of 10.39.11.3.17.",null,"Change these to 10.39.11.3.17.1, 10.39.11.3.17.2 and 10.39.11.3.17.3 respectively","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,574,"No","Qorvo","Technical",138,"10.39.11.3.18",17,"I expect this is in the realm of the NHL to use same address in both radios, (assuming the frame and the address are specified/sent via the MCPS-DATA,request)",null,"change \"the Address field value used shall be the same in both frames.\" to \"the same Address field value is used in both frames.\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"MAMAN, MICKAEL",null,211,"Yes","STMicroelectronics","Editorial",138,"10.39.11.3.18",138,"move sections 10.39.11.3.18, 10.39.11.3.19 and 10.39.11.3.20 as subsections",null,"as in comment and update table 28","Yes","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,575,"No","Qorvo","Technical",139,"10.39.11.3.18",2,"Looks like Message Control Field Values in Table 28 are reversed with respect to what it says in the two referenced caluses.",null,"Reverse numbering in Table 28 so that 0 is NB Acquisition Compact frame and 1 is Acquisition Compact frame","Yes",null,null,null,null,"Assigned",null,"Huan-Bang"]
[null,null,"MAMAN, MICKAEL",null,212,"Yes","STMicroelectronics","Technical",139,"10.39.11.3.19",2,"message control field value zero is for NB acquisition and one is for UWB",null,"change Figure 132 by reversing message control field value","Yes",null,null,null,null,"Assigned",null,"Huan-Bang"]
[null,null,"LI, HuanBang",null,137,"Yes","NICT","Technical",139,"10.39.11.3.19",4,"Message Control Field value of zero is not agree with that of Table 28.",null,"modify the value in this sentence or that in Table 28.","Yes",null,null,null,null,"Assigned",null,"Huan-Bang"]
[null,null,"VERSO, BILLY",null,576,"No","Qorvo","Technical",140,"10.39.11.3.18",7,"If the AP transmissions are aperiodic, will the Next NB AP time always be known, or might they be done opertunistically? Maybe we need something to say whether this field is valid, or allow it to be omitted if it is not known.",null,"Add support for case when next time is not known, (if this is a seenario that needs to be supported). And similarily for UWB AP.","Yes",null,null,"Coord",null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,577,"No","Qorvo","Technical",140,"10.39.11.3.18",10,"It is NHL that is sending these frames indicating all the UWB usage (sessions) it is running, so this SHALL should be a should.",null,"change \"shall send\" to \"should send\"","Yes",null,null,null,null,"Assigned","NHL vs MAC -- simple","Billy"]
[null,null,"MAMAN, MICKAEL",null,213,"Yes","STMicroelectronics","Technical",140,"10.39.11.3.19",12,"the UWB Channel in the UWB AP Info Field is in contradiction with the fixed UWB channel aHrpUwbAquisitionChan defined in 10.39.3.3",null,"A consensus is need for the UWB and NB acquisition channel","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"MAMAN, MICKAEL",null,214,"Yes","STMicroelectronics","Technical",140,"10.39.11.3.19",12,"in UWB AP Info Field, if the UWB channel is a legacy channel, the size should be changed to bits 0-4. If it includes extended UWB Channel as in 16.4.1.2  instead of legacy channel, then the text should be changed",null,"Option legacy: change figure 133 with 0-4 for UWB Channel and 5-7 for reserved.\nOption extended line 19: The UWB Channel field specifies the extended UWB channel number, defined in section 16.4.1.2, on which the UWB Acquisition Compact frame is to be transmitted.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"MAMAN, MICKAEL",null,215,"Yes","STMicroelectronics","Technical",140,"10.39.11.3.19",13,"change Delta T name to avoid confusion with Delta_T in UWB Per session info elements",null,"change to Delta NB to UWB","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,578,"No","Qorvo","Editorial",140,"10.39.11.3.18",18,"hyphenate length 91 and length 127 (on following line)",null,"change to: \"length-91\" and \"length-127\", and look for other occurances to correct.","No","Accepted",null,null,null,"DONE"]
[null,null,"PAKROOH, POORIA",null,242,"No","Qualcomm","Technical",141,"10.39.11.3.18",4,"Does this refer to round hopping? If it is enabled, what is the hopping pattern?",null,"Clarify what \"Hop Mode\" refers to and what the hopping pattern is.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,579,"No","Qorvo","Technical",141,"10.39.11.3.19",4,"\"for a block of UWB session\" reads badly and is not clear in meaning, is it just one block or all blocks.  I assumne all blocks, since round hopping acts acctoss multiple blocks.  Also since this is essentially advertising ",null,"Make it clear by stating this bit \"when one is indicating that round hopping is being used\" (and not being used when = zero).\nMAKE SAME CHANGE ON p142 line 1.","Yes",null,null,"Coord",null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,580,"No","Qorvo","Editorial",141,"10.39.11.3.19",18,"\"within a block of UWB session in RSTU.\" reads badly, and I think the whole sentence would be better re-written",null,"Change sentence to: \"The Active Period Duration field indicates the duration in RTSU of the active period in the ranging block\"","No","Accepted",null,null,null,"DONE"]
[null,null,"LI, HuanBang",null,138,"Yes","NICT","Technical",142,"10.39.11.3.20",11,"Message Control Field value of zero is not agree with that of Table 28.",null,"modify the value in this sentence or that in Table 28.","Yes",null,null,null,null,"Assigned",null,"Huan-Bang"]
[null,null,"VERSO, BILLY",null,581,"No","Qorvo","Technical",143,"10.39.11.3.21",10,"All other vendor specific messages within in 802.15.4 are within properly addressed MAC frames.  Here there is no addressing so the frames are passed to the upper layer without any notion whether they are for this device or not.  If the frames have RPA/HASH they have already passed that part of the MAC where secret keys etc. reside (possibly hidden from the upper layer). Similarly CRC is not part of the definition so if there is one, then the higher layer has to check it separately from any H/W there may have been to do it in the lower MAC. This will make extending the compact messaging scheme less straightforward.  Doing this would also facilitate carrying them in the secure compact frame, and it is likely that MAC level security processing will be needed for many vendor specific use cases.",null,"To allow for common MAC processing of the low level parts of the frame, specify RPA HASH and PRAND fields and CRC as fields as part of the Vendor Specific Compact frame format. This would allow the entities using vendor specific format to use same IRK etc in common way. ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,99,"No","Wi-SUN Alliance","Technical",143,"10.39.11.3.22",21,"The section 9.3.4.3 uses MHR which is not defined for the compact frames. ",null,"Add new figure that defines MHR. The MHR needs to include the first octet of the frame i.e., the compact frame id and frame type, security control field, RPA Hash and RPA Prand fields. The rest can be marked as Private Payload field. ","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,97,"No","Wi-SUN Alliance","Technical",143,"10.39.11.3.22",23,"The Security Compact Frame ID is 8-bit field, but it contains Compact Frame ID that is only 5 bits long. ",null,"Reduce the size of the Secured Compact Frame ID to match Compcat Frame Id Size.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,98,"No","Wi-SUN Alliance","Technical",143,"22 line 23",null,"There is KeyIndex and Key ID terms used by the draft and I assume they are trying to mean same. ",null,"If Key ID and KeyIndex are supposed to be same, use the same term. Also the Key ID and KeyIndex fields are used as 4 bit or 8 bit fields in different places, make sure they are consistent. ","Yes"]
[null,null,"Kivinen, Tero",null,100,"No","Wi-SUN Alliance","Technical",144,"10.39.11.3.22",15,"The MIC field is not really set to those values. ",null,"The output of the AEAD transformation is c data. The Private Payload field of the original unsecured frame shall be replaced by the right-concatenation of that field and the c field if data confidentiality is not provided and shall be replaced by the c field otherwise. There should not be separate MIC field at all. This text requires rewrite to match what 9.3.4/9.3.5 does.","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"PAKROOH, POORIA",null,243,"No","Qualcomm","Technical",144,"10.39.12",21,"Channels 5 and 9 are popular UWB channel. It is good that we do not cause interference there by sending periodic Acquisition packets. ",null,"Change \"9\" to a value other than 5 or 9.","Yes"]
[null,null,"MAMAN, MICKAEL",null,216,"Yes","STMicroelectronics","Technical",144,"10.39.12",22,"missing RPAPrand in MMS related MAC PIB attributes",null,"add a new line in Table 32 macIrkAssocRpaprandpresent|Boolean|TRUE,FALSE|  When macIrkAssocRpaprandpresent is TRUE, the macIrkDescriptorElement list has an associated RPA Prand value stored for each macIrkEntry IRK stored. When FALSE, the macIrkDescriptorElement list no associated RPA Prand stored with the IRKs.\nAdd a new line in Table 33\nmacIrkAssocRpaprand| set of octets|0x000000-0xFFFFFF| This RPA Prand value is a 3-octet bit random sequence computed with the associated IRK","Yes"]
[null,null,"VERSO, BILLY",null,582,"No","Qorvo","Technical",144,"10.39.12",22,"In hindsight it was wrong for many of the parameters in Table 31 to be made into MAC pib attributes. Some may be controlling MAC activity, but many are specifying protocol timings for activities at NHL, i.e., the MAC is not really implementing the protocol, it is the NHL that is deciding what flavour of message to send when. It is the NHL that initiates that sending invoking the MCPS-DATA.request to provide the frame and specify the TX time.  For those parameters not actually used by the MAC it would be clearer to recast these as MMS protocol control parameters, as they were originally provided.",null,"Revert appropriate parameters to protocol specification variables so that they are not confused with PIB parameters that actually control specific MAC activity.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"PAKROOH, POORIA",null,244,"No","Qualcomm","Technical",145,"10.39.11.3.22",1,"Please clarify that round needs to be interger multiplication of slot duration.",null,"Add this sentence in the description of Round duration: \"This needs to be an integer multiple of slot duration.\"\n","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Aldana, Carlos",null,4,"No","Meta","Technical",145,"10.39.12",1,"macmmsnbinitchannel should be consistent with CAD document 15-23-452-11 that states \"Periodic NB packet transmissions on fixed channels such as background advertising and control traffic are allocated in 4ab in newly allocated spectrum outside of the channel map used by 802.11 WLAN such that no interference is cast \"","Change the range from \"0 to 249\" to a range that is consistent with the statement","Change the range from \"0 to 249\" to a range that is consistent with the statement","Yes",null,null,null,null,"Assigned",null,"Alex"]
[null,null,"LI, HuanBang",null,139,"Yes","NICT","Technical",145,"10.39.12",1,"In Table 31, macMmsNbInitMode is given a range of 1-9, which is not agree to that given in Table 67.",null,"set to the same range as that in Table 67.","Yes",null,null,null,null,"Assigned","Huan-Bang volunteered via email,","Huan-Bang"]
[null,null,"Pirhonen, Riku",null,269,"Yes","NXP Semiconductors","Technical",145,"10.39.12",1,"The minimum value for macMmsRcpPollNSlots can be 0",null,"Change the value range for macMmsRcpPollNSlots to 0 - 15","No"]
[null,null,"Pirhonen, Riku",null,270,"Yes","NXP Semiconductors","Technical",145,"10.39.12",1,"The minimum value for macMmsRcpRespNSlots can be 0",null,"Change the value range for macMmsRcpRespNSlots to 0 - 15","No"]
[null,null,"VERSO, BILLY",null,583,"No","Qorvo","Technical",145,"10.39.12",14,"macMmsNbInitMode should be mms application parameter instead of mac PIB, but also range is wrong, table 67 has no config #9",null,"Make into an mms protocol layer variable, and correct range to be 1 to 8 only.","Yes",null,null,null,null,"Assigned","NHL vs MAC -- more complex","Billy"]
[null,null,"PAKROOH, POORIA",null,245,"No","Qualcomm","Technical",146,"10.39.11.3.22",1,"Please clarify that this needs to be interger multiplication of round duration.",null,"Add this sentence in the description of Block duration: \"This needs to be an integer multiple of Round duration.\"","Yes",null,null,null,null,"Assigned",null,"Rojan"]
[null,null,"Kivinen, Tero",null,102,"No","Wi-SUN Alliance","Technical",146,"10.39.12",2,"In the base standard we use extended address instead of Eui. ",null,"Change macIrkAssocEuiPresent to macIrkExtendedAddressPresent.","No"]
[null,null,"Kivinen, Tero",null,101,"No","Wi-SUN Alliance","Technical",146,"10.39.12",5,"The macIrkAssocEuiPresent should point out that if it is FALSE, then no secure communication to or from this device is possible. ",null,"Add text explaining that if it is set to FALSE then no extended address is stored and no security communication to the device is possible.","No"]
[null,null,"Kivinen, Tero",null,103,"No","Wi-SUN Alliance","Technical",146,"10.39.12",10,"In the base standard we use extended address instead of Eui. ",null,"Change macIrkAssocEui to macIrkExtendedAddress.","No"]
[null,null,"VERSO, BILLY",null,584,"No","Qorvo","Technical",148,"10.40.3",2,"The meaning is unclear of \"may be shared per transmission\" is a strang way of saying sent, if tiat is what is meant.  If the stitching is within a single four segment sensing packet, is it saying that this MIGHT generate either four CIR reports or one stitched CIR report?  If frequeny stitchig is with separate pakets than this is more a protocol/application decision and should be described as such (i.e. not be part of the MAC specifation).",null,"Clarifty that tis shared is \"sent\"","Yes",null,null,"Stitch",null,"Assigned",null,"Pooria"]
[null,null,"Sand, Stephan",null,291,"Yes","German Aerospace Center (DLR)","Editorial",147,"10.40.1",11,"\"that Participates in\" should be replaced with \"that participates in\"",null,"as in comment","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,585,"No","Qorvo","Technical",147,"10.40.2",20,"\"may require the sensing measurement report\" should be clearer in what it means, which I think is as per the proposed change.",null,"\"might need to receive sensing measurement reports sent from sensing controlles to perform its sensing functiuon\".","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,586,"No","Qorvo","Technical",147,"10.40.2",21,"I think this report generation is in the domain of the NHL ",null,"change \"shall be sent\" to \"are sent\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,587,"No","Qorvo","Editorial",148,"10.40.4.2",10,"Could reference how the higher layer enables/controls sensing.",null,"Add forward reference to clause 10.40.4.7 that describes the NHL-MAC interacrtions to enable/implement sensing","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,588,"No","Qorvo","Technical",148,"10.40.4.2",12,"I suppose the setup pahse for sensing, exchange capabilities etc, is optional to support?",null,"State that.","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"PAKROOH, POORIA",null,246,"No","Qualcomm","Technical",149,"10.40.4.5.1",16,"Measurement report is mandatory when the controller is the transmitter of the Sensing PPDU. ",null,"Remove the word \"Optional\". Also, Add a sentence:\"When the controller is acting as the transmitter, sensing report phase is mandatory\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,589,"No","Qorvo","Technical",149,"10.40.4.5.1",17,"I think the NHL (sensing protocol/application) may be implicated in processing the CIR and senting the data frame incoprorating the CIR Report IE, so should reword this. Also the line above says it is an optional phase, so how can the report be mandatory if the phase isnt'",null,"Change \"An SDEV shall support a ...\" to \"The basic sensing report is a...\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"PAKROOH, POORIA",null,247,"No","Qualcomm","Technical",149,"10.40.4.5.1",18,"Remove the sentence \"This type is used for most bistatic and multistatic sensing applications\".",null,"Remove the sentence \"This type is used for most bistatic and multistatic sensing applications\".","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,590,"No","Qorvo","Technical",149,"10.40.4.5.1",24,"\"It is negotiated during the sensing session set up phase\" or it could be pre agreed OOB, especially if the phase is optional.",null,"and at end of sentence, \", or it can be pre-agreed via OOB means.\"","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"Kivinen, Tero",null,104,"No","Wi-SUN Alliance","Technical",150,"10.40.4.5.2",4,"The RFC1951 does not only describe the format it also described the whole compression method. Also there is no need to have normative reference to IETF RFC 1951. ",null,"Change \"shall be applied using the\\nDEFLATE compressed data format described in IETF RFC 1951.\" to \"shall be applied as specified in the \\nDEFLATE Compressed Data Format Specification version 1.3 RFC 1951 [Bxx]\". I.e. use full title of the RFC and move IETF RFC 1951 from normative reference to bibliography. This is optional feature inside optional enhancement thus there is no need for readers of the IEEE Std 802.15.4 to go and read  RFC 1951 in general case. Also the RFC 1951 is not a standard it is just informational RFC.","No",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,591,"No","Qorvo","Technical",150,"10.40.4.5.3.1",16,"The second sentence seems to be repeating what is in the first.",null,"Simply it by replacing it with the following addition the previous sentence: \", and, once agreed, are fixed and do not change.\" -- or, seems that this may be a mispalced line 21, in which case the line 16 sentence should be deleted.","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,592,"No","Qorvo","Technical",150,"10.40.4.5.3.2",19,"Again maybe there is a better way to describe than mandatory, (since over-the-air reporting is optional.)",null,"change \"mandatory\" to \"fundamental\" in the context of this bitmap style reporting.","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"PAKROOH, POORIA",null,248,"No","Qualcomm","Technical",150,"10.40.4.5.2",20,"Page 150, line 20, start the sentence by adding this snetence: \"Support for the Compression of measurement report  is optional for an SDEV. Compression, if supported, can …\"",null,"Page 150, line 20, start the sentence by adding this snetence: \"Support for the Comoression of measurement report  is optional for an SDEV. Compression, if supported, can …\"","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,593,"No","Qorvo","Technical",150,"10.40.4.5.3.2",24,"The phrase \"The gap options between them\" should be a bit cleared what \"them\" is… ",null,"Should it be \"The gap options between these mandatory strings of ones are ….\"","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,594,"No","Qorvo","Technical",150,"10.40.4.5.3.2",26,"This line is also pointing to the sentrence on line 16 being wrong.",null,"Delete line 16 sentence.","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,595,"No","Qorvo","Technical",151,"10.40.4.5.3.2",1,"The threshold is relative to and below the peak, to help with understanding this, a figure to explain this might be good. ",null,"Consider adding a figure to show how/where this threshold applies.","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,596,"No","Qorvo","Editorial",151,"10.40.4.5.3.3",31,"Fragmentation should be lower case.",null,"change to \"fragmentation\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,597,"No","Qorvo","Editorial",152,"10.40.4.5.3.3",6,"two fields so should be plural verb",null,"change \"is used ….is set\" to \"are used ….are set\" ","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,598,"No","Qorvo","Editorial",152,"10.40.4.5.3.3",7,"The Report Parameters Control field shall be present only if the First Report Fragment field value (in the Report Identity Control field) is one and is not present otherwise.",null,"The Report Parameters Control field shall be present if the First Report Fragment field value (in the Report Identity Control field) is one and not present otherwise.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,599,"No","Qorvo","Editorial",152,"10.40.4.5.3.3",9,"carry",null,"change to \"carries\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Rolfe, Benjamin",null,279,"Yes","BCA","Technical",152,"10.40.4.5.3.2",25,"\"shall only\" is poor specification practice.  In this csae \"only\" is extraneous. ",null,"Delete \"only\"",null,null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Kivinen, Tero",null,105,"No","Wi-SUN Alliance","Editorial",154,"10.40.4.7.1",3,"This is first use of HRP-SDEV, expand here. ",null,"Expand HRP-SDEV here.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,600,"No","Qorvo","Technical",155,"10.40.5",21,"SBP is essentially a protocol for controlling sensing remorely and getting reports. While defining IEs to support this is informative and possibly useful, it is essentially a networking layer and as such logically lives above 802.15.4 so architecturally should not be in this amendment, and the \"shalls\" should be removed.",null,"We sholuld preferably delete it, and at least move it to an annex, and definitely should remove the \"shall\" statements.","No",null,null,null,null,"Suggested Assignment","Rojan?"]
[null,null,"VERSO, BILLY",null,601,"No","Qorvo","Technical",156,"10.40.6.1",19,"My understanding is that the AC IE is used in the RCM which by definition (P46L25) is transmitted by a controller in slot zero each ranging round. Saying that it sends the session configuration information perhaps should have some more explanation, since presumably it could change the content and session info any (or every) ranging round it chooses.",null,"Change \"The AC IE is used by a controller to send the session configuration information.\" to \"The AC IE is used by the controller in an RCM to send and update the session configuration information\".  ","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,602,"No","Qorvo","Technical",156,"10.40.6.1",19,"I reckon that while the fields of the AC IE are well defined, the use is quite poorly defined.  The AC IE has so many options, one can see how it might cater for multiple modes, applications and uses, but these and its use for them are not described. If a controlee receives an AC IE in a ranging round, when does it change the application use, channel, etc?  Is it expected to be on a new channel, doing a new application on the very next slot of the ranging round?. The mentions of AC IE in subclauses 10.32.1, 10.39.4.3, 10.39.4.6.1 and 10.40 seem inadequate to describe the use of AC IE.",null,"Add either one clause on the use of the AC IE is, or separate clauses for each use case, (sensing, ranging, association, changing modes, etc.), to describe when/how often the AC IE is sent, and what part of the content is allowed to change and when should application make the changes.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"PAKROOH, POORIA",null,249,"No","Qualcomm","Technical",156,"10.40.6.1",26,"This applies to sensing and data comm. Please recall them as \"BDP, RDP, SDP\". This is already done in page 157. Please match the figure\n with the rest of the text in page 157.",null,"In Figure 150 and the descriptions below it, change \"RBDP\", \"RRDP, and \"RSDP\" to \"BDP\", \"RDP\" and \"SDP\" respectively.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,603,"No","Qorvo","Editorial",156,"10.40.6.1",26,"The field's acronyms mostly appear only once. Suggest to use words instead since the acronym makes things less readible and does not save much ink.",null,"Replace Figure 15 field acronyms with expanded terms.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,604,"No","Qorvo","Technical",158,"10.40.6.1",10,"The Preamble Code Configuration field seems intended to signal DPS related info, but it does not say that.  We should state this and cross reference with DPS clause in both directions.",null,"Add words to say that this field is used for signalling information between devices to allow for dynamic preamble and channel selection, as described in 10.29.4 and add words in 10.29.4 (base standard clause) to refer to the AC IE with Preamble Code Configuration field as one possible way to coordinate the DPS/DCS between devices.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,605,"No","Qorvo","Technical",158,"10.40.6.1",12,"The Preamble Code Configuration field seems to be exactly the same content as the RCPCS IE Content.  Assuming this is intended then rather than saying it in two places, lets change the text to just refer to the RCPCS IE Content. Or, if we don't need two IEs to send the same information then remove the Preamble Code Configuration field.",null,"Delete Figure 154—Preamble Code Configuration field of the AC IE and related text and instead state that the Preamble Code Configuration field, if present, is identical, in meaning and format, to the content field of the RCPCS IE as shown in Figure 10-214.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"LI, HuanBang",null,140,"Yes","NICT","Editorial",159,"10.40.6.1",30,"Add a period at the end of sentence.",null,"Add a period at the end of sentence.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"QIAN, BIN",null,276,"No","Huawei","Technical",170,"10.39.6.2",11,"The range of \"i\" is not clearly clarified",null,"The range of i is from 0 to N-1","Yes"]
[null,null,"VERSO, BILLY",null,606,"No","Qorvo","Technical",170,"10.40.6.1",22,"Intra-packet frequency stitching is something that the PHY does (if it supports configuration of mulktip, The channel to use for SHR can be separatelty configured usinf the normal channel selection method..",null,"State that support of intra-packet frequency stitching is dependant on how many sensing segments the PHY supports and on it supporting the configuration of the channel for each frequency stitching segment via the phyFSS1channel, phyFSS2channel, phyFSS3channel and phyFSS4channel attributes. And state, that phyCurrentChannelInfo specifies the channel for the SHR.","Yes",null,null,"Stitch",null,"Suggested Assignment","Panpan (Frequency Stitciing)"]
[null,null,"VERSO, BILLY",null,607,"No","Qorvo","Technical",173,"10.40.6.1",2,"Earlier in the paragraph it says \"UWB Channel field specifies the UWB channel to use, but for frequency stitching \"the UWB Channel field shall be set as the starting channel for sensing\", I think that it should not be a \"shall\" as this IE is UL to UL.  Also, \"starting channel\" is confusing, since there is already a \"base channel\" in the  Frequency Stitching Parameters field.  Maybe this is the control channel rather than the \"starting channel\"",null,"change sentence to \"When the Frequency Stitching Parameters Present field in the Sensing Control field is set to one, the UWB Channel field specifies the channel to be used for sensing control messages\".","Yes",null,null,"Stitch",null,"Assigned",null,"Pooria"]
[null,null,"MAMAN, MICKAEL",null,217,"Yes","STMicroelectronics","Technical",174,"10.40.6.2",12,"When the Compression field value is one, how to diffferentiate when the Receive Report Lists field is compressed or the CIR Taps field of each receive report in the Receive Report Lists field is compressed individually?",null,"clarify the two cases or merge the two paragraphes","Yes",null,null,null,null,"Assigned","Rojan volunteered in email 8 April, but it was already assigned to Pooria","Rojan, Pooria"]
[null,null,"VERSO, BILLY",null,608,"No","Qorvo","Editorial",176,"10.40.6.2",1,"Note 3 and 4 without a note 1 and two,",null,"Restart numering at 1 or make them non-numbered notes.","No","Revised","Number them 1 and 2",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,609,"No","Qorvo","Technical",176,"10.40.6.2",18,"I think this is still not clear \"The CIR taps being reported in the CIR Taps field, i.e., the I and Q (in-phase and quadrature) tap values in the CIR Taps field are divided by 2^F to generate the report.\"",null,"Change to \"The CIR taps, i.e., the I and Q (in-phase and quadrature) tap values in the CIR are divided by 2^F to generate the CIR Taps field values in the CIR report.\"  ","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"VERSO, BILLY",null,610,"No","Qorvo","Technical",176,"10.40.6.2",22,"I am thinking that depending on how RSSI is measure the range and accuracy of the may be more limited than the units and span of the field would suggest.  Maybe we should add something to make this optional, and allow for some imprecision.",null,"Add a note to say that the the range and accuracy of this field may be less than than the units and span of the field specification would suggest","Yes",null,null,"SENS",null,"Assigned",null,"Pooria"]
[null,null,"MAMAN, MICKAEL",null,218,"Yes","STMicroelectronics","Technical",177,"10.40.6.3",2,"Address Size field indicates the size of the addresses used in both the SBP Request IE and the Sensing Control Address List field. Then merge the 2 paragraphes",null,"merge the two paragraphes","Yes"]
[null,null,"VERSO, BILLY",null,611,"No","Qorvo","Editorial",178,"10.40.6.4",23,"\"The SBP Status Code field shall have one of the values specified in Table 54.\" The table has a reserved value. Add \"non-reserved\"",null,"Change to \"The SBP Status Code field shall have one of the non-reserved values specified in Table 54.\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,612,"No","Qorvo","Technical",182,"10.40.6.6",15,"Delay Span field units/range aren't specified.",null,"Specify units and value range.","Yes",null,null,"SENS",null,"Suggested Assignment","Pooria?"]
[null,null,"VERSO, BILLY",null,613,"No","Qorvo","Technical",182,"10.40.6.6",18,"Angle Span (Azimuth) field values/units aren't specified and text says it is an 8-bit value but Figure 179 has it as 2 octets.",null,"Clarify field size and specify units and value range","Yes",null,null,"SENS",null,"Suggested Assignment","Pooria?"]
[null,null,"VERSO, BILLY",null,614,"No","Qorvo","Technical",182,"10.40.6.6",19,"Angle Span (Elevation) field values/units aren't specified and text says it is an 8-bit value but Figure 179 has it as 2 octets.",null,"Clarify field size and specify units and value range","Yes",null,null,"SENS",null,"Suggested Assignment","Pooria?"]
[null,null,"VERSO, BILLY",null,615,"No","Qorvo","Editorial",183,"10.41.2",4,"I have reviewed the use of the word \"process\" and recommend to change this one. ",null,"delete the word \"process\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,616,"No","Qorvo","Technical",183,"10.41.2",4,"There is no \"scanning process\" defined.  I think it is fairly simple to describe, and probablyt not call it scanning process either",null,"replace sentence with: \"a controllee wanting to discover controllee devices around itself with which it may assoicate, configures itself for each mandatory channel and mandatory preamble code combination, unless the channel and preamble code are known in advance, and turns on its receiver to listen for AC IE the Association Availability field set.\"","Yes",null,null,"ASSOC",null,"Assigned",null,"Larry"]
[null,null,"Rolfe, Benjamin",null,282,"Yes","BCA","Technical",183,"10.41.3.1 ",9,"use of \"shall not\" is incorrect.  A correct statement of the requirement speciies when something is done, not when it is not (there are many other cases when it is not).",null,"A controlee shall  send the Controller Association Request command in a block when the Association Availability field is set to a non-zero value. "]
[null,null,"Rolfe, Benjamin",null,280,"Yes","BCA","Technical",185,"10.41.4.1",3,"\"shall only\" is poor specification practice.  In ths case \"only\" is not needed and is not correct.",null,"Delete \"only\""]
[null,null,"QIAN, BIN",null,277,"No","Huawei","Technical",185,"10.41.4.1",18,"The current Capability Information field does not clearly indicate the device type",null,"First, change \"Dynamic PHR\" to \"LLDDEV\", since dynamic PHR is a mandatory feature of LLDDEV. Second, add one bit to indicate ARDEV. Third, add one bit to indicate SDEV","Yes"]
[null,null,"VERSO, BILLY",null,617,"No","Qorvo","Editorial",185,"10.41.4.1",18,"HRP UWB Capability Information should be renamed to Capability Information, to be more generic",null,"Rename three occurrences of \"HRP UWB Capability Information\" to \"Capability Information\", Line 18, and Figures 186 field and Figure 187 caption","No","Accepted",null,null,null,"DONE"]
[null,null,"Rolfe, Benjamin",null,281,"Yes","BCA","Technical",186,"10.41.4.2",12,"\"shall only\" is poor specification practice.  In ths case \"only\" is not needed and is not correct.",null,"Delete \"only\""]
[null,null,"VERSO, BILLY",null,618,"No","Qorvo","Technical",186,"10.41.4.2",14,"This line refers to the addressing mode specified by the MLME-ASSOCIATE.response primitive, however there is no such parameter in that primitive.",null,"Not sure whether we should add a parameter to the primitive for this, or just specify the addressing mode to be extended as is done for the original coordinator association.","Yes",null,null,"ASSOC",null,"Assigned",null,"Larry"]
[null,null,"VERSO, BILLY",null,619,"No","Qorvo","Editorial",187,"10.41.4.2",6,"This figure also defines the format of the ControllerConfiguration parameters of the MLME-ASSOCIATE.response and MLME-ASSOCIATE.confirm primitives, which would be good to note here.",null,"Add text to say that Figure 189 also defines the format of the ControllerConfiguration bitmap parameter of the MLME-ASSOCIATE.response and MLME-ASSOCIATE.confirm primitives, as specified 10.21.6.1.4 and 10.21.6.1.5 respectively. ","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,620,"No","Qorvo","Editorial",188,"10.41.4.2",1,"Blank numbered line, it is actually the line the table is on but it is running onto the next page.",null,"Fix it","No","Accepted",null,null,null,"DONE"]
[null,null,"Kristem, Vinod",null,117,"Yes","Apple","Technical",188,"10.42.2",11,"There are some gaps in Sync length negotiation using TDMS/RDMS exchange. While the transmitter has all the information to determine the outcome of negotiation, there are scenarios where receiver cannot determine the result of negotiation, which could lead to potential interop issues. These are described in detail in DCN 15-24-0620-00-04ab. Potential solutions to address these gaps are also provided, with minimal changes to the spec.",null,"Update the TDMS/RDMS exchanges, based on the propsal presented in DCN 15-24-0620-00-04ab, to fill the gaps. We will provide the CR text to address the gaps.","Yes",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"VERSO, BILLY",null,621,"No","Qorvo","Technical",188,"10.42.2",11,"The points raised in 15-24-0620-00-04ab should be addressed",null,"With reference to the original author and intent of this clause, consider what changes are needed.","Yes",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"VERSO, BILLY",null,634,"No","Qorvo","Editorial",188,"10.42.2",16,"\"seems to be a 10.41.3.1 out og plae on this line\"",null,"Change \"10.41.3.1 Dynamic\" to \"Dynamic\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,622,"No","Qorvo","Technical",188,"10.42.2",20,"\"SYNC and SFD it wants\" is a little unclear also \"SYNC and SFD\" are used for the \"SYNC and SFD fragment\" so it would be good to not says \"SYNC and SFD\" anywhere else except when talking about the SYNC and SDF fragment.",null,"change to say \"and the SYNC length(s) it requires for those modulation rates and the and SFD it requires.\"","Yes",null,null,null,null,"Assigned","I will do / make proposed resolution submission for group to consider","Billy"]
[null,null,"VERSO, BILLY",null,635,"No","Qorvo","Editorial",191,"10.43.2.1",17,"blank line in Table 60",null,"delete the blank line","No","Accepted",null,null,null,"DONE"]
[null,null,"PAKROOH, POORIA",null,250,"No","Qualcomm","Technical",194,"10.44",13,"Not clear why this NB data transmission protocol is needed, given the significantly lower data rate relative to UWB, and also higher fading. If many users start to use this protocol, the congestion can be problematic. This can cause interference to unnecessarily longer range. There is no duty cycle limit specified for this feature and the benefits are not clear.\n\nRemove this functionality, or add a proper mandatory channel access mechanism.",null,"Remove NB data offload by deleting subclause 10.44. Another alternative is to add a proper channel access mechanism for this feature for high duty cycle usage.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,623,"No","Qorvo","Technical",194,"10.44.1",16,"Saying \"up to the implementer\" is a bit vague, and no need to talk about OOB or custome messages if it is out of scope already.",null,"change: \"and up to the implementer\" to \", i.e., is the responsibility of high layer protocols\", and delete the sentence following about OOB custome messages.","Yes",null,null,"Data Offload",null,"Assigned",null,"Youngwan"]
[null,null,"PAKROOH, POORIA",null,251,"No","Qualcomm","Technical",194,"10.44.1",19,"Benefits of NB usage for ranging has been justified. What is the benefit of using two links with significantly different link budget? what is the application? The data communication associated with this application are for close range cases, which does not need NB.",null,"Remove NB data offload by deleting subclause 10.44. ","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,636,"No","Qorvo","Technical",194,"10.44.2",19,"\"narrowband allocation packet\" is not properly defined. I think it is any frame containin the NB Allocation IE, that definition should be clearly made. I think we should call it The narrowband allocation message folling the example of RCM for ranging control message.",null,"On  line 20 instead of saying \"The narrowband allocation packet shall include an NB Allocation IE …\" make it a definition: \"The narrowband allocation message is a Data frame that includes an NB Allocation IE ...\".  And change the other two uses of \"narrowband allocation packet\" to \"\"narrowband allocation message\". ","Yes",null,null,"Data Offload",null,"Assigned",null,"Youngwan"]
[null,null,"Aldana, Carlos",null,8,"No","Meta","Technical",194,"10.44.2",194,"There is no description on how NB channel access is done."," adopt changes described in document 15-407-07"," adopt changes described in document 15-407-07","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"PAKROOH, POORIA",null,252,"No","Qualcomm","Technical",195,"10.44.3.1",6,"If this is a unicast message, why does it inclue address in the IE?",null,"Remove \"Address size\" and \"Address\" from Figure 197.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,637,"No","Qorvo","Technical",195,"10.44.3.1",11,"The address of the participating device doesn't make any sense… it says on line three that the NB Allocation IE is used by an initiator to send … to a responder (in a unicast frame)\" so the address of the responder is already in the frame carrying the IE.",null,"Delete the field.","Yes",null,null,"Data Offload",null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,638,"No","Qorvo","Technical",195,"10.44.3.1",17,"Transmission Offset is good, but is it the (initiator) device sending the IE or the (responder) device receiving the IE that is expected to be tranmsitting first or how is this determined?  One posibility is to use a one of the free reserved bits to say whether which is sending and whihc is receiving this (first) transmittion.",null,"Make it clear that it is the responer always sending, or add a bit to say Responder TX which when one means that the receiver of the IE is to send after the specified offset, or when it's zero is to turn on its receiver to receive a packet from the initiator.","Yes",null,null,"Data Offload",null,"Assigned",null,"Youngwan"]
[null,null,"VERSO, BILLY",null,639,"No","Qorvo","Editorial",197,"10.45.2",3,"NB is used here for number of SSBD backoffs, and as meaning narrowband while elsewhere in the text.  In the base standard NB is already used for number of backoffs in the CSMA-CA text.",null,"Review and change NB to narrowband or O-QPSK, (or NBA if appropriate) where it appears on its own to mean narrowband, ","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Aldana, Carlos",null,9,"No","Meta","Technical",198,"10.45.2",6,"CCA mode 3 does not exist anymore.  It is either 3a or 3b","Please clarify","Please clarify","Yes",null,null,null,null,"Assigned",null,"Larry"]
[null,null,"Kivinen, Tero",null,106,"No","Wi-SUN Alliance","Editorial",198,"10.46.1",14,"This is first use of RSS outside the tables, and headers, expand here. ",null,"Expand RSS here.","No","Rejected","RSS is first expanded on page 15 line 10, in the paragraph text of 5.2.5 ",null,null,"N/A","REVISIT at the end since another comment proposes removing the text in 5.2.5"]
[null,null,"VERSO, BILLY",null,624,"No","Qorvo","Editorial",199,"10.46.2",11,"Ref to Clause 0, should be Clause 13",null,"Change to \"Clause 13\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,640,"No","Qorvo","Editorial",199,"10.46.3.1",35,"Not first use of \"contention access period\"",null,"Replace \"contention access period (CAP).\" by \"CAP.\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,641,"No","Qorvo","Editorial",199,"10.46.3.1",36,"10.29.2 (Ranging block and round structure) seems to be the wrong reference.",null,"Change \"10.29.2 (Ranging 36 block and round structure)\" to \"10.32.2\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,642,"No","Qorvo","Editorial",200,"10.46.3.3",7,"Not first use of Allocated Transmit Slot (ATS)",null,"Replace \"Allocated Transmit Slot (ATS)\" by \"ATS\"","No","Revised","Change \"this slot is called an Allocated Transmit Slot (ATS)\", to \"this slot is an ATS\".",null,null,"DONE"]
[null,null,"VERSO, BILLY",null,625,"No","Qorvo","Editorial",201,"11.1.1",7,"Ref to Clause 0, should be Clause 13",null,"Change to \"Clause 13\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Aldana, Carlos",null,7,"No","Meta","Technical",201,"11.1.1",10,"I've heard the response \"more channels is better\" when discussing NB channel maps.  The spectrum from 5850-5875 is available in Europe.","Change Table 11-1 and equations in lines 17 and 18 to reflect this.","Change Table 11-1 and equations in lines 17 and 18 to reflect this.","Yes"]
[null,null,"VERSO, BILLY",null,626,"No","Qorvo","Technical",201,"11.1.3.15",14,"Just wondering about the pre-existing O-QPSK PHY channel numbering in the base standard. I assume there is also a channel 1, 2, 3 there also. Since we are amending it, we should be clear that any O-QPSK PHY channel we mention is not confused with the original O-QSPK channels, and if so add some qualifier.",null,"Review the rest of the 4ab text (and base standard text?) and decide if this is an issue or not, and if it is make sure to add band modifiers 5800 MHz and 6200 MHz (and the bands of the base standard in the base standard?) as appropriate to make it unambiguous..","Yes",null,null,"NB Channels",null,"Assigned",null,"Alex"]
[null,null,"VERSO, BILLY",null,627,"No","Qorvo","Technical",201,"11.1.4",20,"SIFS and LIFS have been broken for UWB for a while, would be good to solve in 4ab if we could",null,"Need to make appropriate times in line with the processing needed and not think orignal times hugely shortened because of the very short UWB symbol duration are sufficient.  Also AIFS / ACK timeing at the same time.","Yes",null,null,null,null,"Assigned","Need to consider what is appropriate","Billy"]
[null,null,"PAKROOH, POORIA",null,253,"No","Qualcomm","Technical",202,"11.1.4",4,"The macLifsPeriod timing is not well defined. The value of 28 preamble symbol offset from Aifs needs to be better studied and the unit also needs to be updated.",null,"Update the 28 preamble symbol offset in the Lifs t to a number that is acceptable for different implementers in the group.","Yes"]
[null,null,"MAMAN, MICKAEL",null,219,"Yes","STMicroelectronics","Technical",204,"12.3.7",1,"The range of phyHrpUwbTxPacketConfig is incorrect",null,"move phyHrpUwbTxPacketConfig after phyHrpUwbRxPacketConfig and change the range to \"BASIC_PACKET, STS_PACKET_1, STS_PACKET_2, STS_PACKET_3, SENS_PACKET_0, SENS_PACKET_1, SENS_PACKET_2, MMS_PACKET_1, MMS_PACKET_2\"","Yes",null,null,null,null,"Assigned",null,"Billy"]
[null,null,"VERSO, BILLY",null,643,"No","Qorvo","Technical",206,"10.46.3.3",10,"phyFSType is not needed, not a phy parameter.  The phy operates on a packet basis sending one packet whenever the MAC tells it to, and in the case of sensing packets this is based on the NHL invoking the MCPS-DATA.request primitive.  For the PHY. phyFSEnable enable will tell it to change frequencies fo the segments accortdsing to the phyFSS?channel values.  To do inter-packet frequency stitching the NHL should, after receiving the MCPS-DATA.confirm primitive for the one sensing packet, reconfigure phyChannelInfo and phyFSS?channel values and invoke the MCPS-DATA.request primitive for the next packet.",null,"Delete phyFSType and add a message sequence chart for inter-packet frequency stitching that shows the sending of two packets and reconfiguration of the channel infotrmation.","Yes",null,null,null,null,"Suggested Assignment","BinQ"]
[null,null,"Aldana, Carlos",null,5,"No","Meta","Technical",208,"13.2.2",22,"Make 500 kb/s support mandatory to reduce airtime","As in comment","As in comment","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"Aldana, Carlos",null,6,"No","Meta","Technical",208,"13.2.2",22,"Make 1000 kb/s support mandatory to reduce airtime","As in comment","As in comment","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,644,"No","Qorvo","Editorial",210,"13.2.5",1,"For notes e and f under the Table 67 if  Table 22-14 and Table 22-15 are correct the bracketed titles of the table can be removed",null,"Check both table referfence and remove bracketed titles following them","No","Accepted",null,null,null,"DONE"]
[null,null,"LI, HuanBang",null,141,"Yes","NICT","General",212,"13.3.2",8,"Since this subclause specifies the transmit power spectral density (PSD) mask, it'd be better to replace 'the transmitted spectral product' to   'the transmitted power spectral density' .",null,"make change.","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,628,"No","Qorvo","Technical",212,"13.3.3 ",15,"Clause \"13.3.3 Symbol rate\" is missing, and needs to be added so that the Base standard Symbol rate clause can be updated to specify the symbol rate(s) for the 5800 MHz and 6200 MHz bands.  Also for the NBA use case, the tolerance should be same as UWB (i.e. 20 PPM), rather than the 40PPM specified in the base standard, although this could be stipulated by reference to clause 13.3.14",null,"Insert Clause 13.3.3 and add text to specify the symbol rate(s) for the 5800 MHz and 6200 MHz bands, and the tolerance needed. ","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,645,"No","Qorvo","Editorial",212,"13.3.14",20,"numbered blank line",null,"delete it","No","Accepted",null,null,null,"DONE"]
[null,null,"MAMAN, MICKAEL",null,220,"Yes","STMicroelectronics","Technical",213,16.100000000000001,21,"the right section is 16.8.1",null,"change to 16.8.1","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,646,"No","Qorvo","Technical",213,16.100000000000001,21,"The reference to 16.8 on this line should be 16.8.1, While editorial in nature, this is a technical change to the meaning of the specification.",null,"change \"16.8\" to \"16.8.1\"","Yes","Accepted","Doc 15-25-0175-04-04ab-lb213-easy-comments-lhf.docx",null,null,"Ready"]
[null,null,"VERSO, BILLY",null,647,"No","Qorvo","Technical",214,"16.2.1",14,"For STS packets, the RMARKER position in the figure was indicated as \"informative\", because it is precisely specified in 6.9.1, we should do the same for SENS packets.",null,"Add word \"informatively\" after \"shown\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,648,"No","Qorvo","Editorial",214,"16.2.1",15,"\"201\" on its own on line 15 looks bad",null,"use non-breaking space so \"Figure 201\" appears on one line.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,649,"No","Qorvo","Technical",214,"16.2.1",19,"\"ranging sequence sent as short fragments\", could be improved as a description since \"short\" is arguably dependant on the programming, also I think we should be careful with the term \"ranging sequence\"",null,"Change \"ranging sequence sent as short fragments\" to \"sequence of fragments\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,650,"No","Qorvo","Technical",214,"16.2.1",20,"Since \"span\" it a measurement (of distance or time) \"fragments\" shouild be \"miliseconds\"",null,"Change \"fragments\" to \"miliseconds\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,629,"No","Qorvo","Technical",215,"16.2.1",3,"We have omitted to include a way for the NHL to specify whether the UWB packet has the Dynamic PHR or the basic 4z one. A good way to to do this would be to have a UWB packet configuration specifically selecting the use of the Dynamic PHR in both transmitter and receiver.  This only applies to packets without STS and SENS fields, so it is a signle addtional packet type.",null,"Add a line for \"DDMP_PACKET\" with discription \"This selects packet format employing the dynamic data mode PHR described in 16.2.7.4\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,630,"No","Qorvo","Editorial",219,"16.2.7.4.3",5,"The changes captured in 15-24-0559-02 and agreed by TG4ab  (see 15-24-0585-00) were not applied to the draft due to editor oversight. Theses should be applied.",null,"Apply changes from 15-24-0559-02","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,631,"No","Qorvo","Editorial",219,"16.2.7.4.3",6,"The reference to 21.2.4 (PHR of SUN OFDM PHY), no longer needs the bracketed term, which was added as a cross check while numbers were in flux during the 4me project.",null,"Delete the text \" (PHR of SUN OFDM PHY)\" that comes after the 21.2.4 reference.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"VERSO, BILLY",null,632,"No","Qorvo","Editorial",219,"16.2.7.4.3",5,"Submission 15-24-0559-02-04ab was previously approved at TG4ab to clarify the HCS calcuation but the editor overlooked integating it.  This was not a techncial change originally as it was just restating the algorithm in clearer language, and given that it was already agreed it is really an deitorial change.",null,"Integrate the 15-24-0559-02-04ab description of the HCS generating process","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Kristem, Vinod",null,116,"Yes","Apple","Technical",219,"16.2.7.4.3",6,"There are some gaps in HCS generation for dynamic data mode PHR2, which could result in potential interop issues. These are described in detail in DCN 15-24-0558-01-04ab. The proposed text to address these gaps was provided in DCN 15-24-0559-02-4ab.  The group agreed to incorporate the text in the 4ab Draft 2.0, as captured in the meeting minutes document 15-24-0585-00-04ab.",null,"Update the draft based on the CR text provided in DCN 15-24-0559-02-4ab","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"LEE, JAEGOOK",null,120,"Yes","Samsung","Technical",220,"16.2.10",18,"According to 15-24-0679, SHR & the first sensing segment are sent at the same channel. However, the mention in 16.2.10 says that \" If the channel for the SHR is different to the channel specified by phyFSS1channel, …",null,"Clarify whether SHR & the first sensing segment are sent at the same channel.","No",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,651,"No","Qorvo","Editorial",220,"16.2.10",23,"\"91\" on its own should be read with the \"length-91\"",null,"use non-breaking hyphen so \"length-91\" appears on one line.","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,652,"No","Qorvo","Editorial",220,"16.2.10",24,"length 127",null,"change to \"length-127\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,653,"No","Qorvo","Technical",220,"16.2.10",27,"I think this is not the \"CIR Report\" packet that is being talked about, which is not a PHY thing anways be an optional over-the-ari message, but rather the PHY level CIR data generated by accumulating / cross-correlating with the expected sequence in the sensing receiver.",null,"Change paragraph to \"For sensing, in the receiver, CIR data is generated per active SENS segment per active receiver antenna. No CIR data is required from other fields of the packet. CIR data from other (non-sensing) packets may optionally be employed for sensing.  The MLME-SOUNDING.request primitive is used by the next higher layer to extract the CIR data for sensing processing.\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"MAMAN, MICKAEL",null,221,"Yes","STMicroelectronics","Technical",221,"16.2.11.1",4,"the right section is 16.8.1",null,"change to 16.8.1","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"MAMAN, MICKAEL",null,222,"Yes","STMicroelectronics","Technical",221,"16.2.11.1",20,"the right section is 16.8.1",null,"change to 16.8.1","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,654,"No","Qorvo","Technical",221,"16.2.11.1",20,"The reference to 16.8 on this line should be 16.8.1, While editorial in nature, this is a technical change to the meaning of the specification.",null,"change \"16.8\" to \"16.8.1\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"LI, HuanBang",null,142,"Yes","NICT","Editorial",222,"16.2.11.1",5,"Delete extra in from 'as shown in in Figure 205'.",null,"Delete extra in.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Luo, Xiliang",null,144,"Yes","Apple","Technical",222,"16.2.11.1",5,"We should clarify the meaning of the timing durations like 1 ms in Figure 205, the time interval A in Figure 24, etc. \nThis was discussed as in Doc: 15-24-0632-00-04ab",null,"Add the following paragraph after line 5 and before line 6:\n\nIn Figure 205, the start time of each fragment refers to the peak of the pulse in the first chip of that fragment. The time interval of 1 ms correponds to 499200 chips.\n\nIn Figure 24, the start time of the NB packet is defined as the peak of the first half-sine pulse transmitted in the in-phase branch. In interleaving mode as in Figure 40, the time interval A corresponds to (macMmsRcpPollNSlots + macMmsRcpRespNSlots) ranging slots. Each ranging slot is specified in the unit of RSTU. One RSTU corresponds to 416 chips. In non-interleaving mode as in Figure 43, the time interval A corresponds to macMmsRcpPollNSlots ranging slots or macMmsRcpRespNSlots ranging slots.","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"MAMAN, MICKAEL",null,223,"Yes","STMicroelectronics","Technical",222,"16.2.11.1",12,"the right section is 16.8.1",null,"change to 16.8.1","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,655,"No","Qorvo","Technical",222,"16.2.11.1",12,"The reference to 16.8 on this line should be 16.8.1, although it could alos be 16.8 on its own without the 16.8.2, however since it is really repeating what was on line 20 of the previous page, I think we should delete this line.",null,"Delete this line","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"MAMAN, MICKAEL",null,224,"Yes","STMicroelectronics","Technical",222,"16.2.11.1",15,"MMS UWB packet can be RIF only",null,"remove \"additional\"","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,656,"No","Qorvo","Editorial",222,"16.2.11.2",23,"multi-millisecond ranging sequence (MMRS) is badly named and is confusing.  It sounds like it should encompass the RSF and RIF, but is in places it seems to be referring to the RSF, with the word symbol added to refer to the symbol, but in places it seems to be meeings the symbol directly like in Figure 205, elsewhere we have \"MMRS sequence number\".... What to do about it? Is it the symbol or the sequence, and is it just the RSF part or the RIF part too.  Why do we need another term…. lets just get rid of MMRS",null,"Proposal: if we are talking about the whole sequence of RSFs and RIFs and then lets just call that the MMS UWB PACKET.  Where are talking about the symbol being used for the RSF then lets call that RSF symbol. And then instead of MRS call it RSR.  ","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"LI, HuanBang",null,143,"Yes","NICT","General",237,"16.4.1.1",18,"Wrong subclause number.",null,"replace '16.3.4.2' by '16.4.1.2'.","Yes",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"LEONG, FRANK",null,122,"Yes","NXP Semiconductors","Technical",240,"16.4.4",1,"Time domain mask reference is unspecific.",null,"Add specific reference to the sensing time domain mask in Figure 215, noting that satisfying this mask implies satisfying the mask in Figure 16-24.","No",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"LEE, JAEGOOK",null,121,"Yes","Samsung","Technical",242,"16.8.1.2",1,"MSR = 256 with #49 MMRS config set (Gap size = 64) , the RSF length is 2051.28 ns * 256 = 525.127 us. The offset of interleaved MMS is 500 us. It means there is a possible setting which a RSF exceeds MMS offset. Even the interval between fragments is 0.33 us for time efficient O2M ranging.",null,"A solution may be necessary for this corner case.","No",null,null,null,null,"Assigned",null,"Xiliang"]
[null,null,"VERSO, BILLY",null,657,"No","Qorvo","Editorial",242,"16.8.1.2",4,"Table 63 in not a hot link, and wrong reference",null,"Change to \"Table 85\"","No","Accepted",null,null,null,"DONE"]
[null,null,"VERSO, BILLY",null,658,"No","Qorvo","Technical",249,"33.2.6.2",14,"This does not make sense that the higher layer handles an option configurable definition. Actually control of the PHY does not make much send to me…. The NHL can set any of these phyLeUwbModulation, phyLeUwbNumPulse, phyLeUwbFecCC and phyLeUwbFecRate to configure what to send (and receive?) so what does the phy send into PHY Config Index field for each of these possible configurations.  THis doesn't work, or make sense.",null,"Remove the PHY Configuration field, or make it support all the configurable modes, fix this broken clause 33 or delete it.","Yes",null,null,null,null,"Assigned",null,"Larry"]
[null,null,"ZAKAIB, LARRY",null,663,"Yes","Spark Microsystems","Technical",250,"33.2.6.2",1,"Symbol Rates 27.30 MHz and 40.96 MHz are missing from the LE UWB PHY Table 91",null,"Add the 27.30 MHz and 40.96 MHz Symbol Rates and corresponding data rates for each config to Table 91. \nAmend sections 33.3.4 and 33.3.5 to include the added symbol rates in the text and corresponding figures. \nAdd the phyLeUwbSymbolRate attribute to Table 12-14","Yes",null,null,null,null,"Assigned",null,"Larry"]
[null,null,"ZAKAIB, LARRY",null,662,"Yes","Spark Microsystems","Editorial",251,"33.3.1",12,"The equation has a typo in the summation range",null,"Change Ncbp to Ncpb","Yes","Accepted",null,null,null,"DONE"]
[null,null,"NEIRYNCK, DRIES",null,226,"No","Ultra Radio Ltd","Editorial",253,"33.3.4",3,"\"symbol rate\" is missing from the sentence. When adding, it probably makes most sense to adjust to the phrasing of the next BPM section 33.3.5.",null,"The OOK symbol duration shall be 12 chips duration (Nc), transmitted at a chip rate of 245.76 MHz corresponding to a 20.48 MHz symbol rate and (Tsym ~ 48.83 ns).","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Wentink, Menzo",null,1,"Non-Voter",null,"Technical",null,"10.39.8.3 ",null,"CCA with energy detect is currently optional for NB transmissions. This implies that there is no assurance that NB transmissions will defer for ongoing Wi-Fi transmissions.",null,"Make CCA based on energy detect mandatory for NB transmissions in channels 0-249, so that the spectrum can be shared with other technologies. Changes can be made per 15-25-0099-01-04ab-multiple-cca-for-nb or one of its revisions, which also proposes to reduce the impact of CCA busy events.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"Wentink, Menzo",null,2,"Non-Voter",null,"Technical",null,"10.39.8.3 ",null,"The absence of retries in the protocol design makes that any NB packet loss or CCA busy before an NB transmission causes a high penalty, because the entire exchange may be lost.",null,"To increase the resilience of the protocol against interference or CCA busies without building retries into the protocol, a possible consideration might be to allow for more than one CCA before an NB transmission or transmission sequence. A work in progress on this topic is 15-25-0099-01-04ab-multiple-cca-for-nb or one of its revisions. Adopt this document or one of its revisions in 802.15.4ab.","Yes",null,null,null,null,"Assigned",null,"Pooria"]
[null,null,"NEIRYNCK, DRIES",null,225,"No","Ultra Radio Ltd","Technical",null,null,null,"The UWB LE PHY does not have any specification on the clock accuracy. There were none in the original proposal because it was assumed that the LE PHY would be integrated in chapter 16 (HRP PHY) which already has the +/- 20 ppm spec for the coherent radios. However, now that the LE PHY is in a separate chapter, that chapter should specify clock accuracy such that designers know the worst-case to expect at the receiver.",null,"Add a new clause in the \"33.4 RF requirements\" section, \"33.4.5 Symbol clock accuracy\" stating \"Symbol durations shall be within +/- 100 ppm of the specified symbol rate in 33.3.4 and 33.3.5.\"","Yes",null,null,null,null,"Assigned",null,"Larry"]

{"sheet":"Progress-Status","index":1,"n_rows":497,"n_cols":28,"rows_kept":497,"cut":false,"hidden":false,"merged":[[26,1,26,24],[34,1,34,24],[1,1,1,8],[1,10,1,18],[6,4,6,6],[10,10,10,16],[18,1,18,24]]}
[]
[null,"Comments and Resolution Status",null,null,null,null,null,null,null,null,"Draft editing Status"]
[]
[null,"Total #  Comments","# with Blank resolution","# with non-blank resolution","# with \"Rejected\" resolution","# with \"Accepted\" resolution","# with \"Revised\" resolution","# Assigned","No Resolution, not Assigned",null,"DONE","N/A",null,"PART","Ready","ISSUE","ASSIGNED",null,"Blanks"]
[null,{"$f":"COUNTA(Comments!E:E)-1","v":663},{"$f":"B5-D5","v":548},{"$f":"COUNTA(Comments!P:P)-1","v":115},{"$f":"COUNTIF(Comments!P:P,\"Rejected\")","v":5},{"$f":"COUNTIF(Comments!P:P,\"Accepted\")","v":98},{"$f":"COUNTIF(Comments!P:P,\"Revised\")","v":12},{"$f":"COUNTA(Comments!V:V)-1","v":448},{"$f":"B5-D5-H5","v":100},null,{"$f":"COUNTIF(Comments!T:T,K4)","v":85},{"$f":"COUNTIF(Comments!T:T,L4)","v":5},null,{"$f":"COUNTIF(Comments!T:T,N4)","v":0},{"$f":"COUNTIF(Comments!T:T,O4)","v":25},{"$f":"COUNTIF(Comments!T:T,P4)","v":0},{"$f":"COUNTIF(Comments!T:T,Q4)","v":448},null,{"$f":"B5-(COUNTA(Comments!T:T)-1)","v":66}]
[]
[null,"Technical","Editorial",{"$f":"IF(D5=E7,\"Okay\",\"MIS-MATCHED\")","v":"Okay"},{"$f":"E5+F5+G5","v":115},null,null,null,null,null,{"$f":"SUM(K5:L5)","v":90},"Done + N/A"]
[null,{"$f":"COUNTIF(Comments!H:H,B7)","v":449},{"$f":"COUNTIF(Comments!H:H,C7)","v":208}]
[null,"General",{"$f":"IF(B5=C10,\"Okay\",\"MIS-MATCHED\")","v":"Okay"},{"$f":"D5/$B5","v":0.17345399698340874},7.5414781297134239E-3,0.14781297134238311,1.8099547511312219E-2,0.67571644042232282,0.15082956259426847,null,{"$f":"K7/$B$5","v":0.13574660633484162},"of total",null,{"$f":"N5/$B$5","v":0},{"$f":"O5/$B$5","v":3.7707390648567117E-2},{"$f":"P5/$B$5","v":0},{"$f":"Q5/$B$5","v":0.67571644042232282},null,{"$f":"S5/$B$5","v":9.9547511312217188E-2}]
[null,{"$f":"COUNTIF(Comments!H:H,B9)","v":6},{"$f":"C8+B8+B10","v":663}]
[null,null,null,null,null,null,null,null,null,null,{"$f":"K9+SUM(N9:Q9)","v":0.8491704374057315}]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null," "]
[]
[]
[null,"Assigned Comments"]
[]
[null,"Alex","Aniruddh","Ben","Billy","Bin Q","Carl","Carlos","Editor","Frank","Hongwon","Huan-Bang",null,"Jinjing","Kangjin","Larry","Li-Hsiang",null,"Mickael","Pooria","Riku","Rojan","Tero","Wenzheng","Xiliang",null,"Youngwan","SUM"]
[null,{"$f":"COUNTIF(Comments!V:V,B21)","v":59},{"$f":"COUNTIF(Comments!V:V,C21)","v":0},{"$f":"COUNTIF(Comments!V:V,D21)","v":3},{"$f":"COUNTIF(Comments!V:V,E21)","v":61},{"$f":"COUNTIF(Comments!V:V,F21)","v":0},{"$f":"COUNTIF(Comments!V:V,G21)","v":0},{"$f":"COUNTIF(Comments!V:V,H21)","v":0},{"$f":"COUNTIF(Comments!V:V,I21)","v":126},{"$f":"COUNTIF(Comments!V:V,J21)","v":0},{"$f":"COUNTIF(Comments!V:V,K21)","v":10},{"$f":"COUNTIF(Comments!V:V,L21)","v":6},null,{"$f":"COUNTIF(Comments!V:V,N21)","v":0},{"$f":"COUNTIF(Comments!V:V,O21)","v":0},{"$f":"COUNTIF(Comments!V:V,P21)","v":12},{"$f":"COUNTIF(Comments!V:V,Q21)","v":0},null,{"$f":"COUNTIF(Comments!V:V,S21)","v":9},{"$f":"COUNTIF(Comments!V:V,T21)","v":40},{"$f":"COUNTIF(Comments!V:V,U21)","v":21},{"$f":"COUNTIF(Comments!V:V,V21)","v":52},{"$f":"COUNTIF(Comments!V:V,W21)","v":0},{"$f":"COUNTIF(Comments!V:V,X21)","v":0},{"$f":"COUNTIF(Comments!V:V,Y21)","v":21},null,{"$f":"COUNTIF(Comments!V:V,AA21)","v":23},{"$f":"SUM(B22:AA22)","v":443}]
[]
[]
[]
[]
[null,"Comments with Proposed Resolutions"]
[]
[null,"Alex","Aniruddh","Ben","Billy","Bin Q","Carl","Carlos","Editor","Frank","Hongwon","Jinjing",null,"Kangjin","Larry","Li-Hsiang","Mickael",null,"Pooria","Riku","Rojan","Tero","Wenzheng","Xiliang","Youngwan",null,"SUM"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,{"$f":"SUM(B30:Y30)","v":0}]
[]
[]
[]
[]
[null,"Comments without Proposed Resolutions"]
[]
[null,"Alex","Aniruddh","Ben","Billy","Bin Q","Carl","Carlos","Editor","Frank","Hongwon","Jinjing",null,"Kangjin","Larry","Li-Hsiang","Mickael",null,"Pooria","Riku","Rojan","Tero","Wenzheng","Xiliang","Youngwan",null,"SUM"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,{"$f":"SUM(B38:Y38)","v":0}]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Alex, if he agrees, since he has other comments on the same part of the doc already assigned to him."]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"This is a complicated figure without proper text description, and not correct. It is using MLME-SCAN which looks for beacons.  I think it is better not to put this in until we have descriptive text and corrected figure, following the style used in the base standard."]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #782 is already assigned to him"]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #783 is already assigned to him"]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #786 is already assigned to him"]

{"sheet":"Categories","index":2,"n_rows":497,"n_cols":23,"rows_kept":497,"cut":false,"hidden":false,"merged":[]}
["MMS w/NBA","MMS wo/NBA","New frame format","Ack changes","RSS","SSBD","Other channel access","Security","Multi-node ranging / Hyper Block","Narrow Band function","Device discovery Ranging","Device discovery Data","Parameter Negotiation","Wake-up Radio","UWB data offload","Narrow Band PHY","UWB PHY HRP","UWB PHY LE","Sensing","Dynamic Data Rate Mode","PICS","IEs","OTHER"]
["NBMSS","UWBMSS","NEWFR","ACK","RSS","SSBD","CHA","SEC","HB","NBF","DISC-R","DISC-D","PARNEG","WUR","UWBDO","PHYNB","PHYHRP","PHYLE","SENS","DDRN","PICS",null,"OTHER"]
["Alex","Carl","Alex","Billy","Sven","Larry","Ben","Rojan","Youngwan","Alex","Alex","[Carlos]","Billy","Billy","Youngwan","Bin Q","Vinod","Larry","Pooria & Bin Q","[Carlos]"]
[]
[]
[]
[null,null,null,null,null,"11.2.8"]
[null,null,null,null,null,"12.3.2"]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"DONE"]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Alex, if he agrees, since he has other comments on the same part of the doc already assigned to him."]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"This is a complicated figure without proper text description, and not correct. It is using MLME-SCAN which looks for beacons.  I think it is better not to put this in until we have descriptive text and corrected figure, following the style used in the base standard."]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #782 is already assigned to him"]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #783 is already assigned to him"]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"Was Editorial now Technical, Needs Assignment. Perhaps to Jinjing since a similar comment #786 is already assigned to him"]

{"sheet":"Detailed Status","index":3,"n_rows":4,"n_cols":21,"rows_kept":4,"cut":false,"hidden":false,"merged":[[2,10,2,19],[3,10,3,19],[0,1,0,3],[0,4,0,5],[0,6,0,8],[0,9,0,20],[1,1,1,3],[1,4,1,5],[1,6,1,8],[1,9,1,20]]}
["Resolution","Accepted",null,null,"Rejected",null,"Revised",null,null,"Blank"]
[null,{"$f":"COUNTIF(Comments!P:P,\"Accepted\")","v":98},null,null,{"$f":"COUNTIF(Comments!P:P,\"Rejected\")","v":5},null,{"$f":"COUNTIF(Comments!P:P,\"Revised\")","v":12},null,null,0]
["Editor Status","ISSUE","Ready","DONE","Waiting","N/A","ISSUE","Ready","DONE","Ready","Assigned",null,null,null,null,null,null,null,null,null,"Unassigned"]
[null,0,0,0,0,0,0,0,0,0,0,null,null,null,null,null,null,null,null,null,0]

{"sheet":"To-Do","index":4,"n_rows":0,"n_cols":0,"rows_kept":0,"cut":false,"hidden":false,"merged":[]}

{"sheet":"Historical Status","index":5,"n_rows":40,"n_cols":8,"rows_kept":40,"cut":false,"hidden":false,"merged":[[36,1,37,1],[18,0,38,0],[18,1,19,1],[20,1,21,1],[22,1,23,1],[24,1,25,1],[26,1,27,1],[28,1,29,1],[30,1,31,1],[32,1,33,1],[34,1,35,1],[4,0,17,0],[4,1,5,1],[6,1,7,1],[8,1,9,1],[10,1,11,1],[12,1,13,1],[14,1,15,1],[16,1,17,1]]}
["Version",null,"-00","-01","-02","-03","-04","-05"]
["Date",null,"2025-03-31",null,null,null,null,"2025-04-10"]
["Occasion",null,"Initial spreadsheet",null,null,null,null,"After 2025-04-10 telecon"]
[]
["Editorial","Total",216,null,null,null,null,208]
[null,null,{"$f":"C5/(C5+C19)","v":0.32579185520361992},null,null,null,null,{"$f":"H5/(H5+H19)","v":0.31372549019607843}]
[null,"Addressed",0,null,null,null,null,82]
[null,null,{"$f":"C7/C5","v":0},null,null,null,null,{"$f":"H7/H5","v":0.39423076923076922}]
[null,"Ready",0,null,null,null,null,0]
[null,null,{"$f":"C9/C5","v":0},null,null,null,null,{"$f":"H9/H5","v":0}]
[null,"Done",0,null,null,null,null,80]
[null,null,{"$f":"C11/C5","v":0},null,null,null,null,{"$f":"H11/H5","v":0.38461538461538464}]
[null,"N/A",0,null,null,null,null,2]
[null,null,{"$f":"C13/C5","v":0},null,null,null,null,{"$f":"H13/H5","v":9.6153846153846159E-3}]
[null,"ISSUE",0,null,null,null,null,0]
[null,null,{"$f":"C15/C5","v":0},null,null,null,null,{"$f":"H15/H5","v":0}]
[null,"To Be Addressed",216,null,null,null,null,126]
[null,null,{"$f":"C17/C5","v":1},null,null,null,null,{"$f":"H17/H5","v":0.60576923076923073}]
["Technical/General","Total",447,null,null,null,null,455]
[null,null,{"$f":"C19/(C19+C5)","v":0.67420814479638014},null,null,null,null,{"$f":"H19/(H19+H5)","v":0.68627450980392157}]
[null,"Addressed",0,null,null,null,null,33]
[null,null,{"$f":"C21/C19","v":0},null,null,null,null,{"$f":"H21/H19","v":7.2527472527472533E-2}]
[null,"Ready",0,null,null,null,null,25]
[null,null,{"$f":"C23/C19","v":0},null,null,null,null,{"$f":"H23/H19","v":5.4945054945054944E-2}]
[null,"Done",0,null,null,null,null,5]
[null,null,{"$f":"C25/C19","v":0},null,null,null,null,{"$f":"H25/H19","v":1.098901098901099E-2}]
[null,"N/A",0,null,null,null,null,3]
[null,null,{"$f":"C27/C19","v":0},null,null,null,null,{"$f":"H27/H19","v":6.5934065934065934E-3}]
[null,"To Be Addressed",447,null,null,null,null,422]
[null,null,{"$f":"C29/C19","v":1},null,null,null,null,{"$f":"H29/H19","v":0.92747252747252751}]
[null,"Assigned",0,null,null,null,null,322]
[null,null,{"$f":"C31/C19","v":0},null,null,null,null,{"$f":"H31/H19","v":0.70769230769230773}]
[null,"Proposed Resolutions",0,null,null,null,null,7]
[null,null,{"$f":"C33/C19","v":0},null,null,null,null,{"$f":"H33/H19","v":1.5384615384615385E-2}]
[null,"Need Proposals",0,null,null,null,null,315]
[null,null,{"$f":"C35/C19","v":0},null,null,null,null,{"$f":"H35/H19","v":0.69230769230769229}]
[null,"Not Assigned",447,null,null,null,null,100]
[null,null,{"$f":"C37/C19","v":1},null,null,null,null,{"$f":"H37/H19","v":0.21978021978021978}]
[null,"Issue",0,null,null,null,null,0]
["Blank","Total"]

{"sheet":"CAD","index":6,"n_rows":1,"n_cols":22,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["Comment ID","Comment #","Name","Style","Index #","Vote","Affiliation","Category","Page","Sub-clause","Line #","Comment","File","Proposed Change","Must Be Satisfied?","Disposition Status (Accepted, Rejected, Revised)","Disposition Detail","Category","Notes","Editor Status DONE, Ready, N/A)","Editor Notes","Assignee"]

{"sheet":"Sheet1","index":7,"n_rows":25,"n_cols":3,"rows_kept":25,"cut":false,"hidden":false,"merged":[]}
["Commenter","# Comments"]
["Billy Verso",345,{"$f":"B2/663","v":0.52036199095022628}]
["Mickael Maman",80,0.12066365007541478]
["Tero Kivinen",65,9.8039215686274508E-2]
["Pooria Pakrooh",27,4.072398190045249E-2]
["Rojan Chitrakar",24,3.6199095022624438E-2]
["Huan-Bang Li",21,3.1674208144796379E-2]
["Carlos Aldana",15,2.2624434389140271E-2]
["B. Rolfe",13,1.9607843137254902E-2]
["Li Panpan",12,1.8099547511312219E-2]
["Li-Hsiang Sun",10,1.5082956259426848E-2]
["Bin Tian",10,1.5082956259426848E-2]
["Alex Krebs",9,1.3574660633484163E-2]
["Bin Qian",7,1.0558069381598794E-2]
["Riku Pirhonen",5,7.5414781297134239E-3]
["Larry Zakaib",5,7.5414781297134239E-3]
["Jaegook Lee",3,4.5248868778280547E-3]
["Stephen Shellhammer",2,3.0165912518853697E-3]
["Vinod Kristem",2,3.0165912518853697E-3]
["Dries Neirynck",2,3.0165912518853697E-3]
["Menzo Wentink",2,3.0165912518853697E-3]
["Frank Leong",1,1.5082956259426848E-3]
["Hong Won Lee",1,1.5082956259426848E-3]
["Xiliang Luo",1,1.5082956259426848E-3]
["Stephan Sand",1,1.5082956259426848E-3]