{"text_format":"1","workbook":"xlsx","n_sheets":7,"sheets":["D1.2","Sheet1","Stats","Chart detailed","Status change flow","Parameters","Values"],"not_rendered":{"charts":3,"images":1,"macros":1,"external_links":5,"defined_names":4,"comments":0,"pivot_tables":0},"unopened":[{"sheet":"Chart detailed","index":3,"reason":"not_a_worksheet"}],"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":"D1.2","index":0,"n_rows":619,"n_cols":20,"rows_kept":619,"cut":false,"hidden":false,"merged":[]}
["Comment\nNumber","TF?/WG","Comment\nStatus","Resolution\nStatus","Commenter\nSatisfaction","Comment\nCategory","Comment\nType","Required","Page #","Clause","Sub-clause","Line #","Comment","Proposed\nChange","Commenter\nName","Commenter\nAffiliation","Commenter\nEmail","Commenter\nPhone","Comment\nResolution","Last modified on"]
[1,"TF3","Resolved","Accept","None",null,"Editorial","Yes",12,null,1,12,"States \"This specification is concerned with encapsulation and mapping only\" but this contradicts point d) on line 10 and doesn't mention de-encapsulation.\nPoint d) states ","Change to \"This specification is only concerned with point d) above, i.e. the ingress/egress mapping functions\" ",{"$f":"IF($A2<>\"\",'[1]Step 1 -- Commenter information'!$B$2,\"\")","v":"Brian Torley"},{"$f":"IF($A2<>\"\",'[1]Step 1 -- Commenter information'!$B$3,\"\")","v":"Xilinx"},null,null,"ok","2016.11.08, 08:14"]
[2,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1,10,"Suggests ingress/egress mapping function is encapsulation and dejitter and retiming, but line 12 says spec is concerned with encapsulation and mapping only so they are different things.\nWe need to clarify what mapping function is, i.e. does it include encapsulation, does it include dejitter and retiming, Is the spec only concerned with some aspects of the mapping function?","Clarify.\nSplit d) into more parts and on line 10 refer to the part relevant to the spec.","Brian Torley","Xilinx",null,null,"\r\n\"( Note: I have changed dejittering to de-jittering to use same format as used in Fig 5-1, but both could be changed to dejitter if prefered)\r\nChange from: \r\nd) ingress/egress mapping functions that encapsulate/de-encapsulate while dejittering and retiming the recovered signal.\r\nThis specification is concerned with encapsulation and mapping only.\r\n\r\nTO:\r\nd) ingress/egress mapping functions that encapsulate/de-encapsulate \r\ne) de-jittering buffering and retiming the recovered data.\r\nThis specification is concerned with d) and e)  only.\"\r\n\r\n// Consolidate with Kevins comment & check\r\n","2016.11.15, 07:27"]
[3,"TF3","Resolved","Accept","None",null,"Technical","Yes",11,null,1,42,"\"from between\"","Change to \"between\"","Brian Torley","Xilinx",null,null,"ok - editorial.","2016.10.27, 14:38"]
[4,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1.2,20,"native RoE is confusing especially when in quotes the first time it is used.\nIt should be described more clearly\n","Remove (i.e. … RoE\").\nAdd a bullet point or another paragraph to say what Native RoE is.\nI think native is a superset of the other two mappers.\nIt may be worth stating that structure aware and structure agnostic terms do not apply to Native and why there is a difference. (I was unclear about this for a while.)","Brian Torley","Xilinx",null,null,"\"Remove (i.e., the “native RoE”)\r\n\r\nAdd bullet \r\n\" - Transport Radio Fronthaul I/Q in Native RoE packet format.\"","2016.11.15, 07:35"]
[5,"TF3","Resolved","Accept","None",null,"Editorial","Yes",42,null,7.3,7,"Section title \"Native RoE data flow packet\" is not consistent with other Mapper sections.","Change to \"Native RoE mapper\".\nI think it would be better for Native mapper to be section 7.1, then others after, as it is the superset.","Brian Torley","Xilinx",null,null,"ok\r\n\r\na.b Native RoE mapper\r\na.b.c Native RoE data flow packet\r\na.b.c.d Sub type (subType) field","2016.11.08, 08:14"]
[6,"TF3","Resolved","Accept","None",null,"Technical","Yes",22,null,"4.4.1",9,"Function \"Native RoE data flow sub type\" has \"flow\" but other mapper do not.\nAlso RoE is not first word.","Rename to \"RoE native data sub type\"","Brian Torley","Xilinx",null,null,"ok - editorial.","2016.10.27, 14:38"]
[7,"TF3","Withdrawn","None","None",null,"Technical","No",null,null,null,null,"Example of Structure aware and Native (section 7.2 and 7.3) show the same mapping (fig 7.1 and fig 7.6) so don't help explain the difference between the two mapping types.","Clarify what the difference is.","Brian Torley","Xilinx",null,null,"They are different\r\n1) C-plane not present\r\n2) i/q interleaving\r\n3) bit order\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:22","2016.10.27, 15:22"]
[8,"TF3","Resolved","AIP","None",null,"Technical","Yes",20,null,"4.2.2",18,"Describes structure aware and native mappers having separate control and data streams, but does not state what structure agnostic have.","Add Structure agnostic comparison e.g. there is no assocaiated control packets as the entire data dtream is encapsulated ( i..e only have a single data stream. LCd.)","Brian Torley","Xilinx",null,null,"\"Add 2nd paragraph into section 4.2.2 (between line 23 & 24)\r\nStructure agnostic mappers do not have control packets as the entire data stream is encapsulated as a single LCd data stream.\"\r\n","2016.11.15, 07:40"]
[9,"TF3","Resolved","Accept","None",null,"Technical","Yes",20,null,"4.2.2",19,"We use the term streams but use channels elsewhere","Change streams to channels","Brian Torley","Xilinx",null,null,"Change streams to channels","2016.10.27, 16:48"]
[10,"TF3","Resolved","AIP","None",null,"Technical","Yes",23,null,"4.4.4.1",14,"It is not clear why there are 3 field/counter used for sequence number, and this is the first time sequence numbers is mentioned.","Add a description or example and explanation why this is not a single field (eg as example in section 71.2.3)","Brian Torley","Xilinx",null,null,"please suggest text\r\nseqNum is mentioned in the paragraph above.\r\n\r\n\"Add to the start of section 4.4.4.1\r\n\r\nThe sequence number field is used to identify the order of successive packets.\r\nTo allow additional flexibliity it is possible to have up to two independent counters (e.g. one for HFN and another for BFN).\"\r\n\r\n","2016.11.15, 07:44"]
[11,"TF3","Resolved","AIP","None",null,"Technical","Yes",null,null,null,null,"C-Plane is mentioned 3 times but not defined.\nAre we using another term in other parts of the spec ie Control Channel, LCc?","Define first time it is used and add to definitions or change to Logical Channel Control processing.","Brian Torley","Xilinx",null,null,"\"Add C-Plane to Acronyms and abbreviations (section 3.1)\r\nC-plane     Term used in CPRI specification as the Control data flow for call processing.\"\r\n","2016.11.15, 07:46"]
[12,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,37,"The value of \"no more than +/-8ns\"  gives an absolute limit. Where does this come from?\n802.1CM Class A+ is +/- 10ns.","Add source of requirement or say \"expected to be no more than ..\"","Brian Torley","Xilinx",null,null,"This comes from CPRI, who knows where they got it from....\r\nEven though this is in the Overview, I do agree that it sets overly harsh expectations. Also, its not really differential delay, its latency uncertaincy.\r\n\r\nhow about 'There are many strict requirements on the protocol such as absolute end to end delay and deterministic latency.'?","2016.10.27, 16:54"]
[13,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,37,"Is differential delay mean delay between different CPRI links?\nIs this between different CPRI links in the network of on a single aggregator?","Clarify meaning","Brian Torley","Xilinx",null,null,"yes, this should be deterministic latency. See comment 12","2016.10.27, 16:54"]
[14,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,43,"Are there not three encapsulation techniques including native. We should mention native mapping as that is neither of the two mentioned.","Add Native mapping ","Brian Torley","Xilinx",null,null,"please suggest text. we probably need to do this as a group as native is likely to become more expansive.\r\n\r\n\"Change \"\"There are broadly two types of encapsulation techniques\"\" to \"\"There are broadly three types of encapsulation techniques. The first is native encapsulation (which unlike the other two, does not require a CPRI Port).\r\n\r\n// Add something along these lines.\r\n\r\n\"\r\n","2016.11.15, 07:49"]
[15,"TF3","Resolved","AIP","None",null,"Editorial","Yes",15,null,3.3,18,"Field names convention is not clear as it is a continuation of Parameter definition.\nWe also use bold for eth/cpri etc which are not fields or parameters.","Make Field names sentence a separate paragraph as follows'\n\"Field name are in bold without a prexied period, for example subType\"\nExplain bold when used for an object/entity eg eth/cpri/mapper.","Brian Torley","Xilinx",null,null,"1. ok - as described\r\n   Within this document, names of Parameters are .....\r\n   Fields names are shown in bold typeface without a prexied period, for example ....  \r\n\r\n2. ok - but needs more\r\n   add item before 3.2 a). a') RoE Funtional Element. An RoE mapper/demapper, Ethernet link or CPRI port. Add the following to 3.3 'When parameters are described with their asscociated functional element, both the functional element and parameter is shown in bold typeface.  ","2016.11.08, 08:16"]
[16,"TF3","Resolved","AIP","None",null,"Editorial","Yes",null,null,null,null,"Various names used for the same thing, \nnative RoE data packet format\nnative RoE packet\nnative RoE data flow packet\nnative RoE\nnative RoE framing format",null,"Brian Torley","Xilinx",null,null,"ok. We need to select our prefered text and identify each place. \r\n\r\nUse 'native RoE packet' unless something more explicit is needed.","2016.11.08, 08:18"]
[17,"TF3","Incomplete","AIP","None",null,"Editorial","Yes",17,null,4.0999999999999996,7,"Timing control packets doesn't tie up with LCt in definitions and \"control\" in name may cause confusion with \"control packets\"","Change \"Timing control packets\" to \"Timing packets\"","Brian Torley","Xilinx",null,null,"Not sure what to do here, there's a bit more to it.\r\nThe only packet which only contains timing information is the timing packet which is a control packet. Right now the LCt is inside the LCc. We could give the timing packet it's own subType? \r\nAlso, timingInfo is inside data packets too so perhaps it would be better to change the diagram to show LCt inside both LCc and LCd?\r\nOr, we could rewrite this completely to avoid the word 'packets' in preference to 'information'","2016.11.15, 09:30"]
[18,"TF3","Proposed","Reject","None",null,"Editorial","Yes",28,null,6.6,8,"Section is called Ethernet link but  Table 6-2 Description says \"Ethernet port\".","Should Table 6-2 Description to say \"Ethernet link\"","Brian Torley","Xilinx",null,null,"Yes, for reasons lost in time we use the convention 'Ethernet Link' and 'CPRI port'","2016.11.08, 08:20"]
[19,"TF3","Resolved","Accept","None",null,"Editorial","Yes",21,null,"4.2.3",4,"Mention that a CPRI port is a Physical port (as mentioned in later sections)","As per section 4.2.1 add this sentence.\nIn this document, a CPRI port, is defined as a physical CPRI interface.","Brian Torley","Xilinx",null,null,"ok","2016.11.08, 08:20"]
[20,"TF3","Resolved","Accept","None",null,"Editorial","Yes",46,null,"8.1.8",2,"Sub-clause content is missing.","Remove the editor's note and add the following text:\n\nCtrl AxC packets use opCode=1 in the RoE control packet common frame format. The payload contains CPRI stream Ctrl_AxC control words according to the CPRI11.ctrl.axc_vsd container definition as described in sub-clause 7.2.8. The size of the extracted control word is determined by the CPRI option in use (i.e., line bit rate, see CPRI specification V7.0 Table 3). The .cwStart shall be within range from 4 to 7. The sum of .cwStart and .cwSize shall be less than 8.\nThe Ctrl AxC packet’s common RoE header flowID gets populated according to CPRI11.ctrl.axc_vsd container .flowID definition. The orderInfo field shall contain a sequence number.\n The control packet’s payload is populated in a network byte order as extracted by the “control process” (see sub-clause 7.2.3 and illustrated in CPRI specification V7.0 Figure 16). \n\n(Commenter's note: picture provided in this excel in the sheet1) ",{"$f":"IF($A21<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A21<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok. Will work with Jouni to add. Comments can be addressed in the next cycle.","2016.11.08, 08:23"]
[21,"TF3","Resolved","AIP","None",null,"Editorial","Yes",46,null,"8.1.8.1",4,"Sub-clause content is missing.","Remove the editor's note and add the following text:\n\nCtrl AxC packets use opCode=2 in the RoE control packet common frame format. The payload contains CPRI stream VSD control words according to the CPRI11.ctrl.axc_vsd container definition as described in sub-clause 7.2.8. The size of the extracted control word is determined by the CPRI option in use (i.e., line bit rate, see CPRI specification V7.0 Table 3). The .cwStart shall be within range from 16 to p (the pointer p as defined in CPRI specification V7.0 sub-clause 4.2.7.4). The sum of .cwStart and .cwSize shall be less than p.\n\nThe Ctrl AxC packet’s common RoE header flowID gets populated according to CPRI11.ctrl.axc_vsd container .flowID definition. The orderInfo field shall contain a sequence number.\n\n The control packet’s payload is populated in a network byte order as extracted by the “control process” (see sub-clause 7.2.3 and illustrated in CPRI specification V7.0 Figure 16). \n\n\n(Commenter's note: picture provided in this excel in the sheet1)",{"$f":"IF($A22<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A22<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok. Will work with Jouni to add. Comments can be addressed in the next cycle.","2016.11.08, 08:23"]
[22,"TF3","Resolved","Accept","None",null,"Editorial","Yes",46,null,"8.1.8.1",3,"Sub-clause numbering/level is incorrect. The sub-clause should be 8.1.9.","Renumber the sub-clause to 8.1.9.",{"$f":"IF($A23<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A23<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"yes.","2016.11.08, 08:23"]
[23,"TF3","Resolved","Accept","None",null,"Editorial","Yes",46,null,"8.1.8.2",5,"Sub-clause numbering/level is incorrect. The sub-clause should be 8.1.10.","Renumber the sub-clause to 8.1.10.",{"$f":"IF($A24<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A24<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"yes","2016.11.08, 08:23"]
[24,"TF3","Resolved","AIP","None",null,"Editorial","Yes",44,null,"8.1.3",17,"The text now says the orderInfo details _shall_ be per opCode. While this is true, there is no reason to have a general rule for any opCode use and use opCode specific description to override the generic handling when needed.","OLD:\nThe RoE control packet opCode specification shall describe the exact sequence number handling.\n\nNEW:\nThe RoE control packet opCode specification shall describe the exact sequence number handling unless the following generic handling is not adequate.\n\nThe .orderInfoType is set to 0 (indicates the seqNum is used). The seqNum associated orderInfo parameters listed in sub-clause 4.4.4.1 are programmed to appropriate values for each opCode by the management entity setting up the control packet connection.",{"$f":"IF($A25<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A25<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"I'd prefer to use the same section convention we use for the non-control packets.\r\nEach opCode should have a subsection for\r\n   opCode type field \r\n   Flow identifier\r\n   Ordering information\r\n   Length\r\n   Payload\r\n\r\nThis gives us consistancy and the most flexibility.\r\n\r\n","2016.11.08, 08:26"]
[25,"TF3","Resolved","AIP","None",null,"Editorial","Yes",39,null,"7.2.8",18,"The \".cwNum\" is redundant and covered by the \".cwSize\".","Remove \".cwNum\" from the container description.",{"$f":"IF($A26<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A26<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok. See comment 26 too.\r\nI notice we refer to these parameters in 7.2.8 but dont define them until much later. Move Table 7-5 to the start of 7.2.8","2016.11.08, 08:26"]
[26,"TF3","Resolved","Accept","None",null,"Technical","Yes",40,null,"7.2.8",11,"The \".cwSize\" number range is wrong. It should be from 0 to 63 (to fit into 6 bits). Also \".cwNum\" is incorrectrly referenced in this paragraph.","Propose rewriting the paragraph:\n\nThe .cwStart defines the start of sub-channel (Ns) and has the valid range from 0 to 63. The .cwSize defines the number of extracted sub-channels minus one and the valid range is from 0 to 63. The mask defined by .cwSel applies to the “area” defined by the .cwStart and .cwSize. The specific mapper definitions may have more specific restriction to the ranges. ",{"$f":"IF($A27<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A27<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok. ","2016.10.27, 17:05"]
[27,"TF3","Resolved","Accept","None",null,"Editorial","Yes",41,null,"7.2.8",9,"Table 7-5 \".cwNum\" entry should be \".cwSize\" and the description needs to be updated accordingly. Also, the \".cwSel\" is used to selects sub-channels, thus the note \"Value of 0 selects/extracts no sub-channels.\" is unnecessary and does not work either because the \".cwSize\" valid number range is from 0 to 63.","Change \".cwNum\" to \".cwSize\".\n\nPropose updated Description:\nNumber of consecutive sub-channels minus one allocated for the control data. Valid range is from 0 to 63. ",{"$f":"IF($A28<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A28<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok. We agreed the wording in a previous comment. Re-use the same type of text.","2016.11.08, 08:28"]
[28,"TF3","Resolved","Accept","None",null,"Editorial","Yes",33,null,"7.1.2.3",7,"Current text says: ”The 32-bit orderInfo field shall be used as a sequence number, with successive packets increasing the sequence number by 1” – which is wrong.\n\nThe baseline proposal tf3_1606_korhonen_sof_2.pdf added support for 1:2:24:5 timestamp. See tf3_1606_ballot_1904_3-1.pdf comment #45.","OLD:\nThe 32-bit orderInfo field shall be used as a sequence number, with successive packets increasing the sequence number by 1.  A gap in sequence numbers indicates a missing packet.  Packets received out of order due to network traffic may be output in order if egress buffering is used and the out of order packets are received within the window of egress buffering.\n\nNEW:\nThe orderInfo field uses either a sequence number or timestamps as described in sub-clase 4.4.4. When sequence numbers are used a gap in sequence numbers indicates a missing packet.  Packets received out of order due to network traffic may be output in order if egress buffering is used and the out of order packets are received within the window of egress buffering.\n",{"$f":"IF($A29<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A29<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"Yes, this is a hang-over from the old tunneling mapper. I guess when I merged the two mappers I removed the description from agnostic rather than tunneling.\r\n\r\nCovered by previous comment.","2016.11.08, 08:28"]
[29,"TF3","Resolved","Accept","None",null,"Technical","Yes",11,null,6.3,20,"Parameter may also be programmed into RoE Nodes by a controller (a \"god box\"). That mode of operation must also be supported.","OLD:\nParameters are exchanged using OAM TLV packets, see sub-clause 8.1.7. \n\nNEW:\nParameters are either programmed/communicated out of band using some management protocol or exchanged using OAM TLV packets, see sub-clause 8.1.7. ",{"$f":"IF($A30<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A30<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"editorial - yes, better","2016.10.27, 14:38"]
[30,"TF3","Resolved","Accept","None",null,"Technical","Yes",29,null,6.8,6,"The structure agnostic mode \".lenPack\" units should be aligned. Specifically this concerns the 8b10b aware mode. The number of basic frames can be easily deducted with the help of other configuration parameters like \".cpriSpeed\". ","The \".lenPack\" units is the same for all agnostic mode mappers i.e. octets.",{"$f":"IF($A31<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A31<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"yes, this is more explicit","2016.10.27, 14:39"]
[31,"TF3","Resolved","Accept","None",null,"Technical","Yes",30,null,6.9,13,"The structure agnostic mode \".lenPack\" units should be aligned. Specifically this concerns the 8b10b aware mode. The number of basic frames can be easily deducted with the help of other configuration parameters like \".cpriSpeed\". ","The \".lenPack\" units is the same for all agnostic mode mappers i.e. octets.",{"$f":"IF($A32<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A32<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"yes, this is more explicit","2016.10.27, 14:39"]
[32,"TF3","Resolved","AIP","None",null,"Technical","Yes",33,null,"7.1.2.3",16,"it is unnecessary list the relation of the \".lenPack\" to seqNum calculations since we have specific parameters for p-counter and q-counter increments and their respective overflow semantics. There is only a need for simple rules for mapper aware agnostic mode, for example, that the overflow of p-counter means a new radio frame and if the p-counter is all zero, then the radio frame synchronization point is at the start of the payload as it is with timestamps.","OLD:\nFor the 8b10b aware mode (.8b10bstripMode=1), the sequence number is incremented by 1 for each sent RoE data packet and so the sequence number p-counter for deMapperID=.mapperID=x and would wrap around every 256*150/mapperID[x].lenPack sent packets (e.g., if there are 8 BFs per RoE packet the .seqNumPMax is 4799). When the p-counter wraps the sequence number q-counter gets incremented by 1. The q-counter shall wrap after 4096 increments i.e., being able to cover 12 bit CPRI BFN. \nNEW:\nFor the 8b10b aware mode (.8b10bstripMode=1) and when the orderInfo contains a sequence number, the overflow of the p-counter indicates a radio frame boundary. When the p-counter field is 0, this indicates the start of the payload contained within the packet is the start of the radio frame. ",{"$f":"IF($A33<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A33<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok, however, this is a useful illustration .Keep as an example.","2016.10.27, 17:08"]
[33,"TF3","Postponed","AIP","None",null,"Technical","Yes",32,null,7.1,13,"The agnostic mode is currently restricted to 8b10 line coding strip mode. The analysis in tf3_1610_korhonen_64b66b_1.pdf shows that there are use cases and generic alignment reason to allow 64b66b line coding strip mode as well.","Approve the 64b66b line coding strip mode as part of the agnostic mapper and implement changes indicated in tf3_1610_korhonen_64b66b_1.pdf accordingly.",{"$f":"IF($A34<>\"\",'[2]Step 1 -- Commenter information'!$B$2,\"\")","v":"Jouni Korhonen"},{"$f":"IF($A34<>\"\",'[2]Step 1 -- Commenter information'!$B$3,\"\")","v":"Broadcom Ltd."},null,null,"ok, but this is based on baseline approval - lets see....","2016.11.15, 09:29"]
[34,"TF3","Resolved","Accept","None",null,"Editorial","Yes",14,null,3.1,16,"Typo:  \"maitenance\" ","change to \"maintenance\"",{"$f":"IF($A35<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A35<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes. Darn spell check didnt spot it....","2016.11.08, 08:28"]
[35,"TF3","Resolved","Accept","None",null,"Editorial","Yes",19,null,"4.1.2",10,"\"…are within the required timing.\" should be changed to \"meet the application's requirements.\"","modify sentence's ending as suggested",{"$f":"IF($A36<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A36<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok","2016.11.08, 08:29"]
[36,"TF3","Resolved","Accept","None",null,"Editorial","Yes",45,null,"8.1.7",5,"Clarify the term \"payload\" to avoid possible confusion between and Ethernet packet's \"payload field\", which is defined, and \"TLV information string\", which could be viewed as the payload of a TLV.","Change \"The payload contains one or multiple TLVs\" to \"The packet's payload field contains one or multiple TLVs\".",{"$f":"IF($A37<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A37<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, better","2016.11.08, 08:29"]
[37,"TF3","Resolved","Accept","None",null,"Editorial","Yes",32,null,7,3,"The cause-and-effect statements of the following sentence are not worded in the best manner:  \n\"If the encoding and packing method of the source of the I/Q stream is unknown, the required parameters for more efficient mappers are unknown and the simple tunneling mapper (.8b10bstripMode=0) is the only possible mapper to use.\"","Change to: \n\"If the encoding and packing method of the source of the I/Q stream is not known, then the parameters required for using a more efficient mapper are not available.  In this case, using the simple tunneling mapper (.8b10bstripMode=0) is the only possible choice.\"",{"$f":"IF($A38<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A38<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, better.","2016.11.08, 08:29"]
[39,"TF3","Withdrawn","None","None",null,"Editorial","Yes",34,null,"7.2.1",24,"I don't really understand what this sentence is trying to say:\n\"Note that the .lenSkip bits are only valid when extracting/storing data from/to some other source than RoE payload field such as the CPRI basic frame.\"\n\nLet's split the sentence into its two aspects and read them individually:\na) ...the .lenSkip bits are only valid when extracting data from some other source than RoE payload field such as the CPRI basic frame.\nb) ...the .lenSkip bits are only valid when storing data to some other source than RoE payload field such as the CPRI basic frame.\n\nAre you trying to say  \"the .lenSkip bits are only valid when extracting data from and inserting data to the radio stream (e.g. CPRI basic frames)\"?  If so, then you don't need to talk about RoE Payload in this sentence.","Clarify sentence.",{"$f":"IF($A39<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A39<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"Richard/Jouni to propose text?\r\n**************\r\nComment withdrawn on 2016.11.08, at 08:31","2016.11.08, 08:32"]
[39,"TF3","Resolved","Accept","None",null,"Editorial","Yes",17,null,4.0999999999999996,13,"This sentence has a typo (\"/links\") and could be written more clearly:\n\"Although physical connections /links are likely to carry all three logical connections, this is not mandatory.\"","A suggested replacement:\n\"The three logical connections may be carried over the same physical links or over different physical links.\"",{"$f":"IF($A40<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A40<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, better","2016.11.08, 08:32"]
[40,"TF3","Resolved","Accept","None",null,"Editorial","Yes",17,null,4.0999999999999996,14,"In the following paragraph, the word \"node\" is used to define itself.  A few changes are also needed to make the paragraph flow better.\n\n\"This document uses terms node and RoE node meaning a RoE capable networking node that is either the originator or the receiver of a RoE communication. There may be zero or more intermediate networking nodes between RoE end-points. RoE nodes can be defined as end-points, where RoE traffic is terminated or pass-thru nodes where the traffic is forwarded to a following node. A given node can support a mixture of terminating and pass-thru connections where some traffic is terminated and other traffic is forwarded.\"","A suggested replacement:\n\"This document uses the terms node and RoE node, both meaning a RoE capable networking instance that is either the originator or the receiver of a RoE communication link.  RoE nodes can be end-points, where RoE traffic is terminated, or pass-thru points where traffic is forwarded to a following node. A given node can support a mixture of terminated and pass-thru traffic.  There may be zero or more intermediate networking nodes, acting as RoE pass-thru points, between RoE end-points.\"",{"$f":"IF($A41<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A41<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, better.","2016.11.08, 08:32"]
[41,"TF3","Resolved","Accept","None",null,"Editorial","Yes",22,null,"4.4.1",9,"For RoE subType = 000 0100b, the description isn't as specific as for the previous two subTypes..","The description should be changed to \"Data Payload packet with RoE common frame header, for Native RoE\". \nThis makes the description similar in nature to the ones for the previous two subTypes..",{"$f":"IF($A42<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A42<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok","2016.11.08, 08:33"]
[42,"TF3","Resolved","Accept","None",null,"Editorial","Yes",24,null,"4.4.4.1",1,"For the .seqNum.seqNumPIncProp parameter's description, .seqNumPVal should be .seqNumPInc.","Fix description for when .seqNumPIncProp = 0x1 so .seqNumPVal is replaced by .seqNumPInc.",{"$f":"IF($A43<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A43<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, change row 3 to '0x1 increments by the constant .seqNumPVal on every sent packet.'\r\nYes, covered by preevious comment too.","2016.11.08, 08:33"]
[43,"TF3","Resolved","Accept","None",null,"Editorial","Yes",24,null,"4.4.4.2",6,"Improve the following sentence:\n\"Both the transmitting and receiving end-points share the same understanding of the ToD in order for the information to be presented at the desired time.\"","Add \"must\" into the sentence as shown:\n\"Both the transmitting and receiving end-points must share the same understanding of the ToD in order for the information to be presented at the desired time.\"",{"$f":"IF($A44<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A44<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, better.","2016.11.08, 08:34"]
[44,"TF3","Postponed","AIP","None",null,"Technical","Yes",29,null,6.8,9,"Table 6-4 should add 64b66b mode.alongside simple tunneling mode and 8b10b mode.","See recommended changes given in tf3_1609_korhonen_64b66b_1 contribution.",{"$f":"IF($A45<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A45<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok, but this is based on baseline approval - lets see....","2016.11.15, 09:29"]
[45,"TF3","Resolved","Accept","None",null,"Technical","Yes",29,null,6.8,9,"Perhaps .lenPack should always use units of octets.  Other units, such as CPRI Basic Frames could be derived from this .lenPack value along with other parameters.  This also gives more flexibility in selecting the best frame size.","Change .lenPack to always be in units of octets.",{"$f":"IF($A46<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A46<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes","2016.10.27, 17:09"]
[46,"TF3","Postponed","AIP","None",null,"Technical","Yes",30,null,6.9,13,"Table 6-5 should add 64b66b mode.alongside simple tunneling mode and 8b10b mode.","See recommended changes given in tf3_1609_korhonen_64b66b_1 contribution.",{"$f":"IF($A47<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A47<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok, but this is based on baseline approval - lets see....","2016.11.15, 09:29"]
[47,"TF3","Resolved","Accept","None",null,"Editorial","Yes",30,null,6.9,13,"In Table 6-5, why is the Source Ethernet link parameter placed away from the Destination Ethernet link/CPRI port parameter?  It would be more harmonious to the Mapper paremter table (Table 6-4) if they were placed next to each other (like the other parameters are).","Move Source Ethernet link parameter so it is above the Destination Ethernet link/CPRI port parameter",{"$f":"IF($A48<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A48<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"Yes, make it harmonious with mapper.\r\nYes, covered by preevious comment too.\r\n","2016.11.08, 08:34"]
[48,"TF3","Resolved","AIP","None",null,"Technical","Yes",31,null,6.9,1,"Perhaps .lenPack should always use units of octets.  Other units, such as CPRI Basic Frames could be derived from this .lenPack value along with other parameters.  This also gives more flexibility in selecting the best frame size.","Change .lenPack to always be in units of octets.",{"$f":"IF($A49<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A49<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"Fine with me, how does the group feel?","2016.10.27, 17:09"]
[49,"TF3","Postponed","AIP","None",null,"Technical","Yes",32,null,7.1,13,"Add 64B/66B structure agnostic mode","See recommended changes given in tf3_1609_korhonen_64b66b_1 contribution.",{"$f":"IF($A50<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A50<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok, but this is based on baseline approval - lets see....","2016.11.15, 09:29"]
[50,"TF3","Resolved","AIP","None",null,"Editorial","Yes",32,null,"7.1.2.1",38,"This sentence just says \"shall be set to value identified in Table 4-1\".  The grammar needs to be fixed and, optionally, the value could be specified.","Change to \"The subType field for a structure agnostic data packet shall be set to the value 0000 0010b, as identified in Table 4-1.\"",{"$f":"IF($A51<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A51<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"I'd like to avoid having the value (in case we change the table)\r\nChange 'to value' to 'to the value' // multiple instances of this...","2016.10.27, 17:12"]
[51,"TF3","Resolved","Accept","None",null,"Technical","Yes",33,null,"7.1.2.3",7,"Timestamps should also be allowed for all structure agnostic traffic.  \nRecovering the CPRI clock (or any other clock) is much easier when you can use differential methods (which you get with timestamps) as opposed to adaptive methods (which is all you can do with sequence numbers).  The effects of PDV can be easily overcome with differential methods.  It is difficult to do with adaptive methods.","Allow either sequence numbers or timestamps to be used.",{"$f":"IF($A52<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A52<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, see earlier comment - this was an error by the editor when merging tunneling","2016.10.27, 14:40"]
[52,"TF3","Postponed","AIP","None",null,"Technical","Yes",33,null,"7.1.2.5",28,"Add comment for 64B/66B aware mode.","See recommended changes given in tf3_1609_korhonen_64b66b_1 contribution.",{"$f":"IF($A53<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A53<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"ok, but this is based on baseline approval - lets see....","2016.11.15, 09:29"]
[53,"TF3","Resolved","Accept","None",null,"Editorial","Yes",34,null,"7.1.2.5",1,"The figure for a) has an extra \"LSB\" and is missing \"MSB\" on the left side.","Replace the lowest \"LSB\" with \"MSB\"",{"$f":"IF($A54<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A54<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes, I'll provide significance to those poor bits.\r\nYes, covered by preevious comment too.","2016.11.08, 08:34"]
[54,"TF3","Resolved","Accept","None",null,"Editorial","Yes",36,null,"7.2.2.5",1,"The figure for a) has an extra \"LSB\" and is missing \"MSB\" on the left side.","Replace the lowest \"LSB\" with \"MSB\"",{"$f":"IF($A55<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A55<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"yes\r\nYes, covered by preevious comment too.","2016.11.08, 08:35"]
[55,"TF3","Resolved","AIP","None",null,"Technical","Yes",42,null,"7.2.9",1,"Is this supposed to be for \"other AxC_Ctrl and vendor specific words\"?  Or is it for structure agnostic mapper?\nIf the former, then the heading needs to be changed.\nIf the latter, please note that the structure agnostic mapper's ordering information field was already discussed in 7.2.2.3.  7.2.2.3 allows the use of both sequence numbers and timestamps.  I believe the use of timestamps is even more important for the structure agnostic mapper because the data streams have empty spaces, which are not mapped into Ethernet.  This makes the recovery of the clock even more difficult, especially if one only has sequence numbers.","Allow either sequence numbers or timestamps to be used.",{"$f":"IF($A56<>\"\",'[3]Step 1 -- Commenter information'!$B$2,\"\")","v":"Richard Tse"},{"$f":"IF($A56<>\"\",'[3]Step 1 -- Commenter information'!$B$3,\"\")","v":"Microsemi"},null,null,"im confused here. is this a duplicate? something is wrong though....\r\n\r\nMerge into 7.2.2.3? Follow the same heading structure for all these packet types.\r\nCheck with other comment regarding use of timeStamps & include.","2016.11.15, 08:00"]
[56,"TF3","Resolved","Accept","None",null,"Technical","No",24,null,"4.4.4.1",16,"When describing the field p-counter and q-counter, 'field from x to y' is not accurate. 'Bits x to y' should be used.","Modify the text of 4.4.4.1 from Line 15 to 28 as proposed in tf3_1610_lu_1.pdf",{"$f":"IF($A57<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A57<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:01"]
[57,"TF3","Resolved","Accept","None",null,"Technical","No",23,null,"4.4.4.1",18,"Figure 4-7 illustrates the format of sequence number field, not the timeStamp.","Modify the text of 4.4.4.1 from Line 15 to 28 as proposed in tf3_1610_lu_1.pdf",{"$f":"IF($A58<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A58<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:01"]
[58,"TF3","Resolved","Accept","None",null,"Technical","Yes",24,null,"4.4.4.1",1,"When .seqNumPIncProp takes value of 0x1, the increment value should be .seqNumPInc, not the .seqNumPVal.","Modify Table 4-3 as proposed in tf3_1610_lu_2.pdf.",{"$f":"IF($A59<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A59<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:01"]
[59,"TF3","Resolved","Accept","None",null,"Technical","No",24,null,"4.4.4.1",1,"How the .seqNumPInc is affected by .seqNumPIncProp should be elaborated.","Modify Table 4-3 as proposed in tf3_1610_lu_2.pdf.",{"$f":"IF($A60<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A60<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:01"]
[60,"TF3","Resolved","Accept","None",null,"Technical","No",24,null,"4.4.4.1",1,".seqNumPInc and .seqNumQInc is not a constant, but a variable.","Modify Table 4-3 as proposed in tf3_1610_lu_2.pdf.",{"$f":"IF($A61<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A61<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:01"]
[61,"TF3","Resolved","Accept","None",null,"Technical","No",24,null,"4.4.4.1",1,"Since .seqNumPIncProp and .seqNumQIncProp take default value 0x001, suggest that the parameters .seqNumPInc and .seqNumQInc both take default value of 0x0000 0001.","Modify Table 4-3 as proposed in tf3_1610_lu_2.pdf.",{"$f":"IF($A62<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A62<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes, better","2016.11.15, 08:02"]
[62,"TF3","Resolved","Accept","None",null,"Editorial","No",24,null,"4.4.41",1,"In the description of a enumeration value of a parameter, add a colon between the value and the description.","Modify Table 4-3 as proposed in tf3_1610_lu_2.pdf.",{"$f":"IF($A63<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A63<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"ok","2016.11.08, 08:35"]
[63,"TF3","Resolved","Accept","None",null,"Technical","No",39,null,"7.2.7",10,".seqNumPInc should be .seqNumQInc","Change item e) to 'e) mapperID[x].seqNumQInc=1'",{"$f":"IF($A64<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A64<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes","2016.10.27, 14:42"]
[64,"TF3","Resolved","Accept","None",null,"Technical","No",39,null,"7.2.7",11,".seqNumPIncProp should be .seqNumQIncProp","Change item f) to 'f) mapperID[x].seqNumQIncProp=1'",{"$f":"IF($A65<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A65<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes","2016.10.27, 14:42"]
[65,"TF3","Resolved","Accept","None",null,"Technical","Yes",45,null,"8.1.7",7,"In Figure 8-2, the length of field 'TLV information string length' should be 9 bits.","Modify the figure accordingly.",{"$f":"IF($A66<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A66<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes","2016.10.27, 15:26"]
[66,"TF3","Resolved","Accept","None",null,"Technical","No",50,null,"Annex A",10,".seqNumPInc should be .seqNumQInc","Change item e) to 'e) mapperID[x].seqNumQInc=1'",{"$f":"IF($A67<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A67<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes","2016.10.27, 14:42"]
[67,"TF3","Resolved","Accept","None",null,"Technical","No",50,null,"Annex A",11,".seqNumPIncProp should be .seqNumQIncProp","Change item f) to 'f) mapperID[x].seqNumQIncProp=1'",{"$f":"IF($A68<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A68<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes","2016.10.27, 14:42"]
[68,"TF3","Resolved","AIP","None",null,"Editorial","No",47,null,"Annex A",10,"The numbering of figures in incorrect.","Renumbering the figures in Annex A.",{"$f":"IF($A69<>\"\",'[4]Step 1 -- Commenter information'!$B$2,\"\")","v":"Lu Yang"},{"$f":"IF($A69<>\"\",'[4]Step 1 -- Commenter information'!$B$3,\"\")","v":"CAICT"},null,null,"yes.","2016.11.08, 08:35"]
[69,"TF3","Incomplete","AIP","None",null,"Editorial","No",11,null,1,19,"Is it necessarily cost or function that dictates C-RAN split?","Consider specifying in terms of RF vs. signal processing","Kevin Bross","Intel",null,null,"Agreed. This introduction has been around since my day 1\r\nI'm not sure it properly reflects all the possible use cases for RoE very well anymore.","2016.11.15, 09:30"]
[70,"TF3","Resolved","Accept","None",null,"Editorial","No",11,null,1,25,"Packet switching is fine, but when used as an adjective, should be hyphenated","packet-switched network (throughout document)","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:36"]
[71,"TF3","Resolved","Accept","None",null,"Editorial","Yes",11,null,1,29,"Add comma","centrally located, while","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:36"]
[72,"TF3","Resolved","Accept","None",null,"Editorial","Yes",11,null,1,31,"Break up run-on sentence","low-level encoded format; this is predominantly","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:36"]
[73,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,37,"100 us (should be µs) is not part of CPRI specification","Remove this reference","Kevin Bross","Intel",null,null,"see comment 12","2016.10.27, 17:14"]
[74,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,37,"Toffset must be <8.138 ns and R-19 refers to link delay accuracy, excluding cables","Remove or reword this reference","Kevin Bross","Intel",null,null,"see comment 12","2016.10.27, 17:14"]
[75,"TF3","Resolved","Accept","None",null,"Editorial","Yes",11,null,1,39,"Add comma","for 4G/5G, a method","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:36"]
[76,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,43,"There are 3 types of encapsulation defined, not 2","broadly three types","Kevin Bross","Intel",null,null,"yes, new paragraph needed. See Brians comment.","2016.11.15, 08:02"]
[77,"TF3","Resolved","Accept","None",null,"Editorial","Yes",11,null,1,43,"Structure agnostic is now one type of encapsulation, with optional 8b/10b removal","mechanism is oblivious","Kevin Bross","Intel",null,null,"change 'mechanisms are oblivious' to 'mechanism is oblivious'","2016.11.08, 08:36"]
[78,"TF3","Resolved","Accept","None",null,"Editorial","No",11,null,1,44,"Tie two related sentences together by joining with semicolon","encapsulating; this we refer","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:36"]
[79,"TF3","Resolved","AIP","None",null,"Technical","Yes",11,null,1,45,"Structure aware is the second of three techniques","The second encapsulation mechanism is partially aware","Kevin Bross","Intel",null,null,"yes, new paragraph needed. See Brians comment.","2016.11.15, 08:03"]
[80,"TF3","Resolved","AIP","None",null,"Editorial","Yes",12,null,1,1,"Prefer \"structure-aware\" and \"structure-agnostic\" (p.11, l44) as shown in this paragraph vs. their non-hyphenated versions","Suggest using \"structure-aware\" and \"structure-agnostic\" with hyphens throughout the document.  Need to be consistent in any case.","Kevin Bross","Intel",null,null,"Use hyphen version throughout","2016.11.08, 08:37"]
[81,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1,2,"Need to describe the RoE native mode as well.","The third encapsulation mechanism transfers raw I/Q data and control data in the time or frequency domain without requiring an intermediate protocol such as CPRI; this encapsulation is referred to as the RoE native mechanism.","Kevin Bross","Intel",null,null,"yes, new paragraph needed. See Brians comment","2016.11.15, 08:03"]
[82,"TF3","Resolved","Accept","None",null,"Technical","Yes",12,null,1,4,"Does this really recommend the use of 802.1CM?  I don't think so.  Those can help, but there is nothing normative requiring or suggesting this.","IEEE Std 802.1™ CM or similar techniques can be used to help ensure QoS guarantees.","Kevin Bross","Intel",null,null,"Change:\r\n'It does however recommend the support of .... profile or equivalent to help ensure such QoS guarantees'\r\n\r\nTo \r\nIEEE Std 802.1™ CM or similar techniques can be used to help ensure QoS guarantees.","2016.10.27, 15:31"]
[83,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1,12,"Do we need to include de-encapsulation and de-mapping?  Is it accurate to indicate that we're not concerned with retiming or dejittering as specified in point d?","<need to understand answers to questions at the left?","Kevin Bross","Intel",null,null,"Please suggest text. Covered in previous comment.","2016.11.15, 08:04"]
[84,"TF3","Resolved","AIP","None",null,"Editorial","Yes",12,null,1.1000000000000001,15,"Plural signals, Ethernet immaterial in this sentence, front haul is specifically between the radio head and the digital processing equipment (not using BBU to avoid 4G-specific term)","packetized radio signals between the radio head the digital processing equipment is referred to as fronthaul in this standard.","Kevin Bross","Intel",null,null,"Actually the only other uses of the term fronthaul is in the next paragraph only... In addition, typically (today) it is not packetized over ethernet.\r\n\r\nchange 'This document defines the encapsulation and mapping of radio protocols to be transported over Ethernet. The transport of packetized radio signal over Ethernet is referred to in this standard as fronthaul. Furthermore, both structure-agnostic and structure-aware definitions are provided for the most common and current radio protocol – Common Public Radio Interface  (CPRI).'\r\n\r\nto\r\n\r\n'In a wireless telecommunication network, the link and protocol between radio elements and baseband controllers is known as fronthaul. This document defines the encapsulation and mapping of radio protocols to be transported over Ethernet packets. Furthermore, a structure-aware definition is provided for the most common and current radio protocol – Common Public Radio Interface  (CPRI).'","2016.11.08, 08:41"]
[85,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1.1000000000000001,17,"Need to describe the RoE native mode as well.","A third definition (RoE native) is provided for packetized radio signals that don't use CPRI.","Kevin Bross","Intel",null,null,"yes, add 'A third definition (RoE native) is provided for packetized radio signals that don't use CPRI.'","2016.10.27, 17:21"]
[86,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1.2,22,"Structure-agnostic doesn't understand the bits--they're opaque, not transparent.","such as CPRI as binary data (structure-agnostic)","Kevin Bross","Intel",null,null,"Transport a C-RAN Radio Fronthaul protocol such as CPRI in a bit-transparent or a semi-transparent manner (structure agnostic) over Ethernet\r\n\r\nWell, it's not entirely transparent with 8b10b mode. How's this;\r\n\r\n'Transport a Radio Fronthaul protocol such as CPRI, with or without line coding in a transparent manner (structure agnostic) over Ethernet.' \r\n\r\nFurther recommend removing C-RAN from the bullet below.","2016.10.27, 17:25"]
[87,"TF3","Resolved","AIP","None",null,"Technical","Yes",12,null,1.2,27,"Need to describe the RoE native mode as well.","Transport I/Q samples in the time or frequency domain without requiring an intermediate protocol such as CPRI.","Kevin Bross","Intel",null,null,"yes, new paragraph needed. Covered in previous comment.","2016.11.15, 08:04"]
[88,"TF3","Resolved","Reject","None",null,"Technical","Yes",13,null,2,8,"Is 802.1AB needed for TLV","IEEE Std 802.1AB (for TLV definition)","Kevin Bross","Intel",null,null,"editorial - Hmm, we're lifting that part of 802.1AB but i dont think the 'documents are indispensable for the application of this document' . Keep it in biliography.","2016.11.15, 08:06"]
[89,"TF3","Resolved","Accept","None",null,"Technical","Yes",14,null,3,2,"Missing acronyms","Add FCS, SoF, and TDM","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:42"]
[90,"TF3","Withdrawn","None","None",null,"Editorial","No",14,null,3,4,"Should definitions be capitalized (especially with BF, BFN, CPRI, RoE)?","Capitalize definitions where they align with acronym","Kevin Bross","Intel",null,null,"not according to the style guide\r\n**************\r\nComment withdrawn on 2016.11.08, at 08:43","2016.11.08, 08:43"]
[91,"TF3","Resolved","Accept","None",null,"Editorial","Yes",14,null,3,16,"Misspelling","maintenance","Kevin Bross","Intel",null,null,"yes","2016.11.08, 08:43"]
[92,"TF3","Resolved","Accept","None",null,"Technical","Yes",15,null,3.2,9,"This is too CPRI-specific","a CPRI or other radio frame","Kevin Bross","Intel",null,null,"editorial - yes, better","2016.10.27, 14:43"]
[93,"TF3","Withdrawn","None","None",null,"Technical","Yes",15,null,3.4,21,"1914 needs to request this from IEEE now; cannot rely on 1904 Ethertype","<get EtherType assigned and insert number>","Kevin Bross","Intel",null,null,"indeed. no action (plague Jinri)\r\n**************\r\nComment withdrawn on 2016.10.27, at 17:26","2016.10.27, 17:26"]
[94,"TF3","Resolved","Accept","None",null,"Editorial","Yes",16,null,3.5,7,"Integers can be expressed as decimal, binary, or hexadecimal.","Decimal or base 10 value has","Kevin Bross","Intel",null,null,"change 'Integer value has no specific notation, for example: 69'\r\nto 'Decimal or base 10 value has no specific notation, for example: 69'","2016.11.08, 08:44"]
[95,"TF3","Resolved","AIP","None",null,"Editorial","Yes",16,null,3.5,8,"Suggest a value other than 0xDEAD BEEF--use one with some digits.  May want to use the same number for decimal, hexadecimal, and binary numbers, so you can see the same value in 3 different representations",null,"Kevin Bross","Intel",null,null,"ok. 763?","2016.11.08, 08:46"]
[96,"TF3","Resolved","Accept","None",null,"Editorial","Yes",16,null,3.5,10,"Describe how larger numbers are represented","For large numbers, the following rules apply:\n  * Every 3 decimal digits are separated by commas (e.g., 65,535)\n  * Every 4 hexadecimal digits are separated by spaces (e.g., 0xFFFF FFFF)\n  * Every 4 binary digits are separated by spaces (e.g., 1111 1111 1100 1001b)","Kevin Bross","Intel",null,null,"ok, will add this","2016.11.08, 08:46"]
[97,"TF3","Resolved","Accept","None",null,"Editorial","Yes",16,null,3.5,10,"Indicate that periods are used for decimal points to avoid internationalization confusion","Periods are used for decimal points (e.g., 3.14159)","Kevin Bross","Intel",null,null,"ok, will add this","2016.11.08, 08:46"]
[98,"TF3","Resolved","Reject","None",null,"Editorial","Yes",16,null,3.5,10,"Clarify that NIL is -1 (not the same as 0 or NULL)","As used in this specification, NIL is the value with all bits set.  This translates to -1 for signed values, 0xFF for 8-bit unsigned values, 0xFFFF for 16-bit unsigned values, etc.","Kevin Bross","Intel",null,null,"ok, add 'NIL is the value with all bits set. This translates to -1 for signed values, 0xFF for 8-bit unsigned values, 0xFFFF for 16-bit unsigned values, etc.'  ","2016.11.08, 08:48"]
[99,"TF3","Resolved","Accept","None",null,"Technical","Yes",17,null,4.0999999999999996,12,"Need to describe the RoE native mode as well.","7.1, 7.2, and 7.3","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:44"]
[100,"TF3","Resolved","Accept","None",null,"Editorial","No",17,null,4.0999999999999996,13,"Remove space","connections/links","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:48"]
[101,"TF3","Resolved","Accept","None",null,"Editorial","No",17,null,4.0999999999999996,17,"Add comma","terminated, or","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:48"]
[102,"TF3","Resolved","AIP","None",null,"Technical","Yes",18,null,4.0999999999999996,1,"Should this include a description of the agnostic mapper as well?","Add one row that has \"CPRI or other\" on both ends and has \"Agnostic Mapper\" where \"CPRI Mapper\" is shown on the first row","Kevin Bross","Intel",null,null,"In diagrams\r\n\r\nCPRI Mapper -> Mapper\r\nCPRI -> CPRI/other","2016.10.27, 17:29"]
[103,"TF3","Resolved","AIP","None",null,"Editorial","Yes",18,null,4.0999999999999996,11,"Should ensure that figures do not break across pages","Keep lines together/keep with follow, or add page break ahead of figure","Kevin Bross","Intel",null,null,"Look for this next time. Get it tidy for D2.0","2016.11.08, 08:51"]
[104,"TF3","Resolved","Accept","None",null,"Editorial","No",19,null,"4.1.2",6,"Common usage (\"Whilst\" → \"While\")","While the need","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:51"]
[105,"TF3","Resolved","Accept","None",null,"Editorial","Yes",19,null,"4.1.2",7,"Add period","G.8275","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:51"]
[106,"TF3","Resolved","Accept","None",null,"Editorial","No",19,null,"4.1.2",8,"Replace period with colon","requirements:","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:51"]
[107,"TF3","Resolved","Accept","None",null,"Technical","Yes",19,null,"4.1.2",9,"Networks don't have to be mesh networks","A network","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:45"]
[108,"TF3","Resolved","Accept","None",null,"Technical","Yes",19,null,"4.1.2",13,"Oversubscription is allowed for lower-priority traffic as long as RoE traffic is not impacted.  The other types of traffic do not necessarily have to be known as long as they don't impact RoE performance","not oversubscribed (at least for traffic at same/higher priority as RoE), known peak bandwidth","Kevin Bross","Intel",null,null,"ok","2016.10.27, 17:30"]
[109,"TF3","Resolved","Accept","None",null,"Editorial","Yes",19,null,"4.1.2",16,"Misspelling","effective","Kevin Bross","Intel",null,null,"yes","2016.11.08, 08:52"]
[110,"TF3","Withdrawn","None","None",null,"Technical","Yes",19,null,"4.1.2",17,"May want to add condition on capacity","RoE traffic without exceeding PDV limits.","Kevin Bross","Intel",null,null,"ok\r\n**************\r\nComment withdrawn on 2016.10.27, at 14:49","2016.10.27, 14:49"]
[111,"TF3","Resolved","Accept","None",null,"Technical","Yes",20,null,4.2,4,"CPRI technically not required for agnostic mapper","Required for structure-aware mode and typically part of structure-agnostic mode.","Kevin Bross","Intel",null,null,"ok","2016.10.27, 14:49"]
[112,"TF3","Resolved","Accept","None",null,"Technical","Yes",20,null,4.2,5,"Last sentence of paragraph overrides 2nd sentence.","de-mapper.  A mapper","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:49"]
[1113,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,4.2,5,"Common usage (\"Whilst\" → \"While\")","data while a ","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:52"]
[114,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,"4.2.1",12,"Throughout document, recommend changing \"a RoE\" to \"an RoE\" (see http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-abbreviations.html )","An RoE","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:52"]
[115,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,"4.2.1",13,"Replace comma with semicolon","bi-directional; however, ","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:52"]
[116,"TF3","Withdrawn","None","None",null,"Technical","Yes",20,null,"4.2.1",13,"Is this really feasible with a uni-directional Ethernet link?  That would not seem to be practical or reasonable to do.","<remove the last sentence of this paragraph>","Kevin Bross","Intel",null,null,"**************\r\nComment withdrawn on 2016.10.27, at 17:33","2016.10.27, 17:33"]
[117,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,"4.2.2",17,"Add comma to separate independent clauses joined by a conjunction","format, and a","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:52"]
[118,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,"4.2.2",19,"Make reference a parenthetical expression to improve readability","specification (see sub-clause 4.2.4).","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:52"]
[119,"TF3","Resolved","AIP","None",null,"Editorial","No",20,null,"4.2.2",19,"Should we purge the use of sub-clause in this document?  Isn't it just as accurate to refer to \"clause 4.2.4\" as it is to refer to \"sub-clause 4.2.4\"?  (I would only use sub-clause in something like the following:  \"Refer to clause 4.2 and its sub-clauses.\")  Also note that sub-clause is sometimes used in this document with and without hyphens.","see clause 4.2.4","Kevin Bross","Intel",null,null,"Clause 4\r\nSub-clause 4.1 4.1.2 etc.","2016.11.08, 08:54"]
[120,"TF3","Resolved","Accept","None",null,"Editorial","No",20,null,"4.2.2",20,"Add comma","direction, the RoE","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:54"]
[121,"TF3","Resolved","Accept","None",null,"Technical","Yes",20,null,"4.2.2",26,"Tighten up wording, replace last sentence of paragraph.","The functionality of the ordering information is described in clause 4.4.4.  <End of paragraph>","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:50"]
[122,"TF3","Resolved","Accept","None",null,"Technical","Yes",21,null,"4.2.3",4,"Too CPRI-specific","has CPRI (or CPRI-like) ports.","Kevin Bross","Intel",null,null,"ok","2016.10.27, 14:50"]
[123,"TF3","Withdrawn","None","None",null,"Technical","Yes",21,null,"4.2.3",4,"Can CPRI ports really be uni-directional?  I don't think that works.","CPRI ports are bi-directional. <end of paragraph>","Kevin Bross","Intel",null,null,"I cant see a use case, but its not harmful. Again, I forget who wanted this added.\r\n**************\r\nComment withdrawn on 2016.10.27, at 17:34","2016.10.27, 17:34"]
[124,"TF3","Incomplete","AIP","None",null,"Technical","Yes",21,null,"4.2.4",7,"This paragraph only applies to structure-aware mapper.","The control data varies by mapper/de-mapper.  <move rest of data to structure-aware section>","Kevin Bross","Intel",null,null,"yes, I think we had a comment to move this paragraph.\r\nPlease suggest text for each section","2016.11.15, 09:31"]
[125,"TF3","Resolved","Accept","None",null,"Technical","Yes",21,null,4.3,17,"EtherType is not implicit--it needs to be explicitly called out in this specification.","SA, DA, and FCS are implicit to all RoE packets.  The RoE EtherType value is specified in clause 3.4.","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:52"]
[126,"TF3","Resolved","Accept","None",null,"Technical","Yes",21,null,4.4000000000000004,25,"In general, need to make sure we're clear about use of \"frame\".  Is this the same as Ethernet packet or is it the RoE-specific portion of the packet.  [For example, FCS applies to the Ethernet packet.]","octet of the RoE header","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 14:55"]
[127,"TF3","Resolved","Accept","None",null,"Editorial","No",21,null,4.4000000000000004,28,"There should be a space between numbers and units","16 bits","Kevin Bross","Intel",null,null,"ok","2016.11.08, 08:54"]
[128,"TF3","Withdrawn","None","None",null,"Technical","No",22,null,"4.4.1",9,"Comment:  these numbers assume that RoE is not sharing an Ethertype with 1904.",null,"Kevin Bross","Intel",null,null,"indeed. No Action.\r\n**************\r\nComment withdrawn on 2016.10.27, at 14:56","2016.10.27, 14:56"]
[129,"TF3","Resolved","AIP","None",null,"Editorial","No",22,null,"4.4.1",9,"Suggest keeping structure-aware values together","<Move Slow C&M line up above Native RoE and re-number>","Kevin Bross","Intel",null,null,"Yes. I'd also like to space it out a bit in case we get more non-native.\r\n0001 0000b is native aware (we are likely to have a few)","2016.11.08, 08:54"]
[130,"TF3","Resolved","AIP","None",null,"Editorial","No",22,null,"4.4.1",9,"Label function fields of last two rows.","Reserved…Experimental","Kevin Bross","Intel",null,null,"Add text to where it has --","2016.11.08, 08:56"]
[131,"TF3","Postponed","AIP","None",null,"Technical","Yes",22,null,"4.4.1",9,"Need to handle both time-domain and frequency-domain I/Q signals","Add extra line to differentiate Native RoE time domain data from Native RoE frequency domain data.","Kevin Bross","Intel",null,null,"see new baseline proposal.\r\nSuggest we move Native to 0001 0000b to make space for possible new non-native subTypes","2016.11.15, 09:29"]
[132,"TF3","Resolved","Accept","None",null,"Technical","Yes",23,null,"4.4.3",7,"Clarify that this is the RoE common frame (not Ethernet)","the common RoE frame format","Kevin Bross","Intel",null,null,"the common RoE header'","2016.10.27, 14:57"]
[133,"TF3","Withdrawn","None","None",null,"Technical","Yes",23,null,"4.4.4.1",31,"Should this text and Table 4-3 be moved to §8.1.3?","<Move to clause 8.1.3>","Kevin Bross","Intel",null,null,"I dont think so...\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:34","2016.10.27, 15:34"]
[134,"TF3","Resolved","AIP","None",null,"Editorial","Yes",24,null,"4.4.4.1",1,".seqNumXIncProp should be listed before .seqNumXInc","<Move .seqNumPIncProp and .seqNumQIncProp up one line each>","Kevin Bross","Intel",null,null,"ok","2016.11.15, 08:27"]
[135,"TF3","Resolved","Accept","None",null,"Technical","Yes",24,null,"4.4.4.1",1,"Should have default values of 0x0000 0001 for .seqNumXInc","0x0000 0001","Kevin Bross","Intel",null,null,"ok. ","2016.10.27, 17:37"]
[136,"TF3","Resolved","Accept","None",null,"Technical","Yes",24,null,"4.4.4.1",1,".seqNumPIncProp 0x1 should reference .seqNumPInc","constant .seqNumPInc on every sent packet","Kevin Bross","Intel",null,null,"yes","2016.10.27, 14:58"]
[137,"TF3","Resolved","AIP","None",null,"Technical","Yes",24,null,"4.4.4.1",1,"Should .seqNumPIncProp 0x2 be by packet size or by RoE frame size?","by the RoE frame size on every","Kevin Bross","Intel",null,null,"yes, RoE Payload size","2016.10.27, 17:38"]
[138,"TF3","Resolved","Accept","None",null,"Editorial","Yes",24,null,"4.4.4.1",1,"3-bit values should be 001b, not 0x001","001b <both .seqNumPIncProp and .seqNumQIncProp>","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:21"]
[139,"TF3","Resolved","AIP","None",null,"Technical","Yes",24,null,"4.4.4.2",6,"Clarification","end-points must share","Kevin Bross","Intel",null,null,"ok. Something like -  'Both the transmitting and receiving end-points share the same format of time using the timeStamp field'\r\n\r\n\r\nMove something like 'Both the transmitting and receiving end-points share the same understanding of\r\n the ToD in order for the information to be presented at the desired time' to the introduction.\r\n\r\nAnd 4.1.2.\r\n","2016.11.15, 08:12"]
[140,"TF3","Withdrawn","None","None",null,"Technical","Yes",25,null,"4.4.4.2",1,"Should the 2 bits of the seqNum be at the 2 LSB position?","<Move seqNum field to end of timestamp>","Kevin Bross","Intel",null,null,"I think the document reflects what was agreed\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:34","2016.10.27, 15:34"]
[141,"TF3","Resolved","Accept","None",null,"Editorial","No",25,null,"4.4.4.2",4,"Add space","radio frame","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:21"]
[142,"TF3","Resolved","Reject","None",null,"Editorial","No",25,null,"4.4.4.2",7,"There should be a space between numbers and units","0 ns to 16,777,215 ns…0.03125 ns….0 ns…0.96875 ns…17 ms…16,777,215.96875 ns","Kevin Bross","Intel",null,null,"Easier on the eye without","2016.11.15, 08:28"]
[143,"TF3","Resolved","Accept","None",null,"Editorial","No",25,null,"4.4.4.2",8,"Should have 4 hexadecimal digits to right of space (just like having 3 base-10 digits to the right of a comma:  16,384 not 163,84)","0xFF FFFF","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:22"]
[144,"TF3","Resolved","AIP","None",null,"Editorial","No",25,null,"4.4.5",20,"This sentence is awkward","<revise>","Kevin Bross","Intel",null,null,"ok","2016.11.15, 08:28"]
[145,"TF3","Resolved","Accept","None",null,"Editorial","No",25,null,"4.4.5",22,"Improve readability","management information, such as in the form of TLVs","Kevin Bross","Intel",null,null,"ok, better","2016.10.13, 00:24"]
[146,"TF3","Resolved","AIP","None",null,"Editorial","Yes",26,null,"5.1.2",16,"Clarify meaning","payload is expected to be played out","Kevin Bross","Intel",null,null,"how about 'payload shall be played out'","2016.11.15, 08:29"]
[147,"TF3","Resolved","Accept","None",null,"Editorial","No",26,null,"5.1.3",19,"See earlier comment on \"a RoE\"","When an RoE","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:25"]
[148,"TF3","Resolved","Accept","None",null,"Editorial","Yes",26,null,"5.1.3",23,"Missing \"for\"","compensate for packet delay","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:25"]
[149,"TF3","Resolved","Accept","None",null,"Editorial","No",26,null,"5.1.3",25,"Hyphenate","implementation- and deployment-specific.  <or:  implementation-specific and deployment-specific.>","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:25"]
[150,"TF3","Resolved","Accept","None",null,"Editorial","Yes",27,null,6,3,"\"wiring\" may not be the right term","the internal configuration of the node","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:26"]
[151,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.6,9,"While I would expect that 256 Ethernet (and CPRI) ports would usually be enough, I can imagine systems with 160+ cores having lots of physical interfaces or virtualization going beyond 256 ports.  Since this is an infrequently-sent parameter, I think we should cover our bases and make this be a 16-bit value, just in case.  Also, it was unclear why this was up to 255, while the CPRI links were up to 256--what is reserved?  Also, \"links\" --> \"ports\".","up to 65,536 Ethernet ports","Kevin Bross","Intel",null,null,"Extend field. Not a requirement to support 65,536\r\n","2016.11.15, 08:30"]
[152,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.6,12,"Expand to 16 bits","16 (Bits)","Kevin Bross","Intel",null,null,"See 151. reserving more ","2016.11.15, 09:09"]
[153,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.7,14,"Do 16-bit CPRI port number (like Ethernet reasoning above).","up to 65,536 CPRI ports","Kevin Bross","Intel",null,null,"See 151. reserving more ","2016.11.15, 09:09"]
[154,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.7,17,"Expand to 16 bits","16 (Bits--for Identifier)","Kevin Bross","Intel",null,null,"See 151. reserving more ","2016.11.15, 09:09"]
[155,"TF3","Withdrawn","None","None",null,"Technical","Yes",28,null,6.7,17,"Do we really need double-precision floating point representation of port speed?  Do we need sub-bps rate identification?","64 bit integer in bps or 32-bit integer in 1000 bps units","Kevin Bross","Intel",null,null,"This is what we agreed. We can reopen the discussion but for expediancy, id rather not...\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:34","2016.10.27, 15:34"]
[156,"TF3","Resolved","Accept","None",null,"Technical","Yes",29,null,6.8,9,"Packet length should be in octets for all mappers","Identifies the amount of data (in octets) to packetize.","Kevin Bross","Intel",null,null,"yes, see previous comment. lets agree on this","2016.10.27, 17:43"]
[157,"TF3","Resolved","Accept","None",null,"Editorial","No",30,null,6.8,0,"When used as an adjective, hypenate bit lengths","29-bit value <2x>","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:26"]
[158,"TF3","Postponed","AIP","None",null,"Technical","Yes",30,null,6.8,0,"Add parameter to identify if samples are time-domain or frequency-domain (where applicable).  Make ordinal value to leave headroom for future definitions","11 -- Sample Type\n8\n.sampleType\n0\nIndicates type of samples used.  0 = time domain, 1 = frequency domain, 2-255 reserved.","Kevin Bross","Intel",null,null,"see new baseline coming - needs dicussion.","2016.11.15, 09:29"]
[159,"TF3","Resolved","Accept","None",null,"Technical","Yes",30,null,6.8,0,"Add parameter for sample width (where applicable).","12 -- Sample Width\n8\n.sampleWidth\n16\nWhen I/Q samples are used, this indicates the width of each sample in bits.  By default, 16-bit I and 16-bit Q width is assumed.","Kevin Bross","Intel",null,null,"Add sample width parameter for native mode. Same number of bits for I&Q.\r\nAlways packed. (add to 3.5)\r\n","2016.10.27, 15:42"]
[160,"TF3","Withdrawn","None","None",null,"Technical","Yes",30,null,6.8,0,"Add parameter indicating if samples are packed or byte aligned","13 -- Sample Packing\n2\n.samplePacking\n0\nDefines whether I/Q samples are packed.  0 = byte-aligned (no packing), 1 = nibble-aligned, 2 = packed, 3 = reserved.","Kevin Bross","Intel",null,null,"containers have variable bit width etc. Covered in previous comment (packing)\r\n\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:42","2016.10.27, 15:43"]
[161,"TF3","Withdrawn","None","None",null,"Technical","Yes",30,null,6.8,0,"Add parameter indicating samples between I/Q interleaving","14 -- Sample Interleaving\n16\n.sampleInterleaving\n1\nIndicates the interleaving granularity of I/Q samples.  By default, 1 I sample is followed by 1 Q sample, then another I sample and another Q sample.  Increasing this number increases the number of consecutive I samples followed by the same number of Q samples.  0 = reserved (invalid).","Kevin Bross","Intel",null,null,"containers have variable bit width etc.\r\n**************\r\nComment withdrawn on 2016.10.27, at 15:43","2016.10.27, 15:43"]
[162,"TF3","Withdrawn","None","None",null,"Technical","Yes",30,null,6.9,13,"Shouldn't there be a source field here for the de-mapper?  There might be different parameters used for a given destination depending on the port from which this data is sourced,","<replicate Source Link from Table 6-4.>","Kevin Bross","Intel",null,null,"it's there but the order is different compared to mapper. previous comment resolution harmonizes them.\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:00","2016.10.27, 16:00"]
[163,"TF3","Withdrawn","None","None",null,"Technical","Yes",30,null,6.9,13,"Recommend combining §6.8 and §6.9 into one section that talks about mapper and de-mapper parameters together.  This avoids replicating text unnecessarily and helps keep both sections in synch (i.e., new parameters added to Table 6-4).  This also helps developers avoid issues from different parameter indexes for mapper vs. de-mapper.","<combine §6.9 text as needed into §6.8, rename to cover mapper/de-mapper parameters, and delete §6.9.>\n\n<If not accepted, need to replicate other new fields from Table 6-4 into Table 6-5.>","Kevin Bross","Intel",null,null,"We did have it like this and then it was suggested to split them. Im aware there is some replication but it helps when we don't want sections the same...\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:01","2016.10.27, 16:01"]
[164,"TF3","Resolved","AIP","None",null,"Editorial","No",29,null,6.8,9,"Wherever possible, recommend keeping table intact on single page--don't allow it to break across pages.","<insert page break before or otherwise prevent table break across pages>","Kevin Bross","Intel",null,null,"fix for D2.0","2016.11.15, 09:09"]
[165,"TF3","Resolved","Accept","None",null,"Technical","Yes",32,null,7.1,22,"Remove CPRI-related wording.","<delete rest of paragraph after \"source stream.\">","Kevin Bross","Intel",null,null,"CHANGE\r\nFor a CPRI type source stream .lenPack reflects the number of individual CPRI Basic Frames (BF). The mapper does not de-interleave the I/Q samples. As part of the decoding the scrambling (when supported) shall also be undone\r\nTO\r\nFor a CPRI type source stream, the mapper does not de-interleave the I/Q samples. Likewise, as part of the decoding, the scrambling (when supported) shall also be undone.","2016.10.27, 17:45"]
[166,"TF3","Resolved","Accept","None",null,"Editorial","Yes",32,null,7.1,29,"Remove sentence fragment.","<delete rest of paragraph after \"link.\">","Kevin Bross","Intel",null,null,"yes (looks like an old title)","2016.10.13, 00:27"]
[167,"TF3","Incomplete","AIP","None",null,"Technical","Yes",33,null,"7.1.2.3",18,"Parenthetical example is unclear; there's a logical jump to .seqNumPMax that is not obvious.  There are also some assumptions in the earlier part of this sentence that may not always be true (around counter wrapping).","<not sure how to rework this>","Kevin Bross","Intel",null,null,"thats two of us :)","2016.11.15, 09:31"]
[168,"TF3","Resolved","Accept","None",null,"Technical","Yes",33,null,"7.1.2.3",19,"Add comma, make increment normative.","When the p-counter wraps, the sequence number q-counter shall increment by 1.","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 15:09"]
[169,"TF3","Incomplete","AIP","None",null,"Technical","Yes",33,null,"7.1.2.3",21,"Should specify the mandatory values from Table 4-3 for sequence number if we want to have them be consistent.  I think Jouni wanted the q counter to be 12 bits, but I think we should provide a list of the rest of the mandatory parameters from Table 4-3 here.","<add mandatory values from Table 4-3 here (similar to what is done in §7.2.7).  Be sure hex values align with the bit width.>","Kevin Bross","Intel",null,null,"not sure I follow, please suggest text.","2016.11.15, 09:31"]
[170,"TF3","Resolved","Accept","None",null,"Editorial","No",33,null,"7.1.2.5",28,"Add comma","stream, with the exception","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:27"]
[171,"TF3","Resolved","Accept","None",null,"Editorial","No",33,null,"7.1.2.5",29,"Throughout, should we use \"8b/10b\" instead of \"8b10b\"?","8b/10b <throughout doc, except in parameter names>","Kevin Bross","Intel",null,null,"ok","2016.11.15, 09:10"]
[172,"TF3","Proposed","AIP","None",null,"Technical","Yes",33,null,"7.1.2.5",29,"Structure-agnostic mode, not tunneled mode.","In structure-agnostic mode","Kevin Bross","Intel",null,null,"suggest this, change \r\n'The payload contains all the contents of the source stream with the exception of the 8b10b line coding information in 8b10b aware mode. In tunneled mode, the entire payload data shall be comprised of the binary stream of bits without interpretation.'\r\nto\r\n'A structure-agnostic packet can have two payload types. When 8b10b aware mode is off (simple tunneling mode), the entire payload data shall be comprised of the binary stream of bits without interpretation. When 8b10b aware mode is enabled, the payload contains all the contents of the source stream with the exception of the 8b10b line coding information.' \r\n\r\n","2016.11.15, 09:29"]
[173,"TF3","Resolved","Reject","None",null,"Technical","Yes",33,null,"7.1.2.5",30,"Need to explain how K-characters are used.","In CPRI rates 1-7, the start of frame is indicated by a K28.5 character.  This 10-bit character has no simple 8-bit value.  When the K28.5 is encountered by the mapper, the following shall occur:\n  1.  The previous packet shall be terminated so that the K28.5 character always aligns at the start of the RoE payload of the next packet.\n  2.  In the next packet, the character 0xCB shall be placed as the first character in the RoE payload, and the SoF flag in the sequence number field shall be set.\nConversely, when the de-mapper encounters the SoF flag set in the sequence number and 0xCB as the first character of the payload, the de-mapper shall insert a K28.5 character in place of the 0xCB character.","Kevin Bross","Intel",null,null,"needs dicussion, I dont think we were mandating that the packet is terminated upon k28.5. We certainly dont when we are not 8b10b aware.","2016.11.15, 08:13"]
[174,"TF3","Resolved","Reject","None",null,"Technical","Yes",33,null,"7.1.2.5",30,"Do we want to do anything with any other K-characters in 8b/10b mode?","<TBD>","Kevin Bross","Intel",null,null,"i dont think we can.... (even if they came - which they dont in CPRI)","2016.11.15, 08:14"]
[175,"TF3","Postponed","Reject","None",null,"Technical","Yes",33,null,"7.1.2.5",30,"If we add 64b/66b support, we need to define how to handle SoF and any other K-characters that will be part of stream.  This will affect multiple bytes of the output stream.","<TBD>","Kevin Bross","Intel",null,null,"No k-characters in 64b66b. I'm hoping Jouni has SoF covered in his baseline....","2016.11.15, 08:14"]
[176,"TF3","Resolved","Accept","None",null,"Technical","Yes",34,null,"7.1.2.5",1,"LSB in lower left should be MSB.","MSB","Kevin Bross","Intel",null,null,"editorial - yes","2016.10.27, 15:09"]
[177,"TF3","Resolved","Accept","None",null,"Technical","Yes",34,null,"7.1.2.5",1,"In the structure-agnostic mode, the mapper should NOT be interpreting any of the characters, so it shoudn't even know what these values are--it should be black box binary data to the mapper/de-mapper.","<Suggest moving p.33/l31 through p.34/l4 to an appendix; may also want to shift green bits to be white on black so that gradations show up better on B&W/grayscale printout.>","Kevin Bross","Intel",null,null,"Agreed. It is NOT interpreting. Perhaps the figure title is missleading. Change to \r\n'Example of how a CPRI basic frame appears in a structure agnostic packet'\r\n\r\nI'm fine with moving it to appendix...\r\n\r\nI'm fine with someone else trying to remove colors....","2016.10.27, 17:48"]
[178,"TF3","Proposed","AIP","None",null,"Editorial","No",34,null,7.2,6,"\"constructed to and from basic frames\"?","<not sure what is meant>","Kevin Bross","Intel",null,null,"change \"constructed to and from basic frames\"\r\nto \"constructed in to and deconstructed from basic frames\"","2016.11.15, 09:29"]
[179,"TF3","Resolved","Reject","None",null,"Technical","Yes",34,null,7.2,9,"Does a complete CPRI basic frame always fit in one packet???","<TBD>","Kevin Bross","Intel",null,null,"Well, it will be split into containers. I guess you could just have one huge container but i still think it would fit into a packet. One can always set the parameters so the whole thing falls over, but i don't think we need to specify against this.\r\nMaybe we need more text here? Please propose or withdraw.","2016.11.15, 08:14"]
[180,"TF3","Resolved","Accept","None",null,"Editorial","No",34,null,"7.2.1",20,"Improve readability","The .flowID identifies the RoE mapper/de-mapper to which this container belongs.","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:30"]
[181,"TF3","Resolved","Accept","None",null,"Editorial","Yes",34,null,"7.2.1",21,"\"equals to\" → \"equates to\"","equates to","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:30"]
[182,"TF3","Resolved","Accept","None",null,"Editorial","Yes",34,null,"7.2.1",21,"\"In a case flowID\", add comma","If the flowID is set to NIL, the","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:30"]
[183,"TF3","Incomplete","None","None",null,"Technical","Yes",34,null,"7.2.1",24,"Move trailing phrase up","per container (not including .lenSkip).  <remove note at end of paragraph>","Kevin Bross","Intel",null,null,"? dont understand","2016.11.15, 09:31"]
[184,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.1",4,"\"in a same way\"","in the same way","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:30"]
[185,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.1",7,"Improve readability","input container, set the modulo to 2 and set the index","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:30"]
[186,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.1",8,"Add comma","modulo logic, set","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:30"]
[187,"TF3","Incomplete","AIP","None",null,"Technical","Yes",35,null,"7.2.1",8,"What happens if the modulo is set to 1?","<address in text and in Table 7-1>","Kevin Bross","Intel",null,null,"not much. Please propose text","2016.11.15, 09:31"]
[188,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.1",10,"Simplify","per direction; there may be","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:31"]
[189,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.1",12,"\"roughly\" → \"rough\"","describe rough equivalents","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:31"]
[190,"TF3","Incomplete","AIP","None",null,"Technical","Yes",35,null,"7.2.2.5",27,"This is a big open to have at this time…","<TBD>","Kevin Bross","Intel",null,null,"it is","2016.11.15, 09:31"]
[191,"TF3","Resolved","AIP","None",null,"Technical","Yes",36,null,"7.2.2.5",7,"If the control word mapping is not shown, then why have the figure?","<Amend figure to have control words and I/Q data shown in (c)>","Kevin Bross","Intel",null,null,"They are not shown because they go over regular ethernet. Suggest changing \r\n'The control word mapping into RoE control packets (bytes XZ.X.0, Z.X.1, etc.,) are not shown.'\r\nto\r\nThe control word mapping into RoE control packets (bytes XZ.X.0, Z.X.1, etc.,) are not sent within RoE structure aware data packets. See sub-clauses 7.2.3-8.","2016.10.27, 17:49"]
[192,"TF3","Resolved","Accept","None",null,"Technical","Yes",36,null,"7.2.2.5",9,"Lower LSB in both cases is incorrect","MSB <2x>","Kevin Bross","Intel",null,null,"editorial - yes","2016.10.27, 15:09"]
[193,"TF3","Withdrawn","None","None",null,"Technical","Yes",36,null,"7.2.2.5",9,"Why is word 15 populated on right side but not on left?","<populate both word 15's?>","Kevin Bross","Intel",null,null,"its just an example\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:08","2016.10.27, 16:08"]
[194,"TF3","Incomplete","AIP","None",null,"Editorial","No",36,null,"7.2.2.5",9,"Green/olive boxes not sufficiently differentiated if printed B&W/grayscale","<consider making olive boxes black with white text to better differentiate>","Kevin Bross","Intel",null,null,"buy a color printer :)\r\nI tried (briefly) to make good in B&W but gave up...","2016.11.15, 09:31"]
[195,"TF3","Resolved","AIP","None",null,"Editorial","No",36,null,"7.2.3",14,"Consistently spell hyperframe throughout document (although CPRI spec is inconsistent)","<replace throughout document>","Kevin Bross","Intel",null,null,"ok","2016.11.15, 09:11"]
[196,"TF3","Resolved","Accept","None",null,"Editorial","No",36,null,"7.2.3",15,"Improve readability","and the sub-channels to which they (typically) refer.","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:33"]
[197,"TF3","Resolved","AIP","None",null,"Editorial","No",36,null,"7.2.3",17,"Do not break tables across pages (unless longer than 1 page)","<insert page break before or otherwise prevent table break across pages>","Kevin Bross","Intel",null,null,"will do for d2.0","2016.11.15, 09:12"]
[198,"TF3","Resolved","AIP","None",null,"Technical","Yes",37,null,"7.2.4",28,"Explain how (a) and (b)  are re-constituted at the other end if not parameterized.","<TBD>","Kevin Bross","Intel",null,null,"change \r\n'The control process extracts L1 protocol fields c to f and populates them into the CPRI parameter list shown in Table 6 3.'\r\nto\r\n'The control process extracts L1 protocol fields c to f and populates them into the CPRI parameter list shown in Table 6 3. Fields a & b are implicit in the usage of timingInfo.'","2016.10.27, 17:49"]
[199,"TF3","Resolved","Reject","None",null,"Technical","Yes",38,null,"7.2.5",7,"Is Fast C&M always in a fixed position?  Ns = p in figure seems to indicate it's not always in fixed position.  Also, is it clear how to reconstitute this back into the stream if you want to re-create the CPRI stream at the other end?","<TBD>","Kevin Bross","Intel",null,null,"it always starts in the same position but depending on the ethernet rate supported, it will end in a different position - set by p. It is possible to reconstruct - so long as you don't change the rate.\r\n\r\n","2016.11.15, 08:14"]
[200,"TF3","Resolved","Reject","None",null,"Technical","Yes",38,null,"7.2.6",21,"Should not use the NIL value for flowID.  Imagine if you have 10 different CPRI links and want to have different Slow C&M data for each…","<need to make sure it uses a specific flowID>","Kevin Bross","Intel",null,null,"Yes, it uses NIL.  end points are assumed","2016.11.15, 08:16"]
[201,"TF3","Incomplete","AIP","None",null,"Technical","Yes",40,null,"7.2.8",17,"May want to explain if this is a specific RoE packet that is generated on each hyperframe.  At CPRI rate 7, there will be 64 KB of 8b data per each hyperframe, so there won't be only one RoE packet per hyperframe if the data is full.  Even CPRI rate 1 will typically generate multiple packets per hyperframe.","<I'm not sure I understand the drive for the filtering options>","Kevin Bross","Intel",null,null,"? Jouni?","2016.11.15, 09:31"]
[202,"TF3","Resolved","AIP","None",null,"Technical","Yes",41,null,"7.2.8",13,"Recommend changing .offset, .value, and .mask to be more specific names","<use .cwOffset, .cwValue, and .cwMask to avoid generic label errors>","Kevin Bross","Intel",null,null,"fine with me","2016.10.27, 17:50"]
[203,"TF3","Resolved","Accept","None",null,"Editorial","Yes",42,null,"7.2.9",5,"Simplify","increments to cover 12-bit CPRI BFN.","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:33"]
[204,"TF3","Incomplete","AIP","None",null,"Technical","Yes",42,null,"7.2.9",6,"Should specify the mandatory values from Table 4-3 for sequence number if we want to have them be consistent.  I think Jouni wanted the q counter to be 12 bits, but I think we should provide a list of the rest of the mandatory parameters from Table 4-3 here.","<add mandatory values from Table 4-3 here (similar to what is done in §7.2.7).  Be sure hex values align with the bit width.>","Kevin Bross","Intel",null,null,"ok, help please","2016.11.15, 09:31"]
[205,"TF3","Postponed","AIP","None",null,"Technical","Yes",42,null,"7.3.1",12,"Add note.","Note that there are different sub types identified for time-domain data vs. frequency-domain data.","Kevin Bross","Intel",null,null,"need baseline approval","2016.11.15, 09:12"]
[206,"TF3","Resolved","AIP","None",null,"Technical","Yes",42,null,"7.3.2",14,"Include same text as §7.2.2?","<see §7.2.2.>","Kevin Bross","Intel",null,null,"jouni provided text","2016.11.15, 09:13"]
[207,"TF3","Resolved","AIP","None",null,"Technical","Yes",42,null,"7.3.3",16,"Include same text as §7.2.3?","<see §7.2.3>","Kevin Bross","Intel",null,null,"i think so","2016.10.27, 17:50"]
[208,"TF3","Resolved","Accept","None",null,"Technical","Yes",42,null,"7.3.5",22,"Indicate sample width, packing, and interleaving in the example.","how 15-bit samples of packed and interleaved I/Q data","Kevin Bross","Intel",null,null,"yes, add description","2016.10.27, 15:10"]
[209,"TF3","Resolved","Accept","None",null,"Editorial","No",42,null,"7.3.5",23,"Replace semicolon with colon","where:","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:34"]
[201,"TF3","Incomplete","AIP","None",null,"Technical","Yes",43,null,"7.3.6",2,"Containers are not necessarily part of native RoE.  This might have been a copy.  Should we define how this should be used for Native RoE?","<TBD>","Kevin Bross","Intel",null,null,"yes, its a copy paste. help please","2016.11.15, 09:31"]
[211,"TF3","Resolved","Accept","None",null,"Technical","Yes",44,null,"8.1.1",10,"Wrong table","Table 4-1.","Kevin Bross","Intel",null,null,"editorial - yes","2016.10.27, 15:10"]
[212,"TF3","Withdrawn","None","None",null,"Technical","Yes",44,null,"8.1.2",12,"Setting these flowIDs to be NIL seems like it wouldn't scale properly in a system that could be handling many interfaces/flows.","<should this be set to a specific flow ID?  Not sure>","Kevin Bross","Intel",null,null,"default is NIL, others can be specified in individual opCode descriptions (none so far though)\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:38","2016.10.27, 16:38"]
[213,"TF3","Resolved","Accept","None",null,"Technical","Yes",45,null,"8.1.7",7,"Adjust Figure 8-2 so that TLV information string length is 9 bits, not 17 bits.","<Adjust Figure 8-2 so that TLV information string length is 9 bits, not 17 bits.>","Kevin Bross","Intel",null,null,"yes","2016.10.27, 15:11"]
[214,"TF3","Proposed","Reject","None",null,"Editorial","No",45,null,"8.1.7",10,"If 802.1AB is in normative references, don't need full title here.","from IEEE Std 802.1AB™.  Figure 8-3","Kevin Bross","Intel",null,null,"its not normative and appears here for first time. style guru?","2016.10.13, 00:35"]
[215,"TF3","Incomplete","AIP","None",null,"Technical","Yes",45,null,"8.1.7",25,"Should we add an appendix showing TLV encoding for a spate of RoE parameters, such as the defaults in §7.2.7 or the agnostic or structure aware mapper sections?","<add appendix?>","Kevin Bross","Intel",null,null,"feel free :)","2016.11.15, 09:31"]
[216,"TF3","Incomplete","None","None",null,"Technical","Yes",46,null,"8.1.8",2,"Sample text provided, based on §8.1.7.","Ctrl_AxC packets use opCode=1 in the RoE control packet common frame format.","Kevin Bross","Intel",null,null,"?","2016.11.15, 09:31"]
[217,"TF3","Resolved","Accept","None",null,"Editorial","Yes",46,null,"8.1.8.1",3,"Wrong table level--should be peer to Ctrl_AxC opCode (§8.1.8).","Promote to §8.1.9","Kevin Bross","Intel",null,null,"yes, you mean heading level right?","2016.10.13, 00:37"]
[218,"TF3","Resolved","AIP","None",null,"Technical","Yes",46,null,"8.1.8",2,"Sample text provided, based on §8.1.7.","VSD packets use opCode=2 in the RoE control packet common frame format.","Kevin Bross","Intel",null,null,"Joni provided text","2016.11.15, 09:14"]
[219,"TF3","Resolved","Accept","None",null,"Editorial","Yes",46,null,"8.1.8.2",5,"Wrong table level--should be peer to Ctrl_AxC opCode (§8.1.8).","Promote to §8.1.10","Kevin Bross","Intel",null,null,"yes, you mean heading level right?","2016.10.13, 00:37"]
[220,"TF3","Resolved","AIP","None",null,"Technical","Yes",46,null,"8.1.8.2",13,"Need to explain how far in the past or in the future this timing packet applies.  The receiving end cannot maintain a perpetual track of packet timing.  Is this only to be applicable for packets that haven't been sent yet, packets that have been sent but haven't reached their presentation time, or purely after the fact?","<Perhaps indicate that the timing packet should be sent before the packet with that targetSeqnum is sent?>","Kevin Bross","Intel",null,null,"Add sentence along the lines - ' needs to be recieved ahead of time'","2016.11.15, 08:19"]
[221,"TF3","Incomplete","AIP","None",null,"Technical","Yes",46,null,"8.1.8.2",13,"May want to add some guidance text that this is not expected to alter the presentation time of a specific packet that has a sequence number; instead, it's intended to help the recipient adjust for relative clock slippage by correlating a sequence number to the expected presentation time.  The recipient can then use this information to adjust its data rate/clock for that flow, or to identify issues for OAM software to correct.","<see text at left>","Kevin Bross","Intel",null,null,"what text?","2016.11.15, 09:31"]
[222,"TF3","Resolved","Accept","None",null,"Technical","Yes",47,null,"A",10,"Annex A figures should be A-n (throughout).","Figure A-1","Kevin Bross","Intel",null,null,"yes. I tried. I failed.","2016.11.15, 08:19"]
[223,"TF3","Incomplete","AIP","None",null,"Technical","Yes",49,null,"A",19,"No normative text in any annex","The mapper must remove…The mapper must be aware","Kevin Bross","Intel",null,null,"Frankly, this section just got thrown to the back of the document as potentially useful. Jouni?","2016.11.15, 09:31"]
[224,"TF3","Incomplete","AIP","None",null,"Technical","Yes",50,null,"A",1,"No normative text in any annex, show that this is an example only","parameters would be set as follows for this example:","Kevin Bross","Intel",null,null,"Frankly, this section just got thrown to the back of the document as potentially useful. Jouni?","2016.11.15, 09:31"]
[225,"TF3","Proposed","AIP","None",null,"Editorial","Yes",53,null,"Z.Bibliography",2,"This should be listed under normative references","<don't know if it should be in Bibliography if in list of normative references>","Kevin Bross","Intel",null,null,"These references are playing their own game of tennis. Last time around we decided they should be here but I'll happily move them...","2016.11.15, 09:30"]
[226,"TF3","Proposed","AIP","None",null,"Editorial","Yes",53,null,"Z.Bibliography",7,"Is this redundant if it's in the list of normative references?","<don't know if it should be in Bibliography if in list of normative references>","Kevin Bross","Intel",null,null,"These references are playing their own game of tennis. Last time around we decided they should be here but I'll happily move them...","2016.11.15, 09:30"]
[227,"TF3","Withdrawn","None","None",null,"Technical","Yes",13,null,2,8,"Should we add text clearly indicating that shall, should, and may are normative terms (and what the implications are of for each)?  Should we also include shall not and should not in that text.","<can provide text if we want this>","Kevin Bross","Intel",null,null,"this is covered in a IEEE document\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:38","2016.10.27, 16:38"]
[228,"TF3","Resolved","AIP","None",null,"Editorial","No",13,null,2,9,"CPRI™ is first used on p.11/l33.","<Move TM footnote to p.11>","Kevin Bross","Intel",null,null,"ok","2016.11.15, 09:16"]
[229,"TF3","Resolved","Accept","None",null,"Technical","Yes",14,null,3,23,"Include French version of acronym?","<add \"(Temps Atomique International)\" to current explanation>","Kevin Bross","Intel",null,null,"fancy! ok","2016.10.27, 15:12"]
[230,"TF3","Resolved","Accept","None",null,"Technical","Yes",15,null,3.5,25,"32-bit parameters are commonly referred to as double-words (words are often 16 bits)","within a 32-bit double word","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 15:12"]
[231,"TF3","Resolved","Accept","None",null,"Technical","Yes",16,null,3.5,5,"32-bit parameters are commonly referred to as double-words (words are often 16 bits)","within a 32-bit double word","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 15:12"]
[232,"TF3","Resolved","Accept","None",null,"Editorial","Yes",17,null,4.0999999999999996,17,"\"pass-thru\" → \"pass-through\"","pass-through <3x>","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:41"]
[233,"TF3","Withdrawn","None","None",null,"Technical","Yes",18,null,"4.1.1",11,"Since RoE connections are point-to-point, all the various topologies are just sub-sets of the various topologies supported by Ethernet--and there are many others that can be shown as well.  I question whether this section truly adds value (or if it's merely mimicking the CPRI spec). ","All RoE connections are point-to-point.  They may include 0, 1, or more intermediate switches.  Any valid Ethernet topology can be supported, subject to the considerations described in clause 4.1.2.","Kevin Bross","Intel",null,null,"its mostly harmless...\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:39","2016.10.27, 16:41"]
[234,"TF3","Incomplete","AIP","None",null,"Technical","Yes",19,null,4.12,17,"Is item (g) essentially a subset of (d)?","<tighten up if redundant>","Kevin Bross","Intel",null,null,"ok. please propose text.","2016.11.15, 09:31"]
[235,"TF3","Resolved","Accept","None",null,"Technical","Yes",19,null,4.12,18,"The word \"delay\" is ambiguous; I think this means total transmission time.","The maximum one way transmission time has to be less than half of the available total transmission time.","Kevin Bross","Intel",null,null,"ok","2016.10.27, 15:13"]
[236,"TF3","Resolved","Accept","None",null,"Technical","Yes",19,null,"4.1.3",18,"Proposed text","The actual method and characteristics of synchronizing RoE nodes is out of scope, but methods such as GNSS/GPS and IEEE 1588v2 or later may be used to synchronize nodes.","Kevin Bross","Intel",null,null,"P19, L21. Add 'The actual method and characteristics of synchronizing RoE nodes is out of scope, but methods such as GNSS/GPS and IEEE 1588v2 or later may be used to synchronize nodes.'","2016.11.15, 09:16"]
[237,"TF3","Resolved","Accept","None",null,"Technical","Yes",20,null,"4.2.2",16,"Verbiage of \"a native RoE format\" is easily confused with the Native RoE mapper.","formats to an RoE framing format","Kevin Bross","Intel",null,null,"editorial - ok\r\n","2016.10.27, 15:14"]
[238,"TF3","Resolved","Reject","None",null,"Technical","Yes",21,null,4.3,21,"Add text about inter-packet gap.","Note that Ethernet usually requires an inter-packet gap of 12 octets between Ethernet packets.  This gap often becomes significant when figuring maximum throughput possible on a given Ethernet link.","Kevin Bross","Intel",null,null,"ok. No additional text required. See 802.3","2016.11.15, 08:21"]
[239,"TF3","Incomplete","AIP","None",null,"Technical","Yes",22,null,"4.4.2",11,"Need to clarify that the flowID is for a bi-directional link--the same flowID is used for the linked flow in both directions--right?","<TBD>","Kevin Bross","Intel",null,null,"well, in a given box, mapper flowIDs are allocated numerically, de-mappers are assigned.\r\nIt is however true that both ends of a given flow need to share the same flowID but I think this is obvious. Feel free to suggest additional text.","2016.11.15, 09:31"]
[240,"TF3","Resolved","Accept","None",null,"Editorial","No",23,null,"4.4.4.1",15,"\"constitutes of\" → \"consists of\"","consists of","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:41"]
[241,"TF3","Incomplete","AIP","None",null,"Editorial","Yes",24,null,"4.4.4.2",5,"Move reference plane wording","presentation of the information…share the same reference plane of the ToD","Kevin Bross","Intel",null,null,"?","2016.11.15, 09:32"]
[242,"TF3","Incomplete","AIP","None",null,"Technical","Yes",26,null,"5.1.1",9,"I like the fact that we have defined a common epoch (midnight, 1970-01-01).  That said, is it required that all RoE implementations use this as their epoch, or just that they have the same reference plane (see §4.4.4.2)?",null,"Kevin Bross","Intel",null,null,"in a private network it would probably work if they only had the same reference plane. Forcing the same epoch is more robust. I guess this could be optional in the PICs?","2016.11.15, 09:28"]
[243,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.6,9,"Since this section says nothing about encryption and compression, suggest removing the second sentence (that was probably in there from a early draft).","<remove second sentence:  \"Each…schemes.\">","Kevin Bross","Intel",null,null,"Agreed. Remove sentence 'Each link can be assigned one of 15 encryption and compression schemes'","2016.10.27, 16:41"]
[244,"TF3","Resolved","Accept","None",null,"Technical","Yes",28,null,6.8,21,"§7.2.1 says that a NIL flowID is for the control process, so only 255 mappers available.","up to 255 mappers","Kevin Bross","Intel",null,null,"ok","2016.10.27, 15:17"]
[245,"TF3","Resolved","Accept","None",null,"Technical","Yes",30,null,6.9,4,"§7.2.1 says that a NIL flowID is for the control process, so only 255 de-mappers available.","up to 255 de-mappers","Kevin Bross","Intel",null,null,"ok","2016.10.27, 15:17"]
[246,"TF3","Resolved","Accept","None",null,"Editorial","Yes",32,null,"7.1.2",36,"Expunge CPRI from section heading","Structure-agnostic data packet <with or without hyphen to be consistent with earlier change request>","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:43"]
[247,"TF3","Resolved","Accept","None",null,"Editorial","No",32,null,"7.1.2.1",38,"Add \"the\"","set to the value","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:43"]
[248,"TF3","Withdrawn","None","None",null,"Technical","No",33,null,"7.1.2.3",7,"Observation:  at one point, some members were advocating for the ability to use the OrderInfo field as a pointer into a buffer rather than an ordinal number.  This use case seems to have disappeared in the spec--fine by me, but I thought I'd mention it in case that was critical to somebody.","<no action needed unless somebody advocates for this usage>","Kevin Bross","Intel",null,null,"please dont...\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:41","2016.10.27, 16:41"]
[249,"TF3","Resolved","Accept","None",null,"Editorial","No",35,null,"7.2.2.1",17,"Add \"the\"","set to the value","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:43"]
[250,"TF3","Resolved","Accept","None",null,"Editorial","Yes",36,null,"7.2.2.5",11,"Add \"byte\" legend on (c), similar to (b).  Should we add bits as well, since 1023 is there?","<add \"byte\" legend>","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:44"]
[251,"TF3","Withdrawn","None","None",null,"Technical","Yes",38,null,"7.2.5",3,"The fast C&M packet is not just an Ethernet packet, it's an RoE packet","[appropriate] RoE packet","Kevin Bross","Intel",null,null,"no, its just an ethernet packet\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:42","2016.10.27, 16:42"]
[252,"TF3","Withdrawn","None","None",null,"Technical","Yes",38,null,"7.2.5",15,"The first field in the Ethernet payload should be the RoE header, not the Ethernet header","RoE header","Kevin Bross","Intel",null,null,"no, its the ethernet header\r\n**************\r\nComment withdrawn on 2016.10.27, at 16:42","2016.10.27, 16:42"]
[253,"TF3","Resolved","Accept","None",null,"Editorial","Yes",38,null,"7.2.5",17,"Naïve has a negative connotation (uninformed)","A simple example","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:44"]
[254,"TF3","Resolved","Accept","None",null,"Editorial","No",39,null,"7.2.6",2,"Misspelling","transporting","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:44"]
[255,"TF3","Resolved","Accept","None",null,"Editorial","No",40,null,"7.2.8",18,"Add comma","disabled), the","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[256,"TF3","Resolved","Accept","None",null,"Editorial","No",40,null,"7.2.8",21,"Add comma","set to 2, the","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[257,"TF3","Resolved","Accept","None",null,"Editorial","No",40,null,"7.2.8",22,"Improve readability","and is combined with .hfnIndex to allow selecting","Kevin Bross","Intel",null,null,"yes, better","2016.10.13, 00:45"]
[258,"TF3","Resolved","Accept","None",null,"Editorial","No",40,null,"7.2.8",24,"Add comma","For example,","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[259,"TF3","Resolved","Accept","None",null,"Technical","Yes",40,null,"7.2.8",25,"Unclear what \"current_HFN\" literally means in this context.  This term has not been introduced in this document.","<TBD>","Kevin Bross","Intel",null,null,"remove 'current_HFN'","2016.10.27, 16:44"]
[260,"TF3","Resolved","Accept","None",null,"Editorial","No",41,null,"7.2.8",1,"Add comma","set to 3, the the","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[261,"TF3","Resolved","Accept","None",null,"Editorial","No",42,null,"7.2.8",4,"Add comma","wraps, the","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[262,"TF3","Resolved","AIP","None",null,"Technical","Yes",42,null,"7.2.8",5,"Be more precise on when q wraps","shall wrap on the 4096th increment in order to cover the 12-bit CPRI BFN.","Kevin Bross","Intel",null,null,"editorial - yes, better. See previous comment (this is just an example)\r\nLoose the word 'shall'","2016.11.15, 08:23"]
[263,"TF3","Resolved","Accept","None",null,"Editorial","No",42,null,"7.3.1",12,"Add \"the\"","set to the value","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:45"]
[264,"TF3","Resolved","Accept","None",null,"Technical","Yes",43,null,"7.3.5",26,"Wrong bit value",48,"Kevin Bross","Intel",null,null,"editorial - yes","2016.10.27, 15:19"]
[265,"TF3","Resolved","Accept","None",null,"Editorial","No",43,null,"7.3.5",27,"Add \"byte\" legend on (c), similar to (b).  Should we add bits as well, since 64 is there?","<add \"byte\" legend>","Kevin Bross","Intel",null,null,"yes","2016.10.13, 00:46"]
[266,"TF3","Proposed","Accept","None",null,"Technical","Yes",44,null,"8.1.3",15,"Didn't we agree that control packets will always use sequence number so that you can easily tell when a (sporadic) control packet is lost?","Control packets shall always use a sequence number for their orderInfo field.","Kevin Bross","Intel",null,null,"yes, i believe so","2016.11.15, 09:30"]
[267,"TF3","Resolved","AIP","None",null,"Technical","Yes",44,null,"8.1.3",18,"Should specify the mandatory values from Table 4-3 for sequence number if we want to have them be consistent.  I think Jouni wanted the q counter to be 12 bits, but I think we should provide a list of the rest of the mandatory parameters from Table 4-3 here.","<add mandatory values from Table 4-3 here (similar to what is done in §7.2.7).  Be sure hex values align with the bit width.>","Kevin Bross","Intel",null,null,"please propose text. \r\nFollow same section structure\r\nLook at 7.2.7 'shall' too","2016.11.15, 08:24"]
[268,"TF3","Resolved","Accept","None",null,"Technical","Yes",45,null,"8.1.7",9,"Text should correlate with verbiage in Figure 8-3","value (the TLV information string).","Kevin Bross","Intel",null,null,"editorial - ok","2016.10.27, 15:19"]
[269,"TF3","Resolved","Accept","None",null,"Editorial","No",45,null,"8.1.7",10,"\"reused from\" → \"defined in\"","defined in","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:46"]
[270,"TF3","Resolved","Accept","None",null,"Editorial","No",49,null,"A",21,"There should be a space between numbers and units","10 ms","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:46"]
[271,"TF3","Resolved","Accept","None",null,"Technical","Yes",49,null,"A",25,"I think .lenPack is now going to always be in octets","worth of octets and then","Kevin Bross","Intel",null,null,"yes","2016.10.27, 17:58"]
[272,"TF3","Incomplete","AIP","None",null,"Technical","Yes",50,null,"A",1,"The nomenclature should be explicitly defined.","<explain what multiple numbers (separated by commas) between square brackets means>","Kevin Bross","Intel",null,null,"please propose text","2016.10.27, 17:59"]
[273,"TF3","Resolved","Accept","None",null,"Editorial","Yes",52,null,"C",1,"This isn't really pseudo code ","Example C code for handling sequence numbers","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:46"]
[274,"TF3","Resolved","Accept","None",null,"Technical","Yes",53,null,"Z.Bibliography",12,"Add reference for IEEE 1588v2?","<add IEEE Std 1588>, along with URL:  https://standards.ieee.org/findstds/standard/1588-2008.html","Kevin Bross","Intel",null,null,"Add to Biblography","2016.10.27, 18:01"]
[275,"TF3","Resolved","Accept","None",null,"Editorial","Yes",53,null,"Z.Bibliography",7,"Add URL for 802.3","<include https://standards.ieee.org/about/get/802/802.3.html>","Kevin Bross","Intel",null,null,"ok","2016.10.13, 00:46"]
[276,"TF3","Resolved","Accept","None",null,"Technical","Yes",13,null,2,8,"Add 802.3 to list of normative references","<get from bibliography>","Kevin Bross","Intel",null,null,"move as normative","2016.10.27, 18:02"]
[null,null,null,null,"None",null,null,null,null,null,null,null,null,null,null,null,null,null,null,"2016.10.10, 12:20"]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]
[null,null,null,null,null,null,null,null,null,""]

{"sheet":"Sheet1","index":1,"n_rows":6,"n_cols":2,"rows_kept":6,"cut":false,"hidden":false,"merged":[]}
["Incomplete",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A1)","v":22}]
["Postponed",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A2)","v":9}]
["Withdrawn",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A3)","v":22}]
["Proposed",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A4)","v":7}]
["Resolved",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A5)","v":215}]
["Withdrawn",{"$f":"COUNTIF(D1.2!C$3:C$300,Sheet1!A6)","v":22}]

{"sheet":"Stats","index":2,"n_rows":37,"n_cols":7,"rows_kept":37,"cut":false,"hidden":false,"merged":[]}
[null,"E","ER","T","TR",null,"Totals"]
[0,{"$f":"get_Stats($A2,B$1)","v":0},0,0,0,{"$f":"get_TF_assignment(A2)","v":"WG"},{"$f":"SUM(B2:F2)","v":0}]
[99,0,0,0,0,"WG",{"$f":"SUM(B3:F3)","v":0}]
[1,{"$f":"get_Stats($A4,B$1)","v":0},{"$f":"get_Stats($A4,C$1)","v":0},0,0,{"$f":"get_TF_assignment(A4)","v":"WG"},{"$f":"SUM(B4:E4)","v":0}]
[2,0,0,0,0,"WG",0]
[3,0,0,0,0,"WG",0]
[4,0,0,0,0,"WG",0]
["4A",0,0,0,0,"TF5",{"$f":"SUM(B8:E8)","v":0}]
["4B",0,0,0,0,"TF5",0]
["4C",0,0,0,0,"TF5",0]
[5,0,0,0,0,"WG",0]
["5A",0,0,0,0,"WG",0]
[6,0,0,0,0,"TF1",0]
[7,0,0,0,0,"TF1",0]
["7A",0,0,0,0,"TF1",0]
[8,0,0,0,0,"TF2",0]
[9,0,0,0,0,"TF3",0]
["9A",0,0,0,0,"TF3",0]
["9B",0,0,0,0,"TF3",0]
[10,0,0,0,0,"TF3",0]
["10A",0,0,0,0,"TF3",0]
[11,0,0,0,0,"TF4",0]
[12,0,0,0,0,"TF4",0]
[13,0,0,0,0,"TF4",0]
["13A",0,0,0,0,"TF4",0]
[14,0,0,0,0,"TF4",0]
[null,null,null,null,null,null,{"$f":"SUM(G2:G26)","v":0}]
["Totals",{"$f":"SUM(B2:B26)","v":0},{"$f":"SUM(C2:C26)","v":0},{"$f":"SUM(D2:D26)","v":0},{"$f":"SUM(E2:E26)","v":0},{"$f":"SUM(B28:E28)","v":0},{"$f":"IF(F28=G27,\"OK\",\"ERROR\")","v":"OK"}]
[]
["TFs","WG","TF1","TF2","TF3","TF4","TF5"]
["All",{"$f":"SUM(G2:G7,G11:G12)","v":0},{"$f":"SUM(G13:G15)","v":0},{"$f":"SUM(G16)","v":0},{"$f":"SUM(G17:G21)","v":0},{"$f":"SUM(G22:G26)","v":0},{"$f":"SUM(G8:G10)","v":0}]
["E",{"$f":"SUM(B2:B7,B11:B12)","v":0},{"$f":"SUM(B13:B15)","v":0},{"$f":"SUM(B16)","v":0},{"$f":"SUM(B17:B21)","v":0},{"$f":"SUM(B22:B26)","v":0},{"$f":"SUM(B8:B10)","v":0}]
["ER",{"$f":"SUM(C2:C7,C11:C12)","v":0},{"$f":"SUM(C13:C15)","v":0},{"$f":"SUM(C16)","v":0},{"$f":"SUM(C17:C21)","v":0},{"$f":"SUM(C22:C26)","v":0},{"$f":"SUM(C8:C10)","v":0}]
["T",{"$f":"SUM(D2:D7,D11:D12)","v":0},{"$f":"SUM(D13:D15)","v":0},{"$f":"SUM(D16)","v":0},{"$f":"SUM(D17:D21)","v":0},{"$f":"SUM(D22:D26)","v":0},{"$f":"SUM(D8:D10)","v":0}]
["TR",{"$f":"SUM(E2:E7,E11:E12)","v":0},{"$f":"SUM(E13:E15)","v":0},{"$f":"SUM(E16)","v":0},{"$f":"SUM(E17:E21)","v":0},{"$f":"SUM(E22:E26)","v":0},{"$f":"SUM(E8:E10)","v":0}]
["E+ER",{"$f":"SUM(B32:B33)","v":0},{"$f":"SUM(C32:C33)","v":0},0,0,0,0]
["T+TR",{"$f":"SUM(B34:B35)","v":0},{"$f":"SUM(C34:C35)","v":0},0,0,0,0]

{"sheet":"Status change flow","index":4,"n_rows":6,"n_cols":2,"rows_kept":6,"cut":false,"hidden":false,"merged":[[1,0,1,1]]}
[]
["Legend"]
[]
["CS","Comment Status"]
["CC","Commenter Satisfaction"]
["RS","Response Status"]

{"sheet":"Parameters","index":5,"n_rows":50,"n_cols":8,"rows_kept":50,"cut":false,"hidden":true,"merged":[]}
[10000,"TF1","New","AIP","Satisfied","Technical","Yes",50]
[null,"TF2","Incomplete","Accept","Unsatisfied","Editorial","No",49]
[null,"TF3","Postponed","Reject",null,null,null,48]
[null,"TF4","Resolved",null,null,null,null,47]
[null,"WG","Withdrawn",null,null,null,null,46]
[null,null,"Proposed",null,null,null,null,45]
[null,null,"Closed",null,null,null,null,44]
[null,null,null,null,null,null,null,43]
[null,null,null,null,null,null,null,42]
[null,null,null,null,null,null,null,41]
[null,null,null,null,null,null,null,40]
[null,null,null,null,null,null,null,39]
[null,null,null,null,null,null,null,38]
[null,null,null,null,null,null,null,37]
[null,null,null,null,null,null,null,36]
[null,null,null,null,null,null,null,35]
[null,null,null,null,null,null,null,34]
[null,null,null,null,null,null,null,33]
[null,null,null,null,null,null,null,32]
[null,null,null,null,null,null,null,31]
[null,null,null,null,null,null,null,30]
[null,null,null,null,null,null,null,29]
[null,null,null,null,null,null,null,28]
[null,null,null,null,null,null,null,27]
[null,null,null,null,null,null,null,26]
[null,null,null,null,null,null,null,25]
[null,null,null,null,null,null,null,24]
[null,null,null,null,null,null,null,23]
[null,null,null,null,null,null,null,22]
[null,null,null,null,null,null,null,21]
[null,null,null,null,null,null,null,20]
[null,null,null,null,null,null,null,19]
[null,null,null,null,null,null,null,18]
[null,null,null,null,null,null,null,17]
[null,null,null,null,null,null,null,16]
[null,null,null,null,null,null,null,15]
[null,null,null,null,null,null,null,14]
[null,null,null,null,null,null,null,13]
[null,null,null,null,null,null,null,12]
[null,null,null,null,null,null,null,11]
[null,null,null,null,null,null,null,10]
[null,null,null,null,null,null,null,9]
[null,null,null,null,null,null,null,8]
[null,null,null,null,null,null,null,7]
[null,null,null,null,null,null,null,6]
[null,null,null,null,null,null,null,5]
[null,null,null,null,null,null,null,4]
[null,null,null,null,null,null,null,3]
[null,null,null,null,null,null,null,2]
[null,null,null,null,null,null,null,1]

{"sheet":"Values","index":6,"n_rows":25,"n_cols":7,"rows_kept":25,"cut":false,"hidden":true,"merged":[]}
["None","None","WG","None","Technical","Yes",0]
["New","AIP","TF1","Satisfied","Editorial","No",1]
["Proposed","Accept","TF2","Unsatisfied",null,null,2]
["Postponed","Reject","TF3","TBD",null,null,3]
["Incomplete",null,"TF4",null,null,null,4]
["Withdrawn",null,"TF5",null,null,null,"4A"]
["Resolved",null,null,null,null,null,"4B"]
[null,null,null,null,null,null,"4C"]
[null,null,null,null,null,null,5]
[null,null,null,null,null,null,"5A"]
[null,null,null,null,null,null,6]
[null,null,null,null,null,null,7]
[null,null,null,null,null,null,"7A"]
[null,null,null,null,null,null,8]
[null,null,null,null,null,null,9]
[null,null,null,null,null,null,"9A"]
[null,null,null,null,null,null,"9B"]
[null,null,null,null,null,null,10]
[null,null,null,null,null,null,"10A"]
[null,null,null,null,null,null,11]
[null,null,null,null,null,null,12]
[null,null,null,null,null,null,13]
[null,null,null,null,null,null,"13A"]
[null,null,null,null,null,null,14]
[null,null,null,null,null,null,99]