{"text_format":"1","workbook":"xlsx","n_sheets":9,"sheets":["Comments","Progress-Status","Categories","Detailed Status","To-Do","Historical Status","CAD","Rogue Comments","Sheet1"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":4,"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":245,"n_cols":22,"rows_kept":245,"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,"Billy Verso",null,104,"No","Qorvo","Editorial",1,"-",13,"Extraneous \"0.39\" at the end of the line",null,"Delete \"0.39\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,33,"No","Wi-SUN Alliance","Editorial",1,"Frontmatter",13,"There is extra string \"0.39\" at the end of line. ",null,"Remove extra characters.","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,34,"No","Wi-SUN Alliance","Editorial",9,"Introduction",26,"The copyright year in the footer is wrong. ",null,"Change copyright year in the footer to 2025 starting from page 9 to the end of document.","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,105,"No","Qorvo","Editorial",9,"-",27,"Copyright in footer from p9 should be latest year (2025)  ",null,"change to \"2025\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,46,"Yes","NICT","General",14,3.2,11,"Add acronym 'HBS' for 'Hyper Block Structure'.",null,"as suggested.","Yes","Rejected","This only appears as HBS IE, and it is not the practice  to put the IE acronyms in clause 3.2",null,null,"N/A"]
[null,null,"Alex Krebs",null,187,"Yes","Apple","Editorial",14,"3.2",11,"To most humans ARDEV vs ERDEV naming is confusing and indistinguishable what is advanced and what is enhanced.",null,"Consider renaming ARDEV to MMSRDEV or X-ERDEV or something else more intuitive to understand that 4ab ARDEV is a feature increment to 4z ERDEV.","No",null,null,null,null,"Assigned",null,"Editor"]
[null,null,"Tero Kivinen",null,37,"No","Wi-SUN Alliance","Editorial",14,3.2,17,"Acronym list is not sorted alphabetically. ",null,"Move RSR to correct place by sorting the acronym list.","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,35,"No","Wi-SUN Alliance","Editorial",14,3.2,24,"The acronym SBP has expansion of \"UWB sensing by proxy\", but U is not present in the acronym, and is not used when SBP is expanded. ",null,"Change \"UWB sensing by proxy\" to \"sensing by proxy\".","No","Revised","Change \"UWB\" to \"(UWB)\"",null,null,"DONE","Email Tero to explain"]
[null,null,"Tero Kivinen",null,36,"No","Wi-SUN Alliance","Editorial",14,3.2,25,"The acronym SDEV has expansion of \"UWB sensing device\", but U is not present in the acronym, and is not used when SDEV is expanded. ",null,"Change \"UWB sensing device\" to \"sensing device\".","No","Revised","Change \"UWB\" to \"(UWB)\"",null,null,"DONE","Email Tero to explain"]
[null,null,"Pooria Pakrooh",null,174,"No","Qualcomm","Technical",16,"6.6.3.3",18,"The text change from D02 to D03 is modifying the normative language. The sentence in D02 was more clearly reflecting the mandatory/optional values for AIFS for EMDEV. ",null,"Use the sentence in D02, as it better represents the normative language.\"For the high-rate pulse repetition frequency UWB PHY based enhanced modulations device (HRP-EMDEV) sending Imm-Ack, the AIFS duration shall be equal to the value of the macEmdevImmAckAifsPeriod attribute in Table 8-36.\"","Yes",null,null,null,null,null,"ACK"]
[null,null,"Pooria Pakrooh",null,175,"No","Qualcomm","Technical",23,"8.3.2.3",1,"The Rmarkers are defined as 32-bit parameters (similar to 15.4z). That is a maximum of ~67 ms. However, I don't think this is enough for non-interleaved MMS. Treply and Tround for compact frames are defined as 40-bit parameters though, which should be good. Seems like 32-bit has not been updated after adding the non-interleaved mode.",null,"In Table 8-28: \n\n1. Change the valid range to make the elements of RangingReportDescriptor array 10 bit long.\n2. Also, specify that each of 8 elements of the array has thios valid range.","Yes","Revised","Doc 15-25-0522-01-04ab-lb225-d03-comment-resolution-cid-175.docx",null,null,"DONE"]
[null,null,"Billy Verso",null,106,"No","Qorvo","Technical",23,"8.3.3",7,"The range actually depends on the PHY, and the valid range for each PHY given below the table.  I think rather than changing to say 0-8 , a better change  would be to say it depends on the PHY, as per the proposed change (right), especially as arguably a value of 8 which was added to select O-QPSK configuration, is not correct anyway see my comments on p24 line 3. ",null,"Instead of replacing \"0–7\" by \"0–8\" replace it by \"PHY dependent, as described below the table\"","Yes",null,null,null,null,"Assigned","O-QPSK-Modulation/Rate","Huan-Bang"]
[null,null,"Alex Krebs",null,188,"Yes","Apple","Technical",23,"8.3.2.3 RangingReportDescriptor","2 (Table 8-28)","This table only describes up to 8 RIF markers, but misses up to 16 RSF markers.",null,"Duplicate the 4 rows of this table and rename \"Rif\" to \"Rsf\", \"RIF\" to \"RSF\", and change \"Array of eight\" to \"Array of sixteen\" in the resulting 4 additional rows.","No",null,"Doc 15-25-0551-00-04ab-Resolution-of-LB225-comment-index-188.docx",null,null,"Assigned",null,"Billy"]
[null,null,"Mickael Maman",null,73,"Yes","STMicroelectronics","Technical",24,"8.3.3",1,"Add MmsFixedReplyTimeEnable in TxOptions for MMS with fixed reply time option",null,"add new element of TxOptions in Table 8-29\"MmsFixedReplyTimeEnable|Boolean|TRUE, FALSE|For MMS UWB ranging, this parameter is set TRUE if the transmission of the MMS UWB packet is offset from the reception of the MMS UWB packet, or FALSE otherwise","Yes",null,null,null,null,"Assigned","Fixed Reply Time","Mickael"]
[null,null,"Billy Verso",null,107,"No","Qorvo","Technical",24,"8.3.3",3,"There is a conflict between phyOqpskModulationConfig setting the modulation (p214 line 21) and the O-QPSK modulation and the DataRate parameter to the MCPS-DATA.request also doing it for the O-QPSK PHY (p24 line 2).  Could remove the use of DataRate, or make phyOqpskModulationConfig only specify the RX modulation. However this needs careful consideration to make sure the solution covers all the cases and various operations, and that we set all modes appropriately in TX and RX especially so that the receiver can correctly receive and decode the packet and report the result.",null,"The solution proposed for my other comment on this same line seems to be a good way to do it….","Yes",null,null,null,null,"Assigned","O-QPSK-Modulation/Rate","Huan-Bang"]
[null,null,"Billy Verso",null,108,"No","Qorvo","Technical",24,"8.3.3",3,"There is something wrong here, configuration #8 in Table 69 is a \"varies\" mode, so for the O-QPSK PHY DataRate parameter value of 8 does not tell the transmitter what modulation to use. Also DataRate values #2 to #5 in the \"varies\" case have to send a different SFD, versus same values when not in the varies case. (Note DataRate is also reported in MCSP-DATA-indication referencing these TX options for the meaning, in that case also the value #8 would be meaningless as a receive rate).",null,"A solution to this and the other comment I have relating to the conflict with phyOqpskModulationConfig would be to have this DataRate parameter only used when phyOqpskModulationConfig=8 and in that case have DataRate values #1 to #5 only as valid and selecting both the datarate and the SFD pattern.   When phyOqpskModulationConfig is not 8 the DataRate parameter would be meaningless/ignored and the TX and RX mode are selected by phyOqpskModulationConfig only.","Yes",null,null,null,null,"Assigned","O-QPSK-Modulation/Rate","Huan-Bang"]
[null,null,"Mickael Maman",null,74,"Yes","STMicroelectronics","Technical",26,"8.3.4",4,"add description of MmsFixedReplyTimeEnable for MMS with fixed reply time option",null,"add \"The MmsFixedReplyTimeEnable parameter of TxOptions applies to UWB multi-millisecond (MMS) packet transmissions. When MmsFixedReplyTimeEnable is the transmission of MMS UWB packet is offset by a fixed reply time from the reception of the initiator's MMS UWB packet. By default, MmsFixedReplyTimeEnable is FALSE. The fixed reply time may be a fixed known quantity, agreed between the parties participating in the ranging exchange.\"","Yes",null,null,null,null,"Assigned","Fixed Reply Time","Mickael"]
[null,null,"Tero Kivinen",null,38,"No","Wi-SUN Alliance","Editorial",26,"8.3.4",6,"The Description field of the CompactFrameID has some invalid font for the last sentence. ",null,"Fix the font.","No","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,47,"Yes","NICT","Editorial",26,"8.3.4",6,"In the description of 'CompactFrameID' in the first row of Table 1, the second sentence starting with \"If CompactSecurityEnabled …\" uses different font style compared to the rest of the text.",null,"unify font style to the others.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,109,"No","Qorvo","Editorial",26,"8.3.4",10,"In description of CompactFrameID starting at: \"If CompactSecurityEnabled is TRUE...\",  the font is wrong.",null,"change to correct font","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,189,"Yes","Apple","Editorial",26,"8.3.4 MCPS-DATA.request","7 (Table 1)","Row 1 description uses a different font.",null,"Change to Times.","No","Accepted",null,null,null,"DONE"]
[null,null,"Mickael Maman",null,75,"Yes","STMicroelectronics","Technical",27,"8.3.5",6,"There is no error status in MCPS-DATA.confirm to indicate the MMS is not received",null,"add \"MMS_RX_TIMEOUT\" in valid range colomn in Table 8-31 and add text page 26 line 3 \"if no MMS frame is received, the MAC sublaye shall issue the MCPS-DATA.confirm primitive with a Status of MMS_RX_TIMEOUT\"","Yes",null,null,null,null,"Assigned","Need to think about this one","Billy"]
[null,null,"Alex Krebs",null,190,"Yes","Apple","Editorial",27,"8.3.4 MCPS-DATA.request","2 (Table 2)","Row 1 uses weird looking dashes.",null,"Change to same dash as in row 2.","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,191,"Yes","Apple","Technical",29,"8.4.3 MAC PIB attributes","22 (Table 8-36)","64 us is too aggressive for mandatory support. Software decoding of long packets will take longer than that. The mandatory value should assure interoperability with such devices, while the optional values may be used by higher performance devices to reduce latency.",null,"Change Range column to include 250, and change description to \"value of 300 us is mandatory\" and \"values of 16 us, 32 us and 64 us is optional.\" and change Default column to 300.","No",null,null,null,null,"Assigned","ACK","Pooria"]
[null,null,"Alex Krebs",null,192,"Yes","Apple","Editorial",30,"9.2.1",12,"Full stop is missing.",null,"Append \".\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,39,"No","Wi-SUN Alliance","Technical",33,"9.3.2.4",29,"The note is incorrect, it should say that Start of Ranging Compact Frame carrying a Starting Block Index field provides an easy way for attacker to completely break the security of the compact frames. When attacker sends Start of Ranging Compact Frame carrying Starting Block Index to the recipient, it can set the Starting Block Index the recipient will be using in the future. This means it can force the recipient to reuse the nonce for compact frames, thus breaking security of the AEAD. The start of ranging compact frame can't even be protected, as the frame counter used to unsecured the frame needs the frame counter, which depends on the starting block index provided inside the frame. Even if there would be checks in the recipient that starting block index can't go backwards, i.e., it needs to be larger than any starting block index used before that allows another attack where the attacker can send single start of ranging compact frame with starting block index set to 0xffff, thus causing the recipient to reject all future secured frames. ",null,"Remove the special secured compact frames completely (I.e., remove all changes to section 9 from 4ab draft, and section 10.39.11.3.19 Secured Compact frame). Replace secured compact frames with a method of sending compact frame contents in the MAC Command frames, which can use normal security. The actual changes needed are described in document 10-25-505.","Yes",null,null,null,null,"Assigned","Compact Frame Security","Rojan"]
[null,null,"Alex Krebs",null,193,"Yes","Apple","Editorial",34,"9.3.5.3",27,"\"Message iID field.\" appears to be a typo",null,"Change to \"Message ID field.\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,195,"Yes","Apple","Editorial",35,"9.5.11 secCompactFrameKeyDescriptor","11 (Table 3)","The dash used in the Range column in \"0-15\" is a short dash. Hurts my eyes.",null,"Use endash \"–\" instead of the short dash \"-\" for ranges. Appears in multiple other tables.","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,194,"Yes","Apple","Editorial",35,"9.5.1 Generic PIB attributes","5 (Table 9-8)","The dash used in the Range column is a short dash. Hurts my eyes.",null,"Use emdash \"—\" instead of the short dash \"-\" for saying \"none\" instead. Appears in multiple other tables.","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,196,"Yes","Apple","Editorial",39,"10.21.6.1.4 MLME-ASSOCIATE.response","14 (Table 10-106)","\"AddressiongMode\" appears to be a typo.",null,"Change to \"AddressingMode\" eventually.","No","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,48,"Yes","NICT","General",42,"10.29.9.2.2",24,"This paragraph presents description on MLME-SOUNDING.confirm primitive, which should be appear in '10.29.9.2.3 MLME-SOUNDING.confirm'",null,"move this paragraph to '10.29.9.2.3 MLME-SOUNDING.confirm'.","Yes","Rejected","The lines being modified are in this clause in the base standard.",null,null,"N/A"]
[null,null,"Alex Krebs",null,197,"Yes","Apple","Technical",42,"10.29.9",45910,"What is the difference between \"sensing\" and \"sounding\"?",null,"Consider calling it either sensing or sounding consistently.","No",null,null,null,null,"Assigned","Naming","Billy"]
[null,null,"Pooria Pakrooh",null,176,"No","Qualcomm","Technical",46,"10.32.3.1",24,"What do \"time between successive ranging blocks\" and \"the time between successive ranging rounds\" mean? Are they referring to time duration of blocks and rounds? Or gap between successive rounds/blocks? Please clarify that.",null,"Change \"time between successive ranging blocks\" to \"time duration of  ranging blocks\", and \"the time between successive ranging rounds\" to \"the time duration of  ranging rounds\".","Yes",null,null,null,null,"Assigned","hyperblock","Youngwan"]
[null,null,"Zhenzhen Ye",null,18,"Yes","Redpoint Positioning","Editorial",46,"10.32.3.1","24-25","The words \"time\", \"\"non-uniform\", \"uniform\" are not clear.",null,"changing \"time\" to \"duration\", changing \"non-uniform\" to \"different\", changing \"uniform\" to \"same\". ","No","Rejected","Editor thinks the sentence is clear enough as is, and that changing \"time\" to \"duration\" would not be a positive step, while the phrase \"uniform spacing\" already appears in the base standard so reusing that in the lines 24-25 changes seems appropriate.",null,null,"N/A"]
[null,null,"Alex Krebs",null,198,"Yes","Apple","Technical",48,"10.32.3.5 Hyper block mode",22,"\"(where m does not equal p).\" restriction would restrict use of random number generators hence increase complexity. Is it necessary to apply such restriction?",null,"Unless such restriction is necessary, remove.","No",null,null,null,null,"Assigned","hyperblock","Youngwan"]
[null,null,"Zhenzhen Ye",null,20,"Yes","Redpoint Positioning","Technical",51,"10.32.3.5",1,"The Content Control Field example in Figure 8 is not same as that is defined in Figure 20 (page 60). The field \"Ranging Block Duration Present\" is missing in the example  ",null,"revise Figure 8 to include the missing field","Yes",null,null,null,null,"Assigned","hyperblock","Youngwan"]
[null,null,"Huan-Bang Li",null,49,"Yes","NICT","Editorial",51,"10.32.8.2",10,"Delete the unnecessary '-' beford the word 'aware'.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,218,"No","SAMSUNG","Technical",57,"10.32.9.10",25,"The mentioned field \"Number of Gaps\" doesn't exist in Figure 14.",null,"Please delete \"The value of the Number of 25 Gaps field shall be between 0 and 64.\"","Yes",null,null,null,null,"Assigned","msg fields","Youngwan"]
[null,null,"Billy Verso",null,110,"No","Qorvo","Editorial",58,"10.32.9.10",3,"Typo part of header of Table 8 accidently changed to \"q\" ",null,"change \"q\" to \"Block Scheduling Bitmap Length field\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Zhenzhen Ye",null,21,"Yes","Redpoint Positioning","Technical",59,"10.32.9.11",18,"If the ERR IE only works in Hyper Block mode, it should be stated in the description.",null,"\"The ERR IE is used in the Hyper Block mode by the controller to specify, …\"","No",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Zhenzhen Ye",null,19,"Yes","Redpoint Positioning","Technical",61,"10.32.9.12",6,"The description \"When the Ranging Block Duration Present field value is zero, the Ranging Block Duration field is not included in the Ranging Block Description List elements\" contradicts to Figure-21 in which \"Ranging Block Duration\" field always presents with the minimal length to be 1 Octet.",null,"change Figure-21 to allow the size of \"Ranging Block Duration\" field to be 0/1/2/3","Yes",null,null,null,null,"Assigned","msg fields","Youngwan"]
[null,null,"Billy Verso",null,111,"No","Qorvo","Editorial",63,10.39,3,"NBA MMS UWB or UWB Driven MMS UWB is for \"ranging\".  For improved readability it would be worth adding the word \"ranging\" after \"MMS UWB\" whenever doing so does not detract from the meaning.  And perhaps where \"operation\"  is used here to replace \"operation\" with \"ranging\".",null,"Review \"MMS UWB\" and add \"ranging\" afterwards if this does not detract from the sentence meaning","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,40,"No","Wi-SUN Alliance","Editorial",63,"10.39.1",5,"This is first use of HRP-ARDEV, expand it here. ",null,"Expand HRP-ARDEV here.","No","Accepted",null,null,null,"DONE"]
[null,null,"Carlos Aldana",null,27,"No","Meta","Technical",64,"10.39.1",14,"It is not clear what \"values of 2ms and 1.5ms\" refer to",null,"please clarify.  It looks it refers to \"time interval A\", but it's not clear.","Yes","Revised","Doc 15-25-0523-00-04ab-lb225-d03-comment-resolution-cid-27-and-6.docx",null,null,"DONE"]
[null,null,"Bin Tian",null,6,"No","Qualcomm","Technical",64,"10.39.1",18,"Add \" for both the intiatior and responder\" after \"for the time interval A\"",null,"as in the comment","Yes","Revised","Doc 15-25-0523-00-04ab-lb225-d03-comment-resolution-cid-27-and-6.docx",null,null,"DONE"]
[null,null,"Billy Verso",null,112,"No","Qorvo","Technical",64,"10.39.1",26,"This line says \"If another PHY is employed for control and reporting, the MMS UWB packet is recommended to include the initial SYNC and SFD fragment as specified in 16.2.11.\"  Although we agreed to this wording, reading it now it perhaps it could be clearer: (a) the reporting PHY has little or no relevance on whether to including the SYNC&SFD fragment in the preceding ranging phase, (b) to be precise in meaning we should spell out the otherness (i.e. when the PHY is not the \"tightly coupled\" O-QPSK PHY).  (c) Finally a recommendation is pretty weak and arguably insufficient guide for implementers on what they might need to do in their receiver designs, it would be better to mandate that this is transmitted so that the receiver can at least count on its presence to get synchronised.",null,"Replace with \"The initial SYNC and SFD fragment (as specified in 16.2.11) shall be included in the MMS UWB packet when an O-QPSK PHY (as defined clause 13) with UWB aligned clock source (as specified in 13.3.14) is not being used in the control phase.\"","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","SYNC+SFD Frag\n (#112, #113, #114, #126, #155)","Youngwan"]
[null,null,"Billy Verso",null,113,"No","Qorvo","Technical",64,"10.39.1",26,"This sentence is repeated verbatim on p91 line 8. -- Let's only say it once.",null,"Delete the sentence on p91 line 8.","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","SYNC+SFD Frag\n (#112, #113, #114, #126, #155)","Youngwan"]
[null,null,"Billy Verso",null,114,"No","Qorvo","Technical",64,"10.39.1",26,"What this sentence says, is repeated in the final phrase of this sentence on p231 line 15: \"In the case of UWB driven MMS UWB, the SYNC and SFD fragment shall be the first fragment sent in the MMS UWB packet, and this is also recommended when another PHY is employed for control and reporting\".  No need to say this a second time.",null,"Delete the ending phrase, (line 16 p231), \", and this is also recommended when another PHY is employed for control and reporting\".","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","SYNC+SFD Frag\n (#112, #113, #114, #126, #155)","Youngwan"]
[null,null,"Bin Tian",null,8,"No","Qualcomm","Technical",65,"10.39.2",17,"\"precedes active ranging,\", the term active ranging is not well defined. The previous paragraph mentioned than ranging includes three phases which doesn't include the initializaion setup","Add a sentence in the previous paragraph that the NMS ranging session include the initalization and setup, and active ranging stage. The active ranging sessions includes three phases ...","Add a sentence in the previous paragraph that the NMS ranging session include the initalization and setup, and active ranging stage. The active ranging sessions includes three phases ...","Yes","Revised","Doc 15-25-0524-00-04ab-lb225-d03-comment-resolution-cid-8.docx",null,null,"DONE"]
[null,null,"Billy Verso",null,115,"No","Qorvo","Technical",65,"10.39.2",20,"The path to follow to figure out that 1.95Mb/s modulation is required to be used for the control/report packets for the UWB driven MMS UWB ranging is a little convoluted, i.e., this is buried in the specification of the mmsControlPhaseMode and mmsReportPhaseMode parameters (and Control Phase Config and Report Phase Config field values) where in table 21 values 14 or 15 apply to UWB driven, and these point onwards to the Table UWB modulation sets #1 and #2 from Table 86.  We should make this easier to see, and also clarify that the 4z PHR is to be used.",null,"At the end of the  first sentence on p65 line 28, add:  \", and shall use the UWB modulation specified by set #1 or set #2 from Table 86 with the PHR described 16.2.7.3”.","Yes","Accepted","Doc 15-25-0525-01-04ab-lb225-d03-comment-resolution-cid-115.docx",null,null,"DONE","(end of of line 20)"]
[null,null,"Bin Tian",null,7,"No","Qualcomm","Technical",65,"10.39.2.",23,"The term \"ranging phase\" is overloaded: MMS UWB ranging phases inlcude a phase called \"ranging phase\". ","Change the 2nd ranging phase to measurment phase like MMS UWB ranging phases include control and measurement phase. Or change the title of the Figure 25 as MMS UWB active ranging exchange ","Change the 2nd ranging phase to measurment phase like MMS UWB ranging phases include control and measurement phase. Or change the title of the Figure 25 as MMS UWB active ranging exchange ","Yes","Rejected","Doc 15-25-0526-00-04ab-lb225-d03-comment-resolution-cid-7.docx",null,null,"N/A","Naming"]
[null,null,"Billy Verso",null,116,"No","Qorvo","Editorial",67,"10.39.3.2",6,"\"set as SUCCESS as described in Table 27\" left over upper case value.",null,"Change to \"set to indicate success (as per Table 27).\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,199,"Yes","Apple","Technical",67,"10.39.3.2 Session initialization","14-15","Add a MLME sequence chart here.",null,"Add sentence after line 14: \"Figure <editor's choice> shows the message sequence chart for the initialization handshake for one-to-one ranging as illustrated in Figure 26. \" Copy & paste Figure 28 to after this sentence and remove the following 5 messages surrounding the ADV-CONF message:\n\nMLME-RX-ENABLE.request\nMCPS-DATA.request\nAdvertising Confirmation\n(RPA Hash responder IRK, SOR Time Offset)\nMCPS-DATA.indication\nMLME-SET.request","No",null,"Doc 15-25-0547-00-04ab-Resolution-of-LB225-comment-index-199.docx",null,null,"Assigned",null,"Billy"]
[null,null,"Billy Verso",null,117,"No","Qorvo","Technical",69,"10.39.3.3",5,"In the coordination scheme, a new initiator wanting to start ranging listens to hear Acquisition frames sent by other independent initiators in the vicinity and uses this info to position its ranging to avoid collocated sessions. It might be worth recommending that LBT is used for the opportunistic Acquisition frames transmissions to the reduce collision/overlap and improve the likelihood of their reception.",null,"Add text to recommend LBT is used for NB Acquisition frame transmissions, especially for those sent opportunistically.","Yes",null,null,null,null,"Assigned","NB/CCA/LBT","Youngwan"]
[null,null,"Billy Verso",null,118,"No","Qorvo","Technical",69,"10.39.3.3",9,"If we want to have Narrowband Acquisition frames receivable by broadest set of devices we should also specify the modulation to use.",null,"after \"channel\" add \"using config #1 from Table 69\"","Yes",null,null,null,null,"Assigned","Acquisition","Youngwan"]
[null,null,"Billy Verso",null,119,"No","Qorvo","Technical",69,"10.39.3.3",10,"If we want to have UWB Acquisition frames receivable by a broad set of UWB MMS devices, we should probably nominate the mode to use, and the preamble code.",null,"after \"channel\" add \"using set #1 from Table 86 with the PHR described 16.2.7.3, and preamble code index 12”.","Yes",null,null,null,null,"Assigned","Acquisition","Youngwan"]
[null,null,"Billy Verso",null,120,"No","Qorvo","Editorial",69,"10.39.3.3",12,"\"upon regional or regulatory channel availability.\" missing word.",null,"add \"depending\" directly before \"upon\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,219,"No","SAMSUNG","Editorial",70,"10.39.3.3",19,"Two most lefthand sided entity should be \"Initiator 1 next higher layer\" and \"Initiator 1 MAC\", respectively.",null,"Please change \"Initiator\" to \"Initiator 1\", respectively","No","Accepted",null,null,null,"DONE"]
[null,null,"Bin Tian",null,9,"No","Qualcomm","Technical",78,"10.39.3.8",16,"The previous sentence states the new parameters take effect in the next rangng round which contradicts to the current sentence \"effective time is beyond the scope of this standard\"","remove \"and effective time\" before \"is beyond the scope of this standards\"","remove \"and effective time\" before \"is beyond the scope of this standards\"","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Pooria"]
[null,null,"Rojan Chitrakar",null,62,"Yes","Huawei","Technical",79,"10.39.3.9",6,"How the \"more concise representation\" should be interpretated is not clear.",null,"Add text to explain how to interpret the \"more concise representation\"","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Rojan Chitrakar",null,63,"Yes","Huawei","Technical",79,"10.39.3.9",8,"For SMID Tag = 4; \"SMID Length = 2\" should be \"SMID Length = 1\"?",null,"Change to \"SMID Length = 1\"","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Rojan Chitrakar",null,64,"Yes","Huawei","Technical",79,"10.39.3.9",8,"Do we also need a \"more concise representation\" for other Compact frames, e.g., One-to-many Poll?",null,"Add \"more concise representation\" for other Compact frames, e.g., One-to-many Poll","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Billy Verso",null,121,"No","Qorvo","Technical",79,"10.39.3.9",8,"In Figure 40—More concise example, the comment: SMID Tag=4  SMID Length should be 1 not 2",null,"Change to \"SMID Tag=4 (One-to-one Response), SMID Length=1,\"","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Billy Verso",null,122,"No","Qorvo","Technical",79,"10.39.4.1",21,"\"… and includes (mmsRcpPollNSlots + mmsRcpRespNSlots) ranging slots for peer-to-peer ranging.\" is only true for interleaved tanging",null,"change \"peer-to-peer ranging.\" to \"peer-to-peer interleaved ranging.\"","Yes",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Riku Pirhonen",null,206,"Yes","NXP Semiconductors","Technical",80,"10.39.4.1",1,"The draft is missing the resolution to comment #19 from Doc 15-25-0331-01-04ab. The paragraph from the comment resoluton document is provided here. The purpose of the comment is to clarify that in case of non-interleaved mode the responder doesn't send immadiate repsonse to the NB poll. ",null,"Insert text: \"In case of non-interleaved sub-rounds, described in subclause 10.39.7, each non-interleaved sub-round has a control phase with duration defined by macMmsRcpPollNSlots or macMmsRcpRespNSlots parameter followed by a ranging phase of macMmsRpDuration. When a non-interleaved sub-round is used, the Initiator proceeds to transmit the MMS UWB Packet without waiting for a response compact frame from the Responder as it would in the interleaved case. The responder sends the response after the reception of the MMS UWB Packet from the Initiator. Any further non-interleaved NBA MMS UWB exchanges in subsequently sub-rounds would similarly each have the narrowband compact frame followed by the MMS UWB packet.\" ","No",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Bin Tian",null,15,"No","Qualcomm","Technical",80,"10.39.4.2",31,"Change \"may use the listen-before-talk\" to \"shall use the listen-before-talk if the transmission duty cycle is above certain threshold\". ","as in the comment. Threshold can set at 3% or the group compromised value","as in the comment. Threshold can set at 3% or the group compromised value","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Steve Shellhammer",null,17,"No","Qualcomm Technologies, Inc.","Technical",80,"10.39.4.2",32,"NB coexistence with other technologies in UNII-3 and UNII-5 bands needs to be addressed by defining a mandatory coexistence mechanism for NB operation in UNII-3/5, with clear guidance for the implementers.",null,"Adopt a mandatory coexistence mechanism for NB operation in UNII-3 and UNII-5 bands. Adopt the proposed resolution text in DCN 15-25-426/r0 (duty cycle based CCA mode 1), or the proposed resolution text in DCN 15-25-429/r1 (Single CCA mode 1 based on transmit power). ","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,26,"No","Meta","Technical",80,"10.39.4.2",32,"LBT has been shown to be the best channel access mechanism for NB device in the presence of other devices.  Change \"may\" to a \"shall\"",null,"as in comment and then remove the following sentence","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Pooria Pakrooh",null,177,"No","Qualcomm","Technical",80,"10.39.4.2",32,"Usage of the defined channel access (LBT) for NB  should be mandatory to povide predictable and guaranteed coexistence with other spectrum users.",null,"Change page 80, lines 32 and 33 to :\"For the NBA MMS UWB, the O-QPSK PHY shall use the listen-before-talk (LBT) functionality defined in 32 10.39.8.3.\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Alex Krebs",null,200,"Yes","Apple","Technical",80,"10.39.4.2 Channel access",32,"\"For the NBA MMS UWB, the O-QPSK PHY may use the listen-before-talk (LBT) functionality defined in 10.39.8.3. Note that some regulatory domains require channel access using some form of LBT.\" is inaccurate. The channel access described in 10.39.8.3 is called CSMA and SSBD. Also no regulatory domain currently requires LBT in any of the channels used by the PHY.",null,"Change to \"For the NBA MMS UWB, the O-QPSK PHY may use the channel access functionality defined in 10.39.8.3.\"","No",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Alex Krebs",null,201,"Yes","Apple","Technical",80,"10.39.4.2 Channel access",34,"\"When channel access fails, transmission shall be deferred for the remainder of the ranging round.\" is defined more clearly by the respective channel access mechanism that is chosen. The higher layer behavior is more adequately described in the remained of the subclause.",null,"Remove this line.","No",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","MMS Ranging Rounds","Pooria"]
[null,null,"Mickael Maman",null,76,"Yes","STMicroelectronics","Technical",80,"10.39.4.2",35,"An initiator shall discontinue the MMS UWB ranging round if ..., or the initiator fails to receive the response Compact frame at the expected time. There is an exception for one-way ranging",null,"add \"except for one-way ranging\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","MMS Ranging Rounds","Pooria"]
[null,null,"Mickael Maman",null,77,"Yes","STMicroelectronics","Technical",81,"10.39.4.2",1,"To be compatible with non interleaved mode and one to may scheme, a responder shall not discontinue the MMS UWB ranging round if the responder fails to receive the poll Compact frame at the beginning of the expected ranging round but a the expected time.",null,"remove \"at the beginning of the expected ranging round\" and add \"at the expected time\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","MMS Ranging Rounds","Pooria"]
[null,null,"Carlos Aldana",null,28,"No","Meta","Technical",81,"10.39.5",13,"In the text \"either of which may be zero\", can they both be zero?",null,"please clarify  ","Yes",null,null,null,null,"Assigned","UWB MMS PACKET","Panpan"]
[null,null,"Youngwan So",null,220,"No","SAMSUNG","Technical",81,"10.39.5",14,"When explaining about Figure 42, \"mmsRpDuration\" is mentioned, but the figure only has \"RpDuration\"",null,"Please change \"RpDuration\" to \"mmsRpDuration\" in Figure 42.","No",null,null,null,null,"Assigned","MMS Ranging Rounds","Alex"]
[null,null,"Mickael Maman",null,78,"Yes","STMicroelectronics","Technical",81,"10.39.5",22,"add text for SS-TWR with fixed reply time",null,"add \"The MMS ranging procedure may be adapted for SS-TWR with fixed reply time. If the responder is able to accurately estimate the arrival time of the MMS UWB packet and to  reply with pre-known reply time, it obviates the need for any transfer of the reply time as part of the ranging exchange. In the ranging phase, the responder may start transmitting its HRP UWB PHY MMS packet offset by a fixed reply time from the start of the HRP UWB PHY MMS packet received from the initiator. This option is signaled by the MMS Fixed Reply Time parameter described in 10.39.11.1.3.8. The accuracy of the resultant range will depend on how accurate the estimation of the arrival time is and how fine a control the responding device has on the transmit time of its MMS message, where every 1 ns error in TOF translates to approximately 30 cm range error.\nOptionally in the ranging phase, by combining macMmsFixedReplyTimeEnable and macMmsReversedOrder, 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 a fixed reply time from the start of the HRP UWB PHY MMS packet received from the responder. This option is signaled by the reversed MMS Order parameter described in 10.39.11.1.3.8.","Yes",null,null,null,null,"Assigned","Fixed Reply Time","Mickael"]
[null,null,"Alex Krebs",null,202,"Yes","Apple","Technical",82,"10.39.6","19-20","\"If a device fails to deliver a report during its assigned slot in the report phase, OOB mechanisms might be\nemployed to deliver it during the remaining time of the current ranging block.\" behavior is out of scope.",null,"Prepend by \"Note—\"","No",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","MMS Ranging Rounds","Youngwan"]
[null,null,"Mickael Maman",null,79,"Yes","STMicroelectronics","Technical",83,"10.39.7.1",1,"It is easier to introduce NBA-MMS UWB non interleaved with 2 subround and to add report phase. The same for UWB draiver MMS UWB non interleaved",null,"update the figure","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Riku Pirhonen",null,207,"Yes","NXP Semiconductors","Technical",83,"10.39.7.1",1,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Riku Pirhonen",null,208,"Yes","NXP Semiconductors","Technical",83,"10.39.7.1",3,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Youngwan So",null,221,"No","SAMSUNG","Editorial",83,"10.39.7.1",12,"Missing verb.",null,"Please change \"would\" to \"would be\"","Yes","Revised","Remove the \"(as it would in the interleaved case)\"",null,null,"DONE"]
[null,null,"Mickael Maman",null,81,"Yes","STMicroelectronics","Technical",83,"10.39.7.8",15,"Is is not clear how non interleaved mode can be extended to one-to-many",null,"An interesting example is an interleaved subround between the initiator and the responder 1 and non interleaved subround for responder 2, then responder 3 … and at the end a initiator O2M report.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Mickael Maman",null,80,"Yes","STMicroelectronics","Technical",83,"10.39.7.2",16,"add a section 10.39.7.2 NBA MMS UWB non-interleaved and include all the modes in subsection",null,"as in comment","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Riku Pirhonen",null,209,"Yes","NXP Semiconductors","Technical",83,"10.39.7.2",21,"The text misses words \"reception of\", as the response is delayed by the amount of Time of Flight and cannot be perfecly synchronized to the transmission by the initiator.",null,"Add words \"reception of\" to sentence \"one macMmsRpDurtion slots after reception of the start of the MMS packet sent by the initiator in sub-round 1\" as stated in Comment resolution to Comment #22 in DCN 15-25-0292-01-04ab. ","No",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Alex Krebs",null,203,"Yes","Apple","Technical",83,"10.39.7.1","1-4","Figure 44 and 45 have inconsistent legends for the same content.",null,"Change legend of Figures 44, 46, 47, 48, 49, 50, 51 from \"O-QPSK\" to \"O-QPSK compact frame\" and \"UWB\" to \"RSF or RIF fragments\". Change legend of Figure 45 \"Compact frame\" to \"UWB compact frame\".","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Riku Pirhonen",null,210,"Yes","NXP Semiconductors","Technical",84,"10.39.7.2",1,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Billy Verso",null,123,"No","Qorvo","Technical",84,"10.39.7.3",5,"In the description of the non-interleaved ranging with multiple sub rounds, the text says \"repeats the poll\" but constraining it to be this same message exactly is not right.  For instance if it is secured, it will need to be resecured since being in a different slot, I will have different nonce and MIC values.  And it should be allowed to have other parameters added/omitted/different versus the first poll?  Also it would be better to have a separate message type, but if not, since this is logically responding to the Response from the responder, perhaps it should be a Response.",null,"If not a special message, then instead of \"repeats the poll Compact frame\", say \"sends a response Compact frame\" to complete the DS-TWR and consider what additional or different parameters it may have.","Yes",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Riku Pirhonen",null,211,"Yes","NXP Semiconductors","Technical",84,"10.38.7.3",6,"To clarify the timing of the transmission due to impact of Time of Flight in the third subround, add words \"reception of\" to the sentence.",null,"Modify the text to say: \"starting mmsRpDuration after reception of the start of the MMS UWB packet sent by the responder\"","No",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Riku Pirhonen",null,212,"Yes","NXP Semiconductors","Technical",84,"10.39.7.3",10,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","MMS Ranging Rounds","Billy"]
[null,null,"Rojan Chitrakar",null,65,"Yes","Huawei","Technical",84,"10.39.7.4",12,"What is the benefit of the 2 way ranging with four non-interleaved sub-rounds? Also, how is the reply and round-trip time fields in the report frame computed in this case?",null,"Explain the benefit of the 2 way ranging with four non-interleaved sub-rounds. Also, clarify how the reply and round-trip time fields in the report frame computed in this case.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Riku Pirhonen",null,213,"Yes","NXP Semiconductors","Technical",84,"10.38.7.4",17,"To clarify the timing of the transmission due to impact of Time of Flight in the fourth subround, add words \"reception of\" to the sentence.",null,"Modify the text to say:\"starting mmsRpDuration after reception of start of the MMS UWB ranging packet sent by responder","No",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Riku Pirhonen",null,214,"Yes","NXP Semiconductors","Technical",85,"10.39.7.4",3,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Rojan Chitrakar",null,66,"Yes","Huawei","Technical",85,"10.39.7.5",5,"What is the benefit of the Hybrid ranging with an interleaved and a non-interleaved sub-round? Also, how is the reply and round-trip time fields in the report frame computed in this case?",null,"Explain the benefit of the Hybrid ranging with an interleaved and a non-interleaved sub-round. Also, clarify how the reply and round-trip time fields in the report frame computed in this case.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Billy Verso",null,124,"No","Qorvo","Technical",85,"10.39.7.5",8,"In the description of this hybrid exchange it says \"the initiator repeats the control and ranging packets\" but it should not be a repeat. Rather the initiator sends a final control packet, (possibly secured so not a repeat) and another ranging packet (possibly with RIF so again not a repeat).  This is really a response to the responder so if not a special \"final\" frame, a \"response\" frame would be better than using a \"poll\" since a \"poll\" is logically being sent to solicit a response.",null,"If not a special message, then instead of \"repeats the poll Compact frame\", say \"sends a response Compact frame\" to complete the DS-TWR and consider what additional or different parameters it may have.","Yes",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Riku Pirhonen",null,215,"Yes","NXP Semiconductors","Technical",85,"10.39.7.5",9,"The timing of the second packet from the initiator is done in reference to the received packet from the responder and takes Time of Flight into account.",null,"Replace sentence \"The second sub-round starts mmsRpDuration after the start of the MMS UWB ranging packet sent by the initiator in the first sub-round.\" with sentence  \"The initiator starts transmission macMmsRpDuration after reception of the start of the MMS ranging packet from the responder. \" as stated in Comment resolution to Comment #22 in DCN 15-25-0292-01-04ab. ","No",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Pooria Pakrooh",null,178,"No","Qualcomm","Technical",85,"10.39.7.5",15,"Some time durations are shown but not defined in Figure 49.",null,"In Figure 49, either define, or remove the undefined time durations shown by some double-sided arrows.","Yes",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Riku Pirhonen",null,216,"Yes","NXP Semiconductors","Technical",85,"10.39.7.5",15,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Rojan Chitrakar",null,67,"Yes","Huawei","Technical",85,"10.39.7.6",17,"What is the benefit of the Double-sided two-way ranging with two interleaved sub-rounds? Also, how is the reply and round-trip time fields in the report frame computed in this case?",null,"Explain the benefit of the Double-sided two-way ranging with two interleaved sub-rounds. Also, clarify how the reply and round-trip time fields in the report frame computed in this case.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Pooria Pakrooh",null,179,"No","Qualcomm","Technical",85,"10.39.7.6",17,"Not clear why this new interleaved mode has been added in D03. There has not been justification for why this new mode needs to be introduced at this stage. Due to NB exchange and initial CFO compensation, the need for Double sided TWR for interleaved mode is not justified. Also, this is an interleaved mode placed under 10.39.7 subclause under non-interleaved MMS modes.",null,"Remove ubclauese 10.39.7.6. It is about a new interleaved MMS mode that has been defined under 10.39.7 clause for noninterleaved modes. Also, the need for introducing this new mode in D03 has not been discussed or justified.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Rojan Chitrakar",null,68,"Yes","Huawei","Technical",85,"10.39.7.6",20,"Is there a reason to swap the order in the second sub-round? Wouldn't it be simpler to repeat the first sub-round. Also, this will require initiator to support transmission of Poll frame and responder to support transmission of Rest frame. Consider if this is really necessary.",null,"Simply repeat the first sub-round operation in the 2nd sub-round. Else, clarify the reason for the swaping of the transmission sequence in the 2nd sub-round.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Riku Pirhonen",null,217,"Yes","NXP Semiconductors","Technical",86,"10.39.7.6",3,"Non-interleaved drawings do not show the impact of time of fligh on the consecutive alternating packets. The vertical lines aligning initiator and responder slot structures give impression that the packets stay in perfect sync with the slot start. It would be clearer to show a small (although exaggarated) shift in packet position vs start of the slot as done in the comment resolution document. Similar comment is given related to figures 44, 45, 46, 47, 48, 49, 50.",null,"Change the drawings to match with the drawings in DCN 15-25-0292-01-04ab","No",null,null,null,null,"Assigned","Figures","Billy"]
[null,null,"Rojan Chitrakar",null,69,"Yes","Huawei","Technical",86,"10.39.7.7",5,"Is the MMS Initiatlization and Setup phase applicable for One-way ranging as well? OWR use cases may not even require negotiation between devices. In such cases, Initialization and setup may not even be required; it may be sufficient for the initiator to periodically send out SOR frames indicating the start times of the OWR MMS packets. Also, for OWR use case, Poll frame (with RPA hash) may not be the best option.",null,"Clarify whether the initialization and setup phase is required for OWR. Add the option of OWR without Initialization and Setup; in this case it may be benificial to define a variant of Poll frame specifically for OWR.","Yes",null,null,null,null,"Assigned","MMS Ranging Rounds","Riku"]
[null,null,"Youngwan So",null,222,"No","SAMSUNG","Editorial",86,"10.39.7.7",8,"Seems like typo",null,"Please change \"The\" to \"There\" maybe.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Pooria Pakrooh",null,180,"No","Qualcomm","Technical",87,"10.39.8.3",17,"The details of LBT have been removed  in D03, instead of being further clarified. 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 and detailed guidance for the implementers. Adopt the proposed change in DCN 15-25-426/r0, which suggests to use CCA mode 1 for duty cycle greater that 2.5%",null,"Change subclause 10.39.8.3 by replacing the existing text with the proposed text resolution in DCN 15-25-426/r0. The text is copied below for reference, see DCN15-25-426/r0 for thge detailed text proposal:\n\" An NB device in section 10.39 (NBA UWB MMS) and 10.44 (UWB data offload to NB) operating in channels 0-249 in 5800 MHz and 6200 MHz bands, shall measure its NB transmission duty cycle, which is defined as the maximum ratio of the total NB transmission duration divided by any 100 ms observation window. Above 2.5% duty cycle an NB capable device shall perform CCA mode 1 before each O-QPSK PHY transmission. The ED threshold shall be set to the value required by local regulations; otherwise, it shall be set to -75 dBm/MHz. After completing the CCA, if the CCA is idle , the device shall start transmission no later than 16 μs after completing the CCA. If the  CCA is busy and the number of consecutive CCAs is not equal to macMmsNbMaxConsecutiveCCAs, the device shall go the next channel (which might be the same channel) and perform a new CCA after at least 50 us when on another channel or after at least 100 us when on the same channel. Otherwise, the device shall skip transmission for the current ranging round. \n\nA receiving device shall check for the presence of an expected O-QPSK PHY transmission. If the expected transmission is not present and the number of consecutive absences is not equal to macMmsNbMaxConsecutive-CCAs, the device shall go to the next channel (which might be the same channel) and check for the presence of the expected transmission there. Otherwise, the device shall skip the expected reception.\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Bin Qian",null,3,"No","Huawei","Technical",87,"10.39.8.3",18,"The UNII-5 band is not license-free in China, which will result in increasing congestion in the UNII-3 band. To achieve better coexistence, a duty cycle–based LBT mechanism is necessary. We propose setting the duty cycle threshold at 5% within any 100ms interval: when the duty cycle is at or below 5%, LBT may be used; when the duty cycle exceeds 5%, LBT shall be used.",null,"Change 10.39.8.3 to read as follows:\n\"If the NB duty cycle within any 100ms observation window exceeds 5%, 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 when the same channel is used in consecutive slots. If the the NB duty cycle within any 100ms observation window is  5% or lower, the same method may be used to improve coexistence with other spectrum users\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Bin Tian",null,13,"No","Qualcomm","Technical",87,"10.39.8.3",18,"There is no mandatory coexistence scheme defined for NB operation. ","Change to LBT is mandatory required for NB operation if its transmission dutcy cycle is above certain threshold","Change to LBT is mandatory required for NB operation if its transmission dutcy cycle is above certain threshold","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Alex Krebs",null,204,"Yes","Apple","Technical",87,"10.39.8.3 Listen-before-talk (LBT)",18,"The conditional statement \"If LBT is required [...] for regulatory reasons or as a coexistence mechanism, then [...] shall be applied\" is unclear because:\n1.\t\"regulatory reasons\" imply the existence of a legal requirement. Mandating the use of a specific IEEE 802.15.4 method may not meet this requirement. In that case, implementers would have to make a choice between violating regulatory requirements or violating 802.15.4ab requirements.\n2.\t\"coexistence reasons\" would be for the device/implementer to determine subjectively since no objective (normative) criteria for coexistence exist in the 802.15.4-2024 standard.\nThe proposed text change clarifies the sentence adequately by suggesting options to meet the requirements if either of the stated conditions carries.",null,"Change paragraph to \"If LBT is required before a transmission for regulatory reasons then one of the channel access methods defined in 6.3.2 or 10.45 with CCA mode 1 or 3a may 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.\"","No",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Bin Tian",null,14,"No","Qualcomm","Technical",87,"10.39.8.3",19,"\"channel access methods defined in 6.3.2 or 10.45 with CCA mode 1 or 3 shall be applied\".  Many details like the ED threshold need to be defined for NB LBT","Add a setence on the LBT parameters like ED threshold (e.g. -75dBm/MHz) ","Add a setence on the LBT parameters like ED threshold (e.g. -75dBm/MHz) ","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,22,"No","Meta","Technical",87,"10.39.8.3",19,"Energy Detect Threshold is sometimes not defined and could be set arbitrarily large.  Guidance should be provided when it is not defined.",null,"Define EDT to be min(-69 dBm/MHz, -67 dBm/MHz – Ptx) in channels 0 to 49 and to max(-83 dBm/MHz, min(-63 dBm/MHz,-70 dBm/MHz – Ptx)) in channels 50 to 249, where Ptx is the equipment’s instantaneous transmit power for the upcoming transmission in dBm ","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,23,"No","Meta","Technical",87,"10.39.8.3","1900-01-19","CCA Mode 3 is not defined",null,"change it to CCA mode 3a","Yes","Revised","Doc 15-25-0513-00-04ab-lb225-d03-comment-resolution-cids-23-and-30.docx",null,null,"DONE"]
[null,null,"Carlos Aldana",null,24,"No","Meta","Technical",87,"10.39.8.3",19,"CCA Mode 4 is not an adequate mechanism",null,"Add \"CCA Mode 4 shall not be used as a channel access mechanism\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,25,"No","Meta","Technical",87,"10.39.8.3",19,"Channel Access mechanism is ambiguous when LBT is not required.  Change the sentence \"If LBT is not required, the same methods may be used to improve coexistence with other spectrum users.\" to provide better guidance.",null,"Change sentence to \"If LBT is not required, the same methods shall be used to improve coexistence with other spectrum users.\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,29,"No","Meta","Technical",87,"10.39.8.3",19,"The required ED threshold is sometimes specified by local regulations for a given band, and varies region to region and band to band. In the case that it is not specified, we should specify it.",null,"Add a statement that says \"phyCcaEdThreshold shall be set to  shall be set to the value required by local regulations;  otherwise, it shall be set to min(-69 dBm/MHz, -67 dBm/MHz – Ptx) in channels 0 to 49 and to max(-83 dBm/MHz, min(-63 dBm/MHz,-70 dBm/MHz – Ptx)) in channels 50 to 249, where Ptx is the equipment’s instantaneous transmit power for the upcoming transmission in dBm ","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,30,"No","Meta","Technical",87,"10.39.8.3",19,"CCA mode 3 does not exist anymore",null,"specify whether 3a or 3b","Yes","Revised","Doc 15-25-0513-00-04ab-lb225-d03-comment-resolution-cids-23-and-30.docx",null,null,"DONE"]
[null,null,"Carlos Aldana",null,31,"No","Meta","Technical",87,"10.39.8.3",19,"How long is CCA duration?  Too short of a duration can lead to not being able to access the channel when in fact the device can.  Please specify",null,"An 802.11 device has typical CCA measurement duration (aCCATime for those familiar with 802.11 spec) of 4us and uses 20 MHz bandwidth, resulting in 80 CCA samples.  In order to keep the same accuracy and false detection probability,  we should use 4*20/2.5 = 32us.    Note that in order to reduce the CCA duration and keep the same performance, the CCA BW can be increased.  Therefore, add a sentence that says \"The CCA duration should be at least 32us*2.5/CCA_BW_MHz, where CCA_BW_MHz denotes the CCA bandwidth in MHz.\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Carlos Aldana",null,32,"No","Meta","Technical",87,"10.39.8.3",19,"When doing LBT, if the channel is deemed free, the transmission should occur immediately.  This reduces the probability of a collision.",null,"Please add the following: \"When the channel is sensed free, the transmission shall occur immediately.\"","Yes",null,"Doc 15-25-0510-02-04ab-lb225-d03-comment-resolution-channel-access-related-comments.docx",null,null,"Assigned","NB/CCA/LBT","Pooria"]
[null,null,"Pooria Pakrooh",null,181,"No","Qualcomm","Technical",88,"10.39.8.4.3",23,"AllowedChannellist can be changed in every round. However, the channel switching mechanism defined in 10.39.8.4.3 only enables channel switching per block. For better resilience to NB fading and coexistence, it is better to do hopping per block. ",null,"Channel channel switching protocol to enable NB Channel hopping per round. Make the Nbaprng seed to be a function of RangingRoundIndex and RangingBlockIndex, instead of just a function of RangingBlockIndex.","Yes",null,null,null,null,"Assigned","NB/CCA/LBT","Alex"]
[null,null,"Billy Verso",null,125,"No","Qorvo","Technical",89,"10.39.9.1",15,"In Figure 53 the UWB fragments should be on 1ms boundaries, not slots!  Also while the poll and response NB packets have nslots parameters to define the size, there is no need to put this in every figure.",null,"In Figure 53 remove the slot 0, 1, 2, etc designations.  And in ranging phase show distance between UWB fragments transmissions as 1ms.  And do the same in Figure 54.","Yes",null,null,null,null,"Assigned","Figures","Jinjing"]
[null,null,"Youngwan So",null,223,"No","SAMSUNG","Editorial",90,"10.39.9.2",4,"No period mark",null,"Please put period","No","Accepted",null,null,null,"DONE"]
[null,null,"Li-Hsiang Sun",null,186,"Yes","MediaTek","Technical",90,"10.39.9.2",11,"for Message Control field value is 6, the responder does not have a corresponding Prand to calculate the Responder RPA hash. Suggest to add a requirement that Prand in subsequent O2M poll compact frames in the same O2M ranging round has the same Prand as in the initial O2M Poll, if the initial O2M poll has  Message Control field value of 6",null,"Suggest to add a requirement that Prand in subsequent O2M poll compact frames in the same O2M ranging round has the same value of Prand as in the initial O2M Poll, if the initial O2M poll has  Message Control field value of 6","No",null,null,null,null,"Assigned","MMS Ranging Rounds","Jinjing"]
[null,null,"Youngwan So",null,224,"No","SAMSUNG","Editorial",91,"10.39.9.3",3,"Typo in \"Reponse\" in Figure 55 and Figure 56",null,"Please change \"Reponse\" to \"Response\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,126,"No","Qorvo","Technical",91,"10.39.9.2",8,"This sentence is a repeat of p64 line26. I have a separate comment on revising that earlier line, which rather than also doing here, I propose just not saying the same thing twice. ",null,"Delete this sentence.","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","SYNC+SFD Frag\n (#112, #113, #114, #126, #155)","Youngwan"]
[null,null,"Billy Verso",null,127,"No","Qorvo","Editorial",94,"10.39.9.4.4",4,"Earlier heading used \"narrowband assistance\" but here it is \"narrowband assist\", lets be consistent",null,"Look at use of \"narrowband assistance\" and \"narrowband assist\" through the doc and decide which is best, and use same everywhere","No","Accepted",null,null,null,"DONE","Changed 4 cases of \"narrowband assistance\" to \"narrowband assist\"."]
[null,null,"Youngwan So",null,225,"No","SAMSUNG","Editorial",94,"10.39.9.4.4",8,"Sentence in line 8 \"Example operation of the multiple RSF transmissions per slot with narrowband assist is shown in Figure 61.\" is just a repeat of sentence in line 5.",null,"Please delete\"Example operation of the multiple RSF transmissions per slot with narrowband assist is shown in Figure 61.\" in line 8","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,41,"No","Wi-SUN Alliance","Technical",99,"10.39.11.1.2.1",12,"My comment 94 was rejected because there was no alternative text. This comment will provide that alternative text. ",null,"Remove 2nd sentence of 2nd paragraph of 10.39.11.1.2.1 (starting at line 12, ending at line 14. Replace it as follows: \"The RPA Hash field value is calculated by doing an AEAD encryption operation (Section 2.1 of RFC 5116) with following parameters: secret key K=IdentityResolvingKey, nonce N = 0x00 ... 00, plaintext P = empty, and associated data A = RPA prand. The RPA Hash field value is then taken as bits 0 to 23 of the output ciphertext C. The AEAD algorithm used is specified by the macIrkAlgorithmId.\"","Yes",null,null,null,null,"Assigned","RPA","Alex"]
[null,null,"Billy Verso",null,128,"No","Qorvo","Editorial",99,"10.39.11.1.2.1",18,"\"can use the MLME-18 SET.request primitive to set\" is okay but typically we don't need not mention the primitive when talking about setting PIB attributes, since globally in the base standard it is known that they are set this way.",null,"Change to \"can set\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,129,"No","Qorvo","Technical",99,"10.39.11.1.2.1",28,"\"communicated over-the-air by the transmitting device\" referring to the PRAND value is a little confused/confusing here.  The macIrkDescriptor structure has a list of macIrkEntry with space for PRAND and Extended address, but the global Boolean macIrkAssocRpaPrandPresent in the macIrkDescriptor, suggests that the PRAND may not be there.",null,"Add some explicit text to describe the process by which certain specified packets that convey the PRAND are used (by the MAC or the upper layer?) to populate macIrkAssocRpaPrand in the macIrkEntry data.\nAlso text describing the scenarios where macIrkAssocRpaPrandPresent is FALSE, and what is the handling in that case.","Yes",null,null,null,null,"Assigned","RPA","Alex"]
[null,null,"Youngwan So",null,226,"No","SAMSUNG","Editorial",99,"10.39.11.1.2.2",38,"Need consistency : 3-octet in line 38 vs. three-octet in line 40.",null,"Please change \"3-octet\" in line 38 to \"three octet\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,130,"No","Qorvo","Technical",100,"10.39.11.1.2.3",20,"macIrkExtendedAddr is used here but looking at Table 35,  macIrkExtendedAddrPresent may be FALSE, which presumably means that the securing or de-securing will fail.  I think we need some text to (a) describe how macIrkExtendedAddr gets populated (is it OOB or is there an over the air messages used to convey it during association perhaps, and presumably the NHL has a role in validating this before writing the value into the PIB).  Should also make sure securing and de-securing correctly report the failure if the macIrkExtendedAddr is not set.",null,"I think we need text to (a) describe how macIrkExtendedAddr gets populated, and, (b) to return a security failure status for the case that it isn't.  I think this is there for the de-securing case, but not for the securing case.  Presumably if the IRK being used is the destination IRK then the extended address of the destination is needed for securing, and if not set in the IRK descriptor this should produce an error status returned from the securing process.","Yes",null,null,null,null,"Assigned","RPA","Rojan"]
[null,null,"Rojan Chitrakar",null,70,"Yes","Huawei","Technical",101,"10.39.11.1.3.2",15,"How to indicate SMID values for Compact frames with no defined Message Control values (e.g., Secured Compact frame, Vendor specific Compact frame)?",null,"Clarify how to indicate SMID values for Compact frames with no defined Message Control values (e.g., Secured Compact frame, Vendor specific Compact frame)","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Huan-Bang Li",null,50,"Yes","NICT","Editorial",104,"10.39.11.1.3.7",23,"Delete redundant 'in' before word 'Table 12'.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,131,"No","Qorvo","Editorial",104,"10.39.11.1.3.7",23,"\"in in\" typo….",null,"change to single \"in\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,51,"Yes","NICT","Editorial",105,"10.39.11.1.3.7",1,"Delete the colon after word 'selected' in the first row,  right column of Table Table 12.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Mickael Maman",null,82,"Yes","STMicroelectronics","Technical",107,"10.39.11.1.3.8",3,"add MMs Mixed reply time  anf Reversed MMS order in Figure 72 and description for SS-TWR with fixed reply time",null,"add \"The MMS Fixed Reply Time field specifies if the responder may start transmitting its HRP UWB PHY MMS packet offset by a fixed reply time from the reception of the HRP UWB PHY MMS packet from the initiator instead of the start into the ranging phase. By default, the MMS Fixed Reply Time is FALSE.\nThe Reversed MMS Order field specifies if the order of the transmissions of the MMS UWB packet of the Initiator and the responder is reversed. When TRUE, 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. \"","Yes",null,null,null,null,"Assigned","Fixed Reply Time","Mickael"]
[null,null,"Bin Tian",null,10,"No","Qualcomm","Technical",108,"10.39.11.1.3.9",13,"\"in units of ranging slots in the range 0 to 15.9\". Seems wrong",null,"Change to \"in the range of 0 to 15\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,132,"No","Qorvo","Editorial",108,"10.39.11.1.3.9",13,"\"15.9\" typo….",null,"change to \"15\" ","No","Accepted",null,null,null,"DONE"]
[null,null,"Mickael Maman",null,83,"Yes","STMicroelectronics","Technical",108,"10.39.11.1.3.9",19,"It is not possible to indicate \"One ranging sub-round, interleaved, DS-TWR\"",null,"remove reserved value in Table 20, add \"One ranging sub-round, interleaved, DS-TWR\" in Table 20 for the value 1 and move the other","Yes",null,null,null,null,null,"MMS Ranging Rounds"]
[null,null,"Billy Verso",null,133,"No","Qorvo","Technical",109,"10.39.11.1.3.12",33,"We shouldn't say \"This field carries the value of the macMmsPrngSeed attribute.\" I think the field is communicating a seed value, to be used as the seed, possibly to be written to the macMmsPrngSeed attribute, by the NHL if/when it accepts the value.",null,"Just delete this sentence.","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Billy Verso",null,134,"No","Qorvo","Editorial",110,"10.39.11.1.3.13",3,"\"in in\" typo….",null,"change to single \"in\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,52,"Yes","NICT","Editorial",110,"10.39.11.1.3.13",6,"Delete redundant 'in' before word 'Table 21'.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,135,"No","Qorvo","Editorial",110,"10.39.11.1.3.13",6,"\"in in\" typo….",null,"change to single \"in\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Mickael Maman",null,84,"Yes","STMicroelectronics","Editorial",110,"10.39.11.1.3.13",15,"several typos: return line 10, remove \"when the\" line 18",null,"typo as in comment","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,227,"No","SAMSUNG","Editorial",110,"10.39.11.1.3.13",15,"Unintended line-break",null,"Please remove line break","No","Accepted",null,null,null,"DONE"]
[null,null,"Pooria Pakrooh",null,182,"No","Qualcomm","Technical",110,"10.39.11.1.3.13",16,"Sentence in 15-19 seems to be duplicated.",null,"Line 12-14 and 15-19 seem to be repeating same concept. Remove the redundancy.","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Huan-Bang Li",null,53,"Yes","NICT","Editorial",110,"10.39.11.1.3.13",18,"Modify \"when the when the O QPSK\" to \"when the  O-QPSK\".",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,228,"No","SAMSUNG","Editorial",110,"10.39.11.1.3.13",18,"Double \"when the\"",null,"Please remove either of \"when the\"s.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,229,"No","SAMSUNG","Technical",111,"10.39.11.1.3.14",1,"\"Block and Round Index Present\" field is defined here but never used throughout the document.\nThe \"Presence Bitmap\" itself is reused several places in other sub-clauses, such as p.120L16 and p.125L9. \nIn p.120L16, the \"Block and Round Index Present\" field seems to be replaced with \"Starting Block Index\". \nIn p.125L9, \"Block and Round Index Present\" field seems to be replaced with \"Response Status\"",null,"Please align all the fields inside \"Presence Bitmap\" wherever \"Presence Bitmap\" is used in the whole document.","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Youngwan So",null,230,"No","SAMSUNG","Editorial",113,"10.39.11.1.3.17",9,"Seems there's typo in sentence : \"The range of valid of Reply Time and Round-trip Time field values shall be limited….\"",null,"Change \"The range of valid of Reply Time…\"\nto         \"The range of valid Reply Time…\" please.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,136,"No","Qorvo","Editorial",113,"10.39.11.1.3.17",10,"\"in in\" typo….",null,"change to single \"in\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Rojan Chitrakar",null,71,"Yes","Huawei","Technical",115,"10.39.11.3.1",9,"\"A Message Control field value of zero signals that the initiator supports Compact frames with Compact Frame ID field values of 0x01 to 0x06 with a Message Control field value of 0x00.\"\n\"Message Control field value of 0x00\" should be \"Message ID field value of 0x00\"",null,"Change \"… Message Control field value of 0x00\" to \"… Message ID field value of 0x00\"","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Rojan Chitrakar",null,72,"Yes","Huawei","Technical",115,"10.39.11.3.1",9,"\"A Message Control field value of zero signals that the initiator supports Compact frames with Compact Frame ID field values of 0x01 to 0x06 with a Message Control field value of 0x00.\"\nWhat about supoprt of Message Control values for the Advertising Poll Compact frame itself, which has 2 Message Control values: 0 & 1.",null,"Clarify how support for the Message Control values for the Advertising Poll Compact frame itself is signaled.","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Mickael Maman",null,85,"Yes","STMicroelectronics","Technical",115,"10.39.11.3.1",21,"add \"if present\" in the description of the SMID TLV field description for the ADV Poll",null,"add \"if present\"","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Mickael Maman",null,86,"Yes","STMicroelectronics","Technical",117,"10.39.11.3.2",11,"The SMID TLV field for the ADV response is used by the responder to signal to the initiator",null,"change \"This is used by the initiator to signal to responders which compact frames and which message control values it supports.\" by \"This\nis used by the responder to signal to initiator which compact frames and which message control values it supports\"","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Huan-Bang Li",null,54,"Yes","NICT","Editorial",118,"10.39.11.3.3",14,"Add 'Figure 87' to the end of sentence.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Bin Tian",null,11,"No","Qualcomm","Technical",119,"10.39.11.3.4",3,"The RPA Hash field is calculated using either the responser's IPK for single responder case or initiator's IPK otherwise.  Why not just harmonizing to always using the initiator's IPK? ",null,"as in the comment","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Bin Tian",null,12,"No","Qualcomm","Technical",125,"10.39.11.3.6",5,"Why does the One-to-one poll compact frame uses 2 octets with value 0 to clock estimate (in P122) while one-to-one response compact frame needs 5 octets of zeros","Change the response compact frame to only inlcude two octets of zeros","Change the response compact frame to only inlcude two octets of zeros","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Youngwan So",null,231,"No","SAMSUNG","Technical",125,"10.39.11.3.6",11,"\"Response Status Present\" field doesn't exist in Presence Bitmap field in p.110.\nIf assuming it exists, its name should be \"Response Status Present\" not \"Response Status\"",null,"Please align all the fields inside \"Presence Bitmap\" wherever \"Presence Bitmap\" is used throughout the whole document.","Yes",null,null,null,null,"Assigned","msg fields","Rojan"]
[null,null,"Youngwan So",null,232,"No","SAMSUNG","Technical",127,"10.39.11.3.8",24,"No definition of \"Reply Time\"",null,"Please add appropriate definition.","No",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Mickael Maman",null,87,"Yes","STMicroelectronics","Technical",128,"10.39.11.3.8",24,"double definition of round trip time field",null,"remove the first definition","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Youngwan So",null,233,"No","SAMSUNG","Technical",139,"10.39.11.3.11",1,"Octet for Round Trip Time is missing",null,"Please put \"5\"","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","msg fields","Youngwan"]
[null,null,"Youngwan So",null,234,"No","SAMSUNG","Editorial",139,"10.39.11.3.12",27,"\"two\" is missing",null,"Please add \"two\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Hong Won Lee",null,1,"No","LG Electronics","Editorial",143,"10.39.11.3.15",20,"ACCEPT_WITH_NEW_ADDR is not defined in the Table 27",null,"Change from \"ACCEPT_WITH_NEW_ADDR\" to \"accept with new address (as per Table 27)\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Hong Won Lee",null,2,"No","LG Electronics","Editorial",143,"10.39.11.3.15",21,"ACCEPT_WITH_NEW_ADDR is not defined in the Table 27",null,"Change from \"ACCEPT_WITH_NEW_ADDR\" to \"accept with new address (as per Table 27)\"","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,137,"No","Qorvo","Editorial",146,"10.39.11.3.17.2",10,"strange large word spacing on this line for no apparent reason, possibly a <tab> was insert instead of a <space>.",null,"Space words more evenly on this line.","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,138,"No","Qorvo","Editorial",149,"10.39.11.3.19",20,"\"in in\" typo….",null,"change to single \"in\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,42,"No","Wi-SUN Alliance","Editorial",152,"10.39.12",6,"In Table 34 macIrkExtendedAddrPresent description there is referene to the macIrkDescriptorElement \"list\". The macIrkList is list of macIrkDescriptorElements, which have then Elements (i.e., fields inside). ",null,"Change \"macIrkDescriptorElement list has\" to \"macIrkDeviceDescriptor has\". Also rename macIrkDescriptorElement to macIrkDeviceDescriptor, as that is what we usually refer those substructures in base standard (secKeyDescriptor, PanDescriptor etc).","No","Revised","Rename macIrkEntry to macIrkValue everywhere, and rename macIrkDescriptorElement to macIrkDeviceDescriptor, and, change the description of the macIrkExtendedAddrPresent parameter to: \"When macIrkExtendedAddrPresent is TRUE, each macIrkDeviceDescriptor in the macIrkList has an associated macIrkExtendedAddr value stored for each macIrkValue.  When FALSE, extended address values are not present in the macIrkList.\"",null,null,"DONE"]
[null,null,"Tero Kivinen",null,43,"No","Wi-SUN Alliance","Editorial",152,"10.39.12",6,"In Table 34 the macIrkAssocRpaPrandPresent has two \"When FALSE\" cases. ",null,"Remove the first one, and remove the extra \"list\" word from the 2nd.","No","Revised","Rename macIrkEntry to macIrkValue everywhere, and rename macIrkDescriptorElement to macIrkDeviceDescriptor, and, change the description of the macIrkAssocRpaPrandPresent parameter to: \"When macIrkAssocRpaPrandPresent is TRUE, each macIrkDeviceDescriptor in the macIrkList has a macIrkAssocRpaPrand value stored for each macIrkValue. When FALSE, RPA prand values are not present in the macIrkList.\"",null,null,"DONE"]
[null,null,"Tero Kivinen",null,44,"No","Wi-SUN Alliance","Technical",152,"10.39.12",6,"Add macIrkAlgorithmId. ",null,"Add macIrkAlgorithmId with type of \"Integer\", Range \"as defined in Table 9-9\", and description of \"The AEAD algorithm used when generating RPA Hash values from IRK\".","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Pooria Pakrooh",null,183,"No","Qualcomm","Editorial",155,"10.40.4.5.1",19,"Remove the quotation mark.",null,"Remove the quotation mark","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Huan-Bang Li",null,55,"Yes","NICT","Technical",156,"10.40.4.5.3",20,"Figure 153 includes the statement: \"In this example, BM_{offset} is 2 and BM_{length} is 4. \". However, time durations for them shown in the figure are respectively 2 and 3. Description on the unit of the 'length' is not given in the figure or text.",null,"add definition of 'length' and modify accodingly.","Yes",null,null,null,null,"Assigned","Figures","Pooria"]
[null,null,"Huan-Bang Li",null,56,"Yes","NICT","Technical",156,"10.40.4.5.3",20,"Figure 153 includes a parameter 'T', which is not defined in the figure or text.",null,"add definition for 'T' and specify its value range.","Yes",null,null,null,null,"Assigned","Figures","Pooria"]
[null,null,"Billy Verso",null,139,"No","Qorvo","Technical",157,"10.40.3 ",5,"Frequency Stitching Clause 10.40.3 contains just one paragraph of nine lines, while there are four pages that describe frequency stitching based on the AC IE fields for signalling frequency stitching parameters. Much of that latter discussion ought to be moved/captured in 10.40.3, since use of these AC IE fields could be considered optional.",null,"Describe the various modes of operation of Frequency Stitching in clause 10.40.3 (drawing from 10.40.6.1, and reducing the text in 10.40.6.1 to avoid unnecessary repetition)","Yes",null,null,null,null,"Assigned","Stitching","Pooria"]
[null,null,"Huan-Bang Li",null,57,"Yes","NICT","Editorial",160,"10.40.4.7",10,"Replace the text 'what to send when' to 'what and when to send'.",null,"as suggested.","Yes","Revised","Change to \"what to send and when to send it\"",null,null,"DONE"]
[null,null,"Billy Verso",null,140,"No","Qorvo","Editorial",164,"10.40.6.1",11,"\"..\" typo",null,"change to \".\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,141,"No","Qorvo","Technical",165,"10.40.6.1",2,"There is no \"RCP\".  Also what is \"normal ranging\", we can solve this by simplifying the paragraph.",null,"Replace the paragraph with \"The Ranging Control field if present shall be formatted as shown in Figure 161.\"","Yes",null,null,null,null,"Assigned","msg fields","Pooria"]
[null,null,"Youngwan So",null,238,"No","SAMSUNG","Editorial",168,"10.40.6.1",9,"Typo",null,"Pleas change \"Sending Report\" to \"Sensing Report\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,142,"No","Qorvo","Editorial",169,"10.40.6.1",13,"Table 42 heading is on page before the table.",null,"Use \"keep with next\" to keep them together","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,143,"No","Qorvo","Technical",171,"10.40.6.1",2,"\"The Report Mode field when one indicates that the reported IE(s) are transmitted via in-band, or when zero that the reported IE(s) are transmitted via OOB.\"  I am not sure this makes sense.   I think any out-of-band communication is out of scope so we cannot say what form the transmission might take.  ",null,"Delete this bit and its description.","Yes",null,null,null,null,"Assigned","msg fields","Pooria"]
[null,null,"Billy Verso",null,144,"No","Qorvo","Technical",175,"10.40.6.1",21,"Much of the discussion on the operation of frequency stitching is buried in the AC IE text (D03 pages 175 to 178).  It would be better for this to be captured/described in subclause 10.40.3 \"Frequency Stitching\".",null,"Describe the various modes of operation of Frequency Stitching in clause 10.40.3 (drawing from 10.40.6.1, and reducing the text in 10.40.6.1 to avoid unnecessary repetition)","Yes",null,null,null,null,"Assigned","Stitching","Pooria"]
[null,null,"Youngwan So",null,235,"No","SAMSUNG","Editorial",188,"10.40.6.6",5,"Bit number is all set as \"1\". Need to have it increasing order.",null,"Please change Bits: 1,1,1,1,1,1,1,1\n                   to Bits: 0,1,2,3,4,5,6,7","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Youngwan So",null,236,"No","SAMSUNG","Editorial",188,"10.40.6.6",8,"Bit number is all set as \"1\". Need to have it increasing order.",null,"Please change Bits: 1,1\n                   to Bits: 0,1","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,145,"No","Qorvo","Technical",193,"10.41.4.1",1,"Given advanced ranging support can be either NBA or UWB driven without necessarily supporting the other, it would be better to separately indicate whether the device can do NBA MMS UWB ranging, or UWB driven MMS UWB ranging, or both..",null,"Split \"HRP Advanced Ranging\" capability into two separate capability flags: \"HRP NBA Advanced Ranging\" and \"HRP UWB Driven Advanced Ranging\"","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","msg fields","Youngwan"]
[null,null,"Youngwan So",null,237,"No","SAMSUNG","Editorial",195,"10.41.4.2",1,"Typo",null,"Please change \"2-7\" to \"3-7\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Alex Krebs",null,205,"Yes","Apple","Technical",195,"10.41.4.2 Controller Association Response command","5 (Table 59)","64 us is too aggressive for mandatory support. Software decoding of long packets will take longer than that. The mandatory value should assure interoperability with such devices, while the optional values may be used by higher performance devices to reduce latency.",null,"Change AIFS times (us) to 300, 64, 32, 16 for field values 0,1,2,3 respectively","No",null,null,null,null,null,"ACK"]
[null,null,"Pooria Pakrooh",null,184,"No","Qualcomm","Technical",203,"10.44",5,"The NB data offload feature has limitations such as significantly lower data rate relative to UWB, and also higher fading. Given that this feature can have arbitrarily high duty cycle for data transmission, 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\nNeed to add a proper mandatory channel access mechanism for this feature when duty cycle is high.",null,"Adopt the proposed text resolution in DCN 15-25-426/r0 for duty cycle values higher than a threshsold. This avoids unnecessary interference to other NB-MMS devices and other technologies using UNII-3 and UNII-5 bands.","Yes",null,null,null,null,"Assigned","NB","Youngwan"]
[null,null,"Bin Tian",null,16,"No","Qualcomm","Technical",203,"10.44.1",11,"Need to add a few sentence to discuss the LBT requirement for data loading case","Add sentence like \" LBT is mandatory required for NB operation if its transmission dutcy cycle is above certain threshold\"","Add sentence like \" LBT is mandatory required for NB operation if its transmission dutcy cycle is above certain threshold\"","Yes",null,null,null,null,"Assigned","NB/CCA/LBT","Youngwan"]
[null,null,"Youngwan So",null,239,"No","SAMSUNG","Technical",203,"10.44.2",12,"It only says the case narrowband allocation packet is sent in measurement report phase. Please clarify  other cases as well.",null,"Please clarify the case where narrowband allocation message is sent other than measurement report phase.","Yes",null,null,null,null,"Assigned",null,"Youngwan"]
[null,null,"Billy Verso",null,146,"No","Qorvo","Technical",211,"12.3.7",25,"phyHrpUwbRxPacketConfig range enumeration should include the DDMP_PACKET type added in Table 73",null,"Add DDMP_PACKET at the end of the list in the range column for the phyHrpUwbRxPacketConfig attribute.","Yes",null,null,null,null,"Assigned","PIB","Panpan"]
[null,null,"Billy Verso",null,147,"No","Qorvo","Technical",212,"12.3.7",24,"phyHrpUwbTxPacketConfig range enumeration should include the DDMP_PACKET type added in Table 73",null,"Add DDMP_PACKET at the end of the list in the range column for the phyHrpUwbTxPacketConfig attribute.","Yes",null,null,null,null,"Assigned","PIB","Panpan"]
[null,null,"Huan-Bang Li",null,58,"Yes","NICT","Editorial",214,"12.3.12",4,"Modify 'OQPSK PHY' in the last row, right column to 'O-QPSK PHY'.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,148,"No","Qorvo","Technical",214,"12.3.12",21,"There is a conflict between phyOqpskModulationConfig setting the modulation (p214 line 21) and the O-QPSK modulation and the DataRate parameter to the MCPS-DATA.request also doing it for the O-QPSK PHY (p24 line 2).  Could remove the use of DataRate, or make phyOqpskModulationConfig only specify the RX modulation. However this needs careful consideration to make sure the solution covers all the cases and various operations, and that we set all modes appropriately in TX and RX especially so that the receiver can correctly receive and decode the packet and report the result.",null,"The solution proposed for my comment on p24 line 3 seems to be a good way to do it….","Yes",null,null,null,null,"Assigned","O-QPSK-Modulation/Rate","Huan-Bang"]
[null,null,"Billy Verso",null,149,"No","Qorvo","Technical",214,"12.3.12",24,"There is also a conflict here between phyOqpskSfdPatternNumber and the DataRate parameter to the MCPS-DATA.request since the pattern number here also trying to selecting the DataRate to use in TX (with no reporting).  If my proposed solution to the conflict between phyOqpskModulationConfig and DataRate, (as per my comment on p24 line 2), is accepted then phyOqpskSfdPatternNumber is not needed.",null,"Delete the row with phyOqpskSfdPatternNumber.  [Assuming the solution proposed for my comment on p24 line 3 is adopted making phyOqpskSfdPatternNumber unnecessary].","Yes",null,null,null,null,"Assigned","O-QPSK-Modulation/Rate","Huan-Bang"]
[null,null,"Larry Zakaib",null,89,"Yes","Spark Microsystems","Technical",215,"12.3.12",1,"The phyLeUwbCfg1FecCC and phyLeUwbCfg1SymbolRate PHY PIB attributes   are not set by the PHY Config Index field. ",null,"Remove reference to the PHY Config Index in the Description for these PIB Attributes in Table 12-14.\n\nRemove the \"1\" in the name of these PIB attributes in Table 12-14 and wherever they occur in D03 ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Bin Tian",null,4,"No","Qualcomm","Editorial",216,"13.1.2.3",7,"Table 69 should be Table 68","as in the comment","as in the comment","Yes","Rejected","The table references here are correct.",null,null,"N/A"]
[null,null,"Huan-Bang Li",null,59,"Yes","NICT","Technical",216,"13.1.2.3",13,"There is no reason to exclude Config #8 in Table 69. The sentence, \"… Config #1 to #7 in Table 69\" should be modified to \"… Config #1 to #8 in Table 69\".",null,"as suggested.","Yes",null,null,null,null,"Assigned","O-QPSK PHY","Panpan"]
[null,null,"Bin Tian",null,5,"No","Qualcomm","Technical",216,"13.1.2.3",14,"Add \" for the 5800 MHz and 6200 MHz bands\" to the end of Table 68 title",null,"as in the comment","Yes",null,null,null,null,"Assigned","O-QPSK PHY","Panpan"]
[null,null,"Billy Verso",null,150,"No","Qorvo","Technical",220,"13.2.8",4,"Assuming we want the same chip transmission order in 5800 and 6250 bands as is specified in the base standard, we should modify clause 13.2.8 in the base standard to add these new bands.",null,"Add appropriate clause text from base standard clause 13.2.8 and show the editing necessary to properly specify the chip transmission order when operating in the 5800 MHz and 6200 MHz bands.","Yes",null,null,null,null,null,"O-QPSK PHY"]
[null,null,"Billy Verso",null,151,"No","Qorvo","Technical",220,"13.3.9",23,"Given that we have specified a symbol tolerance of 20ppm for 5800 and 6250 bands we should probably also update the transmit centre frequency tolerance accordingly.",null,"Add appropriate clause heading from base standard clause 13.2.8 and similar text to base standard to specify that the transmit center frequency tolerance when operating in the 5800 MHz and 6200 MHz bands shall be 20x10e-6","Yes",null,null,null,null,null,"O-QPSK PHY"]
[null,null,"Mickael Maman",null,88,"Yes","STMicroelectronics","Editorial",221,"13.3.15",6,"wrong reference to the figure",null,"\"Figure 23\"","Yes","Rejected","The figure reference is correct.",null,null,"N/A"]
[null,null,"Billy Verso",null,152,"No","Qorvo","Editorial",221,"13.3.15",7,"blank numbered line",null,"delete it","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,153,"No","Qorvo","Technical",224,"16.2.1",4,"\"of at least one millisecond\" is at odds with p231 line 19, where an exact  1ms between fragments is mandated. ",null,"delete the words \"at least\",","Yes",null,null,null,null,"Assigned","HRP UWB PHY","Alex"]
[null,null,"Billy Verso",null,154,"No","Qorvo","Editorial",224,"16.2.1",4,"\"499,200 chips\" is wrong representation IEEE style guide says \"Digits should be separated into groups of three, counting from the decimal point toward the left and right. The groups should be separated by a space, and not a comma, period, or dash.\"",null,"change to \"499 200 chips\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Tero Kivinen",null,45,"No","Wi-SUN Alliance","Technical",229,"16.2.9.2",14,"Section 10.39.11.3.3 Advertising Confirmation Compact frame does not have Starting Block Index field. ",null,"Perhaps the reference should be to 10.39.11.3.4 Start of Ranging Compact frame. Update the reference to be correct.","Yes",null,null,null,null,"Assigned","msg fields","Alex"]
[null,null,"Huan-Bang Li",null,61,"Yes","NICT","Editorial",231,"16.2.11.1",7,"Replace 'narrowband assisted MMS' by 'NBA MMS', which has been used as the acronym.",null,"as suggested.","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Pooria Pakrooh",null,185,"No","Qualcomm","Technical",231,"16.2.11.1",13,"All \"reply time\" and \"round trip time\" values are defined based on differences of RMARKERs. However, Figure 216 does not clearly specify that the RMARKER for the first RSF is the intended RMARKER used for these calculations. Need to clarify this and call the other RAMERKERs as RIF RMAERKER or some other unique name.",null,"In Figure 216, clarify the RSF RMAERKER as the \"RMAERKER\", and the RIF RMARKERs as \"RIF RMARKER1\", …\n\nFo reference, 15.4a defines the main RMARKR as SRMARKER0, and the STS RMARKERS ans SRMARKER0/1/2/3/4.","Yes",null,null,null,null,null,"HRP UWB PHY"]
[null,null,"Billy Verso",null,155,"No","Qorvo","Technical",231,"16.2.11.1",15,"This phrase \"and this is also recommended when another PHY is employed for control and reporting.\" is repeating what has been said on p64 line26. I have a separate comment on revising that earlier line, which rather than also doing here, I propose just not saying the same thing twice. ",null,"Delete the phrase: \"and this is also recommended when another PHY is employed for control and reporting.\"","Yes",null,"Doc 15-25-0528-00-04ab-comment-resolution-112-113-114-126-145-155-202-233.docx",null,null,"Assigned","SYNC+SFD Frag\n (#112, #113, #114, #126, #155)","Youngwan"]
[null,null,"Billy Verso",null,156,"No","Qorvo","Editorial",231,"16.2.11.1",26,"\"499,200 chips\" is wrong representation IEEE style guide says \"Digits should be separated into groups of three, counting from the decimal point toward the left and right. The groups should be separated by a space, and not a comma, period, or dash.\"",null,"change to \"499 200 chips\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,157,"No","Qorvo","Technical",234,"16.3.3.3 ",1,"Note sure this sentences is totally clear, \"The HRP-EMDEV shall employ the K=7 convolutional code for the PHR, or for the PHR2 in dynamic data mode.\"  I think the OR should be an AND, and that it would be helped to cross reference the clauses where these are defined.",null,"\"The HRP-EMDEV shall employ the K=7 convolutional code for the PHR as described in 16.2.7.3, and for the PHR2 as described in 16.2.7.4.3\"","Yes",null,null,null,null,null,"HRP UWB PHY"]
[null,null,"Huan-Bang Li",null,60,"Yes","NICT","General",234,"16.3.3.3","3, 8, and 10","LDPC encoder' should be replaced by 'LDPC coder' for consistency, because the latter is used more frequently in the document.",null,"as suggested.","Yes","Revised","Change \"coder\" to \"encoder.",null,null,"DONE","Term \"encoder\" is used in 802.11 LDPC text and also used in base 802.15.4 for the convolutional encoder… Changed all \"coder\" to \"encoder\"."]
[null,null,"Billy Verso",null,158,"No","Qorvo","Editorial",238,"16.3.4.1",7,"The \"NOTE  n--\"  parts for the four notes here is being inserted so should be underlined",null,"Underline all of lines 7, 8, 9 and 10.  To ensure the NOTE text at the start of these lines is underlined.","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,159,"No","Qorvo","Editorial",256,33,2,"I note '0' and '1' used in the text.  I think ",null,"Change \"is\" to \"are\"","No","Revised","replace '1' by binary one and '0' by binary zero",null,null,"DONE","A misformed comment, but I knew what the commenter intended to say."]
[null,null,"Billy Verso",null,160,"No","Qorvo","Editorial",256,33.1,13,"\"The data rates supported ... is given by Table 93.\"",null,"Change \"is\" to \"are\"","No","Accepted",null,null,null,"DONE"]
[null,null,"Larry Zakaib",null,90,"Yes","Spark Microsystems","Editorial",257,"33.2.2",3,"Since the PHR contains the Sub-PHR, there is no need to state \"produce PHR and Sub-PHR\"",null,"Remove \"and Sub-PHR\" ","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,161,"No","Qorvo","Technical",257,"33.2.4",15,"\"Each symbol may contain Ncpb pulses\" seems like a strange optional behaviour, but I think the reason is that it might contain no pulses. E.g. in OOK..",null,"\"Each symbol shall contain Ncpb pulses, except for an OOK symbol signalling zero which shall have zero pulses.\"","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,162,"No","Qorvo","Technical",257,"33.2.4",15,"\"The same number of active chips…\" might suggest that the position of the active chips could change so long as the number is the same.",null,"Change to \"The same number and position of active chips…\"","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Dries Neirynck",null,240,"Yes","Ultra Radio Ltd","Technical",257,"33.2.4","13-17","A much more precise definition for the chip duration is given in the the OOK and BPM sections, where it's always defined as 1/245.76 MHz. It might be better to define this here.",null,"Delete chip rate from 33.3.4 and 33.3.5 and specify it in 33.2.4","No",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,163,"No","Qorvo","Technical",258,"33.2.5.2","1900-01-04","This line says the SYNC is sent using the OOK modulation described in 33.3.4, however in that clause it allows three different symbol lengths (12, 9 and 6 chips), and three different active chip possibilities.  Are these all allowed or is a specific value intended. ",null,"Clarify (in 33.2.5.1) that SYNC and SFD are always sent using the symbol length of 12 symbols, or if all three options are intended, say that that is the case and specify that the SYNC & SDD are is sent at the symbol rate/length determined by the <how?>  Similarly specify whether the burst is 1, 2, or 3 pulses as determined <How?>","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,164,"No","Qorvo","Technical",258,"33.2.5.2","1900-01-06","Only a minimum size specified, no maximum, so after detection of the SYNC the receiver should wait forever for the SFD?  I think it would be good to have a maximum so that the receiver might timeout and report an error after that.",null,"Specify a max as well as a minimum, or a set of lengths that a complaint transmitter should support.  Also add a phyLeUwbSyncLengh Attribute for the selection of this parameter (with the appropriate range)","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,165,"No","Qorvo","Technical",258,"33.2.5.3",10,"This line says the SDF is sent using the OOK modulation described in 33.3.4, however in that clause it allows three different symbol lengths (12, 9 and 6 chips), and three different active chip possibilities.  Are these all allowed or is a specific value intended. ",null,"Clarify (in 33.2.5.1)  that SYNC and SFD are always sent using the symbol length of 12 symbols, or if all three options are intended, say that that is the case and specify that the SYNC & SDD are is sent at the symbol rate/length determined by the <how?>  Similarly specify whether the burst is 1, 2, or 3 pulses as determined <How?>","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,166,"No","Qorvo","Technical",258,"33.2.5.3",13,"Table 91 allows for 8 different SFD sequences, but the text does not mention how the SFD to use is  configured…  Suggested to add a PHY PIB attribute to select the SFD pattern to use in the TX and to expect in the RX.. One attribute to set both TX and RX behaviour should be fine",null,"Add a phyLeUwbSfdIndex PIB attribute, with value range 1 to 8 to select an SFD pattern from Table 91 to use for TX and RX.","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,91,"Yes","Spark Microsystems","Technical",258,"33.2.5.2","4,5","It is not clearly stated that the symbol rate for the SYNC and SFD fields are the same as that which is used for the entire packet",null,"Clarify that the SYNC and SFD fields are transmitted at the same symbol rate as negotiated at the NHL for the entire packet","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,95,"Yes","Spark Microsystems","Technical",259,"33.2.6.2",10,"Replace XNOR with NOT(XOR)",null,"Replace \"d(3) = XNOR (d(2),d(1),d(0))\" with \"d(3) = NOT(XOR(d(2),d(1),d(0)))\"","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,92,"Yes","Spark Microsystems","Technical",259,"33.2.6.2",11,"The note regarding the XNOR function is not correct for more than 2-input XNOR. \nAlso, the use of XNOR may lead to misinterpretation and should be replaced with NOT(XOR) ",null,"Delete line 11 on P 259. \nReplace XNOR with NOT(XOR) where it occurs in Clause 33. ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,94,"Yes","Spark Microsystems","Technical",259,"33.2.6.2","12,13","The PHY Config Index is used to configure the modulation and the FEC Rate (puncturing). ",null,"Correct Table 92 to remove references to the Symbol rate and FEC CC ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,96,"Yes","Spark Microsystems","Technical",259,"33.2.6.2","24,25","The NHL also sets the Symbol Rate for the entire packet as well as the Convolutional code for the coded portion of the packet. \nAdd this information to lines 24 & 25.",null,"Remove the \"1\" in the following PHY PIB attribute names \"phyLeUwbCfg1SymbolRate and phyLeUwbCfg1FecCC\"\n\nAmend lines 24 and 25 to state that the NHL is responsible for properly configuring the operation at each end of the link by setting the values of phyLeUwbNumPulse, phyLeUwbCfgSymbolRate and phyLeUwbCfgFecCC at each device.","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,93,"Yes","Spark Microsystems","Technical",259,"33.2.6.2","4 to 6","Figure 234 and lines 4 & 5 do not ensure correct interpretation of the PHY Config Field transmission sequence ",null,"Amend Figure 234 to move the PHY Config Parity field to the left of the PHY Config Index field, and change the Bits designator for the PHY Config Parity field to\"Bit: 0\", and the Bits designator for the PHY Config Index field to  \"1-3\". Also amend the transmission sequence description to indicate that the PHY Config Parity is transmitted first, followed by transmission of the PHY Config Index, MSB first.","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,97,"Yes","Spark Microsystems","Technical",260,"33.2.6.2",2,"The symbol rate is not selected via the PHY Config Index field. Only the Modulation and Code Rate are selected via the PHY Config Index field",null,"Remove note b below Table 93\n","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,98,"Yes","Spark Microsystems","Technical",260,"33.2.6.3",6,"The transmission sequence for the Sub PHR Field needs to be clarified. In its present form, it could be misinterpreted. ",null,"Amend Figure 235 to move the Frame Length Parity field to the left of the Frame Length field, and change the Bits designator for the Frame Length Parity field to\"Bits: 0-4\", and the Bits designator for the Frame Length field to \"5-12\". \n\nAlso amend Line 6 to indicate that the Frame Length Parity field is transmitted first, followed by the Frame Length field (MSB first).","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,167,"No","Qorvo","Technical",260,"33.2.6.3",6,"\"The Sub-PHR shall be passed to the modulator most significant bit first\" means that parity field is sent before frame length field. But normal convention is to draw the first field sent on the left. ",null,"Consider reordering the fields in the figure to match 802.15.4 normal convention.... ALSO, review all figures in clause 33 to make sure that the order of transmission implied by the figures is consistent with 802.15.4 normal conventions, or very clearly captured in the text where it differs.  ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Dries Neirynck",null,241,"Yes","Ultra Radio Ltd","Technical",261,"33.3.1",22,"Is the formula missing the guard interval?",null,"(I would prefer to delete the formula...)","No","Rejected","Comment withdrawn by commentor",null,null,"N/A","LE UWB PHY"]
[null,null,"Larry Zakaib",null,99,"Yes","Spark Microsystems","Technical",261,"33.2.6.3"," 10, 11","XNOR may be confusing. ",null,"Replace with \"b1 = XOR(NOT(XOR(d7, d6, d5)), d3, d1)\"\nReplace with \"b0 = XOR(NOT(XOR(d7, d6, d5)), d4, d2)\"\n","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,100,"Yes","Spark Microsystems","Technical",261,"33.2.7","14-16","The order in which the convolutional encoder outputs e[1] and e[0] (Figure 226) are delivered to the modulator should be specified  \nAlso, for improved clarity, use g1(n) and g0(n)  instead of e[1] and e[0]",null,"Add the transmission sequence to section 33.2.7","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Dries Neirynck",null,242,"Yes","Ultra Radio Ltd","Technical",262,"33.3.3",11,"shall employ' seems the wrong verb if K=7 is also an option.",null,"replace 'shall employ' by 'shall support'","No",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,168,"No","Qorvo","Technical",262,"33.3.3 ",11,"Given that there is an option to employ K=7 convolution code, the \"shall\" in this line needs qualification.",null,"Add at the start of the line, \"Unless the optional K=7 convolutional coding is used as an alternative,\" ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,169,"No","Qorvo","Technical",262,"33.3.3 ",11,"For clarity, the first line of FEC convolutional encoding specifying K=5 convolutional encoding should reference Figure 237",null,"Change \"shall employ an encoder depth of K=5 and ...\" to \"shall employ the encoder shown in Figure 237.  This has an encode depth of K=5 and ...\".","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,170,"No","Qorvo","Technical",262,"33.3.3 ",15,"For clarity the mention of the K=7 convolutional encoding should refer to clause 16.3.3.3.and Figure 16-17",null,"At the start of the paragraph on line 15 add: \"Optionally, as an alternative to the K=5 code described here, the K=7 convolutional encoder described in 16.3.3.3 (and shown in Figure 16-17) may be employed.\"","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,101,"Yes","Spark Microsystems","Technical",262,"33.3.3",21,"XNOR may be confusing",null,"Replace with \"NOT(XOR(i4,i2,i0))\"","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,102,"Yes","Spark Microsystems","Technical",262,"33.3.3",23,"Figure 237 does not correctly depict the XNOR (should be changed to NOT(XOR)). Also, figure 237 does not illustrate  i0 to i4.\nIt is suggested that the figure be amended to more closely resemble the HRP depiction of the convolutional encoder ",null,"On line 21, change XNOR to NOT(XOR) and Amend Figure 237 by adding an inversion following the XOR for e[1]. Amend the figure for closer alignment with HPR  ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,171,"No","Qorvo","Technical",263,"33.3.3",3,"It would be good to clarify, \"The convolutional encoded bits shall be passed to the modulator most significant bit first.\"",null,"at the end of the sentence add: \", i.e., e[1] followed by e[0] for each input bit\". ","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Dries Neirynck",null,243,"Yes","Ultra Radio Ltd","Technical",263,"33.3.3",3,"What is the most significant bit in the a bit stream? Do we mean to specify the order between e[0] and e[1]?",null,"when not omitted e[1] will be transmitted after e[0]? (Or perhaps the other way around?)","No",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Billy Verso",null,172,"No","Qorvo","Technical",263,"33.3.4",13,"A symbol may have 1, 2 or 4 active chips.... Does it matter which of the four chip positions are used when there is 2 or 1 chips.  I think this should be specified. I expect always first needs to be occupied. But for the two active chips case is the second pulse in 2nd, 3rd or fourth chip position?  Also I assume the symbol size stays the same when there are less pulses in the burst, (i.e. for a single pulse burst the guard interval is effectively 11 chip times instead of 8.",null,"Might be clearer to just draw the three options, and describe what is needed in the text.","Yes",null,null,null,null,"Assigned","LE UWB PHY","Larry"]
[null,null,"Larry Zakaib",null,103,"Yes","Spark Microsystems","Editorial",264,"33.3.4",1,"Figure 238 Symbol Rates for OOK modulation  are incorrect",null,"Change frequencies to (from top to bottom) 20.48 MHz, 27.31 MHz and 40.96 MHz ","Yes","Accepted",null,null,null,"DONE"]
[null,null,"Dries Neirynck",null,244,"Yes","Ultra Radio Ltd","Editorial",264,"33.3.5",3,"title should have similar format to 33.3.4",null,"Burst position modulation (BPM)","No","Accepted",null,null,null,"DONE"]
[null,null,"Billy Verso",null,173,"No","Qorvo","Editorial",264,"33.3.5",8,"\",.\" typo",null,"change to \",\"","No","Accepted",null,null,null,"DONE"]

{"sheet":"Progress-Status","index":1,"n_rows":497,"n_cols":29,"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":244},{"$f":"B5-D5","v":155},{"$f":"COUNTA(Comments!P:P)-1","v":89},{"$f":"COUNTIF(Comments!P:P,\"Rejected\")","v":7},{"$f":"COUNTIF(Comments!P:P,\"Accepted\")","v":68},{"$f":"COUNTIF(Comments!P:P,\"Revised\")","v":14},{"$f":"COUNTA(Comments!V:V)-1","v":140},{"$f":"B5-D5-H5","v":15},null,{"$f":"COUNTIF(Comments!T:T,K4)","v":82},{"$f":"COUNTIF(Comments!T:T,L4)","v":7},null,{"$f":"COUNTIF(Comments!T:T,N4)","v":0},{"$f":"COUNTIF(Comments!T:T,O4)","v":0},{"$f":"COUNTIF(Comments!T:T,P4)","v":0},{"$f":"COUNTIF(Comments!T:T,Q4)","v":140},null,{"$f":"B5-(COUNTA(Comments!T:T)-1)","v":15}]
[]
[null,"Technical","Editorial",{"$f":"IF(D5=E7,\"Okay\",\"MIS-MATCHED\")","v":"Okay"},{"$f":"E5+F5+G5","v":89},null,null,null,null,null,{"$f":"SUM(K5:L5)","v":89},"Done + N/A"]
[null,{"$f":"COUNTIF(Comments!H:H,B7)","v":164},{"$f":"COUNTIF(Comments!H:H,C7)","v":77}]
[null,"General",{"$f":"IF(B5=C10,\"Okay\",\"MIS-MATCHED\")","v":"Okay"},{"$f":"D5/$B5","v":0.36475409836065575},2.8688524590163935E-2,0.27868852459016391,5.737704918032787E-2,0.57377049180327866,6.1475409836065573E-2,null,{"$f":"K7/$B$5","v":0.36475409836065575},"of total",null,{"$f":"N5/$B$5","v":0},{"$f":"O5/$B$5","v":0},{"$f":"P5/$B$5","v":0},{"$f":"Q5/$B$5","v":0.57377049180327866},null,{"$f":"S5/$B$5","v":6.1475409836065573E-2}]
[null,{"$f":"COUNTIF(Comments!H:H,B9)","v":3},{"$f":"C8+B8+B10","v":244}]
[null,null,null,null,null,null,null,null,null,null,{"$f":"K9+SUM(N9:Q9)","v":0.93852459016393441}]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null," "]
[]
[]
[null,"Assigned Comments"]
[]
[null,"Alex","Ankur","Ben","Billy","Billy, Alex","Billy, Carl","Billy, Riku","Editor","Frank","Hongwon","Huan-Bang",null,"Jinjing","Kangjin","Larry","Li-Hsiang",null,"Mickael","Panpan","Pooria","Riku","Rojan","Tero","Wenzheng",null,"Xiliang","Youngwan","SUM"]
[null,{"$f":"COUNTIF(Comments!V:V,B21)","v":15},{"$f":"COUNTIF(Comments!V:V,C21)","v":0},{"$f":"COUNTIF(Comments!V:V,D21)","v":0},{"$f":"COUNTIF(Comments!V:V,E21)","v":13},{"$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":1},{"$f":"COUNTIF(Comments!V:V,J21)","v":0},{"$f":"COUNTIF(Comments!V:V,K21)","v":0},{"$f":"COUNTIF(Comments!V:V,L21)","v":5},null,{"$f":"COUNTIF(Comments!V:V,N21)","v":2},{"$f":"COUNTIF(Comments!V:V,O21)","v":0},{"$f":"COUNTIF(Comments!V:V,P21)","v":28},{"$f":"COUNTIF(Comments!V:V,Q21)","v":0},null,{"$f":"COUNTIF(Comments!V:V,S21)","v":4},{"$f":"COUNTIF(Comments!V:V,T21)","v":5},{"$f":"COUNTIF(Comments!V:V,U21)","v":27},{"$f":"COUNTIF(Comments!V:V,V21)","v":9},{"$f":"COUNTIF(Comments!V:V,W21)","v":12},{"$f":"COUNTIF(Comments!V:V,X21)","v":0},{"$f":"COUNTIF(Comments!V:V,Y21)","v":0},null,{"$f":"COUNTIF(Comments!V:V,AA21)","v":0},{"$f":"COUNTIF(Comments!V:V,AB21)","v":19},{"$f":"SUM(B22:AB22)","v":140}]
[]
[]
[]
[]
[null,"Comments with Proposed Resolutions"]
[]
[null,"Alex","Ankur","Ben","Billy","Billy, Alex","Billy, Carl","Billy, Riku","Editor","Frank","Hongwon","Huan-Bang",null,"Jinjing","Kangjin","Larry","Li-Hsiang",null,"Mickael","Panpan","Pooria","Riku","Rojan","Tero","Wenzheng",null,"Xiliang","Youngwan, Billy","SUM"]
[null,0,0,0,0,0,0,0,0,0,0,0,null,0,0,0,0,null,0,0,0,0,0,0,0,null,0,0,{"$f":"SUM(B30:AB30)","v":0}]
[]
[]
[]
[]
[null,"Comments without Proposed Resolutions"]
[]
[null,"Alex","Ankur","Ben","Billy","Billy, Alex","Billy, Carl","Billy, Riku","Editor","Frank","Hongwon","Huan-Bang",null,"Jinjing","Kangjin","Larry","Li-Hsiang",null,"Mickael","Panpan","Pooria","Riku","Rojan","Tero","Wenzheng",null,"Xiliang","Youngwan, Billy","SUM"]
[null,{"$f":"B22-B30","v":15},{"$f":"C22-C30","v":0},0,13,0,0,0,1,0,0,5,null,{"$f":"N22-N30","v":2},0,28,0,null,{"$f":"S22-S30","v":4},5,27,9,12,0,0,null,{"$f":"AA22-AA30","v":0},19,{"$f":"SUM(B38:AB38)","v":140}]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[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":68},null,null,{"$f":"COUNTIF(Comments!P:P,\"Rejected\")","v":7},null,{"$f":"COUNTIF(Comments!P:P,\"Revised\")","v":14},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":45,"rows_kept":40,"cut":false,"hidden":false,"merged":[[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],[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]]}
["Version",null,"-00","-01","-02","-03","-04","-05","-06","-07","-08","-09","-10","-11","-12","-13","-14","-15","-16","-17","-18","-19","-20","-21","-22","-23","-24","-25","-26","-27","-28","-29","-30","-31","-32","-33","-34","-35","-36","-37","-38","-39","-40","-41","-42"]
["Date",null,"2025-10-06","2025-10-07","2025-10-09","2025-10-09","2025-10-13","2025-10-14"]
["Occasion",null,"Initial spreadsheet",null,"Before 2025-10-09 Telecon","After 2025-10-09 Telecn","Before 2025-10-14 Telecon","After 2025-10-14 Telecon"]
[]
["Editorial","Total",76,81,81,77,77,77]
[null,null,{"$f":"C5/(C5+C19)","v":0.30158730158730157},0.33196721311475408,0.33196721311475408,0.3155737704918033,0.3155737704918033,0.3155737704918033]
[null,"Addressed",0,0,70,70,74,74]
[null,null,{"$f":"C7/C5","v":0},0,0.86419753086419748,0.90909090909090906,0.96103896103896103,0.96103896103896103]
[null,"Ready",0,0,0,0,0,0]
[null,null,{"$f":"C9/C5","v":0},0,0,0,0,0]
[null,"Done",0,0,67,67,71,71]
[null,null,{"$f":"C11/C5","v":0},0,0.8271604938271605,0.87012987012987009,0.92207792207792205,0.92207792207792205]
[null,"N/A",0,0,3,3,3,3]
[null,null,{"$f":"C13/C5","v":0},0,3.7037037037037035E-2,3.896103896103896E-2,3.896103896103896E-2,3.896103896103896E-2]
[null,"ISSUE",0,0,4,0,0,0]
[null,null,{"$f":"C15/C5","v":0},0,4.9382716049382713E-2,0,0,0]
[null,"To Be Addressed",76,81,7,7,3,3]
[null,null,{"$f":"C17/C5","v":1},1,8.6419753086419748E-2,9.0909090909090912E-2,3.896103896103896E-2,3.896103896103896E-2]
["Technical/General","Total",176,163,163,167,167,167]
[null,null,{"$f":"C19/(C19+C5)","v":0.69841269841269837},0.66803278688524592,0.66803278688524592,0.68442622950819676,0.68442622950819676,0.68442622950819676]
[null,"Addressed",0,0,0,3,6,13]
[null,null,{"$f":"C21/C19","v":0},0,0,1.7964071856287425E-2,3.5928143712574849E-2,7.7844311377245512E-2]
[null,"Ready",0,0,0,2,0,5]
[null,null,{"$f":"C23/C19","v":0},0,0,1.1976047904191617E-2,0,2.9940119760479042E-2]
[null,"Done",0,0,0,1,4,4]
[null,null,{"$f":"C25/C19","v":0},0,0,5.9880239520958087E-3,2.3952095808383235E-2,2.3952095808383235E-2]
[null,"N/A",0,0,0,0,2,4]
[null,null,{"$f":"C27/C19","v":0},0,0,0,1.1976047904191617E-2,2.3952095808383235E-2]
[null,"To Be Addressed",176,163,163,164,161,154]
[null,null,{"$f":"C29/C19","v":1},1,1,0.98203592814371254,0.9640718562874252,0.92215568862275454]
[null,"Assigned",6,77,76,126,123,139]
[null,null,{"$f":"C31/C19","v":3.4090909090909088E-2},0.47239263803680981,0.46625766871165641,0.75449101796407181,0.73652694610778446,0.83233532934131738]
[null,"Proposed Resolutions",0,0,0,19,19,27]
[null,null,{"$f":"C33/C19","v":0},0,0,0.11377245508982035,0.11377245508982035,0.16167664670658682]
[null,"Need Proposals",6,77,76,107,104,112]
[null,null,{"$f":"C35/C19","v":3.4090909090909088E-2},0.47239263803680981,0.46625766871165641,0.64071856287425155,0.6227544910179641,0.6706586826347305]
[null,"Not Assigned",170,86,86,38,38,15]
[null,null,{"$f":"C37/C19","v":0.96590909090909094},0.52760736196319014,0.52760736196319014,0.22754491017964071,0.22754491017964071,8.9820359281437126E-2]
[null,"Issue",0,0,1,0,0,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":"Rogue Comments","index":7,"n_rows":14,"n_cols":22,"rows_kept":14,"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,"Pelen Salem",null,1,"Non-voter","Cisco Systems","Technical",71,"10.39.3.6 ",36,"Regarding the sentence \"Contention-based initialization and setup may be used for one-to-one ranging or one-to-many ranging.\": Instead of \"may\", Contention based protocol (such as LBT) shall be mandatory.",null,"The sentence to be modified to state that Contention based protocol (such as LBT) shall be mandatory.","No"]
[null,null,"Pelen Salem",null,2,"Non-voter","Cisco Systems","Technical",80,"10.39.4.2",32,"There is no standard coexistence mechanism defined for NB channel access when using O-QPSK.",null,"The first sentence to be modified to state that O-QPSK PHY shall use the listen-before-talk (LBT).","No"]
[null,null,"Pelen Salem",null,3,"Non-voter","Cisco Systems","Technical",80,"10.39.4.2",33,"There is no detail of the coexistence mechanism.",null,"LBT scheme details to be inserted including the ED threshold.","No"]
[null,null,"Pelen Salem",null,4,"Non-voter","Cisco Systems","Technical",87,"10.39.8.3 ",18,"CCA is marked as an optional feature, meaning we cannot does not guarantee coexistence with other devices. Additionally, CCA helps prevent transmissions that would cause interference.",null,"A sentence to be inserted to explain that prior to any O-QPSK PHY transmission, CCA mode 1 or 3a must be used. The ED threshold should be set at -75 dBm/MHz or lower. Transmission must not proceed if the CCA indicates the medium is busy.\"","No"]
[null,null,"Pelen Salem",null,5,"Non-voter","Cisco Systems","Technical",87,"10.39.8.3 ",18,"A CCA busy indication before an NB transmission can result in a significant penalty, as it may cause the entire exchange to be lost. Permitting multiple CCA attempts before an NB transmission can enhance the protocol’s resilience to CCA busy conditions.",null,"A paragraph to be inserted to explain that if a CCA indicates a busy medium and the number of consecutive CCAs is less than the value of macMmsNbMaxConsecutiveCCAs, another CCA may be performed after waiting at least 50 microseconds on a different channel or at least 100 microseconds on the same channel.\n\nA receiving device should check for the presence of an expected O-QPSK PHY transmission. If the expected transmission is not detected and the number of consecutive absences is less than macMmsNbMaxConsecutiveCCAs, the device may proceed to the next channel (which may be the same channel) and check for the expected transmission there.\n\nAdd a new MIB variable with the following properties:\n\t•\tAttribute: macMmsNbMaxConsecutiveCCAs\n\t•\tType: Integer\n\t•\tRange: 0–255\n\t•\tDescription: Number of consecutive CCAs\n\t•\tDefault: 2","No"]
[null,null,"Pelen Salem",null,6,"Non-voter","Cisco Systems","Technical",87,"10.39.8.3 ",18,"ED Threshold is not defined.",null,"A sentence to be inserted to define an ED threshold that is set at -75 dBm/MHz or lower.","No"]
[null,null,"Pelen Salem",null,7,"Non-voter","Cisco Systems","Technical",87,"10.39.8.3 ",18,"Regarding \"with CCA mode 1 or 3\": While CCA mode 1 or 3 can be used, it should be noted that CCA mode 3 includes two options: 3a and 3b and only the  option 3a guarantees energy detection.",null,"The sentence needs to be updated to edit \"3\" as \"3a\".","No"]
[null,null,"Pelen Salem",null,8,"Non-voter","Cisco Systems","Technical",87,"10.39.8.3 ",18,"CCA is marked as an optional feature, which falls below industry best practice for three main reasons: 1) .15.4ab devices collide over the air with other .15.4ab devices much more often, thereby prematurely limiting the achievable capacity and QoS/determinism. This directly limits the available use cases and market size for .15.4ab products. 2) Implementers incorporating .15.4ab devices that are built into larger multi-radio devices in a straightforward way collide \"internally\" with the other radios much more often,  so actual integration is more (unnecessarily) challenging, and oftentimes there is no good solution such that performance of the .15.4a device (or the other radios) is compromised (here, energy detect with deferral-in-time is generally recognized as the best option for in-device coexistence). 3) .15.4ab devices collide over the air with other non-.15.4ab devices much more often, thereby prematurely limiting the achievable capacity and QoS/determinism for both systems, and thereby undermining this amazing experiment of unlicensed spectrum and taking us down a path of tragedy of the commons (e.g., in many scenarios 2.4 GHz is regarded as a junk band unsuited to QoS/deterministic traffic because of impolite transmitters) - basically a lack of community-mindedness. \nNote that there is no 4th bullet related to regulations, because regulations are just separate - devices must meet regulations as well as standard-mandated coexistence requirements. Regulations only matter to standards in that standards should provide a toolkit (potentially of optional features) that enables regulatory requirements to be met. Rather, the argument for mandatory coexistence mechanisms rests on the self-interested bullets 1)-3) above.",null,"Mandate CCA based on energy detect at minimum. \nYes CCA (and thence LBT and related technologies) is always based on imperfect information and achieves less than some theoretical optimum, but if we make perfect the enemy of the good or get distracted by regulatory arguments, we don't make any progress towards the three self-interested industry goals identified in the comment.","No"]
[null,null,"Menzo Wentink",null,9,"Non-voter","Qualcomm","Technical",87,"10.39.8.3 ",18,"CCA is optional, which implies that coexistence with other devices can not be ensured. CCA also avoids transmitting into destructive interference.",null,"Insert the following sentence: \"CCA mode 1 or 3a shall be applied immediately before any O-QPSK PHY transmission. The ED threshold shall be -75 dBm/MHz or lower. The transmission shall not occur when the CCA reports a busy medium.\"","No"]
[null,null,"Menzo Wentink",null,10,"Non-voter","Qualcomm","Technical",87,"10.39.8.3 ",18,"CCA busy before an NB transmission causes a high penalty because the entire exchange may be lost. Allow more than one CCA before an NB transmission to incresae the resilience of the protocol against CCA busy.",null,"Insert the following sentences: \"If the CCA reports a busy medium and the number of consecutive CCAs is not equal to macMmsNbMaxConsecutiveCCAs, a new CCA may be performed after at least 50 s on another channel or after at least 100 s on the same channel.\n\nA receiving device shall check for the presence of an expected O-QPSK PHY transmission. If the expected transmission is not present and the number of consecutive absences is not equal to macMmsNbMaxConsecutiveCCAs, the device may go to the next channel (which might be the same channel) and check for the presence of the expected transmission on that channel.\"\n\nInsert a new MIB variable with Attribute \"macMmsNbMaxConsecutiveCCAs\", Type \"Integer\", Range \"0-255\", Description \"Number of consecutive CCAs\", and Default \"2\".","No"]
[null,null,"Menzo Wentink",null,11,"Non-voter","Qualcomm","Technical",87,"10.39.8.3 ",18,"No ED Threshold is defined.",null,"Add \"The ED threshold shall be -75 dBm/MHz or lower.\"","No"]
[null,null,"Menzo Wentink",null,12,"Non-voter","Qualcomm","Technical",87,"10.39.8.3 ",18,"\"with CCA mode 1 or 3\" -- CCA mode 3 has two options, 3a and 3b, but only option 3a will ensure energy detect.",null,"Change \"3\" to \"3a\".","No"]
[null,null,"Pelen Salem",null,13,"Non-voter","Cisco Systems","Technical",203,"10.44.2",12,"How is NB channel access done here?",null,"A sentence or section to be inserted to define a mandatory channel access mechanism consistent with previous sections.","No"]

{"sheet":"Sheet1","index":8,"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]