zilongwang/ReadingBank huggingface dataset:
CID Page Clause Comment Proposed Change Resolution 2442 158.34 22.3.11.4.1.2 Add limits for i As in comment AGREE IN PRINCIPLE. See 11/1190r0. Discussion: On top of adding the limits for i, we should also add the user index u. Proposed Text Changes: 22.3.10.5.1.2 Binary convolutional coding and puncturing Change P179L4 (D1.1) as follows: The encoder parser output sequences , will each be encoded by a rate R = ½ convolutional encoder defined in 17.3.5.6 (Convolutional encoder). CID Page Clause Comment Proposed Change Resolution 3035 200.48 22.4.4 The VHT PHY characterisitcs for aPPDUMaxTime is inherited from Table 19-25 (MIMO PHY Characteristics) and has the value 10ms. However, given that the LSIG LENGTH can hold only max value of 4095, the max duration of the PPDU is approximately 5.46milli seconds Define aPPDUMaxTime for VHT PHY keeping in mind that the LSIG LENGTH field is used for TXTIME indication AGREE IN PRINCIPLE. See 11/1190r0. Discussion: Max. L-SIG length = 212 - 1 = 4095 bytes Max. duration in time after L-SIG = (4095 + 3) bytes / 3 bytes/symbol * 4 us/symbol = 5.464 ms Max. PPDU duration = 20 us (L-STF + L-LTF + L-SIG) + 5.464 ms = 5.484 ms Hence, aPPDUMaxTime for a VHT PHY should be set to 5.484 ms. Proposed Text Changes: Change 22.4.4 (D1.1) as follows: 22.4.4 PHY characteristics The static VHT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 19-25 (MIMO PHY characteristics) unless otherwise listed in Table 22-24 (VHT PHY characteristics). The definitions for these characteristics are given in 6.5 (PLME SAP interface). Table 22-24 – VHT PHY characteristics Characteristics Value aCCAMidTime < 25 us
IEEE P802.11 Wireless LANs Comment Resolution for CID2950, 3654 Date: 2011-09-14 Author(s): Name Affiliation Address Phone Email Sun Bo ZTE Corporation ZTE Building, #10. Sth Tangyan Rd., Xi’an, China 86 29 88723410 Sun.bo1@zte.com.cn Abstract This document provides resolution for the comments listed below Comments are from: 11-11-0907-0x-00ac-lb178-comments-tgac-d1-0.xlsx Comments refer to: Draft P802.11ac_D1.0.pdf Comments 2950 92/42 9.30.5 Since a VHT Compressed Beamforming frame may be split into segments, when the beamformer fails to receive some of the segments, it should be clarified if segments correctly received could be considered as a valid response to the NDPA or Beamforming Report Poll. Suggest to modify as follows:A VHT Compressed Beamforming frame sent received as a response to the NDPA, or at least one segment received as a response to the NDPA when the VHT Compressed Beamforming frame is segmented ,SIFS time after the NDP, is considered a valid response to the NDPA in the terms used in AGREE. Modify the spec text as suggested in 11/1193 MU
invalid states) 8 C.3 There's a number of "phyType" variables in the MIB (e.g. in the TGk parts). It's nice that .11ac have chosen to update one of them, but it would be nicer if they did them all. Search through the baseline MIB and determine any "phyType" variables and update them. P – Extend all phyType variables by adding “vht(9)”. 9 C.3 "represented by the octet index." - well it's type is an octet string, so they are not accessible in any indexed fashion. Ditto at 230.36. Replace with, "The octet represents stream 1, and so on." A – As suggested 1 C.3 I see BFer here but MIB variable name includes BFee (copy/paste error?) Harmonize D – BFer here refers to number of tx antennas at the beamformer that the beamformee supports. It’s a beamformee capability. 16 C.3 In what's the meaning of having it writable by an external management entity? Surely you don't want SNMP to come and arbitrarily write values here. The for writing this is not clear. It is either the MLME or SME, but certainly not an external entity. A – Change access on dot11CurrentChannelBandwidth, and to read-only. 19
> DESCRIPTION > "This is a capability variable. > Its value is determined by device capabilities. > > This attribute, when true, indicates that the device is capable of receiving 80 MHz short guard interval packets." > DEFVAL { } > ::= { dot11PhyVHTEntry 5 } > > dot11VHTShortGIOptionIn80Activated OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This is a capability variable. > Its value is determined by device capabilities. > > This attribute, when true, indicates that the reception of 80 MHz short guard interval packets is enabled." > DEFVAL { } > ::= { dot11PhyVHTEntry 6 } > > dot11VHTShortGIOptionIn160and80p80Implemented OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is a capability variable. > Its value is determined by device capabilities. > > This attribute, when true, indicates that the device is capable of receiving 160 MHz and 80+80 MHz short guard interval packets." > DEFVAL { false } > ::= { dot11PhyVHTEntry 7 } > > dot11VHTShortGIOptionIn160and80p80Activated OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS > STATUS current > DESCRIPTION > "This is a capability variable. > Its value is determined by device capabilities. > > This attribute, when true, indicates that the reception of 160 MHz and 80+80 MHz short guard interval packets is enabled." > DEFVAL { } > ::= { dot11PhyVHTEntry 8 } > > dot11VHTLDPCCodingOptionImplemented OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is a capability variable. > Its value is determined by device capabilities. >
IEEE P802.11 Wireless LANs Comment Resolution for LB 178 (D1.0): resolutions for comments on 8.5.16.4 Date: 15 September 2011 Author(s): Name Affiliation Address Phone email Robert Stacey Apple rstacey@apple.com Comments CID Page Line Clause Comment Proposed Change Resolution 3478 64.32 32 8.5.16.4 AP behavior using this frame should be described in a normative section. Move statement to 10.25. Also, expand: why is broadcast restricted to AP? Broadcast should not be the only option, in some situations, unicast might be better, for example, AP that has a single client. P – Text changed to give AP option of using broadcast or unicast. There is no restriction on a STA using broadcast, however, this is not explicitly called out. See text changes in 11/1217r0
Item Date Assigned Owner Description Due Date Status 1 Nov. 11, 2013 Mike Harkins Determine the financial results of the Fall Conference. Education Committee Meeting date New 2 Nov. 11, 2013 Scott Berman Review results of conference survey. Education Committee Meeting date New 3 Nov. 11, 2013 Antunano Call meeting of education committee (dinner meeting) to review above survey. Also, make preliminary plans / ideas regarding next year’s event after reviewing learnings from this event. Dec. 6, 2013 (tentative) New 4 Nov. 11, 2013 Cindi Manning a message from the Chair for the December newsletter. Coordinate due date with newsletter editor. New 5 Nov. 11, 2013 AJ and Cindi Update list of new people for the new year. (name changes) After December dinner meeting New 6 Nov. 11, 2013 Todd Minnick Determine if a logo bag or memory drive, or something of that type is useful as a gift for chairs in December. This week New 7 Nov. 11, 2013 Francisco Russi Prepare certificates for December meeting Recertification Units for committee chairs and officers serving until Dec., 2013. Dec. 11, 2013 New 8 Nov. 11, 2013 Cindi Manning Prepare and plan for a planning session ion preparation for the upcoming year. Dec. 11, 2013 New Item Date Assigned Owner Description Due Date Status 1 Oct. 7, 2013 Francisco Russi Get equipment for October Workshop from ASQ storage. Norma will provide the list of items needed. Oct. 12, 2013 Complete 2 Oct. 7, 2013 Norma Antunano Ask ACC to sign our contract and get a signed copy for our records. December 11, 2013 In progress 3 Oct. 7, 2013 All board members Fill out member leader engagement survey October 11, 2013 Complete 4 Oct. 7, 2013 Cindi and Sherry Determine rules around the use of a credit card with HQ. December 31, 2013 In progress
5 October 26, 2013 Mike Harkins Added after meeting: Obtain two projectors for section use: Approved by elected officers. Mike Harkins obtained the selected projectors and will bring to next month’s board meeting November 11, 2013 Complete 4 Aug. 19, 2013 A.J. Scotka Investigate if we should offer a sponsorship program with listings of events, etc. for profit and nonprofit organizations. Form a committee to render a proposal to the board. Take to board in January. Current agreements will remain through January, 2014. Dec., 2013 In progress 5 Aug. 19, 2013 Tony Perez, Francisco Russi Set up an audit in January for ASQ Austin treasury. Tony will call the audit meeting. Dec., 2013 In progress 6 Aug. 19, 2013 Sherry Popiolek Venue for Holiday banquet meeting to be determined by Sherry and proposed to board. She has proposed a place at 10000 Research Blvd. It is a Brazilian Steak House. Meeting will be held on Wednesday, December 11. Sept. 2013 Complete Submitted by, Mike Harkins Section Secretary, ASQ Austin Section 1414 CC: asqaustin.org website Electronic Vote Motion to accept meeting minutes: Name Vote Francisco Russi Accept Todd Minnick Accept Mike Harkins Accept Cindi Manning Accept Megan Oertel Accept w. edit
IEEE P802.11 Wireless LANs D1.0 comment resolutions on miscellaneous COEX and MAC CIDs Date: 2011-11-05 Author(s): Name Affiliation Address Phone email Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 1326 jasonlee@etri.re.kr Minho Cheong ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 5635 Sok-kyu Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 5919 sk-lee@etri.re.kr Comments (CID 3106 – COEX) 3106 72 65 T 9.7.4.3 Rate selection for other group addressed data and management frames. "If the BSSBasicRateSet parameter is empty and the BSSBasicMCSSet parameter is not empty, the frame shall be transmitted in an HT PPDU using one of the MCSs included in the BSSBasicMCSSet parameter." change to: If the BSSBasicRateSet parameter is and the BSSBasicMCSSet parameter is not empty, the frame shall be transmitted in an HT or VHT PPDU using one of the MCSs included in the BSSBasicMCSSet parameter Agree in principle. to CID 3182 also resolves this CID. Discussion Agree in Principle. Resolution to CID 3182 (11/1144r8) which has been already included in D1.2 also resolves this CID. See Clause “9.7.5.3 Rate selection for other group addressed data and management frames” in D1.2. The resolution from 11/1144r8 is as follows: If the BSSBasicRateSet parameter is empty and the BSSBasicMCSSet parameter is not empty, the frame shall be transmitted in an HT PPDU using one of the MCSs included in the BSSBasicMCSSet parameter.
If the BSSBasicRateSet parameter the BSSBasicMCSSet parameter are empty (e.g., a scanning STA that is not yet associated with a BSS), the frame shall be transmitted in a non-HT PPDU using one of the mandatory PHY rates. Proposed resolution: See CID 3182 (11/1144r8). No change is necessary to D1.2 text. Comments (CID 3486, 2679 – COEX) 3486 73 17 T This statement is not needed. I think what it says is that there can't be multiple CH_BANDWIDTH parameters with different values when transmitting a MU PPDU. However, the TXVECTOR does not allow for multiple CH_BANDWIDTH parameters (this parameter is not flaged as 'MU' in the TXVECTOR column) and the PHY doesnt support it. Remove statement. Agree. Removed the statement 2679 Kim, 73 17 T There is only one CH_BANDWIDTH parameter (common to all users) in TXVECTOR even in case of MU-MIMO TX. Hence, CH_BANDWIDTH parameter is inherently the same for all users in a PPDU. Agree in principle. Removed the statement Discussion Agree. In Table 22-1 (TXVECTOR and RXVECTOR parameters), there is only one CH_BANDWIDTH parameter in TXVECTOR even in case of MU-MIMO transmission. Therefore, CH_BANDWIDTH parameter is the same for all users in MU-MIMO PPDU and the statement is not needed. Proposed resolution:
IEEE P802.11 Wireless LANs D1.0 comment resolutions on Clause 9.19.2 Date: 2011-11-07 Author(s): Name Affiliation Address Phone Email Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 1326 jasonlee@etri.re.kr Minho Cheong ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 5635 Sok-kyu Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 5919 sk-lee@etri.re.kr Comments (CID 2915 - MAC) 2915 Liu, Yong 57 T It appears to be too many rules / conditions on TXOP BW selection. Consider to rewrite this section and make the rules simpler and clearer. in principle. to CID 3500 also resolves this CID MAC Discussion in Principle. CID 2915 is similar to CID 3500 (11/1060r0) which has already passed the motion. CID 3500 is as follows: “This paragraph and the next two or three seem overly complex with a lot of repetition. For example, The second sentence talks about TXOP bandwidth coming from the CTS response to non-HT RTS with dynamic bit sent and the so does the bullet at L53. The third sentence says that in all other cases the bandwidth of the TXOP is from the initial frame and then so does L58 and P84L6” 11/1060r0 proposed the following changes to 11ac D1.0 and it was included in TGac D1.2, and it also resolves CID 2915. 9.19.2.4 Multiple transmission in an EDCA TXOP A TXOP is obtained after a STA transmitting an initial frame successfully receives a response frame. When a TXOP is obtained for a bandwidth that is greater than 20MHz by non-HT duplicate frame exchange, the TXOP holder may transmit PPDUs using CH_BANDWIDTH that are up to and including the bandwidth obtained for the TXOP. During the TXOP, the TXOP holder shall not transmit PPDUs using CH_BANDWIDTH greater than the obtained bandwidth for the TXOP. 83
DIVISION OF VOCATIONAL REHABILITATION (DVR) COMMUNITY REHABILITATION PROGRAM (CRP) PRE-EMPLOYMENT TRANSITION SERVICES (PRE-ETS) Service Delivery Outcome Plan: Pre-ETS Job Exploration Page of AFP NUMBER DVR CUSTOMER CRP CONTRACTOR CRP REPRESENTATIVE’S NAME SERVICE DELIVERY DATES From: To: STAFFING INTERVALS NUMBER EXPECTED OUTCOME PARTY RESPONSIBLE PURCHASE AND PAYMENT CRITERIA COST ($) Pre-Employment Transition Services Job Exploration activities are designed to help students discover and explore career interests. MAXIMUM OUTCOME FEE: Fee per hour is $72.00 for up to hours. Outcome fee paid to Contractor upon receipt of invoice and outcomes achieved as described in the Service Delivery Outcome Report (SDOR). Fee is based on direct student activities, and does not include report writing time. SDOR must be written directly to the student, and provided to both the student and DVR VRC. Report must include: CRP Provider representative name Dates and hours of all activities Evidence of student skill gains in identified training areas Specific recommendations for further student exploration and experience $ Specific areas of interest identified in collaboration with the DVR VRC and the student’s school-based transition goals: 1. Enter interest area 2. interest area 3. Enter interest area Specific CRP services may include: Career, personality, values, learning styles, interest inventories, etc. Vocational and person-centered planning Exploring ‘dream jobs’ Steps in setting career and educational goals Connecting current school studies with employment Helping students identify skill sets and strengths CRP Student VRC Travel time at a fixed rate of $35 per hour in quarter-hour increments if service delivery occurs more than fifty (50) miles from the contractor’s nearest staffed office location. $ Specific Job Exploration activities with Student First Name include: 1. Enter activity 2. Enter activity 3. Enter activity Student will participate in all Job Exploration activities, and will attend all scheduled meetings. Student CUSTOMER / GUARDIAN SIGNATURE DATE IL SIGNATURE DATE DVR SIGNATURE DATE TOTAL $ Signature by each party indicates agreement to the contents of this plan.
prepared by the licensed surveyor; or (ii) is based on survey; or (iii) is a plan of subdivision; or applicant, if paragraph (a) does not apply. (6) A plan in a form other than a paper plan must be— or authorised; and by a licensed surveyor. (7) By signing or authorising a plan a licensed surveyor certifies that the plan and any related survey is accurate and was undertaken by himself or herself or under his or her supervision. (8) A plan must contain a new version number when the plan has been amended, altered or recertified. 9 Meaning of abbreviations on plans r. 9 (1) In a plan— AMG means Australian Map Grid; A (no.), when preceding a number, means appurtenant easement number; CP means Common Property; E (no.), when preceding a number, means encumbering easement number, a condition
Example Location of boundaries defined by buildings. Interior Face: all boundaries. The structure of any wall, ceiling, window, door, balustrade (or other) which define boundaries are contained within Common Property (…) or Common Property (....) is all the land in the plan except the lots and (Roads and/or Reserves—if applicable) and includes the structure of any wall, floor, ceiling, window, door, balustrade (or other) which define boundaries. (The following notation may be shown with either of the above statements) All internal columns, service pipe shafts and cable ducts, service installations (or other) within the building are deemed to be part of common property (...). The positions of these columns, service ducts, pipe shafts and cable ducts, service installations (or other) may not have been shown on the diagrams contained herein. r. 10 (6) If a plan adopts any part of a building as a boundary and there is a discrepancy between any dimensions shown and the location of that part of the building, the boundary is that part of the building. (7) Subregulation (6) does not apply to the external boundaries of the subdivision, except when defined by a building in a previously registered plan.
4 Definitions In these Regulations— appurtenance, in relation to a building, means forming part of or belonging to that building and includes air-conditioning and heating units; parcel means the land shown on a plan as a lot, road, reserve, common property or residual land; Register has the same meaning as in the Transfer of Land Act 1958; strata plan means a plan of strata subdivision or strata redevelopment registered or approved— 30 October 1989; or or after 30 October 1989 under the provisions applied by section 44(3B) of the Act; the Act the Subdivision Act 1988. r. 4 __________________ 5 Form and layout of plans and documents r. 5
DIVISION OF VOCATIONAL REHABILITATION (DVR) COMMUNITY REHABILITATION PROGRAM (CRP) PRE-EMPLOYMENT TRANSITION SERVICES (PRE-ETS) Service Delivery Outcome Plan: Pre-ETS Job Shadow Page of AFP NUMBER DVR CUSTOMER CRP CONTRACTOR CRP REPRESENTATIVE’S NAME SERVICE DELIVERY From: To: STAFFING INTERVALS NUMBER EXPECTED OUTCOME PARTY RESPONSIBLE PURCHASE AND PAYMENT CRITERIA COST ($) Pre-Employment Transition Services Job Shadow is a one to five-hour observation at a business in the community. The job shadow should be located at a business or organization not related / connected to the CRP’s own agency. MAXIMUM TOTAL OUTCOME FEE: Fee for each Job Shadow is $125 per hour for up to five hours. Maximum payment for each SDOP is $1250, based on two Job Shadow experiences. This SDOP provides for up to two (2) Job Shadow experiences at two (2) different for up to five (5) hours each. Contractor agrees to provide up to Job Shadow experiences. Outcome fee paid to Contractor upon receipt of invoice and outcomes achieved as described in the Service Delivery Outcome Report (SDOR). Fee is based on direct student activities, and does not include report writing time. SDOR must be written directly to the student, and provided to both the student and DVR VRC. Report must include: CRP Provider representative name Dates and hours of all activities Evidence of student skill gains in identified training areas Specific recommendations for further student exploration and experience $ Specific CRP services include: Developing the Job Shadow site(s) based on student interests Helping student prepare questions for the employer Helping student plan appropriate grooming Helping student plan transportation Accompany student to the site(s) Helping student prepare and deliver a follow-up note to the employer Post-Job Shadow debriefing with student Specific areas of interest identified by Student First Name: 1. Enter interest area 2. Enter interest area 3. Enter interest area CRP Student VRC Travel time at a fixed rate of $35 per hour in increments if service delivery occurs more than fifty (50) miles from the contractor’s nearest staffed office location. $ Student will participate in all Job Shadow activities, and will attend all scheduled meetings. Student CUSTOMER / GUARDIAN SIGNATURE DATE IL SIGNATURE DATE DVR SIGNATURE DATE $ Signature by each party indicates agreement to the contents of this plan.
Regulation 6 Subdivision Act 1988 A. [All Applicants complete this Section] Plan No.: To: [insert name and address of Council] I/We: Of: Telephone: apply to have the attached: *PLAN OF SUBDIVISION *PLAN OF CONSOLIDATION *PLAN OF CREATION/REMOVAL/VARIATION OF EASEMENT/RESTRICTION certified under the Subdivision Act 1988 and to have advice of street numbers allocated 1. [Insert details of situation of land] 2. [Insert name and address of registered proprietor of land or owner] 3. [Insert name and address of applicant] Does the attached plan do anything requiring the unanimous resolution of the members of the owners corporation under Division 3 of Part 5 of the Subdivision Act 1988 or an order of the Victorian Civil and Administrative Tribunal under section 34D of the Subdivision Act 1988? *YES [provide details]/*NO
Regulation 28(2) This plan is certified under section 11(7) of the Subdivision Act 1988. Date of original certification under section 6: [insert date]. Public Open Space: A requirement for public open space under section 18 of the Subdivision Act 1988— *Has not been made. *Has been made and the requirement has been satisfied. *Has been made and the requirement has not been satisfied. *Has been made and the requirement has been satisfied for: [include details]. *Has been made and the requirement is to be satisfied in stage no. #. [*Name and signature of Council delegate or *Council seal] *Surveyor's plan version [insert version number] *[Date of certification under section 11(7)] *Delete if not applicable Note 1: This form is to be used if the Council is not satisfied that section 21(1)(b)(i) or (ii) of the Subdivision Act 1988 has been complied with. Note 2: For a paper plan the Surveyor's plan version number is not required. Note 3: If by certifying the plan a Council exercises its power under clause 5(1)(a) of Schedule 10 to the Local Government Act 1989 to approve, assign or change the name of a road, the Council must act in accordance with any guidelines in force under the Geographic Place Names Act 1998 and must advise the Registrar within the meaning of that Act of the action the Council has taken under that clause.
Coroners Court (Amendment No. 1) Rules 2011 S.R. No. 117/2011 of provisions Rule Page 1 Objective 1 2 Authorising provisions 1 3 Commencement 1 4 Principal Rules 1 5 Seal of the Coroners Court 1 6 New Rule 15A inserted 2 15A Summons must be served personally 2 7 Service of document by the Coroners Court 2 8 Affidavit of service 2 9 Determination by coroner that reported death not a reportable death 2 10 Determination by State Coroner that death not a reviewable death 2 11 Preliminary examinations 3 12 Identification procedure 3 13 Direction for autopsy 3 14 Senior next of kin to be advised of removal of tissue direction 3 15 Application to coroner for release of body 3 16 Publication of the details of an inquest 3 17 Interested party 3 18 Findings of coroner investigating a death 3 19 Findings of coroner investigating a fire 4 20 Findings not required if inquest not held or discontinued 4 21 New rule 62A inserted 4 62A Suppression of findings by coroner 4 22 Publication of findings and reports 4 23 New rule 64A inserted 5 64A Publication of determination, ruling or order 5 24 New Order 9A inserted 5 5 66A Attendance expenses for expert witnesses 5 OF AND trial
37 r. 25 Rule 60(1) IN THE CORONERS OF VICTORIA AT [COURT LOCATION] Court Reference: Form 37 Rule 609(1) Section 67 of the Coroners Act 2008 Inquest into the of: [name of deceased] Delivered On: Delivered At: Hearing Findings of: [name of coroner] Representation: [list representation] *Police Coronial Support Unit [name of PCSU member] *Counsel Assisting the Coroner [name of barrister] [name of solicitor] I, [name], *State Coroner/*Deputy State Coroner/*Coroner having investigated the death of [given names] [surname]
FRANCIS HOWELL HIGH SCHOOL BEHAVIOR Three-Year Goal Statement: By 2013-14 FHHS will demonstrate continuous improvement in student awareness through the following benchmark: Reduce the number of discipline infractions by 8% as compared to 2010-11 school year. ONE-YEAR ACHIEVEMENT GOAL (11/12) During the 11-12 school year, FHHS will demonstrate continuous improvement in student awareness through the following benchmark: Reduce truancy referrals by 5% as compared to the 10-11 school year. Data-driven rationale that led you to this goal (charts): During the 10-11 school year truancy referrals were the most frequent type of discipline infraction.
Integer 1 Specifies a time limit (in TU) after which the authentication procedure is terminated. Content of FT Authentication elements Sequence of elements As defined in 12.8 The set of elements to be included in the message of the FT authentication sequence, as described in 12.8.2. Present only if dot11FastBSSTransitionActivated is true. Content of SAE Authentication Frame Sequence of elements and fields As defined in 8.4.1.37, 8.4.1.38, 8.4.1.39, 8.4.1.40b, 8.4.1.41, and 8.4.1.42 The set of elements and fields to be included in the SAE Commit Message or SAE Confirm Message. Present only if AuthenticationType indicates SAE authentication. FILS wrapped data Sequence of elements and fields As defined in 8.4.1.42a The FILS wrapped data field is used for the STA and AP to communicate data used by the FILS authentication algorithm VendorSpecificInfo A set of elements As defined in 8.4.2.28 Zero or more elements. 6.3.5.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.confirm( PeerSTAAddress, AuthenticationType, ResultCode, Content of FT Authentication elements, Content of SAE Authentication Frame, FILS wrapped data, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the peer MAC entity with which to perform the authentication process. AuthenticationType Enumeration OPEN_SYSTEM, SHARED_KEY, FAST_BSS_TRANSITION, SAE, FILS Specifies the type of authentication algorithm to use during the authentication process. ResultCode Enumeration SUCCESS, REFUSED, ANTI-CLOGGING TOKEN REQUIRED, FINITE CYCLIC GROUP NOT SUPPORTED, AUTHENTICATION REJECTED Indicates the result of the MLMEAUTHENTICATE. request primitive. Content of FT Authentication elements Sequence of elements As defined in 12.8 (FT authentication sequence) The set of elements included in the second message of the FT authentication sequence, as described in 12.8.3 (FT authentication sequence: contents of second
IEEE P802.11 Wireless LANs 802.11 TGad Proposed SB1 Resolutions for CID 6501, 6516 Date: 2012-03-01 Author(s): Name Company Address Phone email Mark Hamilton Polycom 1765 West 121st Avenue Westminster, CO 80234 mark.hamilton@polycom.com Abstract This document presents proposed resolutions to CIDs 6501 and 6516 on the 1st sponsor ballot of REVad. Comments 6501 4.9.3 50.13 The architectural model of multiple MAC entities sharing one PHY (one example of MM-SME usage) seems to be a general enhancement to 802.11 (well beyond 11ad), for some specific usage scenarios (like desiring to have parallel associations with different security modes/levels). This is really quite independent of FST or even MM-SME concepts. The architectural change of multiple MAC entities sharing a single PHY (and the PHY-SAP changes to support this) should be pulled out into its own subclause of clause 4, introduced before the subclause that adds as an additional feature for multiple MAC entity scenarios. Pull out the architectural concept of multiple MAC entities sharing one PHY, and put into its own subclause of clause 4, ahead of 4.9.3. Specifically, create a diagram like Figure 4-16a (but without the MM-SME), pull out the last sentence of the first paragraph of 4.9.3, and the paragraph at lines 21-23 in 4.9.3, and make a new subclause with this source material. Also, modify the reference to 4.9.3 in the NOTE at p51.23 to reference the new subclause, and modify the changes in 9.19.2.5 to not be specific to but rather to be general to a multiple MAC entities sharing one PHY architecture
on page 220, line 13-14 5176 220.41 22.3.10.1 Inconsistent use of N_DBPS N_DBPS,u is defined as N_DBPS for user u. In Table 22-6, it says that N_DBPS is undefined for MU. Delete sentence and replace with "is defined in Table 22-6" A Agree Clause 22.3.10.3 CRC calculation for VHT-SIG-B CID Page Clause Comment Proposed Change Resn Status Resolution 5270 221.58 22.3.10.3 NDP PPDUs have no service field, so the CRC detection cannot be done at receivers. The correctness of the bits recovered by receivers cannot be guaranteed. The wrong VHT-SIG-B bits may lead to seriously bad consequences. Improve the NDP structure to avoid this problem. R Reject. The NDP PPDU is an SU PPDU, see 22.3.12. A receiver can ignore VHT-SIG-B since no information is required from it for processing an SU PPDU, see 22.3.21. Therefore no change is necessary. Clause 22.3.10.4 Scrambler CID Page Clause Comment Proposed Change Resn Status Resolution 5177 222.41 22.3.10.4 Use consistent terminoogy Replace "pad parts" with "PHY pad bits" A Clause 22.3.10.5 Coding CID Page Clause Comment Proposed Change Resn Status Resolution
5178 222.05 22.3.10.5.2 Use consistent terminoogy Replace "pad parts" with "PHY pad bits" A Agree. 5179 223.30 22.3.10.5.2 Inconsistent use of N_DBPS N_DBPS,u is defined as N_DBPS for user u. In Table 22-6, it says that N_DBPS is undefined for MU. Delete sentence and replace with "is defined in Table A 5180 223.34 22.3.10.5.2 Ambiguous wording Replace "Zero tail bits" with "Tail bits with value zero" A Agree. 5181 223.41 22.3.10.5.3 Missing variable "i" Replace "0 < N_SYM N_DBPS,u/N_ES,u" with "0 <= i < N_SYM N_DBPS,u/N_ES,u" A Agree. 5182 223.41 22.3.10.5.3 Replace N_ES with N_ES,u Replace N_ES with N_ES,u A 5183 224.65 22.3.10.5.5 Inconsistent use of N_ES N_ES,u is defined as N_ES for user u. In Table 22-6, it says that N_ES is undefined for MU. Delete sentence and replace with "is defined in Table A 5184 225.01 22.3.10.5.5 Inconsistent use of N_DBPS N_DBPS,u is defined as N_DBPS for user u. In 22-6, it says that N_DBPS is undefined for MU. Delete sentence and replace with "is defined in Table A Agree. Clause 22.3.10.6 Stream parser CID Page Clause Comment Proposed Change Resn Status Resolution
TGac editor: replace “i=0” with “l=0” on P234L5 and L6. Delete “( for 20, 40 and 80 MHz, for 160 and 80+80 MHz)” on P234L1-2. 5191 234.42 22.3.10.9.2 User index missing d' does not have user index (u) A Agree. See CID 5189 5192 234.50 22.3.10.9.2 User index missing d' and d'' do not have user index (u) A Agree. See CID 5189 Clause 22.3.10.11 OFDM modulation CID Page Clause Comment Proposed Change Resn Status Resolution 5445 239.54 22.3.10.11.1 "d" does not have a parameter of user index. Ditto for 40, 80, 160 and 80+80 MHz in 22.3.10.11.1. Change the superscript of "d" as (t_seg, u). A Agree. See CID 5189 5195 240.56 22.3.10.11.1 Q can be either spatial mapping or steering matrix Replace "spatial mapping matrix" with "spatial mapping/steering matrix" A Agree
However, I (Adrian) am willing to accept that most folks in TGac don’t care about the architecture. Therefore I will limit any proposed changes in this document to those easily made. Actioning this particular comment would result in new primitives and interaction with the PLCP rx state machine text and diagrams; these changes are too extensive to be considered “easily made”. Therefore I’m OK with rejecting the comment as shown. 5227 Sigurd 268.01 22.3.21 PHY-RXEND takes two parameters PHY_RXEND has been redefined to take two parameters (see 7.3.5.13.2 in mb). This should be reflected here. J Rejected. 7.3.5.13.2 in states “RXVECTOR is an included parameter only when is true.” We have assumed in the PLCP receive state machine that is false. 4754 There are several inconsistencies between Figure 22-25 (PLCP tx) and Figure 22-27 (PLCP rx):- In tx, the PSDU gets "Bit Padding if needed" and "Tail Bits (if BCC)" before it is scrambled and encoded to a C-PSDU. In rx, they're apparently always present- In tx, the MAC passes an while in rx the MAC is passed an MPDU- There is no PMD data indication or data end Align and complete the two figures:- Say "Bit padding (if needed)" and "Tail bits (if BCC)" in rx- Pass an A-MPDU up to the MAC in rx- Put in the appropriate PMD data signals in rx- Include handling in the PLCP in rx and remove the second sentence of the NOTE- Show how the PARTIAL_AID/GROUP_ID are passed down for tx- Rename "VHT-Training" in rx and "VHT Training Symbols" in tx to or "VHT-STF" and "VHT-LTF"- Rename Non-VHT Training Symbols from the PLCP and rename it to or "L-STF" and in tx- Remove the line of dots at the top of tx
IEEE P802.11 Wireless LANs Max Number of MSDUs in an A-MSDU Date: 2012-03-08 Author(s): Name Affiliation Address Phone Simone Merlin Qualcomm Inc 5775 Morehouse Dr San Diego, CA 92109 8588451243 smerlin@qualcomm.com Guido Frederiks Qualcomm Inc Shukla Ashish Qualcomm Inc Menzo Wentink Qualcomm Inc Abstract Comment is from: 11-12-0752-03-00ac-lb188-comment-tgac-d3-0.xls Comment and editorial instructions refer to: Draft P802.11ac_D3.0.pdf Comment 6855 116.15 9.11 There is no limit on the number of MSDUs that can be packed in an sent in a MPDU. Potentially the number of MSDUs can be very large. As an example, assuming small packets of 62Bytes (e.g. ~TCP ACK) an MPDU of 11454Bytes could include up to 184 MSDUs. For a max sized A-MPDU of 64 MPDUs this can potentially result in >11000 MSDUs. These numbers are exemplary to illustrate the problem. In general, processing a high and unpredictable number of MSDUs increases complexity of receiver Add an optional indication for a receiver VHT STA to signal to a transmitter VHT STA that the number of MSDUs per MPDU shall be less than a given number; ability to limit the number of MSDUs in a MPDU to <= 16 is suggested. The indication can be in the form of a capability indication (TBD). The current operation mode (no limit) is also preserved; Restriction can only be signaled by a VHT STA to a VHT STA; restriction refers to number of MSDUs sent in any MPDU where A-MSDU is allowed. REVISE. Adopt resolution as in DCN 12/0917r1 (this document)
IEEE P802.11 Wireless LANs Normative text for scanning related MLMEs Date:2012-09-17 Author(s): Name Affiliation Address Phone email Jarkko Kneckt, Mika Kasslin, Gabor Bajko Corporation Otaniementie 19, 02150 Espoo Finland +358504821550 Ping Fang, Yunsong Yang, Phillip Barber Huawei Technologies Co. Ltd. Bldg. 7, Vision Software Park, Road Gaoxin South 9, Nanshan District, Shenze, Guangdong, China, 518057 +86755 36839346 Park, Kiseon Ryu LG Electronics LG R&D Complex 533, Dongan-Gu, Anyang, Kyungki, 431-749, Korea +82-31-450-1879 Giwon.Park@lge.com Lei Wang InterDigital Communications 781 Third Ave., King of Prussia, PA 19406 1 858 205 7286 leiw@billeigean.com Jae Seung Lee, Minho Cheong, Sok-kyu Lee ETRI 161 Gajeong-dong, Daejoen, Korea +82 42 860 1326 6.3.3.2 MLME-SCAN.request 6.3.3.2.2 Semantics of the service primitive Instructions to Editor: Change the clause as shown with track changes: The primitive parameters are as follows: MLME-SCAN.request( BSSType, BSSID, SSID, ScanType, ProbeDelay, ChannelList, MinChannelTime, MaxChannelTime, RequestInformation, SSID List, ChannelUsage, AccessNetworkType, HESSID, MeshID, ReportingOption,
IEEE P802.11 Wireless LANs Limiting probe requests and responses Date:2012-09-10 Author(s): Name Affiliation Address Phone Email Jarkko Kneckt, Mika Kasslin, Gabor Bajko Nokia Corporation Otaniementie 19, Espoo Finland +358504821550 Ping Fang, Yunsong Yang Huawei Technologies Co. Ltd. Bldg. 7, Vision Software Park, Road Gaoxin South 9, Nanshan District, Shenze, Guangdong, China, 518057 +86755 36839346 Givon Park, Kiseon Ryu LG Electronics LG R&D Complex 533, Dongan-Gu, Anyang, Kyungki, 431-749, Korea +82-31-450-1879 Giwon.Park@lge.com Lei Wang InterDigital Communications 781 Third Ave., King of Prussia, PA 19406 +1 858 205 7286 leiw@billeigean.com 6.3.3.2 MLME-SCAN.request 6.3.3.2.2 Semantics of the service primitive Instructions to Editor: Change the clause as shown with track changes: The primitive parameters are as follows: MLME-SCAN.request( BSSType, BSSID, SSID, ScanType, ProbeDelay, ChannelList, MinChannelTime, MaxChannelTime, RequestInformation, SSID List, ChannelUsage, AccessNetworkType, HESSID, MeshID, FILSRequestParameters, VendorSpecificInfo )
6831 145.52 9.31.5 The sentence here is not in consistance with the rule at pgl45/ln7 which reads "A VHT beamformer shall not transmit either a VHT NDP Announcement+HTC frame or a Beamforming Report Poll+HTC frame that contains an HT variant HT Control field." Clarify if a VHT NDP Announcement or a Beamforming Report Poll frame can contain an HT variant HT Control field. REVISED See CID 6702 resolution 6095 145.53 9.31.5 The sentence here contradicts with P145L8. fix the problem. REVISED See CID 6702 resolution 6702 145.53 9.31.5 A VHT NDP Announcement frame with more than one STA Info field shall not carry an HT variant HT Con- trol field, unless all the STAs listed in the AID field of the STA Info fields have set +HTC-HT Support to 1 in the HT Extended Capabilities field. conflicts with the paragraph earlier in the section P145L8 A VHT beamformer shall not transmit either a VHT NDP Announcement+HTC frame or a Beamforming Re- port Poll+HTC frame that contains an HT variant HT Control field. remove the sentence: A VHT NDP Announcement frame with more than one STA Info field shall not carry an HT variant HT Con- trol field, unless all the STAs listed in the AID field of the STA Info fields have set +HTC-HT Support to 1 in the HT Extended Capabilities field ACCEPTED 6296 145.54 9.31.5 "unless" seems to contradict P145L8. Duelling paras? Harmonize para at P145L53 with P145L8 REVISED See CID 6702 resolution
Proposed resolution: Revise P151 L30 in P802.11ac_D3.1 as follows: A VHT NDP Announcement frame with more than one STA Info field shall not carry a(#6027) VHT variant HT Control field, unless all the STAs listed in the AID field of the STA Info fields have set +HTC-VHT Capable to 1 in the VHT Capabilities Info field. 6096 146.02 9.31.5 This note is not right since a VHT beamformee and VHT beamformer do not deed to follow the TXOP limit rule. Remove the note or change the note. REJECTED 1) Don’t see that this note implies the VHT BFming frames shall or shall not follow any TXOP limit rule; 2) TXOP limit rules for VHT BFming frames are sufficiently specified in 9.19.2.2. Don’t see any issue there either. Discussion: The commented note is quoted below: NOTE—The transmission of the VHT NDP Announcement, VHT NDP, VHT Compressed Beamforming and Beamforming Report Poll frames is subject to the rules in 9.19.2.4 (Multiple frame transmission in an EDCA TXOP). 6367 146.18 9.31.5 The example given in Figure 9-41b shows BF report polls sent immediately after the first VHT compressed BF. It is not clear to me if sending some other frames after the shown VHT compressed BF frame is possible before sending out the BF report polls. If the behavior described in the comment is permitted. Perhaps we could add a note to say that this is possible. REJECTED 1) The figure caption clearly says it is an example sequence; so it does not imply whether other sequences are allowed or not allowed. 2) The normative text does not prohibit the commented sequence. 3) Don’t it necessary to enumate every possible sequence (there can be tens of possible sequences allowed)
Note to reader, not for inclusion in the draft. From slide 18 of 12/297r1 Field/element/frame Problem Proposed fix 8.5.8.8 DSE Measurement Request format OpClass+Ch# only, no primary channel indication for >40MHz, no 80+80 semantics; no optional subelements. Yet, no 80/160 MHz spectrum with DSE (yet?) No change. When and if this is needed by a new “XHT” TG, use existing OpClass+Ch# to indicate the P20 or P20/40. Define an optional subelement formatted as EID,L, VHT Operation Information field to indicate the BSS operating channel for 80/160/80+80 (sent to a XHT STA only). 8.5.8.9 DSE Measurement Report format OpClass+Ch# only, no primary channel indication for no 80+80 semantics; no optional subelements. Yet, no 80/160 MHz spectrum with DSE (yet?) No change. When and if this is needed by a new “XHT” TG, I have no idea how to extend this except via a new “Extended DSE Measurement Report format” 8.5.13.TDLS Channel Switch Request Action field format OpClass+Ch# only, no primary channel indication for >40MHz, no 80+80 semantics; no optional subelements. Allow Wide Bandwidth Channel Switch element as an optional subelement , as is already addressed by 11acD2.0
any security encapsulation (e.g.,(#6016) TKIP/CCMP/GCMP Header and MIC) or Mesh Control fields; see 8.2.4.7.2 Insert new Table 8-13a: Maximum DU (in octets) and durations (in microseconds) per PPDU format Non-HT non-VHT non-DMG PPDU and non-HT duplicate PPDU HT PPDU(#6669) VHT PPDU(#6669) DMG PPDU MMPDU size 2304 2304 See NOTE 1 2304 MSDU size 2304 2304 2304 7920 A-MSDU size 3839 or 4065 (see NOTE 2) or 7935 (HT STA, see also Table 8-124) or N/A (non-HT STA, see also 9.11 (A-MSDU operation))(#6446) 3839 or 7935 (see also 8-124) See NOTE 3 7935 MPDU size See NOTE 4 See NOTE 5 3895 or 7991 or 11 454 (see also Subfields of the VHT Capabilities Info field ) See NOTE 5 PSDU size (see NOTE 7) 213-1 (Clause 16, see Table 16-2) 212-1 (others, see Table 17-5, Table 18-7, Table 19-8) 216-1 (see Table 20-25) 4 692 480 (~222.16) (see Table 22-29 (VHT PHY characteristics)) 218-1 (see 21-17) PPDU duration (see NOTE 7) See NOTE 6 5484 (HT_MF; see 9.23.4) or 10000 (HT_GF; see Table 20-25) 5484 (see Table 22-29 (VHT PHY characteristics)) 2000 (see Table
IEEE P802.11 Wireless LANs FILS Authentication Protocol Date: 2012-10-26 Author(s): Name Affiliation Address Phone email Dan Harkins Networks 1322 Crossman ave, Sunnyvale, CA +1 408 227 4500 dharkins at aruba networks dot com George Cherian Jouni Malinen Phil Hawkes Qualcomm 5775 Morehouse Dr, San Diego, CA, USA +1 858 651 6645 René Struik Struik Security Consultancy Toronto ON +1 415 690-7363 +1 647 867-5658 Skype: rstruik Insert the following reference into 2: Insert the following definition into 3.1: 3.1 Definitions Modify section 4.5.4.2 as indicated: Authentication IEEE 802.11 authentication operates at the link level between IEEE 802.11 STAs. IEEE Std 802.11 does not provide either end-to-end (message origin to message destination) or user-to-user authentication. IEEE Std 802.11 attempts to control LAN access via the authentication service. IEEE 802.11 authentication is an SS. This service may be used by all STAs to establish their identity to STAs with which they communicate, in both ESS and IBSS networks. If a mutually acceptable level of authentication has not been established between two STAs, an association is not(#1421) established.
Present only if AuthenticationType indicates SAE authentication. VendorSpecificInfo A set of elements As defined in 8.4.2.28 Zero or more elements. 6.3.5.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.confirm( PeerSTAAddress, AuthenticationType, ResultCode, Content of FT Authentication elements, Content of SAE Authentication Frame, , VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the peer MAC entity with which to perform the authentication process. AuthenticationType Enumeration OPEN_SYSTEM, SHARED_KEY, FAST_BSS_TRANSITION, SAE, Specifies the type of authentication algorithm to use during the authentication process. ResultCode Enumeration SUCCESS, REFUSED, ANTI-CLOGGING REQUIRED, FINITE CYCLIC GROUP NOT SUPPORTED, AUTHENTICATION REJECTED Indicates the result of the MLMEAUTHENTICATE. request primitive. Content of FT Authentication elements Sequence of elements As defined in 12.8 (FT authentication sequence) The set of elements included in the second message of the FT authentication sequence, as described in 12.8.3 (FT authentication sequence: contents of second message). Present only if dot11FastBSSTransitionActivated is true. Content of SAE Authentication Frame Sequence of elements and fields As defined in 8.4.1.37 (Send-Confirm field), 8.4.1.38 (Anti-Clogging Token field), 8.4.1.39 (Scalar field), 8.4.1.40 (Element field), 8.4.1.41 (Confirm field), and 8.4.1.42 (Finite Cyclic Group field) The set of elements and fields to be included in the SAE Commit Message or SAE Confirm Message. Present only if AuthenticationType indicates SAE authentication. VendorSpecificInfo A set of elements As defined in 8.4.2.28 Zero or more elements.
IEEE P802.11 Wireless LANs Normative text for GAS configuration sequence number Date: 2012-09-05 Author(s): Name Affiliation Address Phone email Phillip Barber Huawei Technologies Co. Ltd. George Calcev Huawei Technologies Co. Ltd. George.Calcev@huawei.com Eric Zhang Huawei Technologies Co. Ltd. 6.3.3.3.2 Semantics of the service primitive Instructions to Editor: Append the following to the BSSDescriptionSet parameter of the primitive as follows: Name Type Valid range Description GAS configuration sequence number Integer N/A The GAS configuration sequence number of the found BSS. 8.3.3.2 Beacon frame format Instructions to Editor: Add new element to Table 8-20 as shown with track changes; editor to insert the appropriate value for nnTGai in the table for the new element The frame body of a management frame of subtype Beacon contains the information shown in Table 8-20. Table 8-20—Beacon frame body Order Information Notes nnTGai GAS configuration sequence number The GAS configuration sequence number is present if dot11FILSActiveated is true Last Vendor Specific One or more vendor-specific (#1684)elements are optionally present(#29). These (#1684)elements follow all other (#1684)elements(#1221). Probe Response frame format Instructions to Editor: Add new element to Table 8-27 as shown with track changes; editor to insert the appropriate value for nnTGai in the table for the new element. The frame body of a management frame of subtype Probe Response contains the information shown in Table 8-27. See additional details and procedures in 9.18.3 and 10.1.4, respectively.