Docstoc

11-09-0706-16-000m-revmb-wg-ballot-comments

Document Sample
11-09-0706-16-000m-revmb-wg-ballot-comments Powered By Docstoc
					Month Year                                          Title               doc.: IEEE 802.11-yy/xxxxr0

            IEEE P802.11 Wireless LANs
            Submission
Designator: doc.: IEEE 802.11-09/0706r16
Venue Date: August 2010
First Author:Adrian Stephens, Intel Corporation

Subject:     REVmb Working Group Ballot Comments
Full Date:   2010-08-20
Author(s):   Name(s) Adrian Stephens
             Company Intel Corporation
             Address

             Phone:
             Fax:
             email:     adrian.p.stephens@intel.com
Abstract:    This document contains comments submitted by voters for the 802.11 working group
             ballot on IEEE P802.11REVmb. It is a composite document in the sense that TGmb
             comment-resolution ad-hocs may publish spreadsheets containing a subset of these
             comments, which they are responsible for updating. This document is periodically
             updated to reflect the status of those spreadsheets.

             The "Comments" tab contains all comments received during the working group ballot of
             P802.11REVmb. Those in the initial ballot are shown with a 149 in column "LB".
             It also contains the pre-ballot comments received and resolved by TGmb. This are shown
             with a 0 in column "LB".

             The comment ID (CID) is assigned as follows:
                 Pre-ballot comments: 1-104
                 LB149, (i.e. the first working group ballot): 1000 - 1729
                 LB160, (the first recirculation ballot): 2000-2245
                 LB162, 2nd recirculation ballot: 3000-3148
                 LB163, 3rd recirculation ballot: 4000-4097
                 LB167, 4th recirculation ballot: 5000-5015




Submission                                            1                                   Name, Company
            Month Year   Title   doc.: IEEE 802.11-yy/xxxxr0




are shown




            Submission    2                    Name, Company
Revision    Date
        0   2009-06-29
        1   2009-06-29
        2   2009-08-28
        3   2009-09-22
        4   2009-09-24
        5   2009-11-17
        6   2009-12-10
        7   2010-01-11
        8   2010-01-20
        9   2010-03
       10   2010-03-31
       11   2010-04-26
       12   2010-06-10
       13   2010-06-30
       14   2010-07-16
       15   2010-08-03
       16   2010-08-20
       17
       18
       19
       20
       21
       22
       23
       24
       25
       26
       27
       28
       29
Description
Initial version. Comments from LB149 assigned to comment groups.
Following TGmb telecon, LB149 comments assigned to owning ad-hocs.
Updated prior to TGmb telecon
Updated after first day of Sept 2009 meeting
Updated prior to last session of TGmb
Updated prior to November TGmb session
Updated following November TGmb session and preparation of D2.0.
Comments from LB160 added, with initial ad-hoc assignments.
Updated during TGmb session
Updated prior to March 802.11 session
Updated following March 802.11 with resolutions from that meeting. LB160 resolutions now complete.
Includes LB162 comments
Includes resolution of LB162 comments.
Includes LB163 comments
Following July 2010 session
Prior to publication of D5.0
Includes LB167 comments
CID    Commenter          LB     Draft Clause   Page(C)   Line(C) Type of   Part of No   Page
                                        Number(                   Comment   Vote
                                        C)
      1 Adrian Stephens        0      0 11.9    197              T          N              197.00




      2 Adrian Stephens        0    0 11.4     195               T          N              195.00




      3 Adrian Stephens        0    0 9.9.1    113        38     T          N              113.38
4 Adrian Stephens   0   03   1   20   t   N   1.20
5 Adrian Stephens   0   0 9.10.2   116   36   t   N   116.36




6 Adrian Stephens   0   0 9.10.2   116   37   t   N   116.37
7 Adrian Stephens   0   0 7.2.1.1   22    50   T   N    22.50




8 Adrian Stephens   0   0 11.9.6    198   10   T   N   198.10
 9 Adrian Stephens   0   0 Introducti v    17   T   N     0.17
                           on




10 Adrian Stephens   0   0 9.10.4    127   54   T   N   127.54
11 Adrian Stephens   0   03   2   22   T   N   2.22
12 Adrian Stephens   0   03          2   60   T   N   2.60




13 Adrian Stephens   0   0 Annex D            T   N   0.00
14 Adrian Stephens   0   03   2     22   T   N     2.22




15 Adrian Stephens   0   0U   522   1    E   N   522.01
16 Adrian Stephens   0   0 7.1.4      23   3   T   N   23.03




17 Adrian Stephens   0   0 7.3.1.24   48   1   T   N   48.01
18 Adrian Stephens   0   0 9.7a       122   39   T   N   122.39




19 Adrian Stephens   0   0 9.16.1.1   153   30   T   N   153.30




20 Adrian Stephens   0   0 11.2.2.3   209   51   T   N   209.51




21 Adrian Stephens   0   0D           419   27   T   N   419.27
22 Adrian Stephens   0   0 9.9.1.5    128       15     E   N   128.15




23 Krishna Pillai    0   0 17.3.2.1   596              E   N   596.00




24 Peter Ecclesine   0   0 1.2        1                T   N     1.00




25 Bill Marshall     0   0 8.5.1.5.3 26 of      Bottom t   N    26.00
                                     802.11r-   of page
                                     2008




26 Bill Marshall     0   03           5                t   N     5.00




27 Bill Marshall     0   0 5.1.1      23               e   N    23.00
28 Bill Marshall   0   07         59              e   N   59.00




29 Bill Marshall   0   07         59              t   N   59.00




30 Bill Marshall   0   0 7.1.3.5.6 69   first     t   N   69.00
                                        paragra
                                        ph of
                                        7.1.3.5.6

31 Bill Marshall   0   0 7.2.3    80    last     e    N   80.00
                                        sentenc
                                        e of
                                        paragra
                                        ph
                                        starting
                                        "The
                                        frame
                                        body
                                        consists
                                        of…"
32 Bill Marshall   0   0 7.2.3      80            t    N    80.00




33 Bill Marshall   0   0 7.2.3.8    84    first   t    N    84.00
                                          paragra
                                          ph



34 Bill Marshall   0   0 7.2.3.9    84    first   t    N    84.00
                                          paragra
                                          ph




35 Bill Marshall   0   0 7.3.1.4    91    last    t    N    91.00
                                          paragra
                                          ph


36 Bill Marshall   0   0 7.3.1.11   96    final    e   N    96.00
                                          paragra
                                          ph of
                                          7.3.1.11




37 Bill Marshall   0   0B           769           e    N   769.00
38 Bill Marshall     0   0C            783              e    N    783.00




39 Bill Marshall     0   0 G.2         1079   third line e   N   1079.00
                                              of poem




40 Clint Chaplin     0   0 17.3.10.1                    T    N




41 Richard Roy       0   0 Table i.1                    E    N




42 Dorothy Stanley   0   0 6.1.3       9      1         T    N      9.01




43 Dorothy Stanley   0   0 7.2.3.1     10     45        T    N     10.45
44 Dorothy Stanley   0   0 7.3.22.10 30    56   T   N   30.56
                           a




45 Dorothy Stanley   0   0 7.3.2.22   26        E   N   26.00




46 Dorothy Stanley   0   0 7.3.2.6              E   N




47 Dorothy Stanley   0   0 7.2.3.6    14   65   E   N   14.65
48 Dorothy Stanley   0   0 7.3.2.31   33   57   T   N   33.57




49 Dorothy Stanley   0   0 7.3.2.31   29   62   T   N   29.62




50 Dorothy Stanley   0   0 7.3.2.31   29   62   T   N   29.62




51 Dorothy Stanley   0   0 7.3.2.31   32        T   N   32.00
52 Dorothy Stanley   0   0 7.3.2.25. 28   47   E   N   28.47
                           3




53 David Cipher      0   0 General             E   N




54 David Cipher      0   0 General             T   N




55 Mark Hamilton     0   0 5.2.4     28        E   N   28.00
56 Mark Hamilton   0   0 6.2.1.3   57-58   T   N    57.00




57 Mark Hamilton   0   0 10.3.10   342     T   N   342.00
58 Mark Hamilton   0   0 802.11k - 128   T   N   128.00
                         11.10.11
59 Mark Hamilton   0   0 9.1.3.1   254   3   T   N   254.03




60 Mark Hamilton   0   0 9.9.3.1   298       T   N   298.00
61 Mark Hamilton   0   0 11.2.1.1   426   T   N   426.00




62 Mark Hamilton   0   0 11.2.1     425   E   N   425.00




63 Mark Hamilton   0   0                      N
64 Matthew Fischer   0   0 7.3.2.15   112   T   N   112.00




65 Matthew Fischer   0   0 10.3.16.2 363    T   N   363.00
                           .2
66 Matthew Fischer   0   0 8.4.4   190   T   N   190.00




67 Matthew Fischer   0   0 5.2.5   29    T   N    29.00
68 Darwin Engwer   0   0M           1165   1         T   N   1165.01




69 John Kenney     0   0 17.3.2.1   596    15        T   N    596.15




70 John Kenney     0   0 17.3.8.1   612    Fig-17-   E   N    612.00
                                           12

71 John Kenney     0   0 17.3.8.3. 613               E   N    613.00
                         2
72 John Kenney   0   0 17.3.10.1 617       T   N   617.00




73 John Kenney   0   0 17.3.11   618-619   T   N   618.00
74 John Kenney   0   0 17.3.11   619             E   N   619.00




75 John Kenney   0   0 17.3.11   620   Fig 17-   T   N   620.00
                                       15
76 John Kenney     0   0 17.3.12   621          T    N   621.00




77 Youko Omori     0   0 7.3.2.4   102          T    N   102.00




78 Youko Omori     0   0 7.2.3.1   80           T    N    80.00
                         Beacon
                         frame
                         format




79 Clint Chaplin   0   0 17.3.10.1 617   first   T   N   617.00
                                         paragra
                                         ph
80 Clint Chaplin   0   0 11A.11.2 89   Table   T   N   89.00
                                       11A-2
                                       row
                                       "802.11
                                       QoS"




81 Clint Chaplin   0   0 8.4.10   24   24     T    N   24.24




82 Clint Chaplin   0   0 11A.1    50   1st     T   N   50.01
                                       paragra
                                       ph
83 Clint Chaplin   0   0 11A.4.2    53               T    N    53.00




84 Clint Chaplin   0   0 11A.4.3    56-57            T    N    56.00




85 Clint Chaplin   0   0 11A.5.2    57-59            T    N    57.00




86 Clint Chaplin   0   0 11A.5.4    61-62            T    N    61.00




87 Clint Chaplin   0   0 11A.5.5    63               T    N    63.00




88 Clint Chaplin   0   0 11A.5.5    63        5th     T   N    63.05
                                              paragra
                                              ph

89 Clint Chaplin   0   0 7.3.2.46   16        2nd     T   N    16.02
                                              paragra
                                              ph




90 Clint Chaplin   0   0 8.5.8.1-   236-242          T    N   236.00
                         8.5.8.4
91 Clint Chaplin   0   0 7.3.2.46   16   16    T   N   16.16




92 Clint Chaplin   0   0 8.4.10     24   25    T   N   24.25




93 Mark Rison      0   0 7.3.1.17   99   12?   T   N   99.12
94 Mark Rison      0   0 7.3.2.30   135   para 7   T   N   135.00




95 Jouni Malinen   0   0 Annex C                   T   N
96 Jouni Malinen   0   0 Clause          T   N
                         16




97 Jouni Malinen   0   0 Clause          T   N
                         14




98 Jouni Malinen   0   0 6.1.2    53     T   N    53.00




99 Jouni Malinen   0   0 8.3.2.4.1 173   T   N   173.00
100 Jouni Malinen   0   0 7.3.2.9    105   E   N   105.00




101 Jouni Malinen   0   0 11.2.1     425   T   N   425.00




102 Jouni Malinen   0   0 18.2.2.2   639   T   N   639.00
103 Adrian Stephens   0   0 7.1.4     T   N




104 Richard Roy       0   0 Annex J   T   N
1000 Armstrong, Lee   149   1 14.6.16   768   51   T   Y   768.51




1001 Ashley, Alex     149   1 9.3.2.2   382   28   T   Y   382.28
1002 Ashley, Alex   149   1 16        819   1    T   Y   819.01




1003 Ashley, Alex   149   1 9.9.1.5   400   13   E   Y   400.13




1004 Ashley, Alex   149   1 11.1.0a   579   7    E   N   579.07


1005 Bagby, David   149   1 General              T   Y
1006 Bagby, David   149   1 General   T   Y




1007 Bagby, David   149   1 14        T   Y   728.01




1008 Bagby, David   149   1 15        T   Y   780.01
1009 Bajko, Gabor   149   1 7.3.2.21. 146   40     T   Y   146.40
                            9




1010 Bajko, Gabor   149   1 7.3.2.22. 171   9-31   T   Y   171.00
                            9
1011 Bajko, Gabor   149   1 7.4.7.8   241   4-34   T   Y   241.00




1012 Bajko, Gabor   149   1 11.10.8.6 649   18     T   Y   649.18




1013 Bajko, Gabor   149   1 7.3.2.22. 171   9-31   T   Y   171.00
                            9
1014 Bajko, Gabor       149   1 7.3.2.31   192   43      T   N   192.43




1015 Bajko, Gabor       149   1 7.3.2.31   193   21      T   N   193.21




1016 Bumiller, George   149   1 Annex 0A 982     18-19   T   N   982.00



1017 Bumiller, George   149   1 Annex 0A 981     29-30   T   N   981.00




1018 Bumiller, George   149   1 Annex 0A 981     41-42   T   N   981.00



1019 Bumiller, George   149   1 Annex 0A 981     48-49   T   N   981.00



1020 Bumiller, George   149   1 Annex 0A 982     4-5     T   N   982.00
1021 Bumiller, George   149   1 Annex 0A 982   29-30   T   N   982.00

1022 Bumiller, George   149   1 Annex 0A 982   56-58   T   N   982.00

1023 Bumiller, George   149   1 Annex 0A 983   1-3     T   N   983.00




1024 Bumiller, George   149   1 Annex 0A 983   6-8     T   N   983.00

1025 Bumiller, George   149   1 Annex 0A 983   14-16   T   N   983.00




1026 Bumiller, George   149   1 Annex 0A 983   25-27   T   N   983.00




1027 Bumiller, George   149   1 Annex 0A 983   29-30   T   N   983.00



1028 Bumiller, George   149   1 Annex 0A 983   32-34   T   N   983.00



1029 Bumiller, George   149   1 Annex 0A 983   36-37   T   N   983.00



1030 Bumiller, George   149   1 Annex 0A 981   57      E   N   981.57
1031 Bumiller, George   149   1 Annex 0A 981         T   N   981.06




1032 Cam-Winget,        149   1 8.1.2    253    42   E   N   253.42
     Nancy




1033 Cam-Winget,        149   1 8.1.3    253    60   T   Y   253.60
     Nancy




1034 Cam-Winget,        149   1 8.1.3    254    64   T   Y   254.64
     Nancy


1035 Cam-Winget,        149   1 8.4.1.1.2 286   51   T   Y   286.51
     Nancy
1036 Cam-Winget,   149   1 8.4.1.1.3 286   60   T   Y   286.60
     Nancy




1037 Cam-Winget,   149   1 8.4.1.1.2 286   45   T   Y   286.45
     Nancy




1038 Cam-Winget,   149   1 8.4.1.2.1 288   51   T   Y   288.51
     Nancy




1039 Cam-Winget,   149   1 8.4.1.2.1 288   58   T   Y   288.58
     Nancy
1040 Cam-Winget,   149   1 8.4.6     292   38   T   Y   292.38
     Nancy




1041 Cam-Winget,   149   1 8.4.6.2   293   55   T   Y   293.55
     Nancy




1042 Cam-Winget,   149   1 8.4.8     295   30   T   Y   295.30
     Nancy




1043 Cam-Winget,   149   1 8.4.10    296   64   T   Y   296.64
     Nancy
1044 Cam-Winget,   149   1 General              T   Y
     Nancy




1045 Cam-Winget,   149   1 8.7.2     353   40   T   Y   353.40
     Nancy
1046 Chan, Douglas      149   1 General                 T   N




1047 Chan, Douglas      149   1 9.9.2.2   405   57-65   E   N   405.00




1048 Ecclesine, Peter   149   1 9.8.0a    390   45      E   N   390.45


1049 Ecclesine, Peter   149   1 9.8.2     391   30      T   N   391.30
1050 Ecclesine, Peter   149   1 9.8.2a     394   28   E   N   394.28




1051 Ecclesine, Peter   149   1 9.8.2      391   25   T   Y   391.25




1052 Ecclesine, Peter   149   1 18.4.6.7   929   38   T   Y   929.38




1053 Ecclesine, Peter   149   1 18.4.6.6   927   19   T   Y   927.19




1054 Ecclesine, Peter   149   1 18.4.6.2   923   30   T   Y   923.30
1055 Ecclesine, Peter   149   1 15.4.6.2   810   18   T   Y    810.18




1056 Ecclesine, Peter   149   1 Annex A    985   4    T   Y    985.04




1057 Ecclesine, Peter   149   1 Annex D 1308     15   T   Y   1308.15
1058 Ecclesine, Peter   149   1 Annex D 1307   46   T   Y   1307.46




1059 Ecclesine, Peter   149   1 Annex D 1316   40   T   Y   1316.40




1060 Ecclesine, Peter   149   1 Annex D 1311   51   T   Y   1311.51
1061 Ecclesine, Peter   149   1 Annex D 1370   2    T   Y   1370.02




1062 Ecclesine, Peter   149   1 Annex D 1380   39   T   Y   1380.39




1063 Ecclesine, Peter   149   1 16      819    1    T   Y    819.01
1064 Ecclesine, Peter   149   1 14        728    1    T   Y    728.01




1065 Ecclesine, Peter   149   1 Annex D 1385     55   T   Y   1385.55




1066 Ecclesine, Peter   149   1 Annex D 1385     22   T   Y   1385.22




1067 Ecclesine, Peter   149   1 Annex E   1421   1    E   Y   1421.01




1068 Ecclesine, Peter   149   1 Annex F   1422   1    T   Y   1422.01
1069 Ecclesine, Peter   149   1 Annex I   1492   9    E   N   1492.09




1070 Ecclesine, Peter   149   1 Annex J   1493   35   E   N   1493.35




1071 Ecclesine, Peter   149   1 Annex J   1494   52   E   N   1494.52


1072 Ecclesine, Peter   149   1 Annex M 1513     1    T   Y   1513.01
1073 Ecclesine, Peter   149   1 11.10.12 654   5   T   Y   654.05




1074 Ecclesine, Peter   149   1 7.5     248    1   E   N   248.01

1075 Ecclesine, Peter   149   1 10      425    1   T   Y   425.01
1076 Ecclesine, Peter   149   1 10.3.0a   427   2   T   Y   427.02




1077 Ecclesine, Peter   149   1 10.3.11   472   1   T   Y   472.01
1078 Ecclesine, Peter   149   1 1.2     2     13   T   Y     2.13




1079 Ecclesine, Peter   149   1 3.159   20    6    T   Y    20.06




1080 Ecclesine, Peter   149   1 3.159   20    5    E   N    20.05




1081 Ecclesine, Peter   149   1 13      726   1    E   Y   726.01
1082 Engwer, Darwin   149   1 6.1.3   64   5    E   Y   64.05




1083 Engwer, Darwin   149   1 6.1.3   64   22   E   Y   64.22
1084 Engwer, Darwin   149   1 6.1.3   64   25   E   Y   64.25




1085 Engwer, Darwin   149   1 6.1.3   64   27   E   Y   64.27
1086 Engwer, Darwin   149   1 general   1     1    E   Y   1.01




1087 Erceg, Vinko     149   1 Contents viii   57   E   N
1088 Erceg, Vinko    149   1 Contents viii       60   E   N




1089 Erceg, Vinko    149   1 Introducti iv       15   E   N
                             on
1090 Erceg, Vinko    149   1 Contents xxxi       43   E   N

1091 Erceg, Vinko    149   1 Contents xxxiv      27   E   N




1092 Erceg, Vinko    149   1 Contents xxxiv      28   E   N


1093 Gast, Matthew   149   1 3.147     19        1    E   N    19.01



1094 Gast, Matthew   149   1 3.4       6         32   T   N     6.32




1095 Gast, Matthew   149   1 7.5       248-252        E   N



1096 Gast, Matthew   149   1 14        728       1    T   N   728.01
1097 Gast, Matthew   149   1 11A.10.1 702     33   T   N   702.33




1098 Gast, Matthew   149   1 7.1.1      71    1    E   N    71.01



1099 Gast, Matthew   149   1 7.1.3.5.1 78     59   E   N    78.59




1100 Gast, Matthew   149   1 7.1.3.5.3 79     42   E   N    79.42




1101 Gast, Matthew   149   1 7.2.2      89    48   E   N    89.48



1102 Gast, Matthew   149   1 7.2.2      89    51   E   N    89.51



1103 Gast, Matthew   149   1 7.2.3.1    92    1    E   N    92.01




1104 Gast, Matthew   149   1 7.2.3.10   102   45   T   N   102.45
1105 Gast, Matthew   149   1 7.3.1.1   104     15   T   N   104.15




1106 Gast, Matthew   149   1 8.2.1.3   257     36   E   N   257.36




1107 Gast, Matthew   149   1C                       T   Y




1108 Gast, Matthew   149   1 Editors   lxxiv   7    E   N
                             notes




1109 Gast, Matthew   149   1 General                T   Y
1110 Gast, Matthew   149   1 General   T   Y




1111 Gast, Matthew   149   1 General   T   Y




1112 Gast, Matthew   149   1 General   T   Y
1113 Gast, Matthew   149   1 General   T   Y




1114 Gast, Matthew   149   1 General   T   Y
1115 Gast, Matthew   149   1 General               T   Y




1116 Gast, Matthew   149   1 General               E   N




1117 Gast, Matthew   149   1 N.5       1523   20   T   N   1523.20
1118 Gast, Matthew    149   1 Participa vi     21      E   N
                              nts




1119 Gong, Michelle   149   1 11.1.2.1   579   63-64   T   N   579.00




1120 Gong, Michelle   149   1 11.1.2.2   580   33      T   N   580.33




1121 Gong, Michelle   149   1 11.1.2.2   580   45      T   N   580.45




1122 Gong, Michelle   149   1 11.1.2.3   580   64-65   T   N   580.00
1123 Gong, Michelle   149   1 11.1.3     582   36      T   N   582.36




1124 Gong, Michelle   149   1 11.1.3.5   585   28      T   N   585.28



1125 Gong, Michelle   149   1 11.2.1.1   588   7       E   N   588.07




1126 Gong, Michelle   149   1 11.2.1.4   589   36-38   T   N   589.00
1127 Gong, Michelle   149   1 11.2.1.4   590   18-19   T   N   590.18




1128 Gong, Michelle   149   1 11.2.1.5   590   57-60   T   N   590.00




1129 Gong, Michelle   149   1 11.2.1.5   591   4-8     T   N   591.00
1130 Gong, Michelle   149   1 11.2.2.1   595   33-42   E   N   595.00


1131 Gong, Michelle   149   1 11.2.2.1   596   59-65   T   N   596.00




1132 Gong, Michelle   149   1 11.2.2.4   597   54-55   T   N   597.00




1133 Gong, Michelle   149   1 11.3.2.5   605   19      E   N   605.19




1134 Gong, Michelle   149   1 11.4.1     606   39-40   T   N   606.00




1135 Gong, Michelle   149   1 11.4.2     607   16      T   N   607.16




1136 Gong, Michelle   149   1 11.4.4     609   1-26    T   N   609.01
1137 Hamilton, Mark   149   1 Introducti iv    15   T   Y
                              on




1138 Hamilton, Mark   149   1 1.2        1     64   T   Y     1.64




1139 Hamilton, Mark   149   1 11.2.2.1   595   44   E   N   595.44


1140 Hamilton, Mark   149   1 8.4.1.1.3 286    61   T   Y   286.61




1141 Hamilton, Mark   149   1 10.1       425   25   T   Y   425.25
1142 Hamilton, Mark   149   12           3     12   T   N     3.12




1143 Hamilton, Mark   149   1 3.28       8     65   E   N     8.65




1144 Hamilton, Mark   149   1 7.4.8.3    244   40   E   N   244.40




1145 Hamilton, Mark   149   1 11.10.14 657     5    T   Y   657.05




1146 Hamilton, Mark   149   1 11.2.1.4   589   34   T   Y   589.34
1147 Hamilton, Mark   149   1 6.2.3   68   1   T   Y   68.01
1148 Hamilton, Mark   149   1 9.9.3.1    408   33   T   Y   408.33




1149 Hamilton, Mark   149   1 7.1.3.7    82    10   E   N    82.10




1150 Hamilton, Mark   149   1 7.3.2.27   183   58   E   N   183.58
1151 Hamilton, Mark   149   1 7.3.1.11   113   28   T   Y   113.28




1152 Hamilton, Mark   149   1 11.3.0a    598   54   T   Y   598.54




1153 Hamilton, Mark   149   1 10.3.8.1. 463    8    T   Y   463.08
                              1

1154 Hamilton, Mark   149   1 10.3.8.2. 464    23   T   Y   464.23
                              2

1155 Hamilton, Mark   149   1 8.3.2.4.0 271    26   T   Y   271.26
                              a
1156 Hamilton, Mark   149   1 10.3.24.2 507   31   T   Y   507.31
                              .2




1157 Hamilton, Mark   149   1 10.3.29.2 538   21   T   Y   538.21
                              .2




1158 Hamilton, Mark   149   1 10.3.30.2 541   17   T   Y   541.17
                              .2
1159 Hamilton, Mark   149   1 10.3.31.2 544   17   T   Y   544.17
                              .2




1160 Hamilton, Mark   149   1 10.3.32.2 547   28   T   Y   547.28
                              .2




1161 Hamilton, Mark   149   1 11.4.5   610    64   T   Y   610.64
1162 Hamilton, Mark   149   1 9.9.3.1.2 409   22   T   Y   409.22




1163 Hamilton, Mark   149   1 7.3.2.21. 144   27   T   Y   144.27
                              7



1164 Hamilton, Mark   149   1 3.136    18     17   T   Y    18.17




1165 Hamilton, Mark   149   1 3.3      6      23   T   Y     6.23




1166 Hamilton, Mark   149   13         6      1    T   Y     6.01
1167 Hamilton, Mark   149   1 11.10.11 653    48   T   Y   653.48




1168 Hart, Brian      149   1 14        728   1    T   N   728.01




1169 Hart, Brian      149   1 16        819   1    T   N   819.01




1170 Hart, Brian      149   1 17.3.11   866   49   T   N   866.49




1171 Hart, Brian      149   1 17.3.11   868   22   E   N   868.22




1172 Hart, Brian      149   1 15        780   1    T   N   780.01
1173 Hart2, Brian   149   1 14         728   1    T   N   728.01




1174 Hart2, Brian   149   1 16         819   1    T   N   819.01




1175 Hart2, Brian   149   1 17.3.11    866   49   T   N   866.49




1176 Hart2, Brian   149   1 17.3.11    868   22   E   N   868.22




1177 Hart2, Brian   149   1 15         780   1    T   N   780.01




1178 Hart2, Brian   149   1 18.4.6.6   927   20   T   N   927.20
1179 Hart2, Brian   149   1 18.4.6.6   929   40   T   N   929.40




1180 Hart2, Brian   149   1 19.1.2     942   40   T   N   942.40




1181 Hart2, Brian   149   1 19.1.2     942   48   T   N   942.48




1182 Hart3, Brian   149   1 14         728   1    T   Y   728.01
1183 Hart3, Brian   149   1 16         819   1    T   N   819.01




1184 Hart3, Brian   149   1 17.3.11    866   49   T   N   866.49




1185 Hart3, Brian   149   1 17.3.11    868   22   E   N   868.22




1186 Hart3, Brian   149   1 15         780   1    T   Y   780.01




1187 Hart3, Brian   149   1 18.4.6.6   927   20   T   Y   927.20




1188 Hart3, Brian   149   1 18.4.6.6   929   40   T   Y   929.40
1189 Hart3, Brian   149   1 19.1.2   942     40        T   Y    942.40




1190 Hart3, Brian   149   1 19.1.2   942     48        T   Y    942.48




1191 Kennedy,       149   1 9.8.1    391     9         E   N    391.09
     Richard




1192 Kennedy,       149   1 1.3.37.4. 565    20        E   N    565.20
     Richard                2
1193 Kennedy,       149   1 Annex     1063   16 - 25   E   N   1063.00
     Richard                A.4.10
1194 Kennedy,   149   1 Annex    1073   3 - 10    E   N   1073.00
     Richard            A.4.13




1195 Kennedy,   149   1 Annex    1073   12 - 20   E   N   1073.00
     Richard            A.4.13




1196 Kennedy,   149   1 Annex    1073   22 - 30   E   N   1073.00
     Richard            A.4.13




1197 Kennedy,   149   1 Annex    1086   33 - 44   E   N   1086.00
     Richard            A.4.18
1198 Kennedy,   149   1 Annex    1086   46 - 65   E   N   1086.00
     Richard            A.4.18




1199 Kennedy,   149   1 Annex    1087   5 - 26    E   N   1087.00
     Richard            A.4.18
1200 Kennedy,   149   1 Annex    1087   37 - 63   E   N   1087.00
     Richard            A.4.18




1201 Kennedy,   149   1 Annex    1088   4 - 15    E   N   1088.00
     Richard            A.4.18




1202 Kennedy,   149   1 Annex D 1308    16        E   N   1308.16
     Richard            ASN.1
1203 Kennedy,   149   1 Annex I 1488   20   E   N   1488.20
     Richard            Table I.2




1204 Kennedy,   149   1 Annex I 1489   30   E   N   1489.30
     Richard            Table I.3




1205 Kennedy,   149   1 Annex I 1490   36   E   N   1490.36
     Richard            Table !.4




1206 Kennedy,   149   1 Annex I 1490   38   E   N   1490.38
     Richard            Table !.4
1207 Kolze, Tom   149   1 Abstract   ii   1    T   Y




1208 Kolze, Tom   149   1 Introducti iv   22   T   Y
                          on
1209 Malarky, Alastair   149   1 7.3.2.25. 179    41   T   Y   179.41
                                 1




1210 Malarky, Alastair   149   1 7.3.2.26   183   37   T   Y   183.37




1211 Malarky, Alastair   149   1 7.3.2.26   183   37   T   Y   183.37




1212 Malarky, Alastair   149   1 7.4.5      228   15   T   Y   228.15
1213 Malarky, Alastair   149   1 7.4.5     228   34   T   Y   228.34




1214 Malarky, Alastair   149   1 General              T   Y




1215 Malinen, Jouni      149   1 10.3.19.1 498   33   E   Y   498.33
                                 .2
1216 Malinen, Jouni   149   1 J.1       1493        T   Y   1493.12




1217 Marshall, Bill   149   1 7.2.3.1   93     58   E   N     93.58




1218 Marshall, Bill   149   1 7.2.3.4   95     4    E   N     95.04
1219 Marshall, Bill   149   1 7.2.3.4    95    7    E   N    95.07




1220 Marshall, Bill   149   1 7.2.3.5    95    62   E   N    95.62

1221 Marshall, Bill   149   1 7.2.3.7    98    32   E   N    98.32




1222 Marshall, Bill   149   1 7.2.3.10   102   63   E   N   102.63




1223 Marshall, Bill   149   1 7.4.8      242   50   E   N   242.50




1224 Marshall, Bill   149   1 7.5        248   1    E   N   248.01

1225 Marshall, Bill   149   1 8.4.1.1.2 286    36   T   N   286.36




1226 Marshall, Bill   149   1 8.5.1.5.2 305    65   E   N   305.65




1227 Marshall, Bill   149   1 8.5.1.5.3 306    62   T   N   306.62
1228 Marshall, Bill   149   1 8.5.1.5.5 307    32   E   N    307.32




1229 Marshall, Bill   149   1 8.5.2     310    5    E   N    310.05




1230 Marshall, Bill   149   1 11.4.3    608    7    E   N    608.07




1231 Marshall, Bill   149   1 11A.3     668    17   T   N    668.17



1232 Marshall, Bill   149   1 11A.4.2   668    63   E   N    668.63




1233 Marshall, Bill   149   1 11A.4.2   670    31   T   N    670.31




1234 Marshall, Bill   149   1 11A.8.1   687    6    E   N    687.06


1235 Marshall, Bill   149   1D          1307   52   E   N   1307.52


1236 Marshall, Bill   149   1D          1307   64   E   N   1307.64
1237 McCann,   149   1 6.2.1.2    66    1   T   N    66.01
     Stephen




1238 McCann,   149   1 7.3.2.35   196   1   E   N   196.01
     Stephen
1239 McCann,   149   1 Annex D 1105     E   N   1105.00
     Stephen




1240 McCann,   149   1 Annexes 981      E   N    981.00
     Stephen




1241 McCann,   149   1 Annex C 1105     E   N   1105.01
     Stephen


1242 McCann,   149   1 Annex E   1421   E   N   1421.01
     Stephen
1243 McCann,   149   1 5.1a      30    20   T   N    30.20
     Stephen




1244 McCann,   149   1 5.2.3     32    50   E   N    32.50
     Stephen




1245 McCann,   149   1 5.2.3.1   34    22   E   N    34.22
     Stephen




1246 McCann,   149   1 5.4.4.1   50    3    T   N    50.03
     Stephen




1247 McCann,   149   1 7.3.2.25. 179   40   T   N   179.40
     Stephen           1
1248 McCann,   149   1 7.3.2.27   184   1, 45   E   N   184.00
     Stephen




1249 McCann,   149   1 7.3.2.27   184   1, 45   E   N   184.00
     Stephen




1250 McCann,   149   1 11.11.1    657   44      E   N   657.44
     Stephen
1251 Montemurro,   149   1 7.3.2.48   211   44   T   N   211.44
     Michael




1252 Montemurro,   149   1 7.3.1.7    109   14   T   N   109.14
     Michael




1253 Montemurro,   149   1 7.3.2.22. 160    45   T   N   160.45
     Michael               6

1254 Montemurro,   149   1 8.1.0a     253   7    T   N   253.07
     Michael
1255 Montemurro,   149   1 8.5.3.0a   317   41   T   N   317.41
     Michael




1256 Montemurro,   149   1 11.10.8.1 644    59   T   N   644.59
     Michael




1257 Montemurro,   149   1 11A.9.5.1 700    15   T   N   700.15
     Michael




1258 Montemurro,   149   1 8.5.2      310   5    T   N   310.05
     Michael
1259 Montemurro,   149   1 7.3.2.48   212   13   T   N   212.13
     Michael




1260 Montemurro,   149   1 8.5.3.2    320   23   T   N   320.23
     Michael
1261 Montemurro,   149   1 8.5.3.3   321   49   T   N   321.49
     Michael




1262 Montemurro,   149   1 7.3.2.21. 151   35   T   N   151.35
     Michael               10




1263 Montemurro,   149   1 11.10.8.8 651   46   T   N   651.46
     Michael
1264 Myles, Andrew   149   1 General   T   Y




1265 Myles, Andrew   149   1 General   T   N




1266 Myles, Andrew   149   1 10        T   Y   425.01
1267 Myles, Andrew   149   1 16               T   Y   819.01




1268 Myles, Andrew   149   1C                 T   Y




1269 Myles, Andrew   149   1 11.9.7.2   632   T   Y   632.51
1270 Myles, Andrew    149   1N                   T   Y




1271 Myles, Andrew    149   1E                   T   Y




1272 Myles, Andrew    149   1F                   T   Y




1273 Myles, Andrew    149   1O                   T   Y




1274 Myles, Andrew    149   1P                   T   Y




1275 Perahia, Eldad   149   1 14       728   1   T   Y   728.01




1276 Perahia, Eldad   149   1 12.3.4   712   1   E   N   712.01
1277 Perahia, Eldad   149   1 12.3.4.4   713   26   T   N   713.26




1278 Perahia, Eldad   149   1 12.3.5.4. 717    18   T   N   717.18
                              2




1279 Perahia, Eldad   149   1 12.3.5.10 723    35   T   N   723.35
                              .3




1280 Perahia, Eldad   149   1 12.3.5.10 723    35   T   N   723.35
                              .3




1281 Perahia, Eldad   149   1 17.3.2.4   842   51   E   N   842.51




1282 Perahia, Eldad   149   1 17.3.2.4   843   10   E   N   843.10

1283 Perahia, Eldad   149   1 17.3.3     846   7    E   N   846.07

1284 Perahia, Eldad   149   1 17.3.3     846   31   E   N   846.31
1285 Perahia, Eldad   149   1 17.3.4.3   848   7    T   Y   848.07




1286 Perahia, Eldad   149   1 17.3.8.1   857   22   T   N   857.22




1287 Perahia, Eldad   149   1 17.3.9.7   862   64   T   N   862.64


1288 Perahia, Eldad   149   1 17.3.9.7   862   64   E   N   862.64
1289 Perahia, Eldad   149   1 17.3.10.5 865   20   T   Y   865.20
1290 Perahia, Eldad   149   1 17.3.12   869   55   T   Y   869.55




1291 Perahia, Eldad   149   1 17.3.12   870   24   T   Y   870.24
1292 Perahia, Eldad   149   1 17.4.3   873    46   T   N   873.46




1293 Perahia, Eldad   149   1 17.5     874    1    T   N   874.01




1294 Perahia, Eldad   149   1 19.4.6   956    21   T   Y   956.21




1295 Perahia, Eldad   149   1 19.5.4   958    21   E   N   958.21




1296 Perahia, Eldad   149   1 19.9.5.0a 976   38   E   N   976.38
1297 Perahia, Eldad     149   1 19.9.5.0a 976    46   E   N    976.46

1298 Perahia, Eldad     149   1 19.9.5.0a 978    17   E   N    978.17

1299 Perahia, Eldad     149   1 I.1       1487   26   E   N   1487.26

1300 Perahia, Eldad     149   1 I.2.2     1490   38   T   Y   1490.38




1301 Perahia, Eldad     149   1 J.1       1494   1    T   Y   1494.01




1302 Perahia, Eldad     149   1 J.1       1495   21   E   N   1495.21


1303 Perahia, Eldad     149   1 J.1       1496   55   E   N   1496.55


1304 Ptasinski, Henry   149   1 General   1      1    T   Y      1.01




1305 Ptasinski, Henry   149   1 11A.8.4   689    7    T   Y    689.07


1306 Ptasinski, Henry   149   1 11A.8.5   690    4    T   Y    690.04
1307 Purnadi, Rene   149   1 7.3.2.47   210   12   T   N    210.12




1308 Purnadi, Rene   149   1 7.4.7.2    235   13   E   N    235.13

1309 Purnadi, Rene   149   1 Annex Q 1540     7    T   N   1540.07




1310 Purnadi, Rene   149   1 Annex Q 1554     44   T   N   1554.44




1311 Purnadi, Rene   149   1 Annex Q 1560     15   T   N   1560.15




1312 Purnadi, Rene   149   1 Annex Q 1564     63   T   N   1564.63




1313 Purnadi, Rene   149   1 Annex Q 1566     4    T   N   1566.04




1314 Purnadi, Rene   149   1 Annex Q 1568     21   T   N   1568.21




1315 Purnadi, Rene   149   1 Annex Q 1569     35   T   N   1569.35
1316 Purnadi, Rene   149   1 Annex Q 1581   1    T   N   1581.01




1317 Purnadi, Rene   149   1 Annex Q 1585   59   T   N   1585.59




1318 Purnadi, Rene   149   1 Annex Q 1590   30   T   N   1590.30




1319 Purnadi, Rene   149   1 Annex Q 1590   58   T   N   1590.58




1320 Purnadi, Rene   149   1 Annex Q 1596   62   T   N   1596.62




1321 Qi, Emily       149   17        248         E   N    248.00
1322 Qi, Emily   149   1 7.4.6.3   230   62   T   Y   230.62




1323 Qi, Emily   149   1 10.3.32   545   15   T   Y   545.15




1324 Qi, Emily   149   1 10.3.32   545   15   T   Y   545.15




1325 Qi, Emily   149   1 7.4.6.5   232   48   T   Y   232.48
1326 Qi, Emily   149   1 7.4.7.2   235   55   T   Y   235.55




1327 Qi, Emily   149   1 7.3.2     118   38   T   Y   118.38




1328 Qi, Emily   149   1 7.3.2     119   44   T   Y   119.44




1329 Qi, Emily   149   1 10.3.25   517   23   T   Y   517.23




1330 Qi, Emily   149   1 10.3.27   526   1    T   Y   526.01
1331 Qi, Emily   149   1 7.4.5    228    11   T   Y   228.11




1332 Qi, Emily   149   1 5.3.1    42     38   T   Y    42.38




1333 Qi, Emily   149   1 10.3.29.1 537   36   T   Y   537.36




1334 Qi, Emily   149   1 10.3.35.3 557   6    T   Y   557.06
1335 Qi, Emily     149   1 10.3.15.3 490    25   T   Y   490.25




1336 Ramamurthy,   149   1 9.13       420   58   T   N   420.58
     Harish




1337 Ramamurthy,   149   1 11.1.2.3   580   64   T   Y   580.64
     Harish
1338 Ramamurthy,   149   1 9.4   386   53   T   Y   386.53
     Harish




1339 Ramamurthy,   149   1 9.4   386   53   T   Y   386.53
     Harish
1340 Ramamurthy,   149   1 11.1.3.2. 583    31   E   N   583.31
     Harish                1




1341 Ramamurthy,   149   1 11.2.1.5   591   46   T   N   591.46
     Harish
1342 Ramamurthy,   149   1 11.3       599-600        T   N
     Harish




1343 Ramamurthy,   149   1 11.2.2.1   595       44   E   N   595.44
     Harish

1344 Ramamurthy,   149   1 9.4        386       65   T   Y   386.65
     Harish
1345 Ramamurthy,   149   1 9.2.5.4   370   59   T   Y   370.59
     Harish




1346 Ramamurthy,   149   1 9.9.1.2   396   39   T   N   396.39
     Harish
1347 Ramamurthy,   149   1 9.9.1.5   400   13   E   N   400.13
     Harish




1348 Ramamurthy,   149   1 9.9.1.5   400   17   E   N   400.17
     Harish




1349 Ramamurthy,   149   1 9.10.3    413   47   E   N   413.47
     Harish
1350 Ramamurthy,   149   1 9.10.3   413   27   T   Y   413.27
     Harish




1351 Ramamurthy,   149   1 7.1.3.1.7 75   1    E   N    75.01
     Harish




1352 Ramamurthy,   149   1 7.5      246   47   T   Y   246.47
     Harish
1353 Ramamurthy,    149   1 9.1.3.1    360       26      T   N   360.26
     Harish




1354 Ramamurthy,    149   1 9.1.3.1    360       20-29   T   Y   360.20
     Harish




1355 Rosdahl, Jon   149   1 7.3.2.21   134       49      E   Y   134.49




1356 Rosdahl, Jon   149   1 11.9.6     631       49      E   Y   631.49




1357 Rosdahl, Jon   149   1 11.3       599-606           T   Y
1358 Rosdahl, Jon   149   1 7, 11, etc.                     E   Y




1359 Rosdahl, Jon   149   1 3.163,        20, 13   20, 35   T   Y
                            3.87
1360 Rosdahl, Jon   149   1 7.2.3.0a   90   60   T   Y   90.60
1361 Rosdahl, Jon   149   1 7.2.3.1    191        T   Y   191.00




1362 Rosdahl, Jon   149   1 11.2.1.1   588        T   Y   588.00




1363 Rosdahl, Jon   149   1 7.1.3.3.3 77     15   T   Y    77.15
1364 Rosdahl, Jon   149   1 11.2.1.0a 586     53   T   Y   586.53




1365 Rosdahl, Jon   149   1 11.2.1.0a 587     1    T   Y   587.01




1366 Rosdahl, Jon   149   1 7.3.1.11    113   28   T   Y   113.28




1367 Rosdahl, Jon   149   1 10.3.33,               E   N
                            10.3.34
                            and
                            others




1368 Rosdahl, Jon   149   1 7, 9, 11,              E   Y
                            etc.
1369 Rosdahl, Jon   149   1 Annex C,              T   Y
                            E, & P




1370 Sakoda,        149   13           16    50   T   N    16.50
     Kazuyuki




1371 Sakoda,        149   1 7.2.3.2    94    14   E   N    94.14
     Kazuyuki



1372 Sakoda,        149   1 11.2.2.1   595   44   E   N   595.44
     Kazuyuki
1373 Sakoda,          149   1 A.4.4.2   1006   21   T   N   1006.21
     Kazuyuki




1374 Stacey, Robert   149   1 5.4.2.1   45     29   E   N     45.29

1375 Stacey, Robert   149   1 7.1.0a    70     21   E   N     70.21




1376 Stacey, Robert   149   1 7.2.1.1   83     46   T   Y     83.46




1377 Stacey, Robert   149   1 7.1.3.3.3 77     17   E   N     77.17


1378 Stacey, Robert   149   1 7.1.3.5.4 80     30   E   N     80.30
1379 Stacey, Robert   149   1 7.1.3.5.6 80   58   T   N   80.58




1380 Stacey, Robert   149   1 7.2.2    88    28   E   N   88.28




1381 Stacey, Robert   149   1 7.2.2    88    28   T   Y   88.28
1382 Stacey, Robert   149   1 7.2.3.0a   90    35   T   Y    90.35




1383 Stacey, Robert   149   1 7.2.3.1    92    37   E   N    92.37


1384 Stacey, Robert   149   1 7.3.1.4    106   56   T   Y   106.56




1385 Stacey, Robert   149   1 7.3.1.4    107   6    T   Y   107.06
1386 Stacey, Robert   149   1 7.3.1.4    107   52   T   Y   107.52




1387 Stacey, Robert   149   1 7.3.1.4    107   48   E   Y   107.48



1388 Stacey, Robert   149   1 7.3.1.11   112   58   T   N   112.58



1389 Stacey, Robert   149   1            120   52   E   N   120.52




1390 Stacey, Robert   149   1 9.14.0d    423   27   T   Y   423.27
1391 Stanley, Dorothy   149   1 7.3.2.40   202    5    T   N    202.05




1392 Stanley, Dorothy   149   1 7.3.2.22. 173     54   T   N    173.54
                                8




1393 Stephens, Adrian   149   1C           1105        E   N   1105.00
1394 Stephens, Adrian   149   1         10   10   E   N   10.10

1395 Stephens, Adrian   149   1         12   33   E   N   12.33




1396 Stephens, Adrian   149   1         12   60   E   N   12.60

1397 Stephens, Adrian   149   1         13   16   E   N   13.16

1398 Stephens, Adrian   149   1         9    36   E   N    9.36

1399 Stephens, Adrian   149   1         12   18   E   N   12.18



1400 Stephens, Adrian   149   1         12   64   E   N   12.64


1401 Stephens, Adrian   149   1 3.88    13   41   E   N   13.41


1402 Stephens, Adrian   149   1 3.104   15   51   E   N   15.51



1403 Stephens, Adrian   149   1 3.113   16   20   E   N   16.20




1404 Stephens, Adrian   149   1 3.133   17   64   E   N   17.64
1405 Stephens, Adrian   149   1 3.136   18     17   E   N     18.17




1406 Stephens, Adrian   149   1 3.151   19     27   E   N     19.27


1407 Stephens, Adrian   149   1 3.169   20     53   E   N     20.53




1408 Stephens, Adrian   149   1 3.159   20     5    E   N     20.05

1409 Stephens, Adrian   149   1 Annex C 1105   1    T   N   1105.01




1410 Stephens, Adrian   149   14        24     44   E   N     24.44




1411 Stephens, Adrian   149   14        24     62   E   N     24.62
1412 Stephens, Adrian   149   1 General             T   N




1413 Stephens, Adrian   149   1 5.2.3.2   34   32   E   N   34.32



1414 Stephens, Adrian   149   1 5.2.5     37   3    T   N   37.03
1415 Stephens, Adrian   149   1 5.2.6   37   29   T   N   37.29




1416 Stephens, Adrian   149   1 5.2.7   38   34   E   N   38.34




1417 Stephens, Adrian   149   1 5.2.7   38   65   T   N   38.65




1418 Stephens, Adrian   149   1 5.3.2   43   6    T   N   43.06
1419 Stephens, Adrian   149   1 5.4.1.1   44   41   T   N   44.41




1420 Stephens, Adrian   149   1 5.4.1.2   44   49   T   N   44.49
1421 Stephens, Adrian   149   15                  T   N   30.01




1422 Stephens, Adrian   149   1 5.4.3   47   14   T   N   47.14
1423 Stephens, Adrian   149   1 5.4.3.1   48   1    T   N   48.01




1424 Stephens, Adrian   149   1 5.7       53   39   T   N   53.39
1425 Stephens, Adrian   149   1 5.7      53     26   T   N    53.26




1426 Stephens, Adrian   149   1 10.3.29.1 537   10   T   N   537.10
1427 Stephens, Adrian   149   1 5.8.3.3   59    28   T   N    59.28




1428 Stephens, Adrian   149   1 6.1.5     65    1    E   N    65.01

1429 Stephens, Adrian   149   1 7.3.2.25. 179   47   T   N   179.47
                                1
1430 Stephens, Adrian   149   1 10.1      425   14   T   N   425.14




1431 Stephens, Adrian   149   1 10.1      426   1    T   N   426.01




1432 Stephens, Adrian   149   1 10.3.0a   427   1    T   N   427.01




1433 Stephens, Adrian   149   1 11.10.12 654    28   T   N   654.28
1434 Stephens, Adrian   149   1 10.3.2.2. 431   34   T   N   431.34
                                2




1435 Stephens, Adrian   149   1 10.3.2.2. 432   8    T   N   432.08
                                2




1436 Stephens, Adrian   149   1 10.3.2.2. 432   31   T   N   432.31
                                2




1437 Stephens, Adrian   149   1 10.3.2.2. 431   50   T   N   431.50
                                2
1438 Stephens, Adrian   149   1 10.3.2.2. 434    25   T   N   434.25
                                2




1439 Stephens, Adrian   149   1 10.3.2.2. 432    48   E   N   432.48
                                2
1440 Stephens, Adrian   149   1 10                    E   N   425.01




1441 Stephens, Adrian   149   1 10.3.6.3   450   23   E   N   450.23
1442 Stephens, Adrian   149   1 8.2.2.3.0 260    48   T   N   260.48
                                a




1443 Stephens, Adrian   149   1 10                    T   N   425.01




1444 Stephens, Adrian   149   1 11.3.0a    600   5    T   N   600.05




1445 Stephens, Adrian   149   1 11.3.2.5   605   8    T   N   605.08




1446 Stephens, Adrian   149   1 11.3.2.5   605   26   T   N   605.26
1447 Stephens, Adrian   149   1 11.10.5   640    19   T   N    640.19




1448 Stephens, Adrian   149   1           1317   12   E   N   1317.12




1449 Stephens, Adrian   149   1 10.3.9.1. 466    30   T   N    466.30
                                2




1450 Stephens, Adrian   149   1 10.3.9.2. 467    18   T   N    467.18
                                2
1451 Stephens, Adrian   149   1 Annex D             T   N   1307.01




1452 Stephens, Adrian   149   1 Annex D             T   N   1307.01




1453 Stephens, Adrian   149   1 10.3.10a. 471   5   T   N    471.05
                                1.3
1454 Stephens, Adrian   149   1 10.3.11   472   61   T   N   472.61




1455 Stephens, Adrian   149   1 10.3.11   476   30   T   N   476.30




1456 Stephens, Adrian   149   1 10.3.13.2 483   37   E   N   483.37
                                .2


1457 Stephens, Adrian   149   1 10.3.16.2 493   11   T   N   493.11
                                .2




1458 Stephens, Adrian   149   1 10.3.17.1 494   46   T   N   494.46
                                .2




1459 Stephens, Adrian   149   1 10.3.19.1 498   50   T   N   498.50
                                .4
1460 Stephens, Adrian   149   1 10.3.22.1 502   56   T   N   502.56
                                .4




1461 Stephens, Adrian   149   1 10.3.22.1 502   54   E   N   502.54
                                .4
1462 Stephens, Adrian   149   1 10.3.23.1 504   26   T   N   504.26
                                .2




1463 Stephens, Adrian   149   1 10.3.24.1 505   38   E   N   505.38
                                .1

1464 Stephens, Adrian   149   1 10.3.24.1 506   17   E   N   506.17
                                .2




1465 Stephens, Adrian   149   1 10.3.24.7 516   46   E   N   516.46
                                .3




1466 Stephens, Adrian   149   1 10.3.25.2 518   36   T   N   518.36
                                .2
1467 Stephens, Adrian   149   1 10.3.27.5 531   46   T   N   531.46
                                .4




1468 Stephens, Adrian   149   1 General              E   N



1469 Stephens, Adrian   149   1 10.3.30.3 542   28   T   N   542.28
                                .4




1470 Stephens, Adrian   149   1 10.3.31.2 544   39   T   N   544.39
                                .4




1471 Stephens, Adrian   149   1 10.3.31.3 545   32   E   N   545.32
                                .2
1472 Stephens, Adrian   149   1 10                   E   N   425.01

1473 Stephens, Adrian   149   1 10.3.33.6 552   49   E   N   552.49
                                .2
1474 Stephens, Adrian   149   1 10.4.1.1   569   16   T   N   569.16




1475 Stephens, Adrian   149   1 11.1.0a    579   7    E   N   579.07


1476 Stephens, Adrian   149   1 11.1.0a    579   9    T   N   579.09




1477 Stephens, Adrian   149   1 11.1.1     579   16   T   N   579.16



1478 Stephens, Adrian   149   1 General               T   N




1479 Stephens, Adrian   149   1 11.1.2.1   580   20   T   N   580.20
1480 Stephens, Adrian   149   1 11.1.2.1   580   1    T   N   580.01




1481 Stephens, Adrian   149   1 11.1.3.0a 582    23   E   N   582.23

1482 Stephens, Adrian   149   1 11.1.3.2. 583    32   T   N   583.32
                                1




1483 Stephens, Adrian   149   1 11.1.3.2. 583    34   T   N   583.34
                                1




1484 Stephens, Adrian   149   1 11.1.3.2. 583    58   T   N   583.58
                                2
1485 Stephens, Adrian   149   1 11.2.1.3   588   27   T   N   588.27




1486 Stephens, Adrian   149   1 11.2.1.4   590   19   T   N   590.19




1487 Stephens, Adrian   149   1 11.2.1.5   590   51   T   N   590.51




1488 Stephens, Adrian   149   1 11.2.1.5   591   14   T   N   591.14


1489 Stephens, Adrian   149   1 11.2.1.5   591   36   E   N   591.36
1490 Stephens, Adrian   149   1 11.2.1.5   591   37   T   N   591.37




1491 Stephens, Adrian   149   1 11.2.1.5   591   39   T   N   591.39




1492 Stephens, Adrian   149   1 11.2.1.5   591   50   T   N   591.50




1493 Stephens, Adrian   149   1 11.2.1.5   592   8    T   N   592.08




1494 Stephens, Adrian   149   1 11.2.1.5   592   30   T   N   592.30




1495 Stephens, Adrian   149   1 11.2.1.5   590   51   T   N   590.51
1496 Stephens, Adrian   149   1 11.2.1.6   593   21   T   N   593.21




1497 Stephens, Adrian   149   1 11.2.1.6   593   33   T   N   593.33




1498 Stephens, Adrian   149   1 11.2.1.9   594   62   T   N   594.62




1499 Stephens, Adrian   149   1 11.2.1.9   594   64   T   N   594.64




1500 Stephens, Adrian   149   1 11.2.1.9   595   2    T   N   595.02

1501 Stephens, Adrian   149   1 11.2.2.1   595   30   T   N   595.30




1502 Stephens, Adrian   149   1 11.2.2.1   596   19   T   N   596.19
1503 Stephens, Adrian   149   1 11.2.2.4   598   1    E   N   598.01




1504 Stephens, Adrian   149   1 11.2.2.4   598   12   T   N   598.12




1505 Stephens, Adrian   149   1 11.2.2.4   598   15   T   N   598.15




1506 Stephens, Adrian   149   1 11.2.2.4   598   41   T   N   598.41
1507 Stephens, Adrian   149   1 11.3.0a   600   30   T   N   600.30




1508 Stephens, Adrian   149   1 11.3.0a   600   42   T   N   600.42
1509 Stephens, Adrian   149   1 11.3.2.1   603   4    T   N   603.04




1510 Stephens, Adrian   149   1 11.5.3     618   65   T   N   618.65




1511 Stephens, Adrian   149   1 11.4.1     607   5    E   N   607.05

1512 Stephens, Adrian   149   1 11.4.2     607   18   T   N   607.18




1513 Stephens, Adrian   149   1 11.4.4     608   36   E   N   608.36



1514 Stephens, Adrian   149   1 11.6.1     619   28   T   N   619.28
1515 Stephens, Adrian   149   1 11.6.1   619   56   T   N   619.56




1516 Stephens, Adrian   149   1 11.6.2   620   19   T   N   620.19
1517 Stephens, Adrian   149   1 11.7.0a    620   42   T   N   620.42




1518 Stephens, Adrian   149   1 11.7.0a    621   39   E   N   621.39



1519 Stephens, Adrian   149   1 11.7.1.2   622   63   E   N   622.63




1520 Stephens, Adrian   149   1 General               T   N




1521 Stephens, Adrian   149   1 11.9.6     631   45   E   N   631.45

1522 Stephens, Adrian   149   1 11.7.5     626   5    E   N   626.05


1523 Stephens, Adrian   149   1 11.9.0a    629   1    E   N   629.01
1524 Stephens, Adrian   149   1 General              E   N




1525 Stephens, Adrian   149   1 11.9.0a   629   30   T   N   629.30


1526 Stephens, Adrian   149   1 11.9.2    630   11   T   N   630.11




1527 Stephens, Adrian   149   1 11.9.3    630   33   T   N   630.33




1528 Stephens, Adrian   149   1 11.9.6    630   53   T   N   630.53
1529 Stephens, Adrian   149   1 General              E   N




1530 Stephens, Adrian   149   1 11.10.8.4 647   62   E   N   647.62


1531 Stephens, Adrian   149   1 11.10.8.4 648   24   T   N   648.24



1532 Stephens, Adrian   149   1 11.10.8.6 649   28   T   N   649.28
1533 Stephens, Adrian   149   1 11.10.8.8 651   28   T   N   651.28




1534 Stephens, Adrian   149   1 11.10.9   652   18   T   N   652.18




1535 Stephens, Adrian   149   1 General              E   N
1536 Stephens, Adrian   149   1          653    1    T   N   653.01




1537 Stephens, Adrian   149   1 11.10.10 653    33   E   N   653.33
                                a
1538 Stephens, Adrian   149   1 11.10.11 653    50   T   N   653.50




1539 Stephens, Adrian   149   1 11.10.12. 655   23   E   N   655.23
                                1
1540 Stephens, Adrian   149   1 11.10.12. 655   49   E   N   655.49
                                1

1541 Stephens, Adrian   149   1 11.10.13 656    52   E   N   656.52




1542 Stephens, Adrian   149   1 11.10.13 656    53   T   N   656.53
1543 Stephens, Adrian   149   1 11.11.1   657   55   T   N   657.55




1544 Stephens, Adrian   149   1 11.11.2.2 659   5    T   N   659.05




1545 Stephens, Adrian   149   1 11.11.2.3 659   58   T   N   659.58
1546 Stephens, Adrian   149   1 11.11.2.3 659   58   T   N   659.58




1547 Stephens, Adrian   149   1 11.11.2.4 660   3    T   N   660.03




1548 Stephens, Adrian   149   1 11.11.2.2 659   21   T   N   659.21
1549 Stephens, Adrian   149   1 11.11.2.4 660   24   T   N   660.24




1550 Stephens, Adrian   149   1 11.11.3   661   4    T   N   661.04




1551 Stephens, Adrian   149   1 11A.1     665   41   T   N   665.41




1552 Stephens, Adrian   149   1 12.3.5.7. 720   22   T   N   720.22
                                3
1553 Stephens, Adrian   149   1 12.3.5.11 724   6    T   N   724.06
                                .1




1554 Stephens, Adrian   149   1 12.3.5.12 725   17   E   N   725.17
                                .2



1555 Stephens, Adrian   149   1 12.3.5.12 725   52   T   N   725.52
                                .3




1556 Stephens, Adrian   149   1 Clause               T   N   941.01
                                19
1557 Stephens, Adrian   149   1 A.4.4.1   992    23   T   N    992.23


1558 Stephens, Adrian   149   1 A.4.4.1   995    39   T   N    995.39




1559 Stephens, Adrian   149   1 A.4.2     989    24   E   N    989.24




1560 Stephens, Adrian   149   1 General               T   N




1561 Stephens, Adrian   149   1 A.4.4.4   1010   20   E   N   1010.20


1562 Stephens, Adrian   149   1 A.4.8     1051   42   E   N   1051.42
1563 Stephens, Adrian   149   1 Annex A              E   N    985.01




1564 Stephens, Adrian   149   1 Annex A   1089   1   E   N   1089.01




1565 Stephens, Adrian   149   1 Annex C 1105     1   T   N   1105.01




1566 Stephens, Adrian   149   1 Annex E   1421   1   T   N   1421.01
1567 Stephens, Adrian   149   1 Annex F   1423   1    T   N   1423.01




1568 Stephens, Adrian   149   1 K.3.2     1501   40   T   N   1501.40




1569 Stephens, Adrian   149   1 K.3.2     1502   48   E   N   1502.48

1570 Stephens, Adrian   149   1 K.3.2     1502   58   E   N   1502.58
1571 Stephens, Adrian   149   1 K.3.2   1504   34   E   N   1504.34




1572 Stephens, Adrian   149   1 K.3.2   1505   41   E   N   1505.41

1573 Stephens, Adrian   149   1 N.2     1518   44   T   N   1518.44




1574 Stephens, Adrian   149   1         1533        E   N   1533.00


1575 Stephens, Adrian   149   1Q        1535   22   T   N   1535.22



1576 Stephens, Adrian   149   1Q        1535   23   T   N   1535.23
1577 Stephens, Adrian   149   1Q   1535   33   T   N   1535.33




1578 Stephens, Adrian   149   1Q   1537   26   T   N   1537.26




1579 Stephens, Adrian   149   1Q   1540   34   E   N   1540.34

1580 Stephens, Adrian   149   1Q   1541   16   E   N   1541.16



1581 Stephens, Adrian   149   1Q   1543   25   T   N   1543.25



1582 Stephens, Adrian   149   1Q   1544   48   E   N   1544.48

1583 Stephens, Adrian   149   1Q   1588   29   E   N   1588.29



1584 Stephens, Adrian   149   1Q   1588   63   E   N   1588.63
1585 Stephens, Adrian   149   1Q   1599        T   N   1599.00




1586 Stephens, Adrian   149   1D   1307   51   E   N   1307.51




1587 Stephens, Adrian   149   1D   1308   54   T   N   1308.54



1588 Stephens, Adrian   149   1D   1345   40   T   N   1345.40
1589 Stephens, Adrian   149   1D               T   N




1590 Stephens, Adrian   149   1D   1351   35   T   N   1351.35




1591 Stephens, Adrian   149   1D   1352   42   E   N   1352.42




1592 Stephens, Adrian   149   1D   1376   54   E   N   1376.54
1593 Stephens, Adrian   149   1D   1378   34   T   N   1378.34




1594 Stephens, Adrian   149   1D   1396   23   T   N   1396.23




1595 Stephens, Adrian   149   1D               T   N
1596 Stephens, Adrian   149   1D                      E   N




1597 Stephens, Adrian   149   1D          1403   22   T   N   1403.22




1598 Stephens, Adrian   149   1 General               E   N
1599 Stephens, Adrian   149   1D          1408   63   T   N   1408.63




1600 Stephens, Adrian   149   1D                      E   N



1601 Stephens, Adrian   149   1 9.1.3.1   359    46   E   N    359.46




1602 Stephens, Adrian   149   1 9.1.3.2   360    51   T   N    360.51




1603 Stephens, Adrian   149   1 9.1.5     361    35   T   N    361.35
1604 Stephens, Adrian   149   1 9.1.5   361   41   T   N   361.41




1605 Stephens, Adrian   149   1 9.1.5   361   65   T   N   361.65
1606 Stephens, Adrian   149   1 9.2      362   30   T   N   362.30




1607 Stephens, Adrian   149   1 9.2.0a   362   56   T   N   362.56




1608 Stephens, Adrian   149   1 9.2.0a   363   8    T   N   363.08
1609 Stephens, Adrian   149   1 9.2.0a   363   16   T   N   363.16




1610 Stephens, Adrian   149   1 9.2.0a   363   22   T   N   363.22




1611 Stephens, Adrian   149   1 9.2.0a   363   26   T   N   363.26




1612 Stephens, Adrian   149   1 9.2.2    364   19   T   N   364.19
1613 Stephens, Adrian   149   1 9.2.3.3   365   43   T   N   365.43




1614 Stephens, Adrian   149   1 9.2.3.4   365   51   T   N   365.51




1615 Stephens, Adrian   149   1 9.2.3.4   365   55   E   N   365.55



1616 Stephens, Adrian   149   1 9.2.3.4   365   60   T   N   365.60




1617 Stephens, Adrian   149   1 9.2.4     366   30   T   N   366.30




1618 Stephens, Adrian   149   1 9.2.5.1   367   51   T   N   367.51




1619 Stephens, Adrian   149   1 9.2.5.3   369   48   E   N   369.48
1620 Stephens, Adrian   149   1 9.2.5.3   370   28   T   N   370.28




1621 Stephens, Adrian   149   1 9.2.6     374   30   T   N   374.30




1622 Stephens, Adrian   149   1 9.2.6     374   33   T   N   374.33




1623 Stephens, Adrian   149   1 9.2.6     374   35   T   N   374.35
1624 Stephens, Adrian   149   1 9.2.6   374   36   T   N   374.36




1625 Stephens, Adrian   149   1 9.2.6   374   41   T   N   374.41




1626 Stephens, Adrian   149   1 9.2.6   374   40   T   N   374.40




1627 Stephens, Adrian   149   1 9.2.7   374   53   T   N   374.53
1628 Stephens, Adrian   149   1 9.2.7   374   59   T   N   374.59




1629 Stephens, Adrian   149   1 9.2.9   375   55   T   N   375.55




1630 Stephens, Adrian   149   1 9.2.9   376   5    T   N   376.05




1631 Stephens, Adrian   149   1 9.2.9   376   12   T   N   376.12
1632 Stephens, Adrian   149   1 9.2.9    376   58   T   N   376.58




1633 Stephens, Adrian   149   1 9.2.11   378   36   T   N   378.36




1634 Stephens, Adrian   149   1 9.3.0a   379   10   T   N   379.10




1635 Stephens, Adrian   149   1 9.3.0a   379   14   T   N   379.14
1636 Stephens, Adrian   149   1 9.3.0a    379   16   T   N   379.16




1637 Stephens, Adrian   149   1 9.3.0a    379   57   T   N   379.57




1638 Stephens, Adrian   149   1 9.10.4               E   N   416.01




1639 Stephens, Adrian   149   1 9.3.4.1   386   15   E   N   386.15

1640 Stephens, Adrian   149   1 9.3.4.2   386   32   T   N   386.32




1641 Stephens, Adrian   149   1 9.4       386   53   T   N   386.53
1642 Stephens, Adrian   149   1 9.5      387   45   T   N   387.45




1643 Stephens, Adrian   149   1 9.5      387   61   T   N   387.61




1644 Stephens, Adrian   149   1 9.6a     389   25   E   N   389.25

1645 Stephens, Adrian   149   1 9.8.0a   390   45   E   N   390.45

1646 Stephens, Adrian   149   1 9.8.1    390   61   T   N   390.61
1647 Stephens, Adrian   149   1 9.9.1.2   397   1    T   N   397.01




1648 Stephens, Adrian   149   1 9.9.1.3   397   42   T   N   397.42




1649 Stephens, Adrian   149   1 9.9.1.3   397   46   T   N   397.46




1650 Stephens, Adrian   149   1 9.9.1.3   398   1    T   N   398.01




1651 Stephens, Adrian   149   1 9.9.1.5   400   13   E   N   400.13
1652 Stephens, Adrian   149   1 9.9.1.5    400   33   T   N   400.33




1653 Stephens, Adrian   149   1 9.9.1.6    400   48   T   N   400.48




1654 Stephens, Adrian   149   1 9.9.2.0a   401   64   E   N   401.64

1655 Stephens, Adrian   149   1 9.9.2.1.2 402    39   T   N   402.39




1656 Stephens, Adrian   149   1 9.9.2.1.3 403    24   T   N   403.24




1657 Stephens, Adrian   149   1 9.9.2.1.3 403    19   T   N   403.19
1658 Stephens, Adrian   149   1 9.9.2.1.3 403   26   T   N   403.26




1659 Stephens, Adrian   149   1 9.9.2.1.3 403   50   T   N   403.50




1660 Stephens, Adrian   149   1 9.9.2.1.3 403   14   E   N   404.14
1661 Stephens, Adrian   149   1 9.9.2.1.3 404    14   T   N   404.14




1662 Stephens, Adrian   149   1 9.9.2.1.3 404    31   E   N   404.31




1663 Stephens, Adrian   149   1 9.9.2.2a   405   18   T   N   405.18




1664 Stephens, Adrian   149   1 9.9.2.2a   405   24   T   N   405.24




1665 Stephens, Adrian   149   1 9.9.2.2a   405   30   T   N   405.30
1666 Stephens, Adrian   149   1 9.9.2.3.0 406   29   T   N   406.29
                                a




1667 Stephens, Adrian   149   1 9.9.2.3.0 407   19   E   N   407.19
                                a
1668 Stephens, Adrian   149   1 9.9.2.3.1 407   30   E   N   407.30

1669 Stephens, Adrian   149   1 9.0a      357   19   E   N   357.19




1670 Stephens, Adrian   149   1 9.1.2     358   27   T   N   358.27




1671 Stephens, Adrian   149   1 9.1.3.1   360   5    T   N   360.05




1672 Stephens, Adrian   149   1 9.2.5.2   369   35   E   N   369.35
1673 Stephens, Adrian   149   1 9.2.5.3    370   24      T   N   370.24




1674 Stephens, Adrian   149   1 9.2.11     378   28      E   N   378.28



1675 Stephens, Adrian   149   1 9.9.1.2    396   50      E   N   396.50




1676 Stephens, Adrian   149   1 9.9.1.5    400   13-18   E   N   400.00




1677 Stephens, Adrian   149   1 9.9.2.0a   401   28      E   N   401.28




1678 Stephens, Adrian   149   1 9.9.2.1.3 403    60      T   N   403.60
1679 Stephens, Adrian   149   1 9.9.2.2a   405   18   E   N   405.18




1680 Stephens, Adrian   149   1 9.9.2.3.2 407    58   E   N   407.58




1681 Stephens, Adrian   149   1 9.9.3.1.0 408    45   T   N   408.45
                                a




1682 Stephens, Adrian   149   1 9.9.3.1.1 409    12   E   N   409.12
1683 Stephens, Adrian   149   1 9.10.3     415   37   T   N   415.37




1684 Stephenson,        149   1 7.3.2.47   209   59   E   N   209.59
     Dave
1685 Stephenson,   149   1 9.9.3.1.0 408   33   T   Y   408.33
     Dave                  a
1686 Stephenson,   149   1 9.9.3.1.0 408   52   T   Y   408.52
     Dave                  a




1687 Stephenson,   149   1 9.9.3.1.2 409   25   T   Y   409.25
     Dave




1688 Stephenson,   149   1 9.9.3.1.2 410   5    T   Y   410.05
     Dave
1689 Stephenson,   149   1 11.4.3   607   34   T   Y   607.34
     Dave




1690 Stephenson,   149   1 11.4.3   607   42   T   Y   607.42
     Dave




1691 Stephenson,   149   1 11.4.4   609   44   T   Y   609.44
     Dave
1692 Stephenson,   149   1 11.4.6   611   49   T   Y   611.49
     Dave




1693 Stephenson,   149   1 11.4.6   611   51   T   Y   611.51
     Dave




1694 Stephenson,   149   1 11.4.6   611   55   T   Y   611.55
     Dave



1695 Stephenson,   149   1 11.4.6   612   5    T   Y   612.05
     Dave
1696 Stephenson,      149   1 11.4.6   612   11   T   Y   612.11
     Dave




1697 Stephenson,      149   1 11.4.7   612   52   T   Y   612.52
     Dave




1698 Thomson, Allan   149   13         20    48   T   Y    20.48


1699 Thomson, Allan   149   13         20    50   T   Y    20.50
1700 Thomson, Allan   149   1 7.2.3.1    92   37      E   Y   92.37




1701 Thomson, Allan   149   1 7.2.3.8    99   5       T   Y   99.05




1702 Venkatesan,      149   1 5.2.7.2    39   26-27   E   N   39.00
     Ganesh




1703 Venkatesan,      149   1 5.2.7.11   40   41-42   T   N   40.00
     Ganesh
1704 Venkatesan,   149   1 5.4       43        42-43   E   N   43.00
     Ganesh




1705 Venkatesan,   149   1 Table 7-8 92        35-38   E   N   92.00
     Ganesh




1706 Venkatesan,   149   1 7.3.1.4   107-108           T   N
     Ganesh
1707 Venkatesan,   149   1 7.3.2.21   134   31      E   N   134.31
     Ganesh




1708 Venkatesan,   149   1 7.3.2.21   134   60      T   N   134.60
     Ganesh




1709 Venkatesan,   149   1 Table 7- 135     24-25   E   N   135.00
     Ganesh                29
1710 Venkatesan,   149   1 7.3.2.21. 151            T   Y   151.00
     Ganesh                10
1711 Venkatesan,   149   1 7.3.2.21. 145   24   T   Y   145.24
     Ganesh                8
1712 Venkatesan,   149   1 7.3.2.{21|          T   Y   143.56
     Ganesh                22}.7




1713 Venkatesan,   149   1 7.3.2.22. 168/169   E   N
     Ganesh                8




1714 Venkatesan,   149   1 7.3.2.22. 173       T   N   173.13
     Ganesh                10
1715 Venkatesan,   149   1 7.3.2.21. 148, 173          T   N   148.00
     Ganesh                10,
                           7.3.2.22.
                           10




1716 Venkatesan,   149   1 7.3.2.25, 178, 183 31, 62   E   N   178.00
     Ganesh                7.3.2.27




1717 Venkatesan,   149   1 7.3.2.31                    T   Y   191.56
     Ganesh




1718 Venkatesan,   149   1 7.3.1.17   115              T   N   115.44
     Ganesh




1719 Venkatesan,   149   1 7.3.2.37   199       5-6    T   N   199.00
     Ganesh
1720 Venkatesan,   149   1 7.3.2     E   N   117.56
     Ganesh




1721 Venkatesan,   149   1 General   T   Y
     Ganesh
1722 Vlantis, George   149   1 G.2        1426   53   T   N   1426.53




1723 Yee, James        149   1 3.2.3      8      1    E   N      8.01

1724 Yee, James        149   1 9.1.1      357    62   E   N    357.62


1725 Yee, James        149   1 9.1.3.1    358    59   T   N    358.59




1726 Yee, James        149   1 9.2.0a     363    22   T   N    363.22




1727 Yee, James        149   1 9.2.3.0a   364    52   E   N    364.52
1728 Yee, James       149   1 9.9.2.0a   401    28   E   N    401.28




1729 Yee, James       149   1 19         941    1    E   N    941.01


2000 Armstrong, Lee   160   2 14.8.2.4   811    9    T   Y    811.09




2001 Armstrong, Lee   160   2 A.4.5      1048   47   T   Y   1048.47




2002 Armstrong, Lee   160   2 A.4.6      1058   50   T   Y   1058.50




2003 Armstrong, Lee   160   2 A.4.7      1062   23   T   Y   1062.23




2004 Armstrong, Lee   160   2 A4.8       1074   25   T   Y   1074.25




2005 Armstrong, Lee   160   2 A4.9       1094   40   T   Y   1094.40
2006 Armstrong, Lee   160   2 15.3.2   825    59   T   Y    825.59




2007 Armstrong, Lee   160   2 16.4     870    27   T   Y    870.27




2008 Armstrong, Lee   160   2 18.3.2   939    16   T   Y    939.16




2009 Armstrong, Lee   160   2 C.2      1189   2    T   Y   1189.02
2010 Armstrong, Lee   160   2D   1419   30   T   Y   1419.30




2011 Armstrong, Lee   160   2D   1419   65   T   Y   1419.65




2012 Armstrong, Lee   160   2D   1522   1    T   Y   1522.01
2013 Armstrong, Lee     160   2 14.8.2.1   809   18   T   Y   809.18




2014 Ashley, Alex       160   2 9.3.3.1    398   65   T   Y   398.65




2015 Ashley, Alex       160   2 11.4.2     644   44   T   Y   644.44




2016 Ecclesine, Peter   160   2 11.9a.1    672   19   T   Y   672.19




2017 Ecclesine, Peter   160   2 11.10.12. 693    42   E   Y   693.42
                                1
2018 Ecclesine, Peter   160   2 Annex D 1351   63   T   Y   1351.63




2019 Ecclesine, Peter   160   2 Annex D 1353   60   T   Y   1353.60




2020 Ecclesine, Peter   160   2 Annex D 1368   47   E   Y   1368.47

2021 Ecclesine, Peter   160   2 Annex D 1370   11   T   Y   1370.11




2022 Ecclesine, Peter   160   2 Annex D 1444   25   T   Y   1444.25
2023 Ecclesine, Peter   160   2 Annex D 1451   20   T   Y   1451.20




2024 Ecclesine, Peter   160   2 Annex D 1438   31   T   Y   1438.31




2025 Ecclesine, Peter   160   2 Annex D 1432   57   T   Y   1432.57
2026 Ecclesine, Peter   160   2 8.2.2.2   261    28   T   N    261.28




2027 Ecclesine, Peter   160   2 9.6a      404    25   T   Y    404.25




2028 Ecclesine, Peter   160   2 Annex A   1096   47   T   Y   1096.47




2029 Ecclesine, Peter   160   2 7.3.1.4   108    45   T   Y    108.45
2030 Ecclesine, Peter   160   2 Annex D 1354     20   T   Y   1354.20




2031 Ecclesine, Peter   160   2 Annex A   1020   20   T   Y   1020.20




2032 Ecclesine, Peter   160   2 Annex A   1020   15   E   Y   1020.15




2033 Ecclesine, Peter   160   2 Annex I   1625   43   T   Y   1625.43




2034 Ecclesine, Peter   160   2 Annex I   1628   39   T   Y   1628.39


2035 Ecclesine, Peter   160   2 Annex J   1633   40   T   Y   1633.40




2036 Ecclesine, Peter   160   2 Annex I   1626   20   E   Y   1626.20
2037 Ecclesine, Peter   160   2 11.1.3.0a 617    43   E   Y    617.43




2038 Ecclesine, Peter   160   2 7.1.3.3.1 78     30   E   Y     78.30




2039 Ecclesine, Peter   160   2 Annex D 1389     2    E   Y   1389.02




2040 Ecclesine, Peter   160   2 Annex B   1125   1    E   Y   1125.01




2041 Ecclesine, Peter   160   2 Annex I   1628   15   T   Y   1628.15



2042 Ecclesine, Peter   160   2 Annex J   1635   11   T   Y   1635.11




2043 Ecclesine, Peter   160   2 Annex J   1635   9    E   Y   1635.09
2044 Ecclesine, Peter   160   2 Annex J   1633   25   T   Y   1633.25




2045 Ecclesine, Peter   160   2 Annex J   1633   6    T   Y   1633.06




2046 Ecclesine, Peter   160   2 Annex A   1023   10   E   Y   1023.10




2047 Ecclesine, Peter   160   2 10.3.1.1. 443    41   E   Y    443.41
                                2
2048 Ecclesine, Peter   160   2 Annex D 1352   23   T   Y   1352.23




2049 Ecclesine, Peter   160   2 Annex D 1502   14   E   Y   1502.14
2050 Ecclesine, Peter   160   2 Annex D 1500   34   T   Y   1500.34




2051 Ecclesine, Peter   160   2 17.4.2   910   28   E   Y    910.28

2052 Ecclesine, Peter   160   2 Annex D 1440   31   T   Y   1440.31
2053 Ecclesine, Peter   160   2 Annex D 1440   18   T   Y   1440.18




2054 Ecclesine, Peter   160   2 Annex D 1449   52   T   Y   1449.52




2055 Ecclesine, Peter   160   2 Annex D 1449   31   T   Y   1449.31
2056 Ecclesine, Peter   160   2 Annex D 1449     30   T   Y   1449.30




2057 Ecclesine, Peter   160   2 11.11.2.2 696    43   E   Y    696.43

2058 Ecclesine, Peter   160   2 Annex A   1058   50   T   Y   1058.50




2059 Ecclesine, Peter   160   2 Annex A   1074   24   T   Y   1074.24




2060 Ecclesine, Peter   160   2 Annex A   1094   40   T   Y   1094.40
2061 Ecclesine, Peter   160   2 Annex D 1419      65   T   Y   1419.65




2062 Ecclesine, Peter   160   2 Annex A    1062   24   T   Y   1062.24


2063 Ecclesine, Peter   160   2 Annex A    1106   42   T   Y   1106.42




2064 Ecclesine, Peter   160   2 Annex A    1105   55   T   Y   1105.55




2065 Ecclesine, Peter   160   2 Annex A    1107   6    T   Y   1107.06


2066 Ecclesine, Peter   160   2 Annex A    1024   40   T   Y   1024.40




2067 Ecclesine, Peter   160   2 7.3.2.48   214    1    E   Y    214.01
2068 Ecclesine, Peter   160   2 7.4.7.9   243   60   E   Y    243.60




2069 Ecclesine, Peter   160   2 Annex D 1346    54   T   Y   1346.54




2070 Ecclesine, Peter   160   2 11.2.1.0a 621   50   T   Y    621.50
2071 Ecclesine, Peter   160   2 Annex D 1353   23   T   Y   1353.23




2072 Ecclesine, Peter   160   2 Annex D 1352   17   T   Y   1352.17




2073 Ecclesine, Peter   160   2 Annex D 1352   34   T   Y   1352.34




2074 Ecclesine, Peter   160   2 Annex D 1354   15   T   Y   1354.15
2075 Ecclesine, Peter   160   2 Annex D 1369   44   T   Y   1369.44




2076 Ecclesine, Peter   160   2 Annex D 1369   58   T   Y   1369.58




2077 Ecclesine, Peter   160   2 Annex D 1370   11   T   Y   1370.11
2078 Ecclesine, Peter   160   2 Annex D 1388        T   Y   1388.00




2079 Engwer, Darwin     160   2M        1651   1    T   Y   1651.01




2080 Engwer, Darwin     160   2 0A      1019   32   T   Y   1019.32




2081 Engwer, Darwin     160   2 9.8.2   406    22   T   Y    406.22
2082 Erceg, Vinko   160   2 17.3.10.5 ame   15-19   T   Y   902.20




2083 Erceg, Vinko   160   2 General                 E   N




2084 Erceg, Vinko   160   23          k     20      E   N    10.64




2085 Erceg, Vinko   160   2 5.4.1.2   ax    20      E   N    44.01

2086 Erceg, Vinko   160   2 5.4.3.3   bb    41      E   N    48.01




2087 Erceg, Vinko   160   2 5.4.4.1   bc    58      E   N    49.40




2088 Erceg, Vinko   160   2 17.3.8.3. alw   54      T   Y   895.34
                            1
2089 Fischer, Matthew   160   2 9.14.0b    sd    64   T   N   438.28




2090 Fischer, Matthew   160   2 9.8.2      qu    46   T   N   406.06




2091 Fischer, Matthew   160   2 11.2.1.1   aak   26   T   N   622.19




2092 Hamilton, Mark     160   2 6.2.3.2    71    6    T   Y    71.06




2093 Hamilton, Mark     160   2 6.3.2.2    71    2    T   N    71.02
2094 Hamilton, Mark   160   2 10.1       441   30   T   Y   441.30




2095 Hamilton, Mark   160   2 9.9.3.1.0 423    40   T   Y   423.40
                              a




2096 Hamilton, Mark   160   2 10.3.20.2 515    1    T   Y   515.01




2097 Hamilton, Mark   160   2 8.5.6.0a   345   19   E   N   345.19
2098 Harkins, Dan   160   2 8.4.1.1.1 288   1-2     T   Y   289.01




2099 Harkins, Dan   160   2 8.4.1.1.1 288   4       T   Y   289.04




2100 Harkins, Dan   160   2 8.4.6.2   299   32-33   T   Y   299.00
2101 Harkins, Dan       160   2 8.5.1.2   307   41-42   T   Y   307.00




2102 Hiertz, Guido R.   160   2 3.196     19    1-4     T   Y    19.00




2103 Kolze, Tom         160   2 17.3.10.5 ame   15-19   T   Y   902.20
2104 Kolze, Tom       160   2 17.3.8.3. alw   54   T   Y   895.34
                              1




2105 Malinen, Jouni   160   2 6.1.2    65     32   T   Y    65.32




2106 Malinen, Jouni   160   2 7.3.2.25. 181   50   T   Y   181.50
                              1
2107 Malinen, Jouni   160   2 7.3.2.48   214   37   T   Y   214.37




2108 Malinen, Jouni   160   2 8.5.2      318   39   E   Y   318.39




2109 Malinen, Jouni   160   2 8.5.6.0a   344   54   E   Y   344.54
2110 Malinen, Jouni   160   2 11.3.0a   634   33   T   Y   634.33




2111 Malinen, Jouni   160   2 11.3.1.0a 635   57   T   Y   635.57
2112 Malinen, Jouni   160   2 11.3.2.3   640   44   T   Y   640.44




2113 Malinen, Jouni   160   2 7.3.2.54   219   21   T   Y   219.21
2114 Marshall, Bill   160   2 Annex D 1527    38   E   N   1527.38




2115 Marshall, Bill   160   2 Annex D              T   N   1342.01




2116 Marshall, Bill   160   2 Annex C 1138    1    T   N   1138.01




2117 Marshall, Bill   160   2 11.7.0a   658   31   E   N    658.31
2118 Marshall, Bill   160   2 Annex D               E   N   1342.01




2119 Marshall, Bill   160   2 General               E   N




2120 Marshall, Bill   160   2 11.3.1.3   637   33   E   N    637.33
2121 Marshall, Bill   160   2 Annex D             T   N   1342.01




2122 Marshall, Bill   160   2 Annex Q 1671   10   E   N   1671.10
2123 Marshall, Bill   160   2 19.1.1    977    34   T   N    977.34




2124 Marshall, Bill   160   2 11.1.3.0a 617    43   T   N    617.43




2125 Marshall, Bill   160   2 Annex A   1020   16   E   N   1020.16




2126 Montemurro,      160   2 General               E   N
     Michael
2127 Montemurro,   160   2 7.4.9a     374   27   T   N   250.09
     Michael




2128 Montemurro,   160   2 11.3       809   1    T   N   633.34
     Michael




2129 Montemurro,   160   2 11.3.1.4   814   40   T   N   637.61
     Michael
2130 Montemurro,        160   2 11.3.2.8   820   51   T   N   643.28
     Michael




2131 Ptasinski, Henry   160   2 8.1.3      254   58   E   N   254.58


2132 Ptasinski, Henry   160   2 8.1.3      255   59   T   Y   255.59




2133 Ptasinski, Henry   160   2 8.1.3      255   6    E   N   255.06




2134 Ptasinski, Henry   160   2 8.1.3      255   10   E   N   255.10




2135 Ptasinski, Henry   160   2 8.1.3      255   10   T   Y   255.10



2136 Ptasinski, Henry   160   2 8.3.3.3.3 283    30   T   Y   283.30
2137 Ptasinski, Henry   160   2 8.3.3.3.5 284   6    T   Y   284.06




2138 Ptasinski, Henry   160   2 8.3.3.4.0 284   51   T   Y   284.51
                                a


2139 Ptasinski, Henry   160   2 8.3.3.4.1 285   5    T   Y   285.05




2140 Purnadi, Rene      160   2 7.4.7.2   235   13   E   N   237.19




2141 Purnadi, Rene      160   2 11.9a.1   634   47   E   N   672.13




2142 Purnadi, Rene      160   2 11.9a.3.1 635   47   T   N   672.55
2143 Purnadi, Rene    160   2 11.9a.3.2 636   32      T   N   673.47




2144 Purnadi, Rene    160   2 11.10.3   637   65      E   N   675.17




2145 Raja, Banerjea   160   2 9.13      437   20-34   T   N   437.00
2146 Raja, Banerjea   160   2 11.2.2.4    632   56-57   T   N   632.00




2147 Raja, Banerjea   160   2 10.3.2.2.   447   54      T   N   447.54
                              2
2148 Raja, Banerjea   160   2 10.3.10.1   482   45      T   N   482.45
                              .2
2149 Raja, Banerjea   160   2 10.3.10a.   484   64      T   N   484.64
                              1.2
2150 Raja, Banerjea   160   2 10.3.10.1   482   49      T   N   482.49
                              .2




2151 Rosdahl, Jon     160   23            11    1       T   Y    11.01
2152 Rosdahl, Jon   160   2 11.2.1.0a              T   Y   621.47




2153 Rosdahl, Jon   160   2 1.2         1     51   T   Y     1.51




2154 Rosdahl, Jon   160   23            11    61   E   N    11.61



2155 Rosdahl, Jon   160   2 11.3.0a     633   45   T   Y   633.45
2156 Rosdahl, Jon   160   2 11.3.0a    634   42   T   Y   634.42




2157 Rosdahl, Jon   160   2 11.3.1.3   637   36   T   Y   637.36




2158 Rosdahl, Jon   160   2 11.3.1.4   638   1    E   Y   638.01




2159 Rosdahl, Jon   160   2 11.3.2.4   642   8    T   Y   642.08
2160 Rosdahl, Jon   160   2 11.3.0a   634   T   Y   634.00
2161 Rosdahl, Jon   160   2 11.3.1.0a 636    1    T   Y   636.01




2162 Rosdahl, Jon   160   2 11.3.2.0a 638    34   T   Y   638.34




2163 Rosdahl, Jon   160   2 11.3.1.1   636   12   T   Y   636.12
2164 Rosdahl, Jon   160   2 11.3.1.4   637   54   T   Y   637.54




2165 Rosdahl, Jon   160   2 11.3.2.6   642   49   T   Y   642.49
2166 Rosdahl, Jon   160   2 11.3.1.2   637   4    T   Y   637.04




2167 Rosdahl, Jon   160   2 11.3.2.1   638   55   T   Y   638.55




2168 Rosdahl, Jon   160   2 11.3.2.5   642   17   T   Y   642.17
2169 Rosdahl, Jon   160   2 11.3.1.3   637   17   T   Y   637.17




2170 Rosdahl, Jon   160   2 11.3.0a    635   12   E   Y   635.12

2171 Rosdahl, Jon   160   2 11.3.0a    635   32   E   Y   635.32

2172 Rosdahl, Jon   160   2 11.3                  E   Y   633.34
2173 Rosdahl, Jon   160   2 11.3   E   Y   633.34




2174 Rosdahl, Jon   160   2 11.3   E   Y   633.34




2175 Rosdahl, Jon   160   23       T   Y     6.01
2176 Rosdahl, Jon       160   2 11.2                  T   Y    621.39




2177 Sakoda,            160   23          15     56   T   N     15.56
     Kazuyuki




2178 Sakoda,            160   2 A.4.4.2   1039   20   T   N   1039.20
     Kazuyuki




2179 Stephens, Adrian   160   2           iv     28   T   N
2180 Stephens, Adrian   160   2   33    44   T   Y    33.44




2181 Stephens, Adrian   160   2   108   6    T   Y   108.06




2182 Stephens, Adrian   160   2   108   26   T   Y   108.26
2183 Stephens, Adrian   160   2   109   22   T   Y   109.22




2184 Stephens, Adrian   160   2   109   45   T   N   109.45




2185 Stephens, Adrian   160   2   135   36   T   Y   135.36




2186 Stephens, Adrian   160   2   214   29   T   N   214.29
2187 Stephens, Adrian   160   2           243   53   T   Y   243.53


2188 Stephens, Adrian   160   2           280   37   T   N   280.37




2189 Stephens, Adrian   160   2 General              T   N




2190 Stephens, Adrian   160   2           342   49   T   Y   342.49




2191 Stephens, Adrian   160   2           365   10   T   N   365.10




2192 Stephens, Adrian   160   2           369   34   T   N   369.34
2193 Stephens, Adrian   160   2   441   23   T   N   441.23




2194 Stephens, Adrian   160   2   555   20   T   Y   555.20




2195 Stephens, Adrian   160   2   572   25   T   Y   572.25
2196 Stephens, Adrian   160   2   636   39   T   N   636.39
2197 Stephens, Adrian   160   2   637   36   T   N   637.36
2198 Stephens, Adrian   160   2   642   5   T   N   642.05
2199 Stephens, Adrian   160   2   739    47   T   Y    739.47




2200 Stephens, Adrian   160   2   1432   30   T   Y   1432.30
2201 Stephens, Adrian   160   2             1432   38   T   N   1432.38




2202 Stephens, Adrian   160   2             1438   28   T   N   1438.28




2203 Stephens, Adrian   160   2             1502   14   T   Y   1502.14




2204 Stephens, Adrian   160   2             1622   42   E   N   1622.42



2205 Stephens, Adrian   160   2 7.1.3.1.7               T   N     76.46




2206 Stephens, Adrian   160   2 7.4.7.10                T   Y    245.01
2207 Stephens, Adrian   160   2 10.3.40    T   N   587.45




2208 Stephens, Adrian   160   2 10.3.44    T   Y   603.01




2209 Stephens, Adrian   160   2 11.2.2.3   T   Y   632.01
2210 Stephens, Adrian   160   2             635   29   E   N   635.29



2211 Stephens, Adrian   160   2 General                E   N

2212 Stephens, Adrian   160   2             696   57   T   Y   696.57




2213 Stephens, Adrian   160   2 11.11.2.4              T   N   697.38
2214 Stephens, Adrian   160   2 General               E   N




2215 Stephens, Adrian   160   2 17.4.3    910    38   E   Y    910.38




2216 Stephens, Adrian   160   2 11.6.2                E   N    658.01




2217 Stephens, Adrian   160   2 F.0a      1559   19   E   N   1559.19
2218 Stephens, Adrian   160   2 7.3.2.21. 136   11   E   N   136.11
                                1


2219 Stephens, Adrian   160   2 8.5.3.5   331   17   T   Y   331.17




2220 Stephenson,        160   2 7.1.3.3.3 79    6    T   Y    79.06
     Dave




2221 Stephenson,        160   2 10.3.24.3 524   65   E   N   524.65
     Dave                       .3
2222 Stephenson,   160   2 11.2.1.0a 621   47-52   T   Y   621.00
     Dave
2223 Stephenson,   160   2 11.2.1.0a 621    54-57   T   Y   621.00
     Dave




2224 Stephenson,   160   2 11.2.1.0a 622    11      T   Y   622.11
     Dave




2225 Stephenson,   160   2 11.2.1.4   624   46      T   Y   624.46
     Dave
2226 Stephenson,   160   2 11.2.1.5   625   42   T   Y   625.42
     Dave




2227 Stephenson,   160   2 11.2.1.9   629   45   T   Y   629.45
     Dave




2228 Stephenson,   160   2 11.2.1.9   629   49   T   Y   629.49
     Dave
2229 Stephenson,   160   2 11.3.1.0a 635   56   T   Y   635.56
     Dave




2230 Stephenson,   160   2 11.3.1.0a 635   58   T   Y   635.58
     Dave
2231 Stephenson,   160   2 11.3.1.0a 635   58   T   Y   635.58
     Dave




2232 Stephenson,   160   2 11.4.3   644    57   T   Y   644.57
     Dave




2233 Stephenson,   160   2 11.4.3   645    47   T   Y   645.47
     Dave
2234 Stephenson,   160   2 11.4.4   646   48      T   Y   646.48
     Dave




2235 Stephenson,   160   2 11.4.4   647   16      T   Y   647.16
     Dave

2236 Stephenson,   160   2 11.4.4   647   25      T   Y   647.25
     Dave




2237 Stephenson,   160   2 11.4.4   647   24-31   T   Y   647.00
     Dave




2238 Stephenson,   160   2 11.4.6   649   50      T   Y   649.50
     Dave




2239 Stephenson,   160   2 11.4.6   649   55      E   N   649.55
     Dave
2240 Stephenson,      160   2 11.4.6      649    55   T   Y    649.55
     Dave




2241 Stephenson,      160   2 11.4.6      649    55   T   Y    649.55
     Dave




2242 Stephenson,      160   2 11.4.6      650    1    T   Y    650.01
     Dave


2243 Stephenson,      160   2 11.4.8      650    55   E   N    650.55
     Dave




2244 Stephenson,      160   2 11.4.8      650    58   E   N    650.58
     Dave



2245 Venkatesan,      160   2 Table 7-                E   N    136.03
     Ganesh                   29 and 7-
                              30




3000 Armstrong, Lee   162   3 20.3.20     1279   12   T   Y   1279.12
3001 Armstrong, Lee   162   3A         1330   56   T   Y   1330.56




3002 Armstrong, Lee   162   3A         1354   47   T   Y   1354.47




3003 Armstrong, Lee   162   3A         1380   7    T   Y   1380.07




3004 Armstrong, Lee   162   3A         1399   10   T   Y   1399.10




3005 Armstrong, Lee   162   3D         1879   27   T   Y   1879.27




3006 Armstrong, Lee   162   3 19.8.2   1196   29   T   Y   1196.29




3007 Armstrong, Lee   162   3 20.4.2   1294   40   T   Y   1294.40
3008 Armstrong, Lee   162   3C         1518   1    T   Y   1518.01




3009 Armstrong, Lee   162   3C         1518   2    T   Y   1518.02




3010 Armstrong, Lee   162   3D         1878   53   T   Y   1878.53




3011 Armstrong, Lee   162   3D         1921   38   T   Y   1921.38




3012 Bajko, Gabor     162   3 7.3.2.22. 213   9    T   N    213.09
                              9
3013 Bajko, Gabor    162   3 7.3.2.21. 188     7    T   N    188.07
                             9




3014 Cypher, David   162   30                       T   N




3015 Cypher, David   162   3 14.8.2.4   1001   1    T   Y   1001.01




3016 Cypher, David   162   3 17.4.2     1098   54   T   Y   1098.54

3017 Cypher, David   162   3 19.8.2     1196   29   T   Y   1196.29


3018 Cypher, David   162   3 20.3.20    1279   7    T   Y   1279.07


3019 Cypher, David   162   3 20.4.2     1294   45   T   Y   1294.45
3020 Cypher, David      162   3 A.4.3     1330   56-63   T   Y   1330.00




3021 Cypher, David      162   3 A.4.5     1354   47-51   T   Y   1354.00




3022 Cypher, David      162   3 A.4.8     1380   6-15    T   Y   1380.00



3023 Cypher, David      162   3 A.4.9     1399   10-15   T   Y   1399.00



3024 Cypher, David      162   3 D.3       1878   56      T   Y   1878.56




3025 Ecclesine, Peter   162   3 Annex A   1401   34      T   N   1401.34



3026 Ecclesine, Peter   162   3 Annex J   2067   31      T   N   2067.31
3027 Ecclesine, Peter   162   3 Annex J   2067   36   T   N   2067.36




3028 Ecclesine, Peter   162   3 20.3.20   1279   7    T   Y   1279.07




3029 Ecclesine, Peter   162   3 10.3.37.1 739    62   T   N    739.62
                                .3
3030 Ecclesine, Peter   162   3 Annex I   2051   3    T   N   2051.03




3031 Ecclesine, Peter   162   3 11.11.5   867    60   E   N    867.60

3032 Ecclesine, Peter   162   3 3.1       8      21   E   N      8.21
3033 Ecclesine, Peter   162   3 3.1   8   12   E   N   8.12
3034 Ecclesine, Peter   162   3 3.1   8   21   E   N   8.21
3035 Ecclesine, Peter   162   3 3.1   6   49   E   Y   6.49
3036 Ecclesine, Peter   162   3 3.1   9   50   E   Y   9.50
3037 Ecclesine, Peter   162   3 3.1        11    20   E   Y    11.20




3038 Liwen, Chu         162   3 7.1.3.5.3 92     40   T   Y    92.40




3039 Liwen, Chu         162   3 7.1.4.2    99    38   T   Y    99.38




3040 Liwen, Chu         162   3 7.3.2.31   237   11   E   Y   237.11
3041 Liwen, Chu   162   3 9.1.3.1    453   58   T   Y   453.58




3042 Liwen, Chu   162   3 9.1.5      455   60   T   Y   455.60




3043 Liwen, Chu   162   3 9.2.0b.3   458   24   T   Y   458.24




3044 Liwen, Chu   162   3 9.2.0b.4. 460    52   T   Y   460.52
                          6



3045 Liwen, Chu   162   3 9.2.0b.6   462   26   T   Y   462.26




3046 Liwen, Chu   162   3 9.9.1.2    510   30   T   Y   510.30




3047 Liwen, Chu   162   3 9.9.1.3    510   54   T   Y   510.54
3048 Liwen, Chu   162   3 11.1.3.2. 780    6    T   Y   780.06
                          2




3049 Liwen, Chu   162   3 11.2.1.0a 784    50   T   Y   784.50




3050 Liwen, Chu   162   3 11.2.1.4   788   24   T   Y   788.24




3051 Liwen, Chu   162   3 11.2.1.5   788   48   T   Y   788.48




3052 Liwen, Chu   162   3 11.2.1.5   789   18   E   Y   789.18
3053 Liwen, Chu   162   3 11.2.1.9   793   31   T   Y   793.31




3054 Liwen, Chu   162   3 11.2.1.12 794    5    T   Y   794.05
3055 Liwen, Chu   162   3 11.2.1.12 794    26   T   Y   794.26




3056 Liwen, Chu   162   3 11.2.2.4   797   43   T   Y   797.43




3057 Liwen, Chu   162   3 11.4.44    814   38   T   Y   814.38




3058 Liwen, Chu   162   3 9.16.1.7   562   56   T   Y   562.56
3059 Liwen, Chu    162   3 11.9.7.3   839   30      T   Y   839.30




3060 Liwen, Chu    162   3 7.3.27     227   28      T   Y   227.28




3061 Montemurro,   162   3 7.3.2.37   242   60      T   N   242.60
     Michael




3062 Ramamurthy,   162   3 7.3.2.27   228   38-52   T   N   228.00
     Harish


3063 Ramamurthy,   162   3 11.1.3.2. 779    40-44   T   Y   779.00
     Harish                1
3064 Ramamurthy,   162   3 11.2.1.0a 784    17-20   T   Y   784.00
     Harish




3065 Ramamurthy,   162   3 11.2.1.1   785   53-54   T   Y   785.00
     Harish
3066 Ramamurthy,   162   3 7.3.2.4    163   4-5     T   Y   163.00
     Harish




3067 Ramamurthy,   162   3 11.1.2.2   776   57-58   T   Y   776.00
     Harish




3068 Ramamurthy,   162   3 11.2.2.1   795   5-9     T   Y   795.00
     Harish
3069 Ramamurthy,   162   3 11.2.2.1   795   13-16   T   Y   795.00
     Harish




3070 Ramamurthy,   162   3 11.2.2.4   797   43-46   T   Y   797.00
     Harish
3071 Ramamurthy,   162   3 11.2.2     794           T   Y   794.00
     Harish




3072 Ramamurthy,   162   3 11.2.1.5   789   22-24   T   Y   789.00
     Harish
3073 Rosdahl, Jon   162   3 11.3      800   25   T   Y   800.25




3074 Rosdahl, Jon   162   3 11.3.0a   801        T   Y   801.00
3075 Rosdahl, Jon   162   3 11.3.1.2   802   50   T   Y   802.50




3076 Rosdahl, Jon   162   3 11.3.1.0a 802    8    T   Y   802.08




3077 Rosdahl, Jon   162   3 11.3.2.0a 804    31   T   Y   804.31




3078 Rosdahl, Jon   162   3 11.3.2.6   808   39   T   Y   808.39
3079 Rosdahl, Jon   162   3 11.3.2.7   808    64   T   Y    808.64




3080 Rosdahl, Jon   162   3 11.3.1.2   802    62   T   Y    802.62




3081 Rosdahl, Jon   162   3 A.4.11     1407   13   T   N   1407.13
3082 Rosdahl, Jon   162   3 A.4.4.1   1344   23   T   Y   1344.23




3083 Rosdahl, Jon   162   3 20.3.12.1 1269   25   T   Y   1269.25
3084 Sakoda,            162   3 7.4       279         E   N    279.01
     Kazuyuki




3085 Sakoda,            162   3 7.4.2.1   282    34   T   N    282.34
     Kazuyuki




3086 Sakoda,            162   3 A.4.5.3   1360   27   T   N   1360.27
     Kazuyuki




3087 Stephens, Adrian   162   3 General               E   N
3088 Stephens, Adrian   162   3           133   30   T   N   133.30



3089 Stephens, Adrian   162   3 General              E   N




3090 Stephens, Adrian   162   3           255   1    E   N   255.01




3091 Stephens, Adrian   162   3           543   6    T   N   543.06




3092 Stephens, Adrian   162   3           739   58   T   N   739.58
3093 Stephens, Adrian   162   3   784   8    T   Y   784.08




3094 Stephens, Adrian   162   3   784   60   T   N   784.60




3095 Stephens, Adrian   162   3   784   63   T   N   784.63




3096 Stephens, Adrian   162   3   794   59   T   Y   794.59
3097 Stephens, Adrian   162   3           802   49   T   N   802.49




3098 Stephens, Adrian   162   3 General              E   N




3099 Stephens, Adrian   162   3           803   36   T   N   803.36
3100 Stephens, Adrian   162   3   808   25   T   N   808.25




3101 Stephens, Adrian   162   3   808   54   T   N   808.54




3102 Stephens, Adrian   162   3   809   26   T   N   809.26
3103 Stephens, Adrian   162   3   233    5    T   Y    233.05




3104 Stephens, Adrian   162   3   894    47   T   Y    894.47




3105 Stephens, Adrian   162   3   894    57   T   Y    894.57




3106 Stephens, Adrian   162   3   1259   56   T   N   1259.56



3107 Stephens, Adrian   162   3   1279   10   T   Y   1279.10
3108 Stephens, Adrian   162   3   1291   50   T   N   1291.50




3109 Stephens, Adrian   162   3   1292   4    T   N   1292.04




3110 Stephens, Adrian   162   3   1407   13   T   Y   1407.13
3111 Stephens, Adrian   162   3           1669   32   T   Y   1669.32




3112 Stephens, Adrian   162   3           1763   27   T   Y   1763.27



3113 Stephens, Adrian   162   3           1788   32   T   N   1788.32


3114 Stephens, Adrian   162   3           1945   37   T   N   1945.37




3115 Stephens, Adrian   162   3 General               E   N


3116 Stephens, Adrian   162   3           2051   4    T   Y   2051.04




3117 Stephens, Adrian   162   3           2052   30   E   N   2052.30

3118 Stephens, Adrian   162   3           2112   32   E   N   2112.32

3119 Stephens, Adrian   162   3           296    40   E   N    296.40
3120 Stephens, Adrian   162   3 8.7.2.4               E   N   447.42



3121 Stephens, Adrian   162   3 11.5.2.1              T   N   821.56



3122 Stephenson,        162   3 11.2.1.1   785   29   T   Y   785.29
     Dave




3123 Stephenson,        162   3 11.2.1.1   785   49   T   Y   785.49
     Dave
3124 Stephenson,   162   3 11.2.1.4   787   26   E   N   787.26
     Dave




3125 Stephenson,   162   3 11.2.1.5   789   4    T   Y   789.04
     Dave




3126 Stephenson,   162   3 11.2.1.5   789   23   T   Y   789.23
     Dave




3127 Stephenson,   162   3 11.2.1.5   789   54   T   Y   789.54
     Dave
3128 Stephenson,   162   3 11.2.1.7   792   35   T   Y   792.35
     Dave




3129 Stephenson,   162   3 11.2.1.11 793    62   T   Y   793.62
     Dave
3130 Stephenson,   162   33       18    1    T   Y    18.01
     Dave




3131 Stephenson,   162   3 11.4   809   40   T   Y   809.40
     Dave
3132 Stephenson,       162   3 11.4.3   810    47   T   Y    810.47
     Dave




3133 Stephenson,       162   3 9.9.3.1.1 524   30   T   Y    524.30
     Dave




3134 Stephenson,       162   3 9.9.3.1.1 524   30   T   Y    524.30
     Dave




3135 Vlanits, George   162   3 19.8.2   1196   28   T   Y   1196.28
3136 Vlanits, George   162   3 20.3.20   1279   7    T   Y   1279.07




3137 Vlanits, George   162   3 20.4.2    1294   44   T   Y   1294.44




3138 Vlanits, George   162   3 A.4.3     1330   53   T   Y   1330.53




3139 Vlanits, George   162   3 A.4.3     1330   56   T   Y   1330.56




3140 Vlanits, George   162   3 A.4.5     1354   47   T   Y   1354.47




3141 Vlanits, George   162   3 A.4.8     1380   6    T   Y   1380.06
3142 Vlanits, George   162   3 A.4.9   1399   10   T   Y   1399.10




3143 Vlanits, George   162   3 C.2     1518   12   T   N   1518.12




3144 Vlanits, George   162   3D        1878   56   T   N   1878.56



3145 Vlanits, George   162   3D        1879   27   T   N   1879.27




3146 Vlanits, George   162   3D        1879   28   T   Y   1879.28




3147 Vlanits, George   162   3D        1921   39   T   N   1921.39
3148 Vlanits, George   162   3 G.3.6      2010   50   T   Y   2010.50




4000 Armstrong, Lee    163   4A           1316   55   T   Y   1316.55



4001 Armstrong, Lee    163   4D           1863   16   T   Y   1863.16




4002 Bahr, Michael     163   4 7.3.2.6    164    25   E   N    164.25




4003 Bahr, Michael     163   4 7.3.2.48   258    1    E   N    258.01




4004 Bahr, Michael     163   4 7.3.2.48   258    1    E   N    258.01
4005 Bahr, Michael   163   4 7.3.2.0a   158       38      E   N   158.38




4006 Bahr, Michael   163   4 7.3.2.1    161       64      E   N   161.64


4007 Bahr, Michael   163   4 7.3.2.1    161       64      E   N   161.64




4008 Bahr, Michael   163   4 7.3.2.2    162       6       E   N   162.06




4009 Bahr, Michael   163   4 7.3.2.3    162-163   65-1    E   N   162.65




4010 Bahr, Michael   163   4 7.3.2.4    163       31      E   N   163.31




4011 Bahr, Michael   163   4 7.3.2.5    163       46-49   E   N   163.00




4012 Bahr, Michael   163   4 7.3.2.7    165       5       E   N   165.05
4013 Bahr, Michael   163   4 7.3.2.8    165   20-21   E   N   165.00




4014 Bahr, Michael   163   4 7.3.2.14   169   55      E   N   169.55




4015 Bahr, Michael   163   4 7.3.2.25. 221    41      E   N   221.41
                             0a



4016 Bahr, Michael   163   4 7.3.2.25. 221    41-42   E   N   221.41
                             0a




4017 Bahr, Michael   163   4 7.3.2.26   228   14,16   E   N   228.14




4018 Bahr, Michael   163   4 7.3.2.39   247   53-54   E   N   247.53




4019 Bahr, Michael   163   4 9.8.3      507   26      E   N   507.26




4020 Bahr, Michael   163   4 11.10.9.2 844    28      E   N   844.28




4021 Bahr, Michael   163   4 7.3.2.37   245   56      E   N   245.56




4022 Bahr, Michael   163   4 11.10.9.2 844    30      E   N   844.30
4023 Chu, Liwen   163   4 7.1.3.1.7 86    11   E   N    86.11




4024 Chu, Liwen   163   4 7.2.2.2   115   34   T   Y   115.34




4025 Chu, Liwen   163   4 7.1.3.5.3 92    40   T   Y    92.40




4026 Chu, Liwen   163   4 7.1.3.1.8 86    44   T   Y    86.44
4027 Chu, Liwen   163   4 7.1.3.5.0 90     6    T   Y    90.06
                          a




4028 Chu, Liwen   163   4 7.1.3.1    83    19   T   Y    83.19




4029 Chu, Liwen   163   4 11.2.1.5   774   51   T   Y   774.51
4030 Chu, Liwen      163   4 11.2.1.1   771    41   T   Y    771.41




4031 Cypher, David   163   4A           1316   56   T   Y   1316.56
4032 Ecclesine, Peter   163   4 J.1        2040   6    E   N   2040.06




4033 Ecclesine, Peter   163   4 16         1032   7    E   N   1032.01

4034 Hamilton, Mark     163   4 7.3.2.30   235    11   T   Y    235.11




4035 Hamilton, Mark     163   4 3.1        12     61   T   Y     12.61




4036 Hamilton, Mark     163   4 7.3.1.6    136    5    E   N    136.05

4037 Hamilton, Mark     163   4 7.3.2.12   169    8    E   N    169.08
4038 Hamilton, Mark   163   4 7.4.8      310   9    T   Y   310.09




4039 Hamilton, Mark   163   4 7.3.2.31   240   51   E   N   240.51




4040 Hamilton, Mark   163   4 11.2.1.7   777   39   T   Y   777.39




4041 Hamilton, Mark   163   4 11.3.0a    785   5    T   Y   785.05




4042 Hamilton, Mark   163   4 11.3.1.3   788   46   T   Y   788.46
4043 Hamilton, Mark   163   4 11.3.1     787   18   T   Y   787.18




4044 Hamilton, Mark   163   4 11.3.1     787   18   T   Y   787.18




4045 Hamilton, Mark   163   4 11.3       784   29   T   Y   784.29




4046 Hamilton, Mark   163   4 11.3.1.1   787   18   T   Y   787.18




4047 Hamilton, Mark   163   4 11.3.1.3. 788    43   T   Y   788.43
                              b




4048 Hamilton, Mark   163   4 11.3.2     789   12   T   Y   789.12
4049 Hamilton, Mark   163   4 11.3.2     789   12   T   Y   789.12




4050 Hamilton, Mark   163   4 11.4.4     797   50   T   Y   797.50




4051 Hamilton, Mark   163   4 11.3.1.1   787   18   T   Y   787.18
4052 Hiertz, Guido    163   43           19    1-4   T   Y    19.01




4053 Marshall, Bill   163   4 11.3.0a    785   33    T   Y   785.33




4054 Marshall, Bill   163   4 11.3.1.2   787   59    T   Y   787.59
4055 Marshall, Bill   163   4 11.3.0a    784   16      T   Y    784.16




4056 Purnadi, Rene    163   4 7.4.1.1    286   52      E   N    281.41




4057 Purnadi, Rene    163   4 7.4.6.1    297   58      E   N    292.31

4058 Purnadi, Rene    163   4 Annex D 1835     58      E   N   1835.58




4059 Ramamurthy,      163   4 7.3.2.38   247   42-46   T   Y    247.00
     Harish
4060 Ramamurthy,   163   4 9.2.4   469   54-58   T   Y   469.54
     Harish




4061 Ramamurthy,   163   4 11.5    805           T   Y   805.04
     Harish
4062 Ramamurthy,    163   4 7.3.1.15   142   44-45   T   Y   142.44
     Harish




4063 Ramamurthy,    163   4 7.4.4.2    290   55      T   Y   290.55
     Harish




4064 Ramamurthy,    163   4 11.2.1.0a 770    10      E   Y   770.10
     Harish




4065 Ramamurthy,    163   4 11.5.3     822   33      T   Y   808.30
     Harish




4066 Rosdahl, Jon   163   4 11.2.1.0a 770    11      T   Y   770.11
4067 Rosdahl, Jon   163   4 20.3.12.1 1255   25   T   Y   1255.25




4068 Rosdahl, Jon   163   4 11.3.2.2   790   64   E   N    790.64



4069 Rosdahl, Jon   163   4 11.3.2.2   790   42   E   N    790.42
4070 Rosdahl, Jon   163   4 Annex D 1822     27   E   N   1822.27




4071 Sakoda,        163   4 7.3.2.6    164   11   E   N    164.11
     Kazuyuki



4072 Sakoda,        163   4 7.4.1.0a   281   25   E   N    281.25
     Kazuyuki




4073 Sakoda,        163   4 7.4.7.1    297   56   E   N    297.56
     Kazuyuki



4074 Sakoda,        163   4 7.4                   E   N    281.01
     Kazuyuki




4075 Sakoda,        163   4 7.4.1.1    281   41   E   N    281.41
     Kazuyuki
4076 Seok, Yongho       163   4 11.9a.3.1 831    49-50   T   Y   826.49




4077 Seok, Yongho       163   4 11.11.5    858   49-51   T   Y   853.00




4078 Stephens, Adrian   163   4 1.4.1.0a   281   25      E   N   281.25
4079 Stephens, Adrian   163   4 11.1.2.2   763   5    E   N   763.05




4080 Stephens, Adrian   163   4 11.3.0a    784   16   T   Y   784.16




4081 Stephens, Adrian   163   4 11.3.0a    784   22   T   Y   784.22




4082 Stephens, Adrian   163   4 11.3.0a    784   26   T   Y   784.26




4083 Stephens, Adrian   163   4 11.3.1.2   788   1    T   Y   788.01




4084 Stephens, Adrian   163   4 11.3.1.3   788   40   T   Y   788.40
4085 Stephens, Adrian   163   4 11.3.2.2   791   25   T   Y   791.25




4086 Stephens, Adrian   163   4 11.3.2.3   792   11   T   Y   792.11




4087 Stephens, Adrian   163   4 11.3.2.4   792   37   T   Y   792.37




4088 Stephens, Adrian   163   4 11.3.2.4   792   45   T   Y   792.45




4089 Stephens, Adrian   163   4 11.3.2.4   793   38   T   Y   793.38
4090 Stephens, Adrian   163   4 11.3.2.5   793   64   T   Y   793.64




4091 Stephens, Adrian   163   4 11.3.2.7   794   42   T   Y   794.42




4092 Stephens, Adrian   163   4 11.3.2.2   790   41   T   N   790.41



4093 Vlantis, George    163   4 7.4.6.4    295   1    T   Y   295.01
4094 Vlantis, George   163   4 11.10.8.7 841   31   T   Y   841.31
4095 Vlantis, George   163   4 9.9.1.3   510   32   T   Y   510.32
4096 Vlantis, George   163   4 11.10.8.6 840   26   T   Y   840.26
4097 Vlantis, George    163   4 8.4.11    382   49   T   Y   382.49




5000 Canpolat, Necati   167   5 8.4.1.9   284   38   E   N   284.00




5001 Canpolat, Necati   167   5 8.4.1.9   284   38   T   Y   284.00
5002 Chu, Liwen   167   5 11.4.13   766   33   T   Y   766.00
5003 Chu, Liwen   167   5 10.14   698   36   T   Y   698.00
5004 Chu, Liwen         167   5 10.2.1.6   619   34   T   Y   619.00




5005 Ecclesine, Peter   167   5 8.5.9.4    455   17   E   N   455.00

5006 Ecclesine, Peter   167   5 12.2.1     836   34   E   N   836.00

5007 LANDT,             167   5 INTRO      iv    9    E   N    -4.00
     JEREMY
5008 Ramamurthy,   167   5 10.5.4     651   44      T   Y   651.00
     Harish




5009 Ramamurthy,   167   5 8.3.1.1    248   55      E   N   248.00
     Harish



5010 Ramamurthy,   167   5 8.3.3.9    271   37      E   N   271.00
     Harish




5011 Ramamurthy,   167   5 8.4.1.17   290   16-25   T   Y   290.00
     Harish
5012 Ramamurthy,       167   5 11.2.3.3. 725   44-46   T   N   725.00
     Harish                    3




5013 Ramamurthy,       167   5 11.5.2    779   39-40   E   N   779.00
     Harish



5014 Vlantis, George   167   5 8.5.7.5   441   1       T   Y   441.00
5015 Vlantis, George   167   5 10.11.9.7 684   31   T   Y   684.00
Line   Clause   Duplicate   Resn Assignee   Submission Motion
                of CID      Status                     Number

0      11.9                 D




0      11.4                 D




38     9.9.1                P
20   3   U
36   9.10.2   D




37   9.10.2   A
50   7.2.1.1   P




10   11.9.6    A
17   Introducti   D
     on




54   9.10.4       P
22   3   D
60   3   D




0    D   D
22   3   D




1    U   A
3   7.1.4      A




1   7.3.1.24   D
39   9.7a       D




30   9.16.1.1   D




51   11.2.2.3   P




27   D          A
15   9.9.1.5     D




     17.3.2.1    A




     1.2         A




0    8.5.1.5.3   A




     3           A




     5.1.1       A
    7           A




    7           P




0   7.1.3.5.6   A




0   7.2.3       A
    7.2.3      P




0   7.2.3.8    A




0   7.2.3.9    D




0   7.3.1.4    A




0   7.3.1.11   A




    B          A
     C           P




0    G.2         P




     17.3.10.1   A




     Table i.1   P




1    6.1.3       D




45   7.2.3.1     P
56   7.3.22.10   D
     a




     7.3.2.22    P




     7.3.2.6     A




65   7.2.3.6     A
57   7.3.2.31   U




62   7.3.2.31   A




62   7.3.2.31   A




     7.3.2.31   A
47   7.3.2.25.   P
     3




     General     D




     General     D




     5.2.4       D
6.2.1.3   D




10.3.10   A
802.11k -   D
11.10.11
3   9.1.3.1   P




    9.9.3.1   P
11.2.1.1   P




11.2.1     P




           D
7.3.2.15    A




10.3.16.2   D
.2
8.4.4   A




5.2.5   P
1    M           D




15   17.3.2.1    A




0    17.3.8.1    A


     17.3.8.3.   A
     2
17.3.10.1   A




17.3.11     A
    17.3.11   A




0   17.3.11   P
    17.3.12     D




    7.3.2.4     D




    7.2.3.1     D
    Beacon
    frame
    format




0   17.3.10.1   A
0    11A.11.2   A




24   8.4.10     A




1    11A.1      D
    11A.4.2    D




    11A.4.3    D




    11A.5.2    D




    11A.5.4    D




    11A.5.5    D




5   11A.5.5    D



2   7.3.2.46   P




    8.5.8.1-   P
    8.5.8.4
16   7.3.2.46   A




25   8.4.10     P




12   7.3.1.17   P
0   7.3.2.30   P




    C          P
Clause      D
16




Clause      D
14




6.1.2       A




8.3.2.4.1   P
7.3.2.9    D




11.2.1     P




18.2.2.2   P
7.1.4   U




J       A
51   14.6.16   P   Lee           e-mail in      56
                   Armstrong/bil adhoc
                   l Marshall    notes/09/124
                                 4r1




28   9.3.2.2   D                                42
1    16        P                               20




13   9.9.1.5   P                                6




7    11.1.0a   A                                6


     General   A   Bill Marshall   11-09/910   38
    General   A   37




1   14        P   14




1   15        D   14
40   7.3.2.21.   D   4
     9




     7.3.2.22.   D   4
     9
     7.4.7.8     D   4




18   11.10.8.6   D   4




     7.3.2.22.   D   4
     9
43   7.3.2.31   P   32




21   7.3.2.31   P   32




     0A         A    7



     0A         D    7




     0A         A    7



     0A         A    7



     0A         A    7
     0A   A    7

     0A   A    7

     0A   P    7




     0A   A    7

     0A   P    7




     0A   P   18




     0A   P   18



     0A   P   18



     0A   P   18



57   0A   P    6
6    0A          D   14




42   8.1.2       A    6




60   8.1.3       A   10




64   8.1.3       A    5



51   8.4.1.1.2   D   15
60   8.4.1.1.3   A    5




45   8.4.1.1.2   D    5




51   8.4.1.2.1   A    5




58   8.4.1.2.1   P   15
38   8.4.6     P   15




55   8.4.6.2   P   10




30   8.4.8     P   10




64   8.4.10    D   10
     General   D   15




40   8.7.2     D   10
     General   D   19




     9.9.2.2   D    6




45   9.8.0a    A    6


30   9.8.2     P    7
28   9.8.2a     P                            6




25   9.8.2      P                           44




38   18.4.6.7   P                           44




19   18.4.6.6   P                           44




30   18.4.6.2   P   Peter       09/1111r2   45
                    Ecclesine
18   15.4.6.2   P   Peter       09/1111r2   45
                    Ecclesine




4    A          D                           19




15   D          D                           54
46   D   P                           33




40   D   P   Peter       09/1111r2   45
             Ecclesine




51   D   D                           33
2    D    A   54




39   D    P   33




1    16   P   20
1    14   P   14




55   D    P   33




22   D    U    0




1    E    P    6




1    F    P   19
9    I   P    6




35   J   A    6




52   J   A    6


1    M   D   31
5   11.10.12   D   10




1   7.5        A    6

1   10         D    2
2   10.3.0a   D    2




1   10.3.11   D   54
13   1.2     A   19




6    3.159   A   44




5    3.159   A    6




1    13      A    6
5    6.1.3   P   23




22   6.1.3   P   23
25   6.1.3   P   23




27   6.1.3   P   23
1    general    A   23




57   Contents   P    6
60   Contents     D    6




15   Introducti   A    6
     on
43   Contents     A    6

27   Contents     A    6




28   Contents     A    6


1    3.147        P    6



32   3.4          D    7




     7.5          P    6



1    14           P   14
33   11A.10.1    P   29




1    7.1.1       P    6



59   7.1.3.5.1   P    6




42   7.1.3.5.3   P    6




48   7.2.2       P    6



51   7.2.2       P    6



1    7.2.3.1     P    6




45   7.2.3.10    D   54
15   7.3.1.1   D   54




36   8.2.1.3   A    6




     C         P   18




7    Editors   P    6
     notes




     General   U    7
General   U    7




General   U    7




General   A   37
General   D   14




General   D   14
     General   P   12




     General   D    6




20   N.5       P   40
21   Participa   P    6
     nts




     11.1.2.1    P   48




33   11.1.2.2    D   48




45   11.1.2.2    P    7




     11.1.2.3    P   34
36   11.1.3     P   54




28   11.1.3.5   A   34



7    11.2.1.1   D    6




     11.2.1.4   D   27
11.2.1.4   P   31




11.2.1.5   A   27




11.2.1.5   D   27
     11.2.2.1   A    6


     11.2.2.1   P   57




     11.2.2.4   A    7




19   11.3.2.6   P    6




     11.4.1     P    7




16   11.4.2     P    7




     11.4.4     A    7
15   Introducti   U    7
     on




64   1.2          P    7




44   11.2.2.1     A    6


61   8.4.1.1.3    A   10




25   10.1         A   34
12   2          A   19




65   3.28       A    6




40   7.4.8.3    A    6




5    11.10.14   A   26




34   11.2.1.4   A   27
1   6.2.3   P   30
33   9.9.3.1    P   Mark       43
                    Hamilton




10   7.1.3.7    P               6




58   7.3.2.27   P               6
28   7.3.1.11    P                           32




54   11.3.0a     P   Jon Rosdahl 11-09/705   41




8    10.3.8.1.   A                           34
     1

23   10.3.8.2.   A                           34
     2

26   8.3.2.4.0   P                           10
     a
31   10.3.24.2   A   54
     .2




21   10.3.29.2   P   54
     .2




17   10.3.30.2   P   54
     .2
17   10.3.31.2   P   54
     .2




28   10.3.32.2   P   54
     .2




64   11.4.5      P   26
22   9.9.3.1.2   D   42




27   7.3.2.21.   P    7
     7



17   3.136       A   44




23   3.3         P   44




1    3           A   51
48   11.10.11   P                        10




1    14         P                        14




1    16         P                        20




49   17.3.11    A   Adrian     09/1233   53
                    Stephens




22   17.3.11    A                         6




1    15         D                        14
1    14             P    14




1    16             P    20




49   17.3.11    1170 A   53




22   17.3.11        A     6




1    15             D    14




20   18.4.6.6   1187 P   44
40   18.4.6.6   1188 D   44




40   19.1.2     1189 P   14




48   19.1.2     1190 P   14




1    14             P    14
1    16             P    20




49   17.3.11    1170 A   53




22   17.3.11        A     6




1    15             D    14




20   18.4.6.6       P    44




40   18.4.6.6       D    44
40   19.1.2      P   14




48   19.1.2      P   14




9    9.8.1       P    6




20   1.3.37.4.   A    6
     2
     A.4.10      D    6
A.4.13   D   6




A.4.13   D   6




A.4.13   D   6




A.4.18   D   6
A.4.18   D   6




A.4.18   D   6
     A.4.18    D   6




     A.4.18    D   6




16   D ASN.1   D   6
20   I Table I.2   P   Peter       09/1111r2   45
                       Ecclesine




30   I Table I.3   A   Peter       09/1111r2   45
                       Ecclesine




36   I Table       A   Peter       09/1111r2   45
     !.4               Ecclesine




38   I Table       A   Peter       09/1111r2   45
     !.4               Ecclesine
1    Abstract     S   7




22   Introducti   S   7
     on
41   7.3.2.25.   D   46
     1




37   7.3.2.26    D   46




37   7.3.2.26    P   46




15   7.4.5       D   46
34   7.4.5       P   46




     General     P   19




33   10.3.19.1   A    6
     .2
12   J.1       P   Peter       09/1111r2   45
                   Ecclesine




58   7.2.3.1   P                            6




4    7.2.3.4   A                            6
7    7.2.3.4     P    6




62   7.2.3.5     A    6

32   7.2.3.7     P    6




63   7.2.3.10    P    6




50   7.4.8       P    6




1    7.5         A    6

36   8.4.1.1.2   A   10




65   8.5.1.5.2   A    6




62   8.5.1.5.3   P   10
32   8.5.1.5.5   P    6




5    8.5.2       A    6




7    11.4.3      U    6




17   11A.3       A   10



63   11A.4.2     P    6




31   11A.4.2     A   10




6    11A.8.1     A    6


52   D           A    6


64   D           P    6
1   6.2.1.2    S   31




1   7.3.2.35   P    6
    D         1596 P   17




    Annexes       D     6




1   C             D    18



1   E             P     6
20   5.1a        P   44




50   5.2.3       D    6




22   5.2.3.1     P    6




3    5.4.4.1     P   10




40   7.3.2.25.   D   46
     1
     7.3.2.27   P   6




     7.3.2.27   P   6




44   11.11.1    P   6
44   7.3.2.48    P   32




14   7.3.1.7     A   54




45   7.3.2.22.   A   32
     6

7    8.1.0a      P   10
41   8.5.3.0a    A   10




59   11.10.8.1   P   15




15   11A.9.5.1   A   10




5    8.5.2       P   29
13   7.3.2.48   P   32




23   8.5.3.2    P   10
49   8.5.3.3     P   10




35   7.3.2.21.   D   32
     10




46   11.10.8.8   A   10
    General   P   14




    General   U   14




1   10        D    2
1    16         P   20




     C          D   18




51   11.9.7.2   D   10
    N        D   25




    E        P   14




    F        P   14




    O        D   13




    P        A   14




1   14       P   14




1   12.3.4   P    6
26   12.3.4.4    P   46




18   12.3.5.4.   P   46
     2




35   12.3.5.10   D   35
     .3




35   12.3.5.10   P   35
     .3




51   17.3.2.4    P    6




10   17.3.2.4    A    6

7    17.3.3      A    6

31   17.3.3      A    6
7    17.3.4.3   P   Adrian     09/1233   53
                    Stephens




22   17.3.8.1   P                        22




64   17.3.9.7   D                        22


64   17.3.9.7   A                         6
20   17.3.10.5   P   Adrian     09/1233   53
                     Stephens
55   17.3.12   P   Adrian     09/1233   53
                   Stephens




24   17.3.12   P   Adrian     09/1233   53
                   Stephens
46   17.4.3      P   22




1    17.5        D   44




21   19.4.6      D   44




21   19.5.4      A    6




38   19.9.5.0a   A    6
46   19.9.5.0a   A                            6

17   19.9.5.0a   A                            6

26   I.1         A                            6

38   I.2.2       A   Peter       09/1111r2   45
                     Ecclesine




1    J.1         P   Peter       09/1111r2   45
                     Ecclesine




21   J.1         A                            6


55   J.1         A                            6


1    General     P                           12




7    11A.8.4     A                           10


4    11A.8.5     A                           10
12   7.3.2.47   D   46




13   7.4.7.2    A    6

7    Q          D   54




44   Q          D   33




15   Q          D   33




63   Q          D   33




4    Q          A   33




21   Q          P   36




35   Q          D   33
1    Q   D   33




59   Q   D   33




30   Q   A   33




58   Q   D   33




62   Q   P   46




     7   P    6
62   7.4.6.3   D   36




15   10.3.32   A   34




15   10.3.32   D   54




48   7.4.6.5   D   36
55   7.4.7.2   D   36




38   7.3.2     D   36




44   7.3.2     D   54




23   10.3.25   A   34




1    10.3.27   A   34
11   7.4.5       D                          54




38   5.3.1       D   Adrian     09/1233r0   52
                     Stephens




36   10.3.29.1   A                          54




6    10.3.35.3   A                          54
25   10.3.15.3   D   36




58   9.13        D   40




64   11.1.2.3    D   54
53   9.4   P   30




53   9.4   A   24
31   11.1.3.2.   P    6
     1




46   11.2.1.5    D   27
     11.3       P   Jon Rosdahl 11-09/705   41




44   11.2.2.1   A                            6


65   9.4        P                           31
59   9.2.5.4   D   24




39   9.9.1.2   P   39
13   9.9.1.5   P   6




17   9.9.1.5   P   6




47   9.10.3    D   6
27   9.10.3      P   30




1    7.1.3.1.7   P    6




47   7.5         P   36
26   9.1.3.1    A                             31




     9.1.3.1    A                             31




49   7.3.2.21   A                              6




49   11.9.6     A                              6




     11.3       A   Jon Rosdahl 11-09/705r4   41
7, 11, etc.   D    6




3.163,        P   23
3.87
60   7.2.3.0a   P   36
     7.2.3.1     P    7




     11.2.1.1    P   31




15   7.1.3.3.3   A   32
53   11.2.1.0a   A   31




1    11.2.1.0a   D   42




28   7.3.1.11    A   32




     10.3.33     A    6




     7, 9, 11,   D    6
     etc.
     C          P                          18




50   3          D   Adrian     09/1233r0   52
                    Stephens




14   7.2.3.2    A                           6




44   11.2.2.1   A                           6
21   A.4.4.2     D   44




29   5.4.2.1     A    6

21   7.1.0a      P    6




46   7.2.1.1     A   32




17   7.1.3.3.3   A    6


30   7.1.3.5.4   P    6
58   7.1.3.5.6   A   32




28   7.2.2       D    6




28   7.2.2       A   32
35   7.2.3.0a   A   32




37   7.2.3.1    A    6


56   7.3.1.4    A   32




6    7.3.1.4    A   32
52   7.3.1.4    A   32




48   7.3.1.4    A    6



58   7.3.1.11   P   32



52   7.3.2.0a   P    6




27   9.14.0d    P   24
5    7.3.2.40    D   36




54   7.3.2.22.   D   32
     8




     C           P    6
10   3       A   6

33   3       P   6




60   3       A   6

16   3       A   6

36   3       A   6

18   3       P   6



64   3       A   6


41   3.88    A   6


51   3.104   A   6



20   3.113   A   6




64   3.133   A   6
17   3.136   A    6




27   3.151   A    6


53   3.169   A    6




5    3.159   A    6

1    C       D   18




44   4       A    6




62   4       A    6
     General   D   13




32   5.2.3.2   A    6



3    5.2.5     P   44
29   5.2.6   A   31




34   5.2.7   A    6




65   5.2.7   D   10




6    5.3.2   D   51
41   5.4.1.1   D   13




49   5.4.1.2   D   14
1    5       P   21




14   5.4.3   A   10
1    5.4.3.1   P   10




39   5.7       D   51
26   5.7         D   51




10   10.3.29.1   A   34
28   5.8.3.3     D   10




1    6.1.5       A    6

47   7.3.2.25.   A   46
     1
14   10.1       P   54




1    10.1       A   34




1    10.3.0a    A   54




28   11.10.12   P   15
34   10.3.2.2.   A   34
     2




8    10.3.2.2.   D   54
     2




31   10.3.2.2.   A   54
     2




50   10.3.2.2.   A   54
     2
25   10.3.2.2.   A   54
     2




48   10.3.2.2.   A    6
     2
1    10          P    6




23   10.3.6.3    A    6
48   8.2.2.3.0   A                           10
     a




1    10          A                           36




5    11.3.0a     A                           10




8    11.3.2.5    P   Jon Rosdahl 11-09/705   41




26   11.3.2.5    P   Jon Rosdahl 09/705r4    41
19   11.10.5     A   10




12   D           P    6




30   10.3.9.1.   D   54
     2




18   10.3.9.2.   A   34
     2
1   D           P   46




1   D           P   46




5   10.3.10a.   P   54
    1.3
61   10.3.11     P   36




30   10.3.11     A   54




37   10.3.13.2   A    6
     .2


11   10.3.16.2   P   54
     .2




46   10.3.17.1   A   54
     .2




50   10.3.19.1   A   34
     .4
56   10.3.22.1   P   34
     .4




54   10.3.22.1   A    6
     .4
26   10.3.23.1   A   54
     .2




38   10.3.24.1   A    6
     .1

17   10.3.24.1   A    6
     .2




46   10.3.24.7   P    6
     .3




36   10.3.25.2   A   34
     .2
46   10.3.27.5   D   54
     .4




     General     A    6



28   10.3.30.3   P   54
     .4




39   10.3.31.2   A   54
     .4




32   10.3.31.3   A    6
     .2
1    10          A    6

49   10.3.33.6   A    6
     .2
16   10.4.1.1   P   46




7    11.1.0a    A    6


9    11.1.0a    A   34




16   11.1.1     A   34



     General    A   19




20   11.1.2.1   A   34
1    11.1.2.1    P   48




23   11.1.3.0a   A    6

32   11.1.3.2.   A   54
     1




34   11.1.3.2.   A   54
     1




58   11.1.3.2.   D   54
     2
27   11.2.1.3   P   27




19   11.2.1.4   A   27




51   11.2.1.5   A   31




14   11.2.1.5   A   27


36   11.2.1.5   A    6
37   11.2.1.5       P    30




39   11.2.1.5       A    31




50   11.2.1.5   1490 P   30




8    11.2.1.5   1490 P   30




30   11.2.1.5       A    31




51   11.2.1.5       A    31
21   11.2.1.6   1490 P   30




33   11.2.1.6   1490 P   30




62   11.2.1.9       P    31




64   11.2.1.9       A    31




2    11.2.1.9       A    27

30   11.2.2.1       P    30




19   11.2.2.1       A    31
1    11.2.2.4   P    6




12   11.2.2.4   A    7




15   11.2.2.4   A    7




41   11.2.2.4   A   31
30   11.3.0a   D                           10




42   11.3.0a   P   Jon Rosdahl 11-09/705   41
4    11.3.2.1   A   34




65   11.5.3     A    7




5    11.4.1     A    6

18   11.4.2     A   31




36   11.4.4     A    6



28   11.6.1     D   54
56   11.6.1   P   Adrian     55
                  Stephens




19   11.6.2   A              54
42   11.7.0a    P   30




39   11.7.0a    A    6



63   11.7.1.2   P    6




     General    A   22




45   11.9.6     A    6

5    11.7.5     A    6


1    11.9.0a    A    6
     General   D    6




30   11.9.0a   A   10


11   11.9.2    A   10




33   11.9.3    P   15




53   11.9.6    A   10
     General     P    6




62   11.10.8.4   A    6


24   11.10.8.4   A   10



28   11.10.8.6   D   10
28   11.10.8.8   A   10




18   11.10.9     P   10




     General     P    6
1    11.10.9.2   P   10




33   11.10.10    A    6
     a
50   11.10.11    P   10




23   11.10.12.   A    6
     1
49   11.10.12.   A    6
     1

52   11.10.13    P    6




53   11.10.13    A   31
55   11.11.1     P                            7




5    11.11.2.2   A   Peter       09/1111r2   45
                     Ecclesine




58   11.11.2.3   P   Peter       09/1111r2   45
                     Ecclesine
58   11.11.2.3   P   Peter       09/1111r2   45
                     Ecclesine




3    11.11.2.4   P   Peter       09/1111r2   45
                     Ecclesine




21   11.11.2.2   P   Peter       09/1111r2   45
                     Ecclesine
24   11.11.2.4   P   Peter       09/1111r2   45
                     Ecclesine




4    11.11.3     P   Peter       09/1111r2   45
                     Ecclesine




41   11A.1       A                            7




22   12.3.5.7.   P   Adrian      09/1233r0   55
     3               Stephens
6    12.3.5.11   A                          35
     .1




17   12.3.5.12   A                           6
     .2



52   12.3.5.12   P                           7
     .3




     19          P   Adrian     09/1233r0   53
                     Stephens
23   A.4.4.1   P    7


39   A.4.4.1   P   21




24   A.4.2     A    6




     General   P    7




20   A.4.4.4   A    6


42   A.4.8     A    6
1   A   P    6




1   A   A    6




1   C   P   18




1   E   A    7
1    F       P   19




40   K.3.2   A    7




48   K.3.2   A    6

58   K.3.2   A    6
34   K.3.2   P    6




41   K.3.2   A    6

44   N.2     D   30




     P       A    6


22   Q       P    7



23   Q       P    7
33   Q   P   47




26   Q   D   54




34   Q   A    6

16   Q   A    6



25   Q   D   33



48   Q   A    6

29   Q   P    6



63   Q   A    6
     Q   P   47




51   D   P    6




54   D   P    7



40   D   A   33
     D   P    7




35   D   A   33




42   D   P    6




54   D   A    6
34   D   P                          36




23   D   D                          54




     D   P   Adrian     09/1233r0   55
             Stephens
     D         P   17




22   D         P   47




     General   P    6
63   D         D   54




     D         A    6



46   9.1.3.1   P    6




51   9.1.3.2   A   30




35   9.1.5     A   31
41   9.1.5   A   31




65   9.1.5   P   30
30   9.2      A   30




56   9.2.0a   P   24




8    9.2.0a   A   24
16   9.2.0a   P   24




22   9.2.0a   D   24




26   9.2.0a   A   24




19   9.2.2    A   24
43   9.2.3.3   A   24




51   9.2.3.4   P   24




55   9.2.3.4   A    6



60   9.2.3.4   A   24




30   9.2.4     A   24




51   9.2.5.1   A   30




48   9.2.5.3   A    6
28   9.2.5.3   A    7




30   9.2.6     A   24




33   9.2.6     A    7




35   9.2.6     P    7
36   9.2.6   P    7




41   9.2.6   P   23




40   9.2.6   P    7




53   9.2.7   A   24
59   9.2.7   P   24




55   9.2.9   A    7




5    9.2.9   A   24




12   9.2.9   A   24
58   9.2.9    A    7




36   9.2.11   A   30




10   9.3.0a   P   16




14   9.3.0a   A   31
16   9.3.0a    A   16




57   9.3.0a    D   31




1    9.10.4    P    6




15   9.3.4.1   A    6

32   9.3.4.2   P    7




53   9.4       P   40
45   9.5      P   40




61   9.5      A   30




25   9.6a     A    6

45   9.8.0a   A    6

61   9.8.1    P   14
1    9.9.1.2   P   39




42   9.9.1.3   A   24




46   9.9.1.3   A   24




1    9.9.1.3   A   24




13   9.9.1.5   P    6
33   9.9.1.5     A   24




48   9.9.1.6     P   24




64   9.9.2.0a    A    6

39   9.9.2.1.2   P   39




24   9.9.2.1.3   A   39




19   9.9.2.1.3   A   40
26   9.9.2.1.3   A   24




50   9.9.2.1.3   A   24




14   9.9.2.1.3   P    6
14   9.9.2.1.3   P   24




31   9.9.2.1.3   P    6




18   9.9.2.2a    P   24




24   9.9.2.2a    A   24




30   9.9.2.2a    A   40
29   9.9.2.3.0   A   40
     a




19   9.9.2.3.0   A    6
     a
30   9.9.2.3.1   A    6

19   9.0a        P    6




27   9.1.2       A   31




5    9.1.3.1     P   24




35   9.2.5.2     P    6
24   9.2.5.3     P   31




28   9.2.11      P    6



50   9.9.1.2     D    6




     9.9.1.5     P    6




28   9.9.2.0a    A    6




60   9.9.2.1.3   P   24
18   9.9.2.2a    P    6




58   9.9.2.3.2   D    6




45   9.9.3.1.0   D   30
     a




12   9.9.3.1.1   A    6
37   9.10.3     P   30




59   7.3.2.47   P    6
33   9.9.3.1.0   P   Dave         43
     a               Stephenson
52   9.9.3.1.0   D   Dave         43
     a               Stephenson




25   9.9.3.1.2   D                23




5    9.9.3.1.2   P                23
34   11.4.3   P                                7




42   11.4.3   A                               26




44   11.4.4   U   Dave         11-09/1063r0    0
                  Stephenson
49   11.4.6   D   23




51   11.4.6   P   26




55   11.4.6   A   26




5    11.4.6   P   23
11   11.4.6   P   26




52   11.4.7   D   26




48   3        A   22


50   3        P    7
37   7.2.3.1    D    6




5    7.2.3.8    D   46




     5.2.7.2    A    6




     5.2.7.11   P   10
5.4         P    6




Table 7-8   A    6




7.3.1.4     A   36
31   7.3.2.21    P    6




60   7.3.2.21    A   32




     Table 7-    A    6
     29
     7.3.2.21.   A   32
     10
24   7.3.2.21.   D   54
     8
     7.3.2.21.   D   49
     7




     7.3.2.22.   P   32
     8




13   7.3.2.22.   D   54
     10
     7.3.2.21.   D   50
     10




     7.3.2.25    P    6




56   7.3.2.31    D   36




44   7.3.1.17    P   54




     7.3.2.37    A   32
56   7.3.2     P    6




     General   D   44
53   G.2        P    7




1    3.2.3      A    6

62   9.1.1      A    6


59   9.1.3.1    D   24




22   9.2.0a     A   31




52   9.2.3.0a   P    6
28   9.9.2.0a   P    6




1    19         A    6


9    14.8.2.4   A   61




47   A.4.5      D   59




50   A.4.6      P   61




23   A.4.7      A   61




25   A.4.8      D   59




40   A.4.9      D   59
59   15.3.2   P   81




27   16.4     A   61




16   18.3.2   A   61




2    C.2      D   59
30   D   P   81




65   D   P   81




1    D   P   59
18   14.8.2.1    A   61




65   9.3.3.1     P   84




44   11.4.2      P   63




19   11.9a.1     P   65




42   11.10.12.   A   72
     1
63   D   A   59




60   D   A   59




47   D   A   72

11   D   P   59




25   D   A   59
20   D   P   81




31   D   P   67




57   D   P   67
28   8.2.2.2.1   P   Peter E   87




25   9.6a        D             62




47   A.4.10      P             67




45   7.3.1.4     D             62
20   D       A   59




20   A.1     A   60




15   A.1     P   72




43   I.1     A   59




39   I.2.2   A   59


40   J.1     A   81




20   I.1     A   72
43   11.1.3.0a   P   72




30   7.1.3.3.1   P   72




2    D           P   73




1    B           P   72




15   I.2.2       A   59



11   J.1         A   59




9    J.1         A   72
25   J.1         A   59




6    J.1         A   59




10   A.4.1       D   72




41   10.3.1.1.   U   72
     2
23   D   A   59




14   D   P   59
34   D        U   Peter E    0




28   17.4.2   A             72

31   D        P             59
18   D   P   59




52   D   P   69




31   D   P   59
30   D           P   59




43   11.11.2.2   A   72

50   A.4.6       P   61




24   A.4.8       D   59




40   A.4.9       D   59
65   D          P   81




24   A.4.7      A   59


42   A.4.12     A   59




55   A.4.12     A   59




6    A.4.12     A   59


40   A.4.3      D   59




1    7.3.2.48   A   72
60   7.4.7.9     A   62




54   D           P   59




50   11.2.1.0a   P   63
23   D   P   59




17   D   P   59




34   D   A   59




15   D   P   59
44   D   A   59




58   D   A   59




11   D   P   59
     D       D   59




1    M       S   76




32   0A      A   59




22   9.8.2   A   59
20   17.3.10.5   D   59




     General     D   72




64   3           D   72




1    5.4.1.2     A   72

1    5.4.3.3     P   72




40   5.4.4.1     D   72




34   17.3.8.3.   D   59
     1
28   9.14.0b    D                           64




6    9.8.2      D                           59




19   11.2.1.1   P                           63




6    6.2.3.2    P   Adrian     11-10/0308   80
                    Stephens




2    6.2.3.2    A                           62
30   10.1        A   59




40   9.9.3.1.0   A   62
     a




1    10.3.20.2   P   59




19   8.5.6.0a    A   72
1   8.4.1.1.1   D   Dan Harkins   83




4   8.4.1.1.1   D   Dan Harkins   83




    8.4.6.2     D   Dan Harkins   83
     8.5.1.2     D   Dan Harkins   83




     3           D                 60




20   17.3.10.5   D                 59
34   17.3.8.3.   D                   59
     1




32   6.1.2       P   Bill Marshall   87




50   7.3.2.25.   A                   87
     1
37   7.3.2.48   P   62




39   8.5.2      A   65




54   8.5.6.0a   A   72
33   11.3.0a     P   Bill Marshall   11-10/390r0   85




57   11.3.1.0a   P   Jon Rosdahl 11-10-0302        71
44   11.3.2.3   A   Jon Rosdahl 11-10-302r2    85




21   7.3.2.54   P   Peter       11-10/0210r6   74
                    Ecclesine
38   D         P                                 72




1    D         A   Bill Marshall   11-10/300r1   70




1    C         U                                  0




31   11.7.0a   A                                 72
1    D          A   59




     General    P   72




33   11.3.1.3   A   72
1    D   D   67




10   Q   A   72
34   19.1.1      A   59




43   11.1.3.0a   A   59




16   A.1         P   72




     General     D   72
9    7.4.9a     U                            62




34   11.3       D   Jon Rosdahl 11-10-0302   71




61   11.3.1.4   P   Jon Rosdahl 11-10-0302   71
28   11.3.2.8    P   Jon Rosdahl 11-10-0302   71




58   8.1.3       A                            72


59   8.1.3       P                            65




6    8.1.3       P                            72




10   8.1.3       P                            72




10   8.1.3       A                            65



30   8.3.3.3.3   A                            65
6    8.3.3.3.5   D   87




51   8.3.3.4.0   P   65
     a


5    8.3.3.4.1   D   87




19   7.4.7.2     D   64




13   11.9a.1     D   72




55   11.9a.3.1   D   65
47   11.9a.3.2   D   65




17   11.10.3     D   72




     9.13        P   64
     11.2.2.4    A   66




54   10.3.2.2.   A   59
     2
45   10.3.10.1   A   59
     .2
64   10.3.10a.   A   59
     1.2
49   10.3.10.1   D   59
     .2




1    3           A   59
     11.2.1.0a   D                            62




51   1.2         U                            59




61   3           A                            72



45   11.3.0a     A   Jon Rosdahl 11-10-0302   71
42   11.3.0a    P                            85




36   11.3.1.3   A   Jon Rosdahl 11-10-0302   71




1    11.3.1.4   A                            72




8    11.3.2.4   P   Jon Rosdahl 11-10-0302   71
11.3.0a   P   Jon Rosdahl 11-10-0302   85
1    11.3.1.0a   P   Jon Rosdahl 11-10-0302   86




34   11.3.2.0a   A   Jon Rosdahl 11-10-0302   71




12   11.3.1.1    A   Jon Rosdahl 11-10-0302   71
54   11.3.1.4   A   Jon Rosdahl 11-10-0302    71




49   11.3.2.6   P   Jon Rosdahl 11-10/302r1   71
4    11.3.1.2   P   Bill Marshall   11-10/390r0   85




55   11.3.2.1   A   Jon Rosdahl 11-10-0302        71




17   11.3.2.5   P   Jon Rosdahl 11-10-0302        71
17   11.3.1.3   P   59




12   11.3.0a    A   72

32   11.3.0a    A   72

34   11.3       P   72
34   11.3   P                 72




34   11.3   A                 72




1    3      P   Jon Rosdahl   69
39   11.2        P   63




56   3           D   59




20   A.4.4.2     D   59




28   Frontmatt   P   59
     er
44   5.2.3.2   A                             87




6    7.3.1.4   P                             81




26   7.3.1.4   P   Adrian     11-10/0308r0   80
                   Stephens
22   7.3.1.4    P   64




45   7.3.1.4    A   62




36   7.3.2.21   P   62




29   7.3.2.48   P   62
53   7.4.7.9    A   62


37   8.3.3.1    A   65




     General    P   67




49   8.5.6.0a   P   65




10   8.7.2.3    D   87




34   8.7.2.4    D   87
23   10.1        A   59




20   10.3.29.2   A   59
     .2




25   10.3.35.3   A   59
     .2
39   11.3.1.2   P   Jon Rosdahl 11-10-0302   71
36   11.3.1.3   P   Jon Rosdahl 11-10-0302   71
5   11.3.2.4   A   Jon Rosdahl 10-11-0302r1   85
47   11A.10.1   P                             87




30   D          P   Adrian     11-10-0216r2   69
                    Stephens
38   D           P   67




28   D           P   67




14   D           A   59




42   H.8         D   72



46   7.1.3.1.7   P   62




1    7.4.7.10    A   64
45   10.3.40    P   67




1    10.3.44    A   67




1    11.2.2.3   A   84
29   11.3.0a     P   72



     General     A   72

57   11.11.2.2   A   67




38   11.11.2.4   A   68
     General   P   73




38   17.4.3    A   72




1    11.6.2    P   72




19   F.0a      A   72
11   7.3.2.21.   A   72
     1


17   8.5.3.5     P   75




6    7.1.3.3.3   P   62




65   10.3.24.3   P   72
     .3
11.2.1.0a   P   63
     11.2.1.0a   P   63




11   11.2.1.0a   P   62




46   11.2.1.4    S   66
42   11.2.1.5   P   66




45   11.2.1.9   P   77




49   11.2.1.9   P   77
56   11.3.1.0a   P   Jon Rosdahl 11-10-0302   71




58   11.3.1.0a   P   Jon Rosdahl 11-10-0302   71
58   11.3.1.0a   A   Jon Rosdahl 11-10-0302   71




57   11.4.3      D                            79




47   11.4.3      A                            66
48   11.4.4   U   79




16   11.4.4   A   62


25   11.4.4   A   62




     11.4.4   A   78




50   11.4.6   D   79




55   11.4.6   P   62
55   11.4.6     D   62




55   11.4.6     D   79




1    11.4.6     A   62



55   11.4.8     P   72




58   11.4.8     P   72




     7.3.2.21   P   72




12   20.3.20    A   91
56   A        D   91




47   A        A   91




7    A        A   91




10   A        A   91




27   D        D   91




29   19.8.2   A   91




40   20.4.2   A   91
1    C           D                 91




2    C           D                 91




53   D           A                 91




38   D           D                 91




9    7.3.2.22.   D   Gabor Bajko   89
     9
7    7.3.2.21.   P   89
     9




     0           A   91




1    14.8.2.4    D   91




54   17.4.2      A   91

29   19.8.2      A   91


7    20.3.20     A   91


45   20.4.2      A   91
     A.4.3    D   91




     A.4.5    A   91




     A.4.8    A   91



     A.4.9    A   91



56   D.3      P   91




34   A.4.10   P   91



31   J.1      A   91
36   J.1         P            91




7    20.3.20     A            91




62   10.3.37.1   P   Kaberi   91
     .3
3    I.1       A   91




60   11.11.5   A   88

21   3.1       D   88
12   3.1   D   88
21   3.1   D   88
49   3.1   D   88
50   3.1   D   88
20   3.1         D   88




40   7.1.3.5.3   P   91




38   7.1.4.2     P   91




11   7.3.2.31    P   88
58   9.1.3.1     P   91




60   9.1.5       A   89




24   9.2.0b.3    P   91




52   9.2.0b.4.   D   90
     6



26   9.2.0b.6    D   90




30   9.9.1.2     P   91




54   9.9.1.3     D   90
6    11.1.3.2.   D   Kaberi              91
     2




50   11.2.1.0a   P            Adrian     90
                              Stephens




24   11.2.1.4    P            Adrian     90
                              Stephens




48   11.2.1.5    P            Adrian     90
                              Stephens




18   11.2.1.5    P                       88
31   11.2.1.9    D   Adrian     90
                     Stephens




5    11.2.1.12   P   Adrian     90
                     Stephens
26   11.2.1.12   P   Adrian     90
                     Stephens




43   11.2.2.4    D   Adrian     90
                     Stephens




38   11.4.44     D              91




56   9.16.1.7    U              91
30   11.9.7.3    D   91




28   7.3.27      D   91




60   7.3.2.37    D   90




     7.3.2.27    A   90



     11.1.3.2.   D   91
     1
11.2.1.0a   P   Adrian     90
                Stephens




11.2.1.1    D   Adrian     90
                Stephens
7.3.2.4    P                             90




11.1.2.2   P   Harish     11-10/0604r0   91
               Ramamurthy




11.2.2.1   D                             90
11.2.2.1   P   Adrian     90
               Stephens




11.2.2.4   D   Adrian     90
               Stephens
11.2.2     D   Adrian     90
               Stephens




11.2.1.5   P   Adrian     90
               Stephens
25   11.3.0a   P   91




     11.3.0a   D   91
50   11.3.1.2    P            91




8    11.3.1.0a   A            91




31   11.3.2.0a   A   Kaberi   91




39   11.3.2.6    P   Kaberi   91
64   11.3.2.7   P   Kaberi   91




62   11.3.1.2   P            91




13   A.4.11     P   Kaberi   91
23   A.4.4.1     A   Kaberi   91




25   20.3.12.1   D            91
1    7.4       P   Adrian     91




34   7.4.2.1   P              90




27   A.4.5.3   D   Kazuyuki   91
                   Sakoda




     General   A              88
30   7.3.1.4     A            90



     General     A            88




1    7.3.2.47    A            88




6    9.13.2      A            90




58   10.3.37.1   P   Kaberi   91
     .3
8    11.2.1.0a   A   Adrian     90
                     Stephens




60   11.2.1.0a   A   Adrian     90
                     Stephens



63   11.2.1.0a   A   Adrian     90
                     Stephens




59   11.2.2.1    P   Adrian     90
                     Stephens
49   11.3.1.2   P   91




     General    P   88




36   11.3.1.3   P   91
25   11.3.2.5   P   Kaberi   91




54   11.3.2.6   A   Kaberi   91




26   11.3.2.8   A            91
5    7.3.2.30    D   91




47   11A.4.2     A   90




57   11A.4.2     A   90




56   20.3.11.8   A   91
     .1


10   20.3.20     A   91
50   20.3.24   A   91




4    20.3.24   A   91




13   A.4.11    A   91
32   D.2        P   91




27   D.3        A   91



32   D.3        A   91


37   D.3        A   91




     General    A   88


4    I.1        P   91




30   I.1        A   88

32   S.1        A   88

40   7.4.7.1a   A   88
42   8.7.2.4    P              88



56   11.5.2.1   A              90



29   11.2.1.1   P   Adrian     90
                    Stephens




49   11.2.1.1   D   Adrian     90
                    Stephens
26   11.2.1.4   P   Adrian     90
                    Stephens




4    11.2.1.5   P   Adrian     90
                    Stephens




23   11.2.1.5   P   Adrian     90
                    Stephens




54   11.2.1.5   D   Adrian     90
                    Stephens
35   11.2.1.7    D   Adrian     90
                     Stephens




62   11.2.1.11   P   Adrian     90
                     Stephens
1    3      A   Adrian   11-10/0532r0   91




40   11.4   P                           89
47   11.4.3      D   91




30   9.9.3.1.1   P   89




30   9.9.3.1.1   P   89




28   19.8.2      A   91
7    20.3.20   A   91




44   20.4.2    A   91




53   A.4.3     D   91




56   A.4.3     D   91




47   A.4.5     A   91




6    A.4.8     A   91
10   A.4.9   A   91




12   C.2     D   91




56   D       A   91



27   D       D   91




28   D       D   91




39   D       D   91
50   G.3.6      A   91




55   A          A   95



16   D          D   95




25   7.3.2.6    A   93




1    7.3.2.48   A   93




1    7.3.2.48   A   93
38   7.3.2.0a   P   93




64   7.3.2.1    A   93


64   7.3.2.1    P   93




6    7.3.2.2    A   93




     7.3.2.3    P   93




31   7.3.2.4    A   93




     7.3.2.5    A   93




5    7.3.2.7    A   93
     7.3.2.8     A   93




55   7.3.2.14    A   93




41   7.3.2.25.   A   93
     0a



41   7.3.2.25.   D   93
     0a




14   7.3.2.26    A   93




53   7.3.2.39    A   93




26   9.8.3       A   93




28   11.10.9.2   A   93




56   7.3.2.37    A   93




30   11.10.9.2   A   93
11   7.1.3.1.7   P   93




34   7.2.2.2     D   94




40   7.1.3.5.3   D   94




44   7.1.3.1.8   P   94
6    7.1.3.5.0   P   94
     a




19   7.1.3.1     P   94




51   11.2.1.5    D   94
41   11.2.1.1   P   94




56   A          P   95
6    J.1        A   93




1    16         A   93

11   7.3.2.30   A   94




61   3.1        A   95




5    7.3.1.6    A   93

8    7.3.2.12   A   93
9    7.4.8      P                          94




51   7.3.2.31   A                          93




39   11.2.1.7   A                          94




5    11.3.0a    D   Mark       11-10-826   98
                    Hamilton




46   11.3.1.3   D   Mark       11-10-826   98
                    Hamilton
18   11.3.1      D   Mark       11-10-826   98
                     Hamilton




18   11.3.1      D   Mark       11-10-826   98
                     Hamilton




29   11.3        D   Adrian     11-10-768   98
                     Stephens




18   11.3.1.1    D   Mark       11-10-826   98
                     Hamilton




43   11.3.1.3.   D   Adrian     11-10-768   98
     b               Stephens




12   11.3.2      D                          95
12   11.3.2     D   Mark       11-10-826   98
                    Hamilton




50   11.4.4     P                          94




18   11.3.1.1   D   Mark       11-10-826   98
                    Hamilton
1    3.1        D   Dorothy                97
                    Stanley




33   11.3.0a    D   Mark       11-10-826   98
                    Hamilton




59   11.3.1.2   D   Mark       11-10-826   98
                    Hamilton
16   11.3.0a    A   95




41   7.4.1.1    A   93




31   7.4.6.1    A   93

58   Annex D    A   93




     7.3.2.38   A   94
    9.2.4   A   94




4   11.5    D   94
44   7.3.1.15    P              94




55   7.4.4.2     P              94




10   11.2.1.0a   P              94




30   11.5.3      P   Kaberi     94
                     Banerjee




11   11.2.1.0a   D              94
25   20.3.12.1   P   Dorothy   96
                     Stanley




64   11.3.2.2    A             93



42   11.3.2.2    P             93
27   Annex D    P   93




11   7.3.2.6    A   93




25   7.4.1.0a   A   93




56   7.4.7.1    A   93




1    7.4        P   93




41   7.4.1.1    D   93
49   11.9a.3.1   D   94




     11.11.5     D   95




25   7.4.1.0a    A   93
5    11.1.2.2   P                             93




16   11.3.0a    D   Adrian     11-10-0728r1   98
                    Stephens




22   11.3.0a    D   Adrian     11-10-0728r1   98
                    Stephens



26   11.3.0a    D   Adrian     11-10-0728r1   98
                    Stephens




1    11.3.1.2   D   Adrian     11-10-0728r1   98
                    Stephens




40   11.3.1.3   D   Adrian     11-10-0728r1   98
                    Stephens
25   11.3.2.2   D   Adrian     11-10-0728r1   98
                    Stephens




11   11.3.2.3   D   Adrian     11-10-0728r1   98
                    Stephens




37   11.3.2.4   D   Adrian     11-10-0728r1   98
                    Stephens




45   11.3.2.4   D   Adrian     11-10-0728r1   98
                    Stephens




38   11.3.2.4   D   Adrian     11-10-0728r1   98
                    Stephens
64   11.3.2.5   D   Adrian     11-10-0728r1   98
                    Stephens




42   11.3.2.7   D   Adrian     11-10-0728r1   98
                    Stephens




41   11.3.2.2   D   Adrian     11-10-0728r1   98
                    Stephens


1    7.4.6.4    D                             94
31   11.10.8.7   D   94
32   9.9.1.3   A   Kaberi     94
                   Banerjee
26   11.10.8.6   P   94
49   8.4.11          A   94




38   8.4.1.9




38   8.4.1.9   568
33   11.4.13
36   10.14
34   10.2.1.6




17   8.5.9.4

34   12.2.1

9    General
44   10.5.4




55   8.3.1.1




37   8.3.3.9




16   8.4.1.17
44   11.2.3.3.
     3




39   11.5.2




1    8.5.7.5
31   10.11.9.7
Comment                           Proposed Change                Resolution                        Owning
                                                                                                   Ad-hoc

TGn comment: The STA             TGn Resolution:MAC: 2007-07- Reject. There is no proposed         EDITOR
defined quiet element may be 19 16:15:31Z Reject - The            change to this comment.
issued by a STA both in the      requested change to the draft TGmb encourages the
Infrastructure and IBSS          seems to be out of scope of      commentor to submit a
modes. In the former case it     the work of TGn. The group       proposal for consideration, if
could be used by the STA to      suggests taking the comment desired.
complete measurements            to TGmb, although it is not
without disruption and also      clear if that is the appropriate
allow for the completion any co- venue either.
located BT transmissions.
TGn comment: The STA may TGn Resolution:MAC: 2007-07- Reject. There is no proposed                 EDITOR
also reserve medium time for 19 16:12:47Z Reject - The            change to this comment.
its own communication needs requested change to the draft TGmb encourages the
(to participate concurrently in seems to be out of scope of       commentor to submit a
multiple wireless networks) via the work of TGn. The group        proposal for consideration, if
a TSPEC; the use of the          suggests taking the comment desired.
medium time reserved in this to TGmb, although it is not
manner shall not be used to      clear if that is the appropriate
communicate with the AP or       venue either.
DLS neighbor; the signal
strength of the STA's
communications during these
reservation periods shall be
such that it does not interfere
with the infrastructure BSS
operations.The STA shall use
these reservation periods to
participate in other wireless
network protocols.


TGn comment: The sentence         TGn Resolution:MAC: 2007-07- Counter. The text will be         EDITOR
of measurement period in the      19 16:25:31Z Reject - The text modified in clause 11.9.6, last
basic spec seems to be wrong      that the commentor refers to is paragraph on page 465 to be:
in relation to time estimation    directly quoted and unmodified "… switches take
that the channel switch takes.    from the baseline standard       dot11ChannelSwitchTime per
It should be not less than the    and is with reference to a topic switch"
related parameter. Proposed       which is unaddressed and
Change: Change the last           unmodified by the TGn draft.
sentence in the first paragraph   Therefore, the issue raised by
"… switches take not less than    the commentor should be
dot11ChannelSwitchTime per        addressed to TGmb. TGn will
switch."                          forward this comment to
                                  TGmb.
TGn comment: LongNAV in           TGn Resolution:MAC: 2007-07- UNRESOLVABLE (EDITOR: EDITOR
EDCA has some problems,           17 21:20:45Z Reject - the       2010-05-20 09:24:36Z) - In
esp at the AP because frames      issue cited here applies to the 9.2.1, 3rd paragraph, replace
for different STAs are mixed      baseline standard, and is not “and use of the NAV in HCF is
together unlike in HCCA.1.        necessarily related to anything described in 9.9.2.2.1” with
Say the AP starts the TXOP by     that has been introduced by     “and the use of the NAV in
performing a self-CTS for         TGn, with the exception that    HCF is described in 9.9.1.2
LongNAV protection. If it wants   some of the rationales for the and 9.9.2.2.1”.
to perform a RTS/CTS              given behavior are related to Add a new paragraph to the
transaction with a STA in the     TGn features, but others are    end of subclause 9.9.1.2:
same TXOP, the STA will not       not, and therefore, the problem “A STA shall save the TXOP
respond with CTS.2. Say the       is one that can exist in the    holder address for the BSS in
AP starts the TXOP by             baseline, and as such, the      which it is associated, which is
performing an RTS/CTS frame       issue should be raised with     the MAC address from the
exchange for LongNAV with         TGmb.                           Address 2 field of the frame
the first STA for which data is                                   that initiated a frame exchange
pending in the AC queue.                                          sequence. If an RTS frame is
Subsequently if it wants to                                       received with the RA address
perform an RTS/CTS frame                                          matching the MAC address of
exchange with another STA in                                      the STA and the MAC address
the same TXOP, the other                                          in the TA field in the RTS
STA will not respond with the                                     frame matches the saved
CTS.Why will it want to                                           TXOP holder address, then
perform RTS/CTS inside a                                          the STA shall send the CTS
TXOP?1. For Beamforming.2.                                        frame after SIFS, without
For MIMO PS.3.                                                    regard for, and without
Implementation specific stuff..                                   resetting, its NAV. When a
Proposed Change: HCCA had                                         STA receives a frame
LongNAV much before EDCA                                          addressed to it and requires
had. See section 9.9.2.2.1                                        an acknowledgment, it shall
which says that all STAs                                          respond with an ACK frame
should keep track of who is the                                   independent of its NAV. The
TXOP holder and respond if                                        saved TXOP holder address
TGn comment: 2005 Style            TGn Resolution:GEN: 2007-07- Reject. As per original TGn      EDITOR
Guide 10.5.2 states                19 17:41:28Z Reject -            commenter, no action is
"Definitions shall not include     submission 11-07-2145r1:         necessary, as the clause was
references to other parts of the   Reject. The commenter            fixed in TGn draft 6.
standard". Proposed Change:        correctly quotes the style
remove the references to           guide. The 802.11 baseline
"Clause 17", "Clause 19",          uses the definitions for two
"Clause 20". This problem          purposes: a) generic
needs to be fixed at the           definitions suitable for
following page.lines: 1.20 (3      inclusion in IEEE 100; b) IEEE
times), 1.25 (3 times), 1.36,      802.11 specific definitions that
1.44, 2.09, 2.14, 2.32, 2.43,      make no sense outside the
3.15, 3.20, 3.24                   context of the 802.11
                                   standard. The definitions that
                                   the commenter identifies fall
                                   into the latter category and
                                   there is no obvious way to
                                   avoid the use of Clause
                                   references as they identify
                                   PHY capabilities.
                                   This has been discussed with
                                   the IEEE-SA editorial staff.
                                   They suggest that we address
                                   this in REVmb, by introducing
                                   a new section for local terms,
                                   which is not intended to
                                   provide definitions for IEEE
                                   100.
                                   Until then, it makes no sense
                                   to attempt to do this piecemeal
                                   in 802.11 amendments, so no
                                   action is proposed in the TGn
TGn comment: I would hope          draft Resolution:MAC: 2007-06- Accept the proposed
                                   TGn in resolution of this                                     EDITOR
that the receiving STA is the      20 00:30:24Z Reject -            resolution embedded in the
intended STA!. Proposed            comment rejected by MAC          "Comment" column. Proposed
Change: delete "which is the       adhoc because the comment Change: delete "which is the
intended STA"                      is out of scope - This comment intended STA"
                                   questions language that is part
                                   of the baseline standard and
                                   that is not changed by the
                                   proposed TGn amendment.
                                   The correct venue for raising
                                   this issue is within TGmb. The
                                   TGn group will forward this
                                   comment to TGmb.
TGn comment: identify which       TGn Resolution:MAC: 2007-06- Counter. Reword the last             EDITOR
STA is accepting. Proposed        20 00:30:24Z Reject -           sentences of the first para of
Change: change to "When the       comment rejected by MAC         9.10.2 as follows: "The
receiving STA accepts"            adhoc because the comment recipient(#7) STA(#6) has the
                                  is out of scope - This comment option of accepting or rejecting
                                  questions language that is part the request. When the
                                  of the baseline standard and recipient(#7) STA accepts,
                                  that is not changed by the      then a Block Ack agreement
                                  proposed TGn amendment.         exists between the originator
                                  The correct venue for raising and recipient. When the
                                  this issue is within TGmb. The recipient(#7) STA accepts, it
                                  TGn group will forward this     indicates the type of Block Ack
                                  comment to TGmb.                and the number of buffers that
                                                                  it shall allocate for the support
                                                                  of this block. If the intended
                                                                  recipient(#7) STA rejects the
                                                                  request, then the originator
                                                                  shall not use the Block Ack
                                                                  mechanism. "

TGn comment: The sentence         TGn Resolution:Reject.            Accept TGn resolution to     EDITOR
leads to several                  Reason to reject: This text is in reject, but note that the
interpretations. Is it the TXOP   baseline and should be            references do not match.
Limit (as communicated by the     addressed by TGmb through
AP in the beacon) or just any     an interpretation request.
value between zero and the        A strawpoll was conducted
TXOP Limit?. Proposed             and the proposed to reject was
Change: Clarify.                  accepted Unanimously
TGn comment: Draft 2.0 uses     TGn Resolution:Reject - The Reject. Not applicable to          EDITOR
elements of IEEE P802.11k       commenter does not indicate TGmb.
D7.0. The Introduction to Draft any changes to the draft.
2.0 states that the Draft 2.0   In answer to the commenter,
amendment specifies             REVmb will wrap in one or
enhancements from other         more of the drafts listed as our
drafts, as well: IEEE P802.11   dependencies. One or more
Rev-ma D9.0; IEEE 802.11r       of these dependencies may be
D4.1; IEEE 802.11p D2.0..       replaced by IEEE 802.11 200x
Proposed Change: Assuming       where 200x is its publication
Draft 2.0 is approved for       date, if this occurs during
recirculation ballots, please   TGn's ballot process.
clarify whether transition of   If any of the drafts have not
TGn's draft to sponsor ballot   been wrapped into an 802.11
be dependent upon the           revision at the time of TGn's
completion of these other       publication, it will list the
                                dependencies as shown here.
drafts (i.e. either completion of
their recirculation or sponsor  The published TGn draft can
ballot or ExecCom approval or   only depend on published
IEEE publication). If not,      802.11 standards and
please clarify the IEEE 802.11  amendments, and so this list
mechanism to incorporate any    is dependent on the order of
changes from these other        completion of amendments,
drafts.                         which is dependent on the
                                progress that task groups
                                make through letter and
                                sponsor ballot. This may
                                result in the list of our
                                dependencies being adjusted
                                at any time during the balloting
                                process as the 802.11 task
                                groups adjust their official
TGn comment: The lost           predictions of publication
                                TGn Resolution:MAC: 2008-01- Counter. Add "or missing" after EDITOR
MSDU should be considered 11 01:54:51Z Reject -                  the word "incomplete", in the
here. Otherwise 11 MAC may This issue is not related to the cited sentence.
send out of order frame to the .11n. All problems found in the
upper layer which is not        basic spec should be fixed in
allowed.. Proposed Change: the TGmb.
Change the sentence to: Upon
arrival of a BlockAckReq
frame, the recipient shall pass
up the MSDU and A-MSDU
starting with the starting
sequence number sequentially
until there is an incomplete
MSDU or A-MSDU or lost
MSDU.
TGn comment: Was                   TGn Resolution:Reject: The         Reject. As per original TGn    EDITOR
LB97/9492005 Style Guide           commenter correctly quotes         commenter, no action is
10.5.2 states "Definitions shall   the style guide. The 802.11        necessary, as the clause was
not include references to other    baseline uses the definitions      fixed in TGn draft 6.
parts of the                       for two purposes: a) generic
standard"Resolution given          definitions suitable for
was: Reject. The commenter         inclusion in IEEE 100; b) IEEE
correctly quotes the style         802.11 specific definitions that
guide. The 802.11 baseline         make no sense outside the
uses the definitions for two       context of the 802.11
purposes: a) generic               standard. The definitions that
definitions suitable for           the commenter identifies fall
inclusion in IEEE 100; b) IEEE     into the latter category and
802.11 specific definitions that   there is no obvious way to
make no sense outside the          avoid the use of Clause
context of the 802.11              references as they identify
standard. The definitions that     PHY capabilities. This has
the commenter identifies fall      been discussed with the IEEE-
into the latter category and       SA editorial staff. They
there is no obvious way to         suggest that we address this in
avoid the use of Clause            REVmb, by introducing a new
references as they identify        section for local terms, which
PHY capabilities. This has         is not intended to provide
been discussed with the IEEE-      definitions for IEEE 100. Until
SA editorial staff. They           then, it makes no sense to
suggest that we address this in    attempt to do this piecemeal in
REVmb, by introducing a new        802.11 amendments, so no
section for local terms, which     action is proposed in the TGn
is not intended to provide         draft in resolution of this
definitions for IEEE 100. Until    comment.
then, it makes no sense to
attempt to do this piecemeal in
802.11 amendments, so no
TGn comment: 2005 Style            TGn Resolution:Reject: The         Reject. As per original TGn    EDITOR
Guide 10.5.2 states                commenter correctly quotes         commenter, no action is
"Definitions shall not include     the style guide. The 802.11        necessary, as the clause was
references to other parts of the   baseline uses the definitions      fixed in TGn draft 6.
standard". Proposed Change:        for two purposes: a) generic
Remove "The value is defined       definitions suitable for
in 9.6.0c."                        inclusion in IEEE 100; b) IEEE
                                   802.11 specific definitions that
                                   make no sense outside the
                                   context of the 802.11
                                   standard. The definitions that
                                   the commenter identifies fall
                                   into the latter category and
                                   there is no obvious way to
                                   avoid the use of Clause
                                   references as they identify
                                   PHY capabilities. This has
                                   been discussed with the IEEE-
                                   SA editorial staff. They
                                   suggest that we address this in
                                   REVmb, by introducing a new
                                   section for local terms, which
                                   is not intended to provide
                                   definitions for IEEE 100. Until
                                   then, it makes no sense to
                                   attempt to do this piecemeal in
                                   802.11 amendments, so no
                                   action is proposed in the TGn
                                   draft in resolution of this
                                   comment.


TGn comment: There're MIB          TGn Resolution:GEN: 2008-05- Reject. Not applicable to            EDITOR
variables listed that the 11n      15 17:33:20Z Reject -         TGmb. The commentor is
amendment text does not use        The 11n amendment simply      encouraged to supply a list of
or even refer to at all, like      follows the practice followed MIB variables that need to be
"dot11HTgreenfieldOptionEna        by 802.11 regarding MIB       removed.
bled", just to give a random       variables. This issue is
example. Why do we specify         beyond the scope of TGn.
them if we never set them          This comment will be
properly or use them?.             forwarded to TGmb for
Proposed Change: Decide this       considerations.
issue and amend accordingly.
TGn comment: IEEE Style            TGn Resolution:Reject. The         Reject. As per original TGn    EDITOR
Guide clearly states               commenter correctly quotes         commenter, no action is
"Definitions should not include    the style guide. The 802.11        necessary, as the clause was
references to other parts of the   baseline uses the definitions      fixed in TGn draft 6.
standard".. Proposed               for two purposes: a) generic
Change: Remove the                 definitions suitable for
references to clause numbers       inclusion in IEEE 100; b) IEEE
from the definitions               802.11 specific definitions that
                                   make no sense outside the
                                   context of the 802.11
                                   standard. The definitions that
                                   the commenter identifies fall
                                   into the latter category and
                                   there is no obvious way to
                                   avoid the use of Clause
                                   references as they identify
                                   PHY capabilities.
                                   This has been discussed with
                                   the IEEE-SA editorial staff.
                                   They suggest that we address
                                   this in REVmb, by introducing
                                   a new section for local terms,
                                   which is not intended to
                                   provide definitions for IEEE
                                   100.
                                   Until then, it makes no sense
                                   to attempt to do this piecemeal
                                   in 802.11 amendments, so no
                                   action is proposed in the TGn
                                   draft in resolution of this
                                   comment."

TGn comment: LB115/5442            TGn Resolution:EDITOR:             Accept. Also add an editorial EDITOR
was accepted, but not              2008-04-24 13:36:00Z Reject -      comment to the beginning of
implemented in D4.0.               In a previous draft the change     the annex to indicate that the
Proposed Change: Move the          indicated in the resolution to     Bilbliography is always the last
Bibliography to the final annex    5442 had been implemented.         annex.
                                   The change was undone in
                                   D4.0 because it proved to be
                                   difficult to coordinate the
                                   updates to the Annex
                                   insertions across the multiple
                                   current amendments.
                                   This change can be handled
                                   while rolling amendments into
                                   the anticipated REVmb
                                   revision.
                                   This comment will be
                                   forwarded to the TGmb.
TGn comment: the definition of       TGn Resolution:EDITOR:            Accept in principle.        EDITOR
the Duration/ID field belongs in     2008-06-26 10:23:41Z Reject -     Changes to be made once the
7, but this text defines the         There is no rule in the style     amendment is available for
procedures and normative             guide that requires Clause 7      incorporation, based on the
behavior of the STA to set the       not to have normative text.       resolution to Comment 29.
value of the field. It belongs in    While a separation of structure
9, not in 7.. Proposed               versus behavior is beneficial,
Change: move this text to            the TGn draft is an
clause 9. Change cross ref in        amendment to an existing
7.1.3.2 (where the field is          baseline. The description of
adequately defined in clause         how to calculate the contents
7) to point to its new place in 9    of this field is present in the
instead of 7.1.4. Change cross       baseline in clause 7. The
ref in 7.2.1.7.1 to point to new     TGn amendment is merely
place in 9.                          reworking and extending
                                     existing clause 7 material to
                                     cover the mechanisms
                                     introduced by TGn.
                                     Attempted piecemeal
                                     reorganization of the baseline
                                     through its amendments is not
                                     beneficial.
                                     The correct place to change
                                     where this description should
                                     be put is in REVmb, where all
                                     such text relating to
                                     calculations can be addressed
                                     consistently.

TGn comment: The PSMP                TGn Resolution:EDITOR:           Reject. This is not applicable   EDITOR
Parameter Set field occurs           2008-06-26 13:10:13Z Reject - to TGmb.
only in a single frame, the          The baseline contains mutliple
PSMP Action frame, in                examples of fields used in only
7.4.10.4. As such it is not a        one action frame being
multiply-used field to qualify for   specified in 7.3.1. STD-2007
inclusion in 7.3.1. Proposed         7.4 contains no example of an
Change: move the definition of       action frame defining one of its
the PSMP Parameter Set field         constituent fields.
to 7.4.10.4                          If the commenter wishes to
                                     change this style, it should be
                                     done by comment to REVmb
                                     (rather than in comment to
                                     TGn) where it can be treated
                                     consistently rather than
                                     piecemeal.
TGn comment: This paragraph      TGn Resolution:MAC: 2008-07- Reject. This paragraph is not EDITOR
duplicates the requirements of   10 15:23:42Z Counter - TGn        included in TGmb at this time.
the previous paragraph.          editor to make changes shown This issue may be addressed
Proposed Change: delete it       under any heading that            when P802.11n is rolled into
                                 includes CID 7226 within the TGmb.
                                 document 11-08-0742r4. The
                                 paragraphs are different, since
                                 they include different reasons
                                 for setting the same field to the
                                 same value. Note to REVmB -
                                 some of this behavior is
                                 intended to be performed by
                                 SME, but there is no clause in
                                 the baseline to describe SME
                                 behavior, such a clause needs
                                 to be added, and needs to be
                                 populated with all of the SME
                                 behavior that appears spread
                                 throughout the entire baseline
                                 document.

TGn comment: source of the      TGn Resolution:MAC: 2008-07- Reject. Source of                 EDITOR
value of aDTT2UTTTime           11 21:59:02Z Reject - This     characteristics can be easily
should be mentioned.            attribute comes from the same found using global text search,
Proposed Change: insert         location (PLME-                so this change adds very little
"(provided by the PHY in the    CHARACTERISTICS.confirm) value to the document.
PLME-                           as aSIFStime. There are 84
CHARACTERISTICS.confirm         instances of aSIFStime in the
primitive, see 10.4.3.2)"       baseline, none of which
                                include this reference.
                                If the commenter believes
                                references to be necessary,
                                this should be handled
                                consistently in REVmb, rather
                                than piecemeal in TGn
TGn comment: "if and only if" TGn Resolution:EDITOR:           Counter. Change "A STA may EDITOR
is being used here for literary 2008-07-01 09:23:30Z Reject - enter PS mode if and only if
emphasis, not for its technical The cited text is unchanged    the value of the ATIM window
meaning. The rejection of       text quoted from the STD-2007 in use within the IBSS is
LB124/6239 is incorrect in its baseline. Notwithstanding that greater than zero." to "A STA
analysis. See my comment on the responses to LB129             may enter PS mode if the
11.14.3.3 (page 221 line 25)    comments on "if and only if"   value of the ATIM window in
for further explanation..       have been to change this form use within the IBSS is greater
Proposed Change: change "if in new text within TGn, it is      than zero. A STA shall not
and only if" to "if"            better to address the issue of enter PS mode if the value of
                                this language consistently in  the ATIM window in use within
                                REVmb, rather than             the IBSS is equal to zero."
                                piecemeal in the current
                                amendments.

TGn comment: addition of         TGn Resolution:GEN: 2008-07- Accept the proposed           EDITOR
dot11SMTbase3 was a goof in      16 15:19:26Z Reject -         resolution in the Comment
11k and should be fixed.         This correction is not in the column. Delete
Proposed Change: delete          scope of TGn and should be dot11SMTbase3 from the
dot11SMTbase3 from the           forwarded to TGmb.            IEEE 802.11k-2008
OPTIONAL-GROUPS (show                                          amendment as referenced,
deletion with strikethrough)                                   when merging with IEEE
                                                               802.11-2007.
TGn comment: only a single         TGn Resolution:EDITOR:        Reject. TGn addressed this           EDITOR
ordered list is allowed per        2008-06-19 12:52:04Z Reject - comment, and no action is
subclause, see 11.3 in Style       The cited text is quoted      necessary by TGmb.
Manual. Proposed Change:           baseline text that is not
since its important that the       modified by TGn (it is quoted
middle list in this subclause be   to provide context). This
an ordered list (so the items      comment will be passed on to
can be referenced at lines 12-     TGmb for their consideration.
13 on page 128), this third list
needs to be changed to a dash
list
the variable N_{CBPS} should       Replace N_{CBPS} should be Accept.                                 EDITOR
be replaced by N_{BPSC} in         replaced by N_{BPSC}
Section 17.3.2.1, bullet (i).


No Regulations and              The final sentence should be          Accept.                         EDITOR
conformance tests are listed in deleted.
Clause 2, and Annexes I and J
point to regulatory matters.
"— Defines mechanisms for
dynamic frequency selection
(DFS) and transmit power
control (TPC) that
may be used to satisfy
regulatory requirements for
operation in the 5 GHz band.
The regulations and
conformance tests are listed in
Clause 2."



802.11r added a normative         insert a new item to the dash       Accept.                         EDITOR
reference to FIPS PUB 180-2- list at bottom of this page,
2002, but failed to reference it. following the dash list entry for
                                  "Truncate-128", new text to
                                  read "SHA256 shall be as
                                  defined in FIPS PUB 180-2-
                                  2002"
With the addition by TGn of a Spreadsheet page "802.11-               Accept. Move all 16             EDITOR
new definition clause,            specific definitions" contains a    definitions in tab to 802.11-
containing definitions that are list of definitions to move from      specific definition clause.
specific to 802.11 and not        existing clause 3
appropriate for _The
Authoritative Dictionary of
IEEE Standards Terms_, the
existing definitions in clause 3
should be evaluated to
determine the appropriate
clause.
Subheadings x.y.z.1 should        spreadsheet page "extraneous        Accept in principle. Editor     EDITOR
only appear when there is also subheadings" contains a list of        empowered to conform to
x.y.z.2; where there is only a .1 subheadings to either (1)           intent of comment.
subheading, it should be          remove, or (2) insert another
removed                           subheading at same level,
                                  fixing them as "hanging
                                  paragraphs"
The IEEE Style Guide prohibits       Spreadsheet page "hanging      Accept in principle. Editor   EDITOR
"hanging paragraphs", where a        paragraphs" contain a list of  empowered to conform to
paragraph of text appears after      places in the document that    intent of comment.
a heading and before a next-         need to be fixed. Insert a new
level subheading. This text is       subheading "General" in front
unable to be referenced by a         of each of these hanging
subclause number. See Style          paragraphs.
Guide 11.1 for examples and
potential ways to fix.


Clause 7 is intended to contain      Spreadsheet page "7-           Counter. Adopt proposal in     EDITOR
frame formats, and not the           normative formats" contains    submission 11-09/0433r1.
procedures that are followed         changes needed to add          Accept the changes
by a STA that either generate        normative text to clause 7     recommended in the "7-
or process the frame. There          where needed to define the     procedures" tab.
are two problems with the            frame formats. Spreadsheet     Add a new paragraph to
current text - (1) that it doesn't   page "7-procedures" contains   clause 7 (will eventually
include normative language           changes needed to remove       become clause 7.1.1) stating
that mandates the frame              procedures that are current    the following:
contents, and (2) it often           contained in clause 7.         "A compliant STA shall
contains procedures that are                                        transmit frames using only the
followed by the STAs to                                             frame formats described in
generate/process the frame.                                         Clause 7."

where it says "If the calculated change "factor" to "multiple"      Accept.                       EDITOR
TXOP duration requested is
not a factor of 32us", it really
means "multiple of 32us"

replace "IE" in this sentence        as in comment                  Accept in principle. Make a     EDITOR
with "information element"                                          global change of "IE" to
(twice)                                                             "information element", deleting
                                                                    the use of "IE" where it is
                                                                    being defined as an
                                                                    abreviation.
Several of the notes in Tables    delete the use of "only" in the Counter. See CID 29.           EDITOR
7-8 through 7-18 use the          Notes to Tables 7-8 through 7-
wording "<xxx> is present only    18, changing "only if" to "if"
if <yyy>". The formal meaning     throughout.
of this phrase is "If <yyy> is
false, then <xxx> shall not be
present, otherwise <xxx> may
be present." However that is
not the intention here; rather
the intent is "If <yyy> is true
then <xxx> shall be present."
The "only if" (also called the
contrapositive form) is, in
addition to not making the
statement of inclusion that is
desired, also restricting any
future use of the information
elements. Such restrictions on
the future should be avoided in
the standard.


second and third sentences of     delete second and third           Accept.                      EDITOR
this paragraph duplicate          sentences of this paragraph.
information elsewhere in the
subclause, and do not follow
the style of other frame
formats in 7.2.3
Use of the "Requested             change final sentence of first    Reject. The FH parameters       EDITOR
Information" may result in        paragraph to "Note that the       element is mentioned explicitly
many pieces of information        information returned as a         because it is a special case.
appearing in the Probe            result of a Probe Request
Response twice, not just the      frame with a Request
FH parameters and FH Pattern      information element may
Table. There is no reason to      include items replicating the
identify them specifically.       optional elements identified in
                                  Table 7-15."
since all the bits of the         delete final paragraph of    Accept.                           EDITOR
Capabilities Information field    7.3.1.4
have now been assigned,
there is no need to reserve the
unused bits
The additional fixed fields used delete this paragraph         Accept.                           EDITOR
within Action frames are not in
the subclauses referenced
here. Also, a range of
subclauses with the first
number higher than the
second (7.3.2.12 through
7.2.1.17) makes no sense.
Possibly its a double typo, and
what was intended was
"7.3.1.12 through 7.3.1.17";
even so the paragraph should
be deleted.
Tables B.1, B.2, and B.3 do      Add a reference to these      Accept                            EDITOR
not have any references in the tables in the text on page 769.
text.
This informative annex is no      delete annex C                     Counter. See CID 95         EDITOR
longer informative, as it is so
far out of date that it no longer
describes a reasonable subset
of MAC operation.

actually, this is only one          perhaps change first line of    Counter. We applied the      EDITOR
possible translation of that line   G.2 from "of the well-known" to "BROOM" function.
of Friederick von Schiller's An     "of a mis-typed translation of
de Freude, and it is "Fire-         the well-known". Or just
inspired we tread" (Not "Fire-      sweep this one under the rug.
insired"). Someone did a typo.
(BTW, its "Wir betreten
feuertrunken/ Himmlische,
dein Heiligtum" in the original,
literally "We enter, drunk with
fire/Heavenly one, your
sanctuary". Its not surprising
that there are multiple
translations of this phrase.)

"The packet error rate (PER) Clarify the sentence                    Accept. See comment 72.     EDITOR
shall be less than 10% at a
PSDU length of 1000 octets
for rate-dependent input levels
shall be the numbers listed in
Table 145 or less." Sentence
makes no sense at all

In the behavior limits set table change to 389                       Counter. Replace "EN 301 389- EDITOR
I-3 we find ETSI EN 301 389-                                         1" with "EN 301 893"
1, but in                                                            throughout the document.
Table I.1—Regulatory
requirement list
we find ETSI EN301 893
It seems there may be a typo
893 -> 389. There is a 893
doc that does contain emission
requirements for Europe.

There is no rules defined to        Clarify the transmission order   Reject. The text in this      EDITOR
specify the transmssion order       rules for frames which are       paragraph states that the MAC
of the MSDUs which are              targetted to different           does not reorder frames for
targetted to different unicast or   addresses. If there are no       non-QoS STA's, except for
groupcast addresses. Also the       rules to specify the             "power management"
clause 6.1.3 is difficult to        trnasmission order between       procedures.
understand                          different destinations delete
                                    the text which proposes such
                                    functionality.
normative statements about          change "is optionally present"   Counter. See CID 29.        EDITOR
presence of IEs in frames are       to "may be present"
appropriate in clause 7
The text states "The Multicast    Clarify the text.               Reject. The Supported Rate IE EDITOR
Rate field specifies the data                                     always refers to the PHY data
rate, 0.5 Mb/s units …". The                                      rate.
text is ambiguous since data
rate can have multiple
meanings? For example, it is
the PHY rate or the MSDU
data rate. If it's MDSU data
rate, how does the STA know
the rate of the multicast
stream?
It is important to awknowledge    Please add the phrase             Counter. Add "Spectrum      EDITOR
(at least for outdoor networks)   “Spectrum Management” in          Management" to the third
that location is a key part of    the 3rd column entry for any      column for the "LCI" row.
spectrum management. I think      row in the table that clearly has
that column 3 of the              to do with location data or its
measurement report table          format.
should have a 2nd
“measurement use”
descriptions in any row who's
report has to do with location
information. (LCI etc) For
future considerations, it makes
sense to specify that location
is more than simply a “radio
resource measurement”
parameter--but also has a role
to play in “spectrum
management” as well.


"that bits numbered (N2 + 1) × Replace "through" with "to".       Accept in principle. Globally   EDITOR
8 through 2007                                                    replace any use of "through"
in the bitmap are all 0."                                         with "to", where it expresses a
                                                                  range. Do not make any
This is an ugly American                                          changes in Annex C.
Colloquialism
since N1 is already defined to remove FLOOR function              Accept.                       EDITOR
be an even number, the
FLOOR function unnecessary
for (N1)/2
There should be a classifier      Add Classifier Type: "For           UNRESOLVABLE (EDITOR: EDITOR
type which will allow             Classifier Type 4, the classifier   2010-05-20 09:24:40Z) - In
classification based on the       parameters are the following        Table 7-42 replace the last two
802.1D UP and/or 802.1Q           parameters in an IEEE 802.1Q        lines with:
VLAN ID in an 802.1Q tag          tag header: IEEE 802.1D-
header independently.             2004 [Bxx] User Priority and        2         IEEE 802.1Q
                                  IEEE 802.1Q-2003 [Byy] VLAN         parameters
                                  ID. The Frame Classifier field      4         IEEE 802.1D/Q
                                  for Classifier Type 4 is defined    parameters
                                  in Figure xx. The CFI bit           3, 5-255 Reserved
                                  cannot be used for                  [Note: 3 reserved for expected
                                  classification. The subfields in    use by 802.11v.]
                                  the classifier parameters are
                                  represented and transmitted in      At the end of section 7.3.2.31
                                  big-endian format." and add a       add:
                                  suitable figure.
                                                                      For Classifier Type 4, the
                                                                      classifier parameters are the
                                                                      following
                                                                      parameters in an IEEE 802.1Q-
                                                                      2003 [B14] tag header:
                                                                      Priority Code Point (PCP;
                                                                      equivalent to IEEE 802.1D-
                                                                      2004 [B12] User
                                                                      Priority), Canonical Format
                                                                      Indicator (CFI) and VLAN ID
                                                                      (VID). The
                                                                      Frame Classifier field for
                                                                      Classifier Type 4 is defined in
                                                                      Figure 7-90x.
                                                                      The subfields in the classifier
                                                                      parameters are represented
The endianness of the             Suggestion: add at 802.11-          and
                                                                      Accept.                         EDITOR
"802.1Q Tag Type" field in        2007, 7.3.2.31 on page 137 --
Type 2 (802.1Q) TCLASes           "as in IEEE 802.1Q-2003
should be specified. In 802.11-   [Bxx]"
2007, 7.3.2.31. (page 137)
This should be added in the
TGv Draft
The endianness of the             Suggestion: add at 802.11-          Accept.                          EDITOR
"[Ethernet] Type" field in Type   2007, 7.3.2.31 on page 136
0 (Ethernet) TCLASes should       "as in "Ethernet" [Bxx]".
be specified. See 802.11-
2007, 7.3.2.31 (page 136).
This should be added in the
TGv Draft
The text for Type 2 (802.1Q)      Add editor instructions to  Accept.                                  EDITOR
TCLASes implies the UP and        amend test to read "For
the VLAN ID can be matched        Classifier Type 2, the
independently, but Figure 7-90    Classifier Parameter is the
shows otherwise.                  IEEE 802.1Q-2003 [Bxx] VLAN
See also 802.11-2007,             Tag TCI". Amend Figure 7-90
7.3.2.31 page 137                 to say "802.1Q VLAN TCI".
"The RSN Capabilities field       "The RSN Capabilities field         Counter. Change the second EDITOR
indicates requested or            indicates requested or              sentence of the first paragraph
advertised capabilities. The      advertised capabilities. The        of 7.3.2.25.3 to the following:
value of each of the RSN          value of each of the RSN            "If the RSN Capabilities field is
Capabilities fields is 0 if the   Capabilities fields is 0 if that    not present, the default value
RSN Capabilities field is not     RSN Capabilities field is not       of 0 is used for all its
available in the RSN              available in the RSN                subfields."
information element."             information element."
IEEE 802.11 is under the IEEE     First reach agreement on each       Reject.                        EDITOR
802, which is under IEEE-SA.      and every unwritten rule and        No specific change is
IEEE-SA has an IEEE               document it. (If the first cannot   requested.
Standards Style Manual, which     be accomplished, then for any       While the TG understands the
applies to all standards          comment that is submitted with      commentors sentiments,
produced under the IEEE-SA.       the premise that it is an           unwritten conventions or
This document defines the         unwritten rule, a long standing     assumptions in standards
mandatory clauses that shall      tradition the comment is            development are inevitable.
be present within all IEEE-SA     discredited without                 The process for applying these
Standards. This document          documented proof. A                 rules or assumptions is up to
also defines word usage (e.g.,    comment resolution /                the group that addresses the
shall and may) along with         disposition cannot be based         issues. The commentor is
many other items. However         under the guise of an unwritten     encouraged to participate in
there appears to be a             rule or a long standing             the activities of the TG.
movement within IEEE 802.11       tradition. In other words a
by some individuals that there    comment cannot be dismissed         TGmb has approved the
are other requirements that       simply based on an unwritten        following responses to the
are neither written nor           rule.) Second recognize that        "unwritten rules" enumerated
documented anywhere. These        these agreed-to unwritten           given in the "Comment" field:
unwritten rules are causing       rules (now documented) are          A) IEEE 802.11 will keep its
two problems. 1) Comments         only applicable to 802.11           MIB.
being made to 802.11 working      drafts and standards and are        B) IEEE 802.11 will keep a
group drafts are being            not applicable to other working     PICS proform.
dismissed due to these            groups' drafts or standards         C) and D) refer to comment
unwritten rules. The              within 802 or under IEEE-SA         29.
comments would most likely        and that individuals should         E) An informative annex
not be made or reoccur with       keep this in mind when voting       should not include normative
such frequency, if they were      on drafts outside of 802.11.        text. If normative text is
known and if these rules were     Third that any item not             included in an informative
document for all to see. 2)       covered by the IEEE-SA IEEE         annex, it should be changed.
Some individuals of 802.11        Standards Style Manual and          F) This is an editorial matter
when they vote on non-802.11      that the 802.11 membership          and should not be discussed in
drafts a MIB (Annex D) is
Since are claiming these          agrees to during any of its
                                  Update the normative                the TG. The document is
                                                                      Reject.                        EDITOR
required for 802.11, will the     references, which are currently     consistent with the current
normative references for their    dated as ISO/IEC 8825-x             quoted references. The
creation be updated and so        1995, and the MIB in Annex D        commentor is encouraged to
too the MIB itself based on       accordingly.                        create a submission with the
these updated normative                                               changes required to address
references?                                                           this suggestion.
Figure 5-4 has never come         Replace Figure 5-4 with a           Reject. This figure is the     EDITOR
through well in the published     better representation.              original graphic.
Std. Can we get back to an
original (that I suspect was
useful), or replace this with a
new diagram that actually is
worth 1,000 words?
There appears to be confusion      Change 6.2.1.3.1's "status       Reject. The proposed change EDITOR
about what the MA-                 information" and                 does not contain the specifics
UNITDATA.confirm primitive's       "corresponding preceding"        necessary to update the draft.
behavior is, or, as a result,      phrases to be clear. Change      The commentor is encouraged
when it is generated. The          6.2.1.3.3's "status of the       to create a submission with the
1999 version of 802.11 had a       service provided" to be clear.   changes required to address
MA-UNITDATA-                                                        this suggestion.
STATUS.indication primitive,
which was apparently replaced
by this .confirm. That primitive
provided information about the
successful/unsuccessful
delivery of an MSDU to the
peer entity (apparently?). The
2007 MA-UNITDATA.confirm
appears to only provide
immediate response status as
to the MAC's ability and
readiness to perform the
delivery service as described
in the Standard, without regard
to whether this will result in
actual successful delivery to
any peer MAC. The wording is
not clear in this regard,
however.


There is no concept of             Add MLME-STOP mechansim          Accept the proposed                 EDITOR
terminating a BSS once             and primitives. Detailed         resolution contained in
started. With "controller-         changes provided in separate     document 11-08/1340r0,
based" AP structures               presentation.                    excluding the following two
becoming popular, and the                                           paragraphs:
concept of multiple BSS APs                                         'The following paragraph can
being introduced in 802.11k,                                        be included if 802.11v BSS
there is a need for a                                               Transition Management with
mechanism that ends BSSs                                            Termination information is
created by MLME-START.                                              available:

                                                                    It is desirable, but not required
                                                                    that the SME notify associated
                                                                    non-AP STAs of imminent
                                                                    infrastructure BSS termination
                                                                    before issuing the MLME-
                                                                    STOP.request. This can be
                                                                    done with the BSS Transition
                                                                    Management procedure, using
                                                                    the Termination information.'
802.11k introduces the              Relate the "Multiple BSS set"    DISAGREE (EDITOR: 2010- EDITOR
concept of "Multiple BSSID          concept to the architectural     05-20 09:24:46Z) - Decline.
set" but does provide any           concepts in 802.11-2007          MBSSID should be further
architectural description of        Section 5, especially Sections   defined in the task groups that
how these are represented.          5.2 and 5.5.                     are currently using the
The last paragraph would                                             concept.
imply that the multiple BSSIDs
are actually multiple, individual
APs. If this is the case, then it
would imply multiple, individual
MACs and PHYs (except for
the antenna connector), which
would lead to independent
medium access, and frame
queuing, so coordination
occurs only when actual
collisions occur at the antenna
connector. This does not
seem effieicient, nor what
most implementations do.
Further, there is no discussion
of the relationship between
these BSSes and their ESSes,
nor how DS Associations or
Portal (integration service)
address mappings are
maintained such that the
system can integrate into an
802 network unambiguously.
The 802.11-2007 Std says,          Clarify in 9.1.3.1 or 9.9.3.1.2,   Change the 8th paragraph of EDITOR
"The management frames             whether the management             9.9.3.1.2 as follows: “The
shall be sent using the access     frames sent using AC_VO AC         MPDUExchangeTime equals
category AC_VO without being       shall count toward the             the time required to transmit
restricted by admission control    used_time parameter or not.        the MPDU sequence. For the
procedures." But, this leaves it                                      case of an MPDU transmitted
ambiguous whether these                                               with Normal Ack policy and
frames count toward the                                               without RTS/CTS protection,
used_time parameter                                                   this equals the time required to
described in 9.9.3.1.2.                                               transmit the MPDU plus the
                                                                      time required to transmit the
                                                                      expected response frame plus
                                                                      one SIFS. Frame exchange
                                                                      sequences for Management
                                                                      frames are excluded from the
                                                                      used_time update. If the
                                                                      used_time value reaches or
                                                                      exceeds the admitted_time
                                                                      value, the corresponding
                                                                      EDCAF shall no longer
                                                                      transmit using the EDCA
                                                                      parameters for that AC as
                                                                      specified in the QoS
                                                                      Parameter Set element.
                                                                      However, a non-AP STA may
                                                                      choose to temporarily replace
                                                                      the EDCA parameters for that
                                                                      EDCAF with those specified
                                                                      for an AC of lower priority, if no
                                                                      admission control is required
                                                                      for those ACs.”

Section 9.9.3.1 says, "A non-      Clarify that the use of a EDCA Comment has been              EDITOR
AP STA may support                 parameters for a lower priority withdrawn.
admission control procedures       (non admission mandatory)
in 9.9.3.1.2 to send frames in     AC does not require
the AC where admission             modification of the QoS control
control is mandated; but, if it    field.
does not support that
procedure, it shall use EDCA
parameters of a lower priority
AC, as indicated in Table 9-1,
that does not require
admission control" and also "If
a STA desires to send data
without admission control
using an AC that mandates
admission control, the STA
shall use EDCA parameters
that correspond to a lower
priority and do not require
admission control." Nothing in
this section discusses the
setting of the TID(UP) field in
the QoS control when this is
done.
Section 11.2.1.1 says, "The        To clarify the meaning of "shall Counter. Adopt the changes in EDITOR
Power Managment bit shall not      not be set" change this phrase document 11-09/0003r4.
be set in any management           to "is reserved, and shall be
frame, except an Action            ignored on reciept".
frame." What does "not set"
mean? Is this meant to say
"set to zero"? It's not clear
where this statement
orignated, and it would put an
undue restriction on non-AP
STAs, if it said "set to zero."
Since management frames
from the AP to non-AP STA
are explicitly buffered when the
STA is in Power Save (Section
11.2.1.5(a)), there is no reason
to restrict an associated non-
AP STA from doing
management frame
transactions while in PS mode.


This section discusses the      Change "MSDUs" to "MSDUs             Counter. See the resolution ot EDITOR
behavior for buffering MSDUs and management frames"                  comment 61
when a non-AP STA is in PS throughout 11.2.1.
mode. But, Section
11.2.1.5(a) makes it clear that
this applies to management
frames as well. It is confusing
that management frames are
not mentioned in 11.2.1.

The Standard contains              Formulate a approach to use       Reject. The proposed change EDITOR
inconsistent approaches to the     of these terms and concepts in    does not contain the specifics
terms “mandatory” and              the main body and PICS, and       necessary to update the draft.
“optional”, especially when a      then edit the Standard to apply   The commentor is encouraged
feature could be either or both    this approach consistently.       to create a submission with the
“implemented” or “enabled.”                                          changes required to address
Further, the relationship                                            this suggestion.
between the main body
normative text containing
discussion of “mandatory” or
“optional”, and the PICS
entries for M/O is inconsistent
and confusing.
In the description of the Power     Replace "The field is coded as Accept.                       EDITOR
Constraint field of the Power       an unsigned integer in units of
Constraint Element, the             decibels relative to
following sentence appears:         1mW." with "The field is coded
"The field is coded as an           as an unsigned integer in units
unsigned integer in units of        of decibels."
decibels relative to 1mW." This
sentence is different from the
one that appeared in the
originally approved 11h
amendment. In the
amendment, the sentence
appeared as: "The field is
coded as an unsigned integer
in units of dB." I believe that
the original was correct and
that the attempt to remove the
abbreviations dB and dBm
from the rollup have
introduced an error. Some
other fields were correctly
translated from "dBm" to
"decibels relative to 1mW"
because those fields contain
an absolute value of signal
level. But this field is intended
to be used as a relative value
of signal - specifically, it is
used as an adjustment to a
specific absolute maximum
signal power, as indicted in
this subclause by the following
The "The local maximum
text: Transmit Power and Link       Resolve the mismatch            Reject. The Transmit Power      EDITOR
Margin entries in the table in      between the SAP and the field   and Link Margin field
this subclause show that these      that is used to carry the       descriptions in clause 7.3.2.18
parameters are integers with a      information.                    are defined to be signed
range of -127 to 127, but the                                       integers.
field descriptions in the frames
that carry this information
indicate that the values in the
fields are unsigned integers,
suggesting that a different
range should be specified
here, or that the the fields in
the frames should be integers.
The Text says:                     Change the sentence: "The       Accept                    EDITOR
When an IBSS STA’s SME             pair of STAs shall use the
wants to set up a security         pairwise cipher suite specified
association with a peer STA,       in Message 3 of the 4-Way
but does not know the peer’s       Handshake sent by the
policy, it must first obtain the   Authenticator STA with the
peer’s security policy using a     higher MAC address (see
Probe Request frame. The           8.5.1)." to read "If the 4-Way
SME entities of the two STAs       Handshake is succesfully
select the pairwise cipher         completed, then the pair of
suites using one of the 4-Way      STAs shall use the pairwise
Handshakes. The SMEs of            cipher suite specified in
each pair of STAs within an        Message 2 of the 4-Way
IBSS may use the EAPOL-Key         Handshake initiated by the
4-Way Handshake to select a        Authenticator STA with the
pairwise cipher suite.             higher MAC address (see
As specified in 8.5.2, Message     8.5.1)."
2 and Message 3 of the 4-Way
Handshake convey an RSN
information element. The
Message 2 RSN information
element includes the selected
pairwise cipher suite, and
Message 3 includes the RSN
information element that the
STA would send in a Probe
Response frame.

The pair of STAs shall use the
pairwise cipher suite specified
in Message 3 of the 4-Way
Handshake sent by the
Authenticator STA with the
Figure 5.6 uses the term        Change the term to use the        Counter. Changed to IEEE   EDITOR
"802.xLAN", but this term is    more recognized standard          802 LAN
never defined in the standard. one.
IEEE Std. 802-2001 uses the
term "IEEE 802 LANs and
MANs"
The issue might be named            I think this should be             Reject. The proposed change EDITOR
"gratuitous double-                 documented in Annex M, since       does not contain the specifics
encapsulation". It involves         the behavior is out there in the   necessary to update the draft.
deliberately (and incorrectly)      field. Whether we want to          The commentor is encouraged
placing an additional RFC1042       discourage it or not is open to    to create a submission with the
SNAP header around the              debate.                            changes required to address
contents of a frame that                                               this suggestion.
already has such a header (in
particular, an AppleTalk Phase
II frame) to encode the length
field. The decoding rules for
the default case of 802.1H
then cause a correct
implementation to strip the
outer SNAP header and turn it
into an 802.3 length field,
leaving the interior SNAP
header alone (since the length
field in the outer SNAP header
is neither the AppleTalk nor
IPX special-case
encoding/decoding rules
value).
    There are implementations
out there that do this on
purpose, since then an
incorrect (always remove
SNAP header) and a correct
(do not remove SNAP header
if it's one of the special values
or is the BTEP header)
implementation both produce
the same 802.3 frame the the
Item (i) starts: "Divide on         Change N sub CBPS to N sub Accept.                                  EDITOR
resulting coded and                 BPSC.
interleaved data string into
groups of NCBPS bits." (CBPS
is a subscript, referring to the
number of coded bits per
symbol). I believe the correct
variable is N sub BPSC
(number of bits per
subcarrier). Clause 17.3.5.7
uses the latter.
The abbreviations FEC, AGC          Add entries to Clause 4 for        Accept. See submission in 11- EDITOR
and AFC are not includced in        FEC, AGC and AFC.                  09/0051r1.
clause 4
Three things. 1) missing period     Fix these three editorial          Accept in principle. Editor is   EDITOR
at end of "nch = 0, 1, …, 200"      problems.                          directed to solve issues to
(this is the end of a sentence).                                       match style guide.
2) The indendation is screwed
up for two paragraphs
following that equation. 3)
There is a space missing
between "frequency" and "is"
in the first sentence following
that equation.
First sentence of 17.3.10.1         Fix grammer. Maybe it should Accept.                       EDITOR
reads "The packet error rate        read "The packet error rate
(PER) shall be less than 10%        (PER) shall be 10% or less
at a PSDU length of 1000            when the PSDU length is 1000
octets for rate-dependent input     octets and the rate-dependent
levels shall be the numbers         input level is as shown in
listed in Table 17-13 or less."     Table 17-13."
I'm not sure exactly what this
should say, but the grammer is
obviously wrong with the two
occurence of "shall be".

Third paragraph of clause           1) add "shall begin" following Accept. See submission in 11- EDITOR
17.3.11 has several problems.       "PLCP header" in the second 09/0051r1.
1) There is something missing       sentence.             2) correct
from the second sentence:           the third and fourth sentences.
"The PLCP shall then issue a
PMD_TXSTART.request, and
transmission of the PLCP
preamble and PLCP header,
based on the parameters
passed in the PHY-
TXSTART.request primitive."
Perhaps the words "shall
begin" should follow "PLCP
header"?
2) The third sentence states
that scrambling shall begin
immediately after transmission
of the preamble is started.
This contradicts clause
17.3.2.1 point (b), which
states: "The contents of the
SIGNAL field are not
scrambled."
3) The fourth sentence says
that scrambled and encoded
data are exchanged between
the MAC and the PHY, which I
believe is not correct. I believe
that the sending PHY
scrambles and encodes, the
receiving PHY unscrambles
and unencodes, and the MAC
sublayer never sees
The last sentence of the          Reword sentence as: "If the   Accept.                            EDITOR
paragraph following Figure 17-    coded PSDU (C-PSDU) length
14 reads: "If the coded PSDU      is not a multiple of the OFDM
(C-PSDU) is not multiples of      symbol length NCBPS, the
the OFDM symbol, bits shall       PSDU is padded prior to
be stuffed to make the C-         scrambling and coding (see
PSDU length multiples of the      clause 17.3.5.3)".
OFDM symbol." This is
misleading because it implies
that bit padding is done after
coding. Clause 17.3.5.3
explains how the number of
pad bits is determined. Also,
the word "stuffed" is used
instead of "padded" and the
phrases "is not multiples of"
and "to make C-PSDU length
multiples of" are not correct
grammar.

The TX Preamble state block       Edit this block so that it is      Counter. Edit this block so that EDITOR
incorrectly says that the         correct. For example, it could     it says: "followed by the
training symbols consist of the   say that the training symbols      SIGNAL field".
SIGNAL contents.                  are FOLLOWED BY the
                                  indicated fields (rate, etc.) It
                                  would be better to say the
                                  training symbols are followed
                                  by the SIGNAL symbol.
The paragraph following          Clarify both aspects of the first Reject. See submission in 11- EDITOR
Figure 17-16 begins: "Upon       sentence following Figure 17- 09/0051r1.
receiving the transmitted        16.
PLCP preamble,
PMD_RSSI.indicate shall
report a significant received
signal strength level to the
PLCP. This indicates activity to
the MAC via
PHY_CCA.indicate." The
words "upon receiving" are
ambiguous. Do they mean
upon receiving a complete
preamble? I don't think so
since that would require more
time than is alloted for CCA
Activity indication in Clause
17.3.10.5. How much of the
preamble should be received
before the PMD issues this
indication? This should be
clarified, either to provide a
specific portion of the
preamble or at least to avoid
implying a PMD waits until it
receives the entire preamble.
Also, the words "shall report a
significant received signal
strength level" are unclear.
What is "significant"?

DS Parameter Set element          Extend DS Parameter Set     Reject. The current text does EDITOR
support only 2.4 GHz band it's    element to 5GHz band. (Name not prevent the DS Parameter
because DSSS is used only         would be change.)           Set from being used for the 5
2.4GHz. However STA, in                                       GHz band.
5GHz band, have a difficulty to
recognize current channel
correctly because of inter
channel interference.
Table 7-8 includes many           Consider to reduce a length of   Reject. Making this proposed   EDITOR
information element and it's      beacon. for example.             change would affect the
getting long when new                - Allow to include IE's in    interoperability of current
amendments comes. Current         Probe/Association request        implementations of IEEE
standard require to include       only.                            802.11.
such IEs into both of Beacon         - Beacon include a part of
and Probe/Association             IE's and only DTIM Beacon
response. But long beacon         include whole IE's.
affect to power consumption
and band efficiency.
"The packet error rate (PER)      Clarify the sentence             Accept. See comment 72.        EDITOR
shall be less than 10% at a
PSDU length of 1000 octets
for rate-dependent input levels
shall be the numbers listed in
Table 145 or less." Sentence
makes no sense at all
In table 11A-2, The text in the    Amend the sentence to read         Accept the first option of the   EDITOR
table states, "In a response:      as follows, "In a response: a      proposed change.
TSPEC (see 7.3.2.30),              TSPEC element (see
followed by zero or one            7.3.2.30), followed by zero or
Schedule (See 7.3.2.34)". This     one Schedule elements (See
is confusing since it implies      7.3.2.34), followed by zero or
that some IEs mandated by          more Delay elements (see
clause 11.4 are not required in    7.3.2.32), followed by other
a response.                        optional elements as specified
(Submitted on behalf of Dave       in 11.4".
Stephenson)                        Note: I think the elements
                                   which are not part of the non-
                                   AP STA's request, but may be
                                   part of the AP's response are
                                   worth mentioning explicitly. For
                                   the sake of brevity, I
                                   suggested referring to clause
                                   11.4 to address other
                                   elements which may be
                                   present in the response.
                                   Alternatively, the following
                                   resolution could also be used:
                                   "In a response: a TSPEC
                                   element (see 7.3.2.30),
                                   followed by zero or one
                                   Schedule elements (See
                                   7.3.2.34), followed by zero or
                                   one Delay elements (see
                                   7.3.2.32), followed by zero or
                                   more TCLAS elements (see
                                   7.3.2.31), followed by zero or
                                   on TCLAS processing
"The IEEE 802.1X Controlled        elements (see 7.3.2.33)". If
                                   Delete both the sentences.         Accept. Delete both              EDITOR
Port returns to being blocked.     these are considered within        sentences.
As a result, all data frames are   scope of 11r PAR, then either
unauthorized before invocation     delete the second sentence.
of an MLME-                        OR, change:"As a result of the
DELETEKEYS.request                 802.1X Controlled port being
primitive." - this change seems    blocked, all data frames are
out-of-scope for this group, as    unauthorized before invocation
this is not pertinent to 11r.      of an MLME-
Moreover, the second               DELETEKEYS.request
sentence is ambiguous and          primitive."
even, technically incorrect.
The data frames may be valid
before invocation of the
DELETEKEYS.requst
primitive.

Not just any "STA" - this          Change "STA" to "non-AP          Reject. In this case, the use of EDITOR
should be a non-AP STA             STA" twice in first paragraph of STA is clear since it refers to
                                   11A.1                            the process of BSS-Transition.
Not just any "STA" - this      Based on the page/line as they   Reject. In this case, the use of EDITOR
should be a non-AP STA         appeared in P802.11r-D8.0-       STA is clear since it refers to
                               redline.pdf, change "STA" to     the process of BSS-Transition.
                               "non-AP STA" on (page.line)
                               56.64, 57.06, 57.10, 57.13,
                               57.20, 57.40, 57.51, 57.54,
                               57.55
Not just any "STA" - this      Based on the page/line as they   Reject. In this case, the use of EDITOR
should be a non-AP STA         appeared in P802.11r-D8.0-       STA is clear since it refers to
                               redline.pdf, change "STA" to     the process of BSS-Transition.
                               "non-AP STA" on (page.line)
                               59.04, 59.35, 59.43, and 59.48

Not just any "STA" - this      Based on the page/line as they   Reject. In this case, the use of EDITOR
should be a non-AP STA         appeared in P802.11r-D8.0-       STA is clear since it refers to
                               redline.pdf, change "STA" to     the process of BSS-Transition.
                               "non-AP STA" on (page.line)
                               61.06, 61.22, 61.64, 62.01,
                               62.04, 62.06, 62.08, 62.16,
                               62.58
Not just any "STA" - this      Based on the page/line as they   Reject. In this case, the use of EDITOR
should be a non-AP STA         appeared in P802.11r-D8.0-       STA is clear since it refers to
                               redline.pdf, change "STA" to     the process of BSS-Transition.
                               "non-AP STA" on (page.line)
                               65.35, 65.55, 65.60, 65.63,
                               65.64
Not just any "STA" - this      Based on the page/line as they   Reject. In this case, the use of EDITOR
should be a non-AP STA         appeared in P802.11r-D8.0-       STA is clear since it refers to
                               redline.pdf, change "STA" to     the process of BSS-Transition.
                               "non-AP STA" on (page.line)
                               66.37, 66.60, 66.63

Not just any "STA" - this      Change "MAC address of the Reject. In this case, the use of EDITOR
should be a non-AP STA         STA" to "MAC address of non- STA is clear since it refers to
                               AP STA"                      the process of BSS-Transition.

"Current mesage number" is a In second sentence of second       Counter. See comment 91         EDITOR
duplicate definition of "RSC  paragraph, change from "The
value", and is not needed     RSC field gives the current
                              message number for the GTK,
                              to allow a STA" to "Delivery of
                              the RSC field value allows a
                              STA"
The REVma MEC told the        change all of the remaining       Counter. Change all             EDITOR
editor to change every        occurrences of "RC4" to           occurences of RC4 to ARC4,
occurrence of "RC4" to        "ARC4"                            excluding entries in the PICS
"ARC4", and this was done                                       and Annex C.
throughout the draft at that
time. However, a later
submission (PeerKey
Handshake) incorporated
during the Sponsor Ballot
process added further uses of
"RC4"
"Current mesage number" is a Change from "The RSC field Accept.                               EDITOR
duplicate definition of "RSC gives the current message
value", and is not needed    number for the GTK, to allow a
                             STA" to "Delivery of the RSC
                             field value allows a STA"

The last sentence in the           Change to "...are unauthorized Counter. See CID 81         EDITOR
paragraph: "As a result, all       after receipt of the MLME
data frames are unauthorized       Association or Reassociation
before invocation of an MLME-      confirm primitive that is not
DELETEKEYS.request                 part of a Fast BSS Transition,
primitive" seems to be missing     MLME Disassociation or
a statement of the beginning of    Deauthentication primitive and
the interval.                      before invocation of an MLME-
                                   DELETEKEYS.request
                                   primitive."


Section 7.3.1.17 says that the     Remove the sentence "This        Counter. Make the proposed EDITOR
Max SP Length subfield of the      subfield is also reserved when   change AND remove the
QoS Info field is reserved         all four U-APSD flags are set    phrase
when all four U-APSD flags         to 0."                           "and at least one of the four U-
are set to 0.                                                       APSD flags is set to 1" from
Section 7.1.1 says that                                             the
reserved fields and subfields                                       sentence following the
are set to 0 on transmission                                        deletion.
and ignored upon reception.
This implies the value in this
field (which should be 0) has
no meaning.
So if a non-AP STA sets all
four U-APSD flags to 0 in the
QoS Info field in the QoS
Capability IE in the Association
Request, and then uses an
ADDTS Request to set up a
delivered-enabled TS (and
also sets up a trigger-enabled
TS -- perhaps the same TS),
how many buffered MSDUs
and MMPDUs may the AP
deliver to this non-AP STA
during an SP triggered by this
non-AP STA?
Section 7.3.2.30 says that          Add to the end of the               Counter. Add the following text EDITOR
"The Minimum PHY Rate field         paragraph in question:              in Clause 11.4.2:
is 4 octets long and contains       The Minimum PHY Rate is in          "The value of the minimum
an unsigned integer that            the AP's operational rate set,      PHY rate in a TSPEC shall
specifies the desired minimum       for an uplink TS.                   satisfy the following
PHY rate to use for this TS, in     The Minimum PHY Rate is in          constraints:
bits per second, that is            the non-AP STA's operational        The Minimum PHY Rate is in
required for transport of the       rate set, for a downlink TS.        the AP's operational rate set,
MSDUs belonging to the TS in        The Minimum PHY Rate is in          for an uplink TS.
this TSPEC. This rate               the AP's operational rate set       The Minimum PHY Rate is in
information is intended to          and non-AP STA's operational        the non-AP STA's operational
ensure that the TSPEC               rate set, for a bidirectional TS.   rate set, for a downlink TS.
parameter values resulting                                              The Minimum PHY Rate is in
from an admission control                                               the AP's operational rate set
negotiation are sufficient to                                           and non-AP STA's operational
provide the required                                                    rate set, for a bidirectional TS."
throughput for the TS. In a                                             The editor is directed to re-
typical implementation, a TS is                                         word the text as necessary.
admitted only if the defined
traffic volume can be                                                   Add a reference to clause
accommodated at the                                                     11.4.2 at the cited location.
specified rate within an
amount of WM occupancy
time that the admissions
control entity is willing to
allocate to this TS."
There is no further clarification
on the allowable values.
Annex K.2 (informative) refers
to duration (Nominal MSDU
Size, Minimum PHY Rate).
This is not well-defined if the
Minimum has not been not a
Annex C PHY Rate is                 Remove Annex C and all              Counter. Insert a sentence      EDITOR
maintained for ages and it          references to it (18.1.2,           describing the date of last
does not match with the             A.4.4.1, A.4.4.2, A.4.4.3,          maintenance of Annex C.
normative behavior described        A.4.4.4, A.4.9).
elsewhere in the standard. It is
questionable whether it would
still be of any real benefit to
include the SDL description.
Since the IEEE 802.11
standard is already very long
and is getting longer with the
new amendments, it would be
useful to get rid of unneeded
areas in the standard.
Clause 16 has not been             Remove Clause 16 and all      Reject. This clause has      EDITOR
maintained for ages and may        references to it.             already been marked as not
not match with the normative                                     being maintained.
behavior described elsewhere
in the standard. There does
not seem to be any interest in
implementing or deploying
802.11 with IR PHY. Since the
IEEE 802.11 standard is
already very long and is
getting longer with the new
amendments, it would be
useful to get rid of unneeded
areas in the standard.
Clause 14 describes                Remove Clause 14 and all      Reject. The are currently     EDITOR
techonology that is not used       references to it.             deployed devices that support
anymore. Since the IEEE                                          Clause 14 and this clause
802.11 standard is already                                       helps administrators of these
very long and is getting longer                                  systems to support their
with the new amendments, it                                      network.
would be useful to get rid of
unneeded areas in the
standard.
TKIP has reached the end of        Add following paragraph to the Accept.                     EDITOR
its designed lifetime and          end of 6.1.2: “The use of TKIP
number of critical deficiencies    is deprecated. The TKIP
in its security has already been   algorithm is unsuitable for the
identified. Consequently, TKIP     purposes of this standard.”
cannot be considered secure        Replace “TKIP and CCMP”
and its use not should be          with “CCMP” elsewhere in
promoted in any way.               6.1.2.

8.3.2.4 recommends an              Add following informative note Counter. TKIP will be       EDITOR
additional security feature of     into 8.3.2.4.1 item b) 2) “Note deprecated by TGmb.
rekeying PTK (and GTK in           – Authenticator should change
case of Authenticator) when        the PTK or GTK whenever a
Michael MIC failure is             Michael MIC failure is detected
detected. The way this is          or reported.”
written in 8.3.2.4 can be read
to include even the case of the
first Michael MIC failure (i.e.,
not TKIP countermeasures
that are started after two
failures within 60 seconds).
8.3.2.4.1 does not include
such recommendation and
may result in implementations
that do not rekey PTK/GTK in
case of active attacks against
TKIP (e.g., chopchop
decryption with 60 second wait
per octet to avoid hitting TKIP
countermeasures). It would be
better to recommend rekeying
of PTK/GTK in 8.3.2.4.1, too.
“The minimum length of the         Replace “The minimum length Reject. The information and      EDITOR
information element is 8           of the information element is 8 the statement are correct.
octets.” can be a bit confusing    octets.” with “The minimum
in the same paragraph that         length of the information
talks about IE fields, one of      element, including the Element
which is “Length”. The total       ID and Length fields, is 8
length (including Element ID       octets.”
and Length) has indeed
minimum length of 8 octets,
but the minimum Length field
value is 6.

11.2.1 describes power             Make sure that 11.2.1 (and in   Counter. See the resolution ot EDITOR
management buffering for           general, the whole standard)    comment 61
MSDUs, but not for MMPDUs.         describes PS buffering to
This could mean that only          include Action frames and
Data frames are buffered and       Deauthentication and
all Control and Management         Disassociation frames for
frames to a STA that is in PS      associated STAs.
mode are sent immediately
which would result in the
receiving STA not seeing
them. This would break
multiple current and future
functions in 802.11 (e.g.,
measurement requests in
802.11k and ping procedure in
802.11w). It looks like power
save buffering should also
apply to add at least some
Management frames (at least
Action frames and
Deauthentication/Disassociatio
n to associated STAs). Some
other areas of 802.11 seem to
describe PS buffering also for
MMPDUs (e.g., 7.1.3.1.7), but
the standard does not seem to
be very clear on which frame
types/subtypes are to be
buffered.


“all management traffic is         Add normative requirement for Counter. See submission in     EDITOR
returned with the same type        a receiver of a management      11-09/0051r1.
preamble as received” seems        frame to use the same type
to suggest that there would be     preamble that was received in
a “shall” requirement              the request into a suitable
somewhere in the standard for      clause or remove this
a receiver to use the same         comment from 18.2.2.2 if it is
type preamble for                  referring to a behavior that is
“management traffic”               not actually mandated
(whatever that is referring to).   anywhere in the standard.
However, I could not find such
requirement anywhere.
TGn comment: The                  TGn Resolution:EDITOR:          UNRESOLVABLE (EDITOR:       EDITOR
procedures for calculation of     2008-08-11 05:42:22Z Reject - 2010-05-20 09:24:52Z) - See
the Duration/ID field do not      There is no rule in the style   comment 16.
belong in clause 7. The           guide that requires Clause 7
reasoning behind the rejection    not to have normative text.
of CID 7118, that the base        While a separation of structure
standard is wrong and TGn         versus behavior is beneficial,
should do nothing to fix it, is   the TGn draft is an
not an adequate technical         amendment to an existing
resolution to the technical       baseline. The description of
comment.. Proposed                how to calculate the contents
Change: Adopt the changes         of this field is present in the
proposed in CID 7118              baseline in clause 7. The
                                  TGn amendment is merely
                                  reworking and extending
                                  existing clause 7 material to
                                  cover the mechanisms
                                  introduced by TGn.
                                  Attempted piecemeal
                                  reorganization of the baseline
                                  through its amendments is not
                                  beneficial.
                                  The correct place to change
                                  where this description should
                                  be put is in REVmb, where all
                                  such text relating to
                                  calculations can be addressed
                                  consistently.
                                  (The above is the same
                                  resolution as CID 7118, which
                                  is deemed to be an adequate
                                  response, notwithstanding the
Annex J needs to be cleaned       commenters additional
                                  Counter. See 11-09/0050r1.                                  EDITOR
up.
Operating temperature should       Remove all references to  AGREE IN PRINCIPLE (GEN: EDITOR
not be a part of this PHY/MAC                                2009-11-18
                                   operating temperature in the
standard. It belongs in a                                    21:47:06Z)Operating
                                   standard, deleting subclauses
product specification but not a                              temperatures should not be
                                   14.6.16, 15.4.6.10, 16.3.2.4,
PHY/MAC function standard.         17.3.8.8, 18.4.6.14, and  part of the normative clauses
This is a specification that is                              defining the PHYs. Delete
                                   applicable places in Annex A.
implementation specific and                                  cited subclauses.
should be left between the                                   Change 17.3.8.0a (General)
device manufacturer and                                      from:
implementors. This comment                                      "General specifications for
is also applicable to all places                             the BPSK OFDM, QPSK
in the standard that apply,                                  OFDM, 16-QAM OFDM, and
such as 15.4.6.10, 16.3.2.4,                                 64-QAM OFDM PMD
17.3.8.8, 18.4.6.14, and Annex                                  sublayers are provided in
A.                                                           17.3.8.1 (Outline description)
                                                             to 17.3.8.8 (Transmit and
                                                             receive operating
                                                                temperature range). These
                                                             specifications apply to both the
                                                             receive and transmit functions
                                                             and general
                                                                operation of the OFDM
                                                             PHY."
                                                             to
                                                                 "General specifications for
                                                             the BPSK OFDM, QPSK
                                                             OFDM, 16-QAM OFDM, and
                                                             64-QAM OFDM PMD
                                                                 sublayers are provided in
                                                             17.3.8.1 (Outline description)
                                                             to 17.3.8.7 (Transmit and
                                                             receive antenna port
Clause 9.3.2.2 (page 382)      Resolve this conflict. My     impedance ). These
                                                             DISAGREE (MAC: 2009-10-23 EDITOR
says "The PC shall transmit a suggestion is to change clause 15:47:14Z). In the overlapping
CF-End or CF-End+ACK           9.3.2.2 to check BSSID in CF- BSS case, it is necessary for
frame at the end of each CFP. End frames and leave 9.3.3.1 all STAs to update the NAV so
A STA that receives either of and 9.9.2.2a unchanged.        that the CFP is ended on the
these frames, from any BSS,                                  wireless medium. Change
shall reset its NAV".                                        cited sentence in 9.3.3.1 to a
Clause 9.3.3.1 says "All STAs                                NOTE-- and rewrite to read:
of the BSS receiving a CF-End                                "All STAs receiving a CF-End
or CF-End+ACK shall reset                                    or CF-End+ACK reset their
their NAVs so they may                                       NAVs according to the
attempt to transmit during the                               procedures described in
CP.".                                                        9.3.2.2 so they may attempt to
Clause 9.9.2.2a says "A non-                                 transmit during the CP." See
AP STA that receives a CF-                                   also CID 1665.
End frame containing the
BSSID of the BSS, in which
the non-AP STA is associated,
shall reset the NAV value to
0."
These seem to be in conflict
as to whether the BSSID
should be checked for CF-End
frames.
Remove this clause, as it is                                       AGREE IN PRINCIPLE (GEN: EDITOR
not used and is an                                                 2009-09-24 00:11:25Z) Agree
unnecessary burden on the                                          in Principle -- Mark the IR PHY
maintenance of the standard.                                       as obsolete and subject to
                                                                   removal in a future revision:
                                                                   instruct the editor to insert the
                                                                   following line at the beginning
                                                                   of clause 16:"This clause is
                                                                   obsolete and is subject to
                                                                   removal from a future
                                                                   revision."
"If the backoff procedure is      Change bullet list on lines 1 to AGREE IN PRINCIPLE                EDITOR
invoked for reason a) above, 11 to a alphabetically                (EDITOR: 2009-07-02
the value of CW[AC] shall be numbered list.                        15:43:28Z) - See resolution to
left unchanged. If the backoff                                     CID 1651, which addresses
procedure is invoked because                                       this issue.
of reason b) above, the value
of CW[AC] shall be reset to
CWmin[AC]." But the above
list is a "-" bullet list, when I
think it should be a numbered
list ("a .. d").
Sub-clause title is "General(" Change to "General"                 AGREE (EDITOR: 2009-07-03 EDITOR
                                                                   13:13:18Z)

There are multiple issues with     Review the MB draft wrt to the   AGREE (GEN: 2009-09-22          EDITOR
the usage of MIB variables         11-09-533 and revise as          22:00:17Z) Editor is instructed
within the standard. Significant   necessary to bring the           to make the changes as
discussion of these topics has     document into accord with the    recorded in 11-09/910r6 and
occurred in the ARC SC and         recommendations.                 11-09/1196r0.
elsewhere. This has resulted
in a recommendation for MOB
variable usage (ref doc 11-09-
533 R1). The MB draft should
be reviewed wrt to this
recommendation and brought
into compliance. While this will
not resolve all mib variable
usage issues, it will
significantly improve the
quality of the document. While
the reviewer acknowledges
that the referenced
recommendation has not been
formally adopted by the WG,
there has been near universal
consensus that this would
improve a significant issue
within the document and the
WG Chair has encouraged
members to support the
recommendation.
Over the years a concept has       Review the MB draft and          AGREE (EDITOR: 2009-12-01 EDITOR
somehow crept into the .11         rework all places where the      02:52:37Z) - Changes given in
standard which I believe to be     concept of "non-AP STA" is       11-09/1068r0
significantly incorrect. Within    used in the language and
the .11 document all ends of a     remove the meaningless
.11 link are stations (Noted as    phrase. Determine if the
STA in the document). In the       content of the afflicted section
case of an infrastructure ESS,     is correct and rewrite as
some stations also provide         necessary. I suggest that
DSS; these STAs are                searching for "non-AP" may be
commonly known as Access           the best starting point as the
Points ("APs"). All APs are        language used often is
also Stations - by definition      structured as <phrase about
APs are functionally a             stations><"non-AP"><rest of
superset of the STA                phrase>.
functionality. Yet the phrase
"non-AP STA" has been
introduced and appears in
multiple places in the
document. I suspect that most
(if not all) places where this
phrasing is used indicate a
place where the original
author)s) of the text have
included a misunderstanding
of the 802.11 architecture. The
phrase is semantically
meaningless as a "non-AP
STA" is a "STA".
This phy (FH) is no longer         Deprecate the section and      AGREE IN PRINCIPLE (GEN: EDITOR
commercially viable and the        adjust any other sections of   2009-09-22 07:30:18Z) Agree
contents of this section are not   the document that are          in Principle -- Mark the FH
worth maintaining going            impacted by this action.       PHY as deprecated and
forward.                                                          subject to removal in a future
                                                                  revision Editor to add
                                                                  immediately following the
                                                                  clause heading the following
                                                                  new paragraph: This clause is
                                                                  obsolete and is subject to
                                                                  removal in a future revision.
This phy (DSSS) is no longer       Deprecate the section and       DISAGREE (GEN: 2009-09- EDITOR
commercially viable and the        adjust any other sections of   22 07:35:54Z) Products are
contents of this section are not   the document that are          still being produced and
worth maintaining going            impacted by this action.       developed using this PHY.
forward.
LCI field in 802.11-2007 is      as suggested.   DISAGREE                       EDITOR
based on IETF RFC3825. The                       (ARCHITECTURE: 2009-07-
representation and encoding                      15 03:44:11Z) No explanation
of fields in the RFC was                         of why the current RFC3825
subject to long debate in IETF,                  method is broken was
with the outcome that the RFC                    provided. Any consideration of
is broken, the representation                    an updated RFC from IETF
and encoding of location                         would have to be considered
information is wrong.                            after it is done.
Specifically, the Longitude,
Latitude and Altitude
Resolution field definitions are
ambigous. Therefore, the LCI
definition has to be revised.
There is a new proposal in
IETF which is backward
compatible with the length of
the fields but changes their
meaning. What are currently
known as Resolution fields for
the coordinates will be
replaced by uncertainty and
the meaning adjusted
correspondingly. As a
consequence, the Latitude
Requested Resolution,
Longitude Requested
Resolution and Altitude
Requested Resolution field will
need to be removed from
figure 7-62i. Fixing LCI
requires changes the spec in
many places, btw. to be
The LCI format has               As suggested.   DISAGREE                       EDITOR
changed. See my previous                         (ARCHITECTURE: 2009-07-
comment on 7.3.2.21.9. It is                     15 03:49:59Z) No explanation
not clear which TG is in charge                  of why the current RFC3825
to fix LCI in the 802.11 spec,                   method is broken was
but someone has to fix it. A                     provided. Any consideration of
new version of 802.11 should                     an updated RFC from IETF
not be published with this                       would have to be considered
broken LCI format. Fixing it in                  after it is done.
TGv would be another option,
but their PAR does not include
anything on that. If TGmb does
not want to fix the LCI, then
clear guidance should be
requested from the plenary on
which TG is in charge of doing
it. And the new version of the
spec should not be published
until that TG fixes the LCI
format and all other issues
which come along with it.
same as comment for            as suggested.      DISAGREE                       EDITOR
7.3.2.22.9                                        (ARCHITECTURE: 2009-07-
                                                  15 03:52:30Z) No explanation
                                                  of why the current RFC3825
                                                  method is broken was
                                                  provided. Any consideration of
                                                  an updated RFC from IETF
                                                  would have to be considered
                                                  after it is done.

                                                  Note: commenter is referring
                                                  to CID 1010.

The NOTE has text copied       delete the NOTE.   DISAGREE (SECURITY: 2009- EDITOR
from RFC3825, an                                  07-15 04:19:22Z)
interpretation of the fields                      The comment does not
which causes the problem.                         indicate a problem that needs
                                                  to be fixed as far as this group
                                                  is concerned. The text doesn't
                                                  seem to be copied from RFC
                                                  3825.
 If LCI format is changed, its   as suggested.    DISAGREE                          EDITOR
name has to be changed as                         (ARCHITECTURE: 2009-07-
well. Currently LCI stands for                    15 04:01:42Z) There seem to
Location Configuration                            be two interpretations of the
Information, but only includes                    comment: 1) The LCI element
binary encoding of                                in 802.11 does not match
geolocation. TGv defined a                        exactly the RFC's LCI, so
'Civic Location Report', for                      rename it. Disagree as this is
Civic Location. Therefore there                   a lot of work (there are a lot of
are currently in 802.11 (and all                  MIB attributes with this name
across the industry) two                          in them) and of marginal value;
location formats available: geo                   2) The LCI element may be
and civic. The new name of                        changed if/when the IETF
LCI should reflect its                            makes a new RFC (per CID
geolocation nature, eg GLI                        1009), and the LCI name
(GeoLocation Information).                        should change. Disagree as
                                                  we are not making any
                                                  changes to the LCI until/if the
                                                  IETF is done with their update.
The Frame Classifier Type 1      Change "TCP/UDP IP            AGREE IN PRINCIPLE             EDITOR
lists "TCP/UDP IP". there are    parameters" to "transport     (ARCHITECTURE: 2009-07-
transport protocols other than   protocol parameters" or       19 02:28:38Z) A change
TCP and UDP, eg SCTP and         "TCP/UDP/SCTP/DCCP            supporting classifiers for non
DCCP. Those should be            parameters"                   TCP and non UDP protocols is
supported as well. The                                         present in P802.11v-D6.0.
abbreviation "IP" doesn't have                                 Accept in principle, but make
to be there.                                                   no text change because the
                                                               change will be made when
                                                               802.11v is incorporated.




The text says: "In a TCP or      Change "In a TCP or UDP     AGREE IN PRINCIPLE              EDITOR
UDP header: Source Address,      header: Source Address,     (ARCHITECTURE: 2009-07-
Destination Address, Source      Destination Address, Source 19 02:30:11Z) A change
Port, Destination Port, and      Port, Destination Port, and adding classifier type 4 for
Version"                         Version"                    other protocols is present in
                                                             P802.11v-D6.0. Accept in
There are other transport     to "In a TCP, UDP, SCTP or     principle, but make no text
protocols, like SCTP or DCCP, DCCP header: Source            change because the change
which should be listed also.  Address, Destination Address, will be made when 802.11v is
                              Source Port, Destination Port, incorporated.
                              and
                              Version"

                                 or "In a transport protocol
                                 header: Source Address,
                                 Destination Address, Source
                                 Port, Destination Port, and
                                 Version"
[B15] IEEE Std 802.10 is not     Remove this reference.        AGREE (EDITOR: 2009-08-07 EDITOR
referred to anywhere in D_1.0.                                 09:00:27Z)
It is a _withdrawn_ standard.

[B4] is not referred to         Remove this reference.         DISAGREE (EDITOR: 2009- EDITOR
anywhere in D_1.0. Also not                                    08-07 10:24:22Z) -
referred to anywhere in 802.11-                                Please see CID 1049 for a
2007.                                                          change that cites this
                                                               reference.
[B7] is not referred to         Remove this reference.         AGREE (EDITOR: 2009-08-07 EDITOR
anywhere in D_1.0. Also not                                    08:55:39Z)
referred to anywhere in 802.11-
2007.
[B9] is not referred to         Remove this reference.         AGREE (EDITOR: 2009-08-07 EDITOR
anywhere in D_1.0. Also not                                    08:54:48Z)
referred to anywhere in 802.11-
2007.
[B12] is not referred to        Remove this reference.         AGREE (EDITOR: 2009-08-07 EDITOR
anywhere in D_1.0                                              08:59:31Z)
[B18] is not referred to        Remove this reference.          AGREE (EDITOR: 2009-08-07         EDITOR
anywhere in D_1.0                                               09:00:51Z)
[B27] is not referred to        Remove this reference.          AGREE (EDITOR: 2009-08-07         EDITOR
anywhere in D_1.0                                               08:57:27Z)
[B28] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:08:27Z)
                                                                Insert "(following the model
                                                                described in ITU-T
                                                                Recommendation X.210
                                                                [B28])" in 10.3.0a after "in an
                                                                abstract way".
[B29] is not referred to        Remove this reference.          AGREE (EDITOR: 2009-08-07         EDITOR
anywhere in D_1.0                                               09:13:20Z)
[B31] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:05:38Z)
                                                                Replace the reference in N.2
                                                                to "Schneier [B32]" with
                                                                "Rumbaugh [B31]".
                                                                Remove Bib entry B32.
[B33] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:15:14Z) - Remove Heading
                                                                0A.2 and its 3 entries.

[B34] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:17:19Z) - Please see
                                                                resolution of CID 1026
[B35] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:18:17Z) - Please see
                                                                resolution of CID 1026
[B36] is not referred to        Remove this reference.          AGREE IN PRINCIPLE                EDITOR
anywhere in D_1.0                                               (EDITOR: 2009-08-07
                                                                09:17:57Z) - Please see
                                                                resolution of CID 1026
footnote 39 (ANSI               add: ANSI and other standards AGREE IN PRINCIPLE                  EDITOR
Publications) mentions their    publications are also available (EDITOR: 2009-07-23
web site, http://www.ansi.org/. from the ANSI eStandards        12:10:58Z) -
Suggest that the ANSI           Store                           Add " and
eStandards Store also be        (http://webstore.ansi.org/)     http://webstore.ansi.org/"
included in the footnote.                                       before the closing
                                                                parenthesis.

                                                                To the commenter, whether
                                                                other standards are available
                                                                or not is not relevant in this
                                                                footnote. The proposed
                                                                wording could be read as a n
                                                                advertisement, so the minimal
                                                                addition described above is to
                                                                be preferred.
add footnote applicable to the    Add new footnote to the         DISAGREE (GEN: 2009-09-22 EDITOR
Bibliography annex in general,    Bibliography Annex: Standards   07:45:12Z) Proposed
that the ANSI eStandards          from more than 100 standards    Resolution: Decline. There
Store has other standards         publishers are available from   are numerous secondary
from more than 100 standards      the ANSI (American National     sources for obtaining copies of
publishers available for          Standards Institute)            approved standards, and there
purchase. The site enables        eStandards Store. Single        is no obligation to list all of
purchase in US dollars of non-    copies and site licenses are    those places. The primary
US standards. This may be a       available.                      sources are listed in the
convenient way for many           (http://webstore.ansi.org/)     appropriate footnotes.
purchasers to obtain
standards of other publishers.
There probably are other
standards publishers in other
countries that have similar e-
stores and provide a similar
convenience with regard to
purchase in the local currency.
If any are known, they could
be added as well.

Reference should be cited at      In the comment                  AGREE (EDITOR: 2009-07-02 EDITOR
the end of the sentence to                                        11:05:41Z)
read "…RSN information
element described in 7.3.2.25
(RSN information element)."

As there are now more than      In the comment                    AGREE (SECURITY: 2009-08- EDITOR
one key management protcol,                                       21 15:55:06Z)
this line number should be                                        Change
more explicit to this and                                         "using the protocol defined by
perhaps define which ones are                                     8.5 (Keys and key
used based on the selected                                        distribution)"
AKM. One possible fix ione of                                     to
the protocols as defined by 8.5                                   "using the protocol defined by
(Keys and key distribution) or                                    8.5 (Keys and key distribution)
11A (Fast BSS Transition).".                                      or 11A (Fast BSS Transition)."


"shared authentication" should In the comment                     AGREE (SECURITY: 2009-07- EDITOR
be "Shared Key authentiation"                                     14 21:40:10Z)
as defined by 8.2.2.3.

A PTKSA should have the           In the comment                  DISAGREE (SECURITY: 2009- EDITOR
identities of its full lineage,                                   09-22 00:22:32Z)
including the PMKR0Name.                                          The PMKR0Name is already
Inlcude as a subitem                                              bound into the list as it is used
"PMKR0Name" in the FT key                                         to derive the PTKName.
hierarchy list.
The GTK is also distributed   In the comment      AGREE (SECURITY: 2009-07- EDITOR
during the FT protocol. The                       14 21:46:11Z)
sentence should be updated to
read "….4-Way Handshake,
FT 4-Way Handshake, FT
Protocol, FT Resource
Request Protocol or the Group
Key Handshake…."

A PTKSA should also be        In the comment      DISAGREE (SECURITY: 2009- EDITOR
bound to the associated                           07-14 21:46:22Z)
pairwise cipher suite. A new                      The text is already included.
item under the PTKSA should
be added to include "Pairwise
cipher suite selector"

As TGmb is merging 802.11r In the comment         AGREE (SECURITY: 2009-07- EDITOR
into the base, this section                       14 21:46:50Z)
seems to either focus on non-
FT enabled STAs or this
section must be updated to
state that the key management
invoked will depend on
whether it is a "simple" RSN or
an FT. One possible update to
remedy this is to change this
sentence to read "STA uses
one of the key confirmation
handshakes, e.g. the 4-Way
Handshake or FT 4-Way
Handshake, to complete...."

This first sentence is true only In the comment   AGREE IN PRINCIPLE           EDITOR
for the non-FT case. Perhaps                      (SECURITY: 2009-07-14
the simplest update is to state                   21:46:57Z)
"When FT is not enabled, the                      Adopt the second change in
case of (re)association                           the comment:
followed…." or in line 56,                        Change the sentence to
(since the rest of the items                      "When FT is not enabled, a
seems to also suggest non-                        STA roaming within an ESS
FT) change the sentence to                        establishes a new PMKSA by
"When FT is not enabled, a                        one of the three schemes:"
STA roaming within an ESS
establishes a new PMKSA by
one of the three schemes:". A
last alternative is to rename all
of clause 8.4.1.2.1 to be non-
FT Security association in an
ESS.
This section while parts can    In the comment    AGREE IN PRINCIPLE              EDITOR
apply to an FT enabled link, is                   (SECURITY: 2009-07-14
more relevant for when the link                   21:48:43Z)
is not FT enabled. Suggest                        Change:"When establishing
this be renamed to "non-FT                        an RSNA,"
enabled RSNA authentication                       to
in an ESS", otherwise, we'll                      "When establishing an RSNA
have to sprinkle clarifications                   in a non-FT environment or
throughout this clause and sub-                   during an FT initial mobility
clauses for when FT kicks in.                     domain association,"
For instance, line 38 "Open
System Authentication" is only
usedwhen either the 4-Way
Handshake or FT 4-Way
Handshake are used and not
during the FT Protocol or FT
Resource Request PRotocol.


As this is part of 8.4.6, my     In the comment   AGREE IN PRINCIPLE            EDITOR
previous comment is                               (SECURITY: 2009-07-14
highlighted by the relevance of                   21:49:33Z)
this clause mainly applying to                    Change: "A STA" to "In a non-
the non-FT case. Suggest this                     FT environment, A STA".
be renamed if the whole of
8.4.6 is not…to ensure that
this section only applies to
AKMs 1 and 2.
Again, this section only applies In the comment   SECURITY: 2009-08-14          EDITOR
to the non-FT (e.g. AKMs 1                        15:27:28Z - AGREE IN
and 2 only) and should be                         PRINCIPLE
state as such. Or the clause                      Change "The AS transfers…"
could be adapted to referent                      to "In an non-FT environment,
11A for the FT case as well.                      the AS transfers…" in the
                                                  second sentence of the first
                                                  paragraph.
It is also possible to also                       DISAGREE (SECURITY: 2009- EDITOR
invoke the FT Protocol.                           08-14 15:30:50Z)
                                                  FT does not apply to an IBSS.
In looking at the flow of the   In the comment   DISAGREE (SECURITY: 2009- EDITOR
document, it appears that we                     09-22 05:47:36Z)
sometimes refer to the very                      The FT 4-way handshake is
first FT association as either                   defined in 11A.4.2 on page
the FT 4-Way handshake or                        670, line 27, and it makes a
initial mobility domain                          reference to clause 8.5.3.
association. There is no
formal description of the
former that the latter is in
11A.4 which actually fully
desribes the full association
procedures. One possible way
to make this consistant is to
allow 11A.4 to remain and to
relabel 8.5.3 as "4-Way
Handshake and FT 4-Way
Handshake". Also with this
update an update to the
General section should
highlight that the message
flows are indeed the same,
with the only distinction being
the selection of AKM values 3
or 4 for the FT 4-Way
Handshake.
Given that state machine        In the comment   DISAGREE (SECURITY: 2009- EDITOR
descriptions are already                         08-14 15:32:54Z)
provided both in visual and                      The pseudo-code is the most
long prose formats, there                        formal description we have of
seems to be little value gained                  the logic.
by providing this pseudo-code                    Provided it is up to date with
other than adding bloat to the                   the description, there is value
document and another tedious                     in having it present.
section that may not be                          Non-native speakers find it
consistant with the state                        much easier to understand
machine. Please consider                         pseudo-code
removing this whole clause.                      and diagrams than 50-word
                                                 paragraphs full of conditional
                                                 phrases and subordinate
                                                 phrases
                                                 and member-invented jargon
                                                 and conventions.
During the development of the       Consider providing a list of   DISAGREE (GEN: 2009-09-22 EDITOR
802.11 standard and its             essential submissions on the   22:17:25Z)Disagree : Nice
amendments, there have been         results, rationales and        idea, but impractical. All the
numerous technical results          background of the current      submissions and Minutes that
submitted by participants to        802.11 protocols, perhaps to   are used for creating the draft
illustrate and to support the       be added in the appendix.      are available -- "see
protocol that is finally in the                                    mentor.ieee.org/802.11/docum
current text. For example,                                         ents" Also the Task group is
there must have been                                               not making any statements of
numerous simulation results                                        Essentiality of any of the IP.
on the PHY and MAC                                                 Also the submissions are not
performance. But these                                             the final version of what is in
submissions are never (if not                                      the standard, so the historical
rarely) mentioned in the final                                     view is left as an exercise for
specification. Granted,                                            the student.
participants originally involved
with them have knowledge of
the protocols' origins, but in
general, readers are not aware
of their reasons and sources,
especially new implementers.
They will have to rely on an
exhaustive and tedious search
on our document database or
anedoctal references if they
wish to learn of the rationale of
our the 802.11 protocols, say if
they wish to provide further
research on them. Thus, I
propose it may be beneficial to
future generation of
implementers and researchers
if our spec can provide a list of
These footnotes should be on        Pls fix, if deemed to be an    DISAGREE (EDITOR: 2009- EDITOR
the previous page. The same         error.                         07-03 10:32:46Z)
for footnote 34 in the following                                   The footnotes are positioned
page.                                                              automatically, and the REVmb
                                                                   editor has no control of the
                                                                   positioning. In this case,
                                                                   however, the positioning is
                                                                   correct.

                                                                   The commenter will note that if
                                                                   the footnote 32 was to be
                                                                   moved backwards, there
                                                                   would no longer be room on
                                                                   this page for the reference to
                                                                   it. So then we would have the
                                                                   footnote on the page
                                                                   preceding the reference. This
                                                                   is even less logical.
Third sentence "mechanisms" per comment                            AGREE (EDITOR: 2009-07-02 EDITOR
should be "mechanism"                                              15:08:35Z)

"please see the references."        per comment                    AGREE IN PRINCIPLE          EDITOR
should read "please see the                                        (EDITOR: 2009-08-06
references in [B4]."                                               13:33:16Z) -
                                                                   Replace cited text with:
                                                                   "please see the reference
                                                                   [B4]".
The equations and references per comment                              AGREE IN PRINCIPLE           EDITOR
should be renumbered to 9-2,                                          (EDITOR: 2009-07-02
9-3 and 9-4.                                                          15:32:07Z)
                                                                      Add contiguous (9-<number>)
                                                                      labels to all equations in
                                                                      Clause 9, add references so
                                                                      that each is referenced, and
                                                                      reword where statements as
                                                                      necessary in 9.8.2a.

The HCC and EHCC                  Remove Reference [B4] and           AGREE IN PRINCIPLE (GEN: EDITOR
frequency hop method              all mention of HCC and EHCC,        2009-11-18 02:16:54Z) Insert
specified here and 7.3.2.10 is    including 7.3.2.10 , 9.6a, 9.8.2,   at cited locations: "The use of
obsolete, and is not in current   and Annex A.4.10 MD7                mechanisms described in this
products that claim 802.11                                            subclause is obsolete, and
conformance. I do not know of                                         this subclause may be
any products introduced since                                         removed in a later revision of
2004 that claim to use HCC or                                         the standard."
EHCC.
The High Rate Channel Agility     Remove all mention of               AGREE IN PRINCIPLE (GEN: EDITOR
option specified here is          Channel Agility, including the      2009-11-18 02:09:27Z) - Mark
obsolete, and is not in current   CA bit in 7.3.1.4, in clause 18,    Annex F as obsolete and
products that claim 802.11        the PICs and remove Annex F         subject to removal in a future
conformance. I do not know of     (which has no redeeming             revision.
any products introduced since     value).
2004 that claim to support the
Channel Agility option of the
High Rate PHY.

The PBCC option specified         Remove all mention of PBCC,         AGREE IN PRINCIPLE (GEN: EDITOR
here is obsolete, and is not in   including the PBCC bit in           2009-11-18 02:07:02Z) Insert
current products that claim       7.3.1.4, in clauses 9.6, 9.6a,      in 7.3.1.4 (P107.12), 18
802.11 conformance. I do not      18, 19, the PICs and remove         (P885.34), Annex A (P998.35
know of any products              Annex F (which has no               PC17 under "Protocol
introduced since 2004 that        redeeming value).                   Capability"):
claim to support the PBCC                                             "The use of the PBCC option
option of the High Rate PHY,                                          is obsolete, and this option
nor the ERP PHY.                                                      may be removed in a later
                                                                      revision of the standard."
The frequency plan specified      Deprecate this table and add        AGREE IN PRINCIPLE (GEN: EDITOR
here is obsolete, and is not      Regulatory Classes for China        2009-11-16 13:01:46Z) -
used in current products that     in Annexes I and J. Add a           Accept in Principle based on
claim 802.11 conformance.         requirement to support J.1          discussion and editorial
Amendment 1, 11k, added 2.4       class 12, J.2 class 4, J.3          instructions in 09/1111r2:
GHz band Regulatory Classes       classes 30 and 31, and the          1054, 1055, 1059, 1205 and
for US, ETSI and Japan. This      China 2.4 GHz class.                1216 see
clause should be like                                                 (https://mentor.ieee.org/802.11
17.3.8.3.3, "The set of valid                                         /dcn/09/11-09-1111-02-000m-
operating channel numbers by                                          lb149-proposed-regulatory-
regulatory domain is defined in                                       comment-resolutions.doc)
Annex J."
The frequency plan specified      Deprecate this table and add    AGREE IN PRINCIPLE (GEN: EDITOR
here is obsolete, and is not      Regulatory Classes for China    2009-11-16 12:48:56Z) -
used in current products that     in Annexes I and J. Add a       Accept in Principle based on
claim 802.11 conformance.         requirement to support J.1      discussion and editorial
Amendment 1, 11k, added 2.4       class 12, J.2 class 4, J.3      instructions in 09/1111r2
GHz band Regulatory Classes       classes 30 and 31, and the      (https://mentor.ieee.org/802.11
for US, ETSI and Japan. This      China 2.4 GHz class.            /dcn/09/11-09-1111-02-000m-
clause should be like                                             lb149-proposed-regulatory-
17.3.8.3.3, "The set of valid                                     comment-resolutions.doc)
operating channel numbers by
regulatory domain is defined in
Annex J."

The PICS is for comparison       Remove the PICS proforma or      DISAGREE (GEN: 2009-09-24 EDITOR
shopping, and does not belong make it informative.                00:40:53Z) Disagree: As part
in the standard. There are no                                     of the 802.11 Revision PAR
PICS in 802.16 or 802.15.4                                        request and approval, a PICS
standards. 802.11T                                                proforma was specifically
Recommended Practice for                                          requested and required by the
testing procedures was                                            802 EC. The TG also debated
terminated for lack of interest,                                  the comment and the
and Annex A should share the                                      consensus was that the PICs
same fate. If the PICS annex is                                   provides value and belongs in
not removed, make it                                              the standard.
informative with the statement
"This clause is no longer
maintained and may not be
compatible with or describe all
features of this standard."




Annex D SMT Attributes states Remove SMT Attributes that          DISAGREE                        EDITOR
"The SMT object class          are not referred to in normative   (ARCHITECTURE: 2009-11-
provides the necessary         text.                              18 20:33:37Z) DISAGREE The
support at the station to                                         commentor is encouraged to
manage the processes in the                                       provide more details of any
station such that the station                                     proposed improvement, but
may work cooperatively as a                                       without the details of what is
part of an IEEE 802.11                                            proposed, the group cannot
network." This is not a true                                      evaluate the technical merit at
statement, and I know of no                                       this time.
products introduced since
2004 that claim the SMT object
class provides the necessary
support ... . The time to
remove SMT Attributes is now,
as all SNMP scripts will have
to change with this
maintenance of the standard.
The ieee802dot11 MODULE           per comment                        AGREE IN PRINCIPLE             EDITOR
needs to be updated to be                                            (ARCHITECTURE: 2009-07-
correct at the time of REVmb                                         31 15:39:21Z) - See resolution
publication - correct the                                            CID #1586 for one example of
information herein. It is time to                                    the updates being done.
maintain all of Annex D.                                             Annex D is being updated as
                                                                     part of the Revision process.

Country string third character    Change the description of the      AGREE IN PRINCIPLE (GEN: EDITOR
values "space", "I", and "O" do   third character to allow only      2009-11-16 12:27:29Z) -
not allow the possbility of       "space" for a country or "X" for   Accept in Principle based on
complying with some               a non-country.                     discussion and editorial
environments of the country                                          instructions in 09/1111r2:
but not all. The distinction is                                      1054, 1055, 1059, 1205 and
obsolete, and I know of no                                           1216
products introduced since
2004 that use "I" or "O" or
correctly use "space".




Annex D contains many object per comment                             DISAGREE                          EDITOR
definitions whose STATUS is                                          (ARCHITECTURE: 2009-07-
deprecated. Remove those                                             16 06:01:00Z) - We generally
objects. It is false to think that                                   keep, but deprecate, facilities
legacy managers of 802.11                                            that are not to be used
stations rely on receiving                                           anymore, for historical
"deprecated" as any SNMP                                             reasons.
scripts will be updated when
REVmb changes the
ieee802dot11 MODULE.
In dot11PHYType, the "OFDM per comment                        AGREE (ARCHITECTURE:              EDITOR
5GHz" should be changed to                                    2009-11-18 20:01:02Z)
"OFDM" as 11k and 11y
expanded the application of
OFDM outside 5 GHz.




The                              per comment                  AGREE IN PRINCIPLE                EDITOR
dot11RegDomainsSupported                                      (ARCHITECTURE: 2009-07-
Table is obsolete, and is not                                 16 06:01:50Z) We generally
necessary to manage the                                       keep, but deprecate, facilities
processes in the station or with                              that are not to be used
other stations. The Supported                                 anymore, for historical
Regulatory Classes construct                                  reasons. Set the status to
is more comprehensive, and                                    deprecated.
used from 11k onward.
Remove the
dot11RegDomainsSupported
table,
dot11CurrentRegDomain and
related fields in PHY objects.




The IR PHY is obsolete and     remove all mention of the IR   AGREE IN PRINCIPLE (GEN: EDITOR
should be removed as part of   PHY.                           2009-09-24 00:11:08Z) -Agree
this maintenance.                                             in Principle -- Mark the IR PHY
                                                              as obsolete and subject to
                                                              removal in a future revision:
                                                              instruct the editor to insert the
                                                              following line at the beginning
                                                              of clause 16:"This clause is
                                                              obsolete and is subject to
                                                              removal from a future
                                                              revision."
The FH PHY clause and             remove all mention of the FH      AGREE IN PRINCIPLE (GEN: EDITOR
operation is not considered in    PHY or make clause 11.1.5,        2009-09-22 07:33:58Z) Agree
11k or any newer                  14, Annex B and Annex F           in Principle -- Mark the FH
amendments. It either should      informative. If this comment is   PHY as deprecated and
be removed as part of this        not rejected, Annex A and D       subject to removal in a future
maintenance or be made            will need to also be              revision Editor to add
informative with the statement    maintained.                       immediately following the
"This clause is no longer                                           clause heading the following
maintained and may not be                                           new paragraph: This clause is
compatible with all features of                                     obsolete and is subject to
this standard." This comment                                        removal in a future revision.
also applies to Annex B and
the FH PHY in Annex F.

dot11FrequencyBandsSupport per comment                              AGREE IN PRINCIPLE                EDITOR
ed is obsolete, and is not                                          (ARCHITECTURE: 2009-07-
necessary to manage the                                             16 06:03:13Z) We generally
processes in the station or with                                    keep, but deprecate, facilities
other stations. It was not                                          that are not to be used
updated by 11y, nor is it being                                     anymore, for historical
changed in 11p. The                                                 reasons. Set the status to
Supported Regulatory Classes                                        deprecated.
construct is more
comprehensive and used from
11k forward. Remove
dot11FrequencyBandsSupport
ed.
dot11TIThreshold is              per comment                        UNRESOLVABLE (EDITOR:             EDITOR
deprecated and not used in                                          2009-11-19 22:03:57Z) -
dot11PhyOFDMComplianceGr                                            Withdrawn by commenter
oup3. Remove
dot11TIThreshold from
dot11PhyOFDMEntry, and its
object definition.
Are we reserving Annex E for remove Annex E                         AGREE IN PRINCIPLE              EDITOR
the junior prom?                                                    (EDITOR: 2009-07-24
                                                                    08:42:03Z)
                                                                    Please see resolution of CID
                                                                    1242, which adds an editorial
                                                                    note.
"High Rate PHY/FH               remove Annex F or add               AGREE IN PRINCIPLE (GEN: EDITOR
interoperability" is an         disclaimer.                         2009-09-24 01:09:09Z) Agree
oxymoron. The clause                                                in Principle -- Mark Annex F as
provides no value to the users                                      deprecated and subject to
of the standard, and should be                                      removal in a future
removed, or begin with the                                          revision.The editor will put in
statement "This clause is no                                        the first part of the ….
longer maintained and may not
be compatible with all features
of this standard." ;-)
Figure I.1 has the Mask labels Change the Mask labels to          AGREE IN PRINCIPLE            EDITOR
in color, not black            black.                             (EDITOR: 2009-07-24
                                                                  08:47:43Z)
                                                                  Change Mask labels, "xBW",
                                                                  and the axis arrows to black.
                                                                  Move the mask labels clear of
                                                                  the grid and remove the grey
                                                                  blobs behind them. Reposition
                                                                  the callout arrows
                                                                  appropriately.
"wherein further transmission per comment                         AGREE (EDITOR: 2009-07-24 EDITOR
requirements may be found" is                                     08:50:50Z)
inaccurate, ignoring
operational requirements.
Change to "where further
operational requirements may
be found."
Missing "Reserved" in           per comment                       AGREE (EDITOR: 2009-07-24 EDITOR
Transmit power limit (EIRP)                                       08:51:38Z)
column.
Given the Public Action         Add references to submissions     DISAGREE (MAC: 2009-09-30 EDITOR
Frames that operate outside     that illustrate the problems of   14:20:15Z) - As per the
the context of the BSS, if we   inserting an 802.11 bridged       comment, Annex M should be
agree the concept of " the DS" link into an 802.1 architecture.   removed only if the DS is
is not relevant, and remove the                                   removed; the resolution to CID
DS concept from clause 5,                                         1412 retains the concept of the
then this apology (Annex M)                                       DS.
for breaking 802.1 bridging
should be removed. If this
annex remains, both Annex M
and O should have pointers to
802.1 presentations that
describe how 802.1 bridging is
broken by 802.11, and
propose resolutions
http://www.ieee802.org/1/files/
public/docs2008/avb-nfinn-802-
11-bridging-0108-v1.pdf and
subsequent prezos)
The Measurement Pilot option Remove the Measurement               DISAGREE (SECURITY: 2009- EDITOR
specified here is obsolete, and Pilot option from the standard.   07-14 21:36:43Z)
is not in current products that                                   Reject. This is a new feature
claim 802.11 conformance. I                                       that is less than a year old,
do not know of any products or                                    and should be given time to be
plans to implement                                                implemented before removal.
Measurement Pilots. The                                           The proposed change may
option would add lots of noise                                    make existing 802.11 devices
in whatever band it is used in                                    non-compliant with the
(Note 1 pg 655, Note 2 and                                        standard.
NOTE, pg 656). Commenter                                          The comment has not justified
will make a submission                                            the change. This comment
removing 7.3.2.42, 7.4.7.2,                                       was previously rejected as CID
11.10.12 and whatever other                                       158 in 11-07/2642r9.
text changes are needed to
remove the Measurement Pilot
Transmission option from the
standard.


remove these blank pages that per comment                         AGREE (EDITOR: 2009-07-02 EDITOR
come before Clause 8.                                             11:03:04Z)
This clause should be marked per comment                          DISAGREE                       EDITOR
informative. There is nothing                                     (ARCHITECTURE: 2009-07-
here that is externally visible or                                15 03:10:25Z) There are
other normative text outside                                      normative dependencies on
clause 10 that depends on the                                     this clause. These are the
presence of normative text in                                     bones of the architecture, and
clause 10 for specified                                           are needed to support the rest
operation. If there is, move                                      of the normative text. The
such normative text from                                          behavior defined based on
clause 10 to the correct place.                                   these interfaces is not
                                                                  intended to be implementation,
                                                                  but is meant to be the
                                                                  structure for describing
                                                                  important behavior, and helps
                                                                  focus on one part of the whole
                                                                  of an 802.11 STA. The
                                                                  Standard needs to define end-
                                                                  point behavior, too, not just
                                                                  over-the-air protocol.
There is nothing here that is   per comment                       DISAGREE                       EDITOR
externally visible or other                                       (ARCHITECTURE: 2009-07-
normative text outside clause                                     15 03:14:35Z) There are
10 that depends on the                                            normative dependencies on
presence of normative text in                                     this clause. These are the
clause 10.3 for specified                                         bones of the architecture, and
operation. If there is, move                                      are needed to support the rest
such normative text from                                          of the normative text. The
clause 10.3 to the correct                                        behavior defined based on
place. After the last sentence                                    these interfaces is not
insert the statement "The                                         intended to be implementation,
remainder of this clause is no                                    but is meant to be the
longer maintained and may not                                     structure for describing
be compatible with all features                                   important behavior, and helps
of this standard." ;-)                                            focus on one part of the whole
                                                                  of an 802.11 STA. The
                                                                  Standard needs to define end-
                                                                  point behavior, too, not just
                                                                  over-the-air protocol.

This set of figures and text      Move 10.3.11 to within 11.9.6   DISAGREE                      EDITOR
belong outside clause 10,         Radio Measurement, and          (ARCHITECTURE: 2009-11-
which otherwise is a collection   update the references in the    18 20:03:50Z) The commentor
of elements and fields. There     start of the third paragraph.   is encouraged to provide more
are no references to 10.3.11.                                     details of any proposed
                                                                  improvement, but without the
                                                                  details of what is proposed,
                                                                  the group cannot evaluate the
                                                                  technical merit at this time.
The TPC and DFS                per comment     AGREE (GEN: 2009-09-22        EDITOR
mechanisms are required for                    22:23:25Z) However this
operation in the the 3.65 GHz                  change will cause a PAR
band, and IEEE 802.16h                         modification to possibly me
requires the quieting                          required. Note that the Scope
procedure to attempt                           and Purpose of the final
coexistence with 802.11 in any                 document and the PAR must
band. Change "regulatory                       match.
requirements for operation in
the 5 GHz band." to
"regulatory requirements for
operation in any band."

The OFDM phy is used in        per comment     AGREE (GEN: 2009-11-18      EDITOR
many bands, and the definition                 02:03:50Z)
of OFDM transmitter power
should be frequency band
agnostic. Change "operation of
a 5 GHz IEEE 802.11 " to
"operation of an IEEE 802.11".


This definition of transmitter   per comment   AGREE (EDITOR: 2009-07-01 EDITOR
power is 802.11 OFDM                           12:27:29Z)
specific, and should be moved
to clause 3A. Someone should
generalize this (look at other
802 wireless standards) if it is
to remain in the general
section.

This clause contains no        per comment     AGREE (EDITOR: 2009-07-23 EDITOR
normative text and should                      10:46:56Z)
become 12.4 at the end of
clause 12. The original 1997
standard's MAC and three
PHYs structure is not relevant
to the standard going forward.
The terms broadcast/multicast,   Change "broadcast and          AGREE IN PRINCIPLE (MAC: EDITOR
unicast/directed have been       multicast MSDUs, relative to   2009-09-23 03:58:46Z)
deprecated for use within IEEE   directed MSDUs" to "group      Review all uses of broadcast,
802. The appropriate terms       addressed MSDUs, relative to   multicast and unicast and
are "group addressed" and        individually addressed         replace as follows:
"individually addressed".        MSDUs"                         (1) "Unicast" changes to
                                                                "individual" or "individually
                                                                addressed" according to
                                                                context
                                                                (2) "multicast", "broadcast /
                                                                multicast" or "broadcast or
                                                                multicast" changes to "group"
                                                                or "group addressed"
                                                                according to context. This
                                                                specifically applies to MIB
                                                                variables of the form
                                                                {something}Multicast{somethin
                                                                gelse}, which change to
                                                                {something}Group{somethinge
                                                                lse}
                                                                (3) "broadcast" remains the
                                                                term to use when specifically
                                                                referring to the broadcast
                                                                address

                                                                See also CID 1086.

The terms broadcast/multicast,   Change "broadcast and          AGREE IN PRINCIPLE (MAC: EDITOR
unicast/directed have been       multicast MSDUs, relative to   2009-09-23 03:59:03Z) -
deprecated for use within IEEE   unicast MSDUs" to "group       Review all uses of broadcast,
802. The appropriate terms       addressed MSDUs, relative to   multicast and unicast and
are "group addressed" and        individually addressed         replace as follows:
"individually addressed".        MSDUs"                         (1) "Unicast" changes to
                                                                "individual" or "individually
                                                                addressed" according to
                                                                context
                                                                (2) "multicast", "broadcast /
                                                                multicast" or "broadcast or
                                                                multicast" changes to "group"
                                                                or "group addressed"
                                                                according to context. This
                                                                specifically applies to MIB
                                                                variables of the form
                                                                {something}Multicast{somethin
                                                                gelse}, which change to
                                                                {something}Group{somethinge
                                                                lse}
                                                                (3) "broadcast" remains the
                                                                term to use when specifically
                                                                referring to the broadcast
                                                                address

                                                                See also CID 1086.
The terms broadcast/multicast, Change "broadcast and        AGREE IN PRINCIPLE (MAC: EDITOR
unicast/directed have been     multicast MSDUs" to "group   2009-09-23 03:59:16Z) -
deprecated for use within IEEE addressed MSDUs"             Review all uses of broadcast,
802. The appropriate terms                                  multicast and unicast and
are "group addressed" and                                   replace as follows:
"individually addressed".                                   (1) "Unicast" changes to
                                                            "individual" or "individually
                                                            addressed" according to
                                                            context
                                                            (2) "multicast", "broadcast /
                                                            multicast" or "broadcast or
                                                            multicast" changes to "group"
                                                            or "group addressed"
                                                            according to context. This
                                                            specifically applies to MIB
                                                            variables of the form
                                                            {something}Multicast{somethin
                                                            gelse}, which change to
                                                            {something}Group{somethinge
                                                            lse}
                                                            (3) "broadcast" remains the
                                                            term to use when specifically
                                                            referring to the broadcast
                                                            address

                                                            See also CID 1086.

The terms broadcast/multicast, Change "unicast MSDUs" to    AGREE IN PRINCIPLE (MAC: EDITOR
unicast/directed have been     "individually addressed      2009-09-23 03:59:35Z) -
deprecated for use within IEEE MSDUs"                       Review all uses of broadcast,
802. The appropriate terms                                  multicast and unicast and
are "group addressed" and                                   replace as follows:
"individually addressed".                                   (1) "Unicast" changes to
                                                            "individual" or "individually
                                                            addressed" according to
                                                            context
                                                            (2) "multicast", "broadcast /
                                                            multicast" or "broadcast or
                                                            multicast" changes to "group"
                                                            or "group addressed"
                                                            according to context. This
                                                            specifically applies to MIB
                                                            variables of the form
                                                            {something}Multicast{somethin
                                                            gelse}, which change to
                                                            {something}Group{somethinge
                                                            lse}
                                                            (3) "broadcast" remains the
                                                            term to use when specifically
                                                            referring to the broadcast
                                                            address

                                                            See also CID 1086.
The terms broadcast/multicast,    Throughout the draft, change       AGREE (MAC: 2009-09-23        EDITOR
unicast/directed have been        "broadcast", "multicast",          03:50:06Z) - Review all uses
deprecated for use within IEEE    "broadcast or multicast",          of broadcast, multicast and
802. The appropriate terms        "broadcast and multicast" to       unicast and replace as
are "group addressed" and         "group addressed".                 follows:
"individually addressed".         Throughout the draft, change       (1) "Unicast" changes to
    There are (rare) cases        "unicast" to "individually         "individual" or "individually
where it is valid to use the      addressed".                        addressed" according to
terms multicast and broadcast.    The changes required for           context
Those cases are the instances     "directed" are more complex        (2) "multicast", "broadcast /
where reference is being          since this word is often used in   multicast" or "broadcast or
made to a non-IEEE protocol,      other contexts. When               multicast" changes to "group"
for example an IETF protocol,     "directed" in used in the          or "group addressed"
where the the protocol is         context of "directed frame",       according to context. This
defined in terms of a             "directed MPDU", or "directed      specifically applies to MIB
broadcast or multicast            MSDU" it should be changed         variables of the form
construct. For example, the       to "individually addressed         {something}Multicast{somethin
802.11u and 802.11v               {identifier}".                     gelse}, which change to
amendments are known to                                              {something}Group{somethinge
introduce a few such instances                                       lse}
into the 802.11 standard                                             (3) "broadcast" remains the
where a specific protocol is                                         term to use when specifically
referenced or where the                                              referring to the broadcast
handling of group addressed                                          address
MSDUs/frames is specified
differently for broadcasts than
it is for specific multicast
group(s).
   When reference is made to
IEEE 802 entities,
mechanisms, procedures and
constructs the terms "group
addressed"Editorial
"...BSS61" and "individually      As in comment                      AGREE IN PRINCIPLE               EDITOR
                                                                     (EDITOR: 2009-06-30
                                                                     12:33:56Z)
                                                                     Add a space to the template
                                                                     before the last tab.

                                                                     In response to the commenter,
                                                                     the TOC embeds lots of
                                                                     compromises. Ultimately it's a
                                                                     matter of style as interpreted
                                                                     by the IEEE publishing editor.
"…STA 62" Editorial             As in comment                     DISAGREE (EDITOR: 2009-          EDITOR
                                                                  06-30 12:35:56Z)

                                                                  See also comment CID 1087.
                                                                  For that comment I inserted
                                                                  some space. However, as I
                                                                  interpret this comment, the
                                                                  commenter wants the 62 right
                                                                  aligned. The REVmb editor
                                                                  does not know how to do this
                                                                  without manual editing of the
                                                                  TOC, which is not feasible.

                                                                  This is ultimately a matter of
                                                                  style, as interpreted by the
                                                                  IEEE-SA publication editor.

...ammendments" spelling        As in comment                     AGREE (EDITOR: 2009-07-01 EDITOR
                                                                  11:45:52Z)
"General(" Editorial            As in comment                     AGREE (EDITOR: 2009-06-30 EDITOR
                                                                  12:25:48Z)
Please make a space between As in comment                         AGREE (EDITOR: 2009-06-29 EDITOR
# and letter                                                      11:45:27Z)




Please make a space between As in comment                         AGREE (EDITOR: 2009-06-29 EDITOR
# and letter                                                      11:46:25Z)

TK is often used as an          Add "(TK)" to the title of this   AGREE IN PRINCIPLE               EDITOR
abbreviation for the temporal   definition.                       (EDITOR: 2009-08-03
key.                                                              14:06:19Z) - As specified, and
                                                                  add TK to acronyms.
AAD should be an 802.11-         Move AAD to clause 3A.           DISAGREE (EDITOR: 2009- EDITOR
specific definition, because as                                   08-06 11:15:30Z) -
used in this document it is tied                                  The rule we have used to
to the specification of CCMP.                                     move items to 3A is whether
                                                                  the definition is itself
                                                                  dependent on the 802.11
                                                                  standard in some way. This
                                                                  definition is not, and therefore
                                                                  should not be moved.

Text on these pages is hard to Use black letters instead of       AGREE IN PRINCIPLE             EDITOR
read.                          white letters.                     (EDITOR: 2009-06-29
                                                                  11:48:57Z)
                                                                  Remove surplus pages.
The FH PHY should be            Deprecate this clause.            AGREE IN PRINCIPLE (GEN: EDITOR
deprecated since it is no                                         2009-09-22 07:31:59Z) Agree
longer used and has speeds                                        in Principle -- Mark the FH
such that it is no longer                                         PHY as deprecated and
commercially viable.                                              subject to removal in a future
                                                                  revision Editor to add
                                                                  immediately following the
                                                                  clause heading the following
                                                                  new paragraph: This clause is
                                                                  obsolete and is subject to
                                                                  removal in a future revision.
"The current AP encapsulates       Two options: (1) change the        AGREE IN PRINCIPLE            EDITOR
the FT Action frame (Request       definition of "encapsulate" in     (SECURITY: 2009-11-06
or Confirm) inside a Remote        3.49 so that it does not require   16:04:25Z) -
Request frame and transmits it     cryptography, or (2) change        Accept option 2. Change the
to the target AP over the DS."     the usage of "encapsulate" in      sentence to
By definition, "encapsulate"       this clause to some other          "The current AP includes the
(3.49) refers only to encrypting   word.                              contents of the FT Action
frames, not the act of putting a                                      frame (Request or Confirm) in
higher layer frame inside a                                           a Remote Request frame"
lower layer type.


"7.1.3.1.1" is a vampirical        Write cross link on a wooden       AGREE IN PRINCIPLE                EDITOR
reference.                         stake, and drive it into the       (EDITOR: 2009-07-01
                                   reference to kill it.              14:38:53Z)
                                                                      Replace with live reference.
"7.3.2.30" is dead, Jim, it's      I'm a doctor, not a technical      AGREE IN PRINCIPLE                EDITOR
dead!                              editor. How would I know?          (EDITOR: 2009-07-01
                                                                      14:42:24Z)
                                                                      The technical editor, being
                                                                      also a doctor, is instructed to
                                                                      resurrect this reference.


Are "9.2.8" and "9.3.3" live       Take pulse and, if no              AGREE IN PRINCIPLE                EDITOR
references or dead                 response, begin CPR and call       (EDITOR: 2009-07-01
references?                        911 to summon emergency            14:46:34Z)
                                   link enlivening services.          Replace with live references.

7.1.3.4 is an ex-reference.     See if it can be returned to the AGREE IN PRINCIPLE             EDITOR
                                reference store, or if it's well (EDITOR: 2009-07-01
                                and truly passed on.             14:56:09Z) - Replace with live
                                                                 reference.
7.1.3.5 has gangrene.           Reattach it to a link to the     AGREE IN PRINCIPLE             EDITOR
                                section header and hope it       (EDITOR: 2009-07-01
                                grows back?                      14:56:38Z)
                                                                 Replace with live reference.
Table 7-8 mixes up all sorts of I believe the TG has decided AGREE IN PRINCIPLE                 EDITOR
MIB references. Sometimes       on "set to TRUE"?                (EDITOR: 2009-07-27
variables "are true,"                                            11:06:38Z)
sometimes they are "set to
TRUE". Use one consistent                                        Please see resolution of CID
method of reference.                                             1535.

Deprecate shared key               Change "Shared Key" to             DISAGREE                      EDITOR
"authentication" in the table,     "Shared Key (deprecated)"          (ARCHITECTURE: 2009-11-
since it doesn't supply actual                                        19 01:12:28Z) - Shared key
authentication.                                                       authentication is only used
                                                                      with WEP, and WEP has
                                                                      already been deprecated. No
                                                                      change is needed to deprecate
                                                                      shared key authentication.
Deprecate shared key             Change "Shared Key" to         DISAGREE                      EDITOR
"authentication" in the text,    "Shared Key (deprecated)"      (ARCHITECTURE: 2009-11-
since it doesn't supply actual                                  19 01:14:41Z) - Shared key
authentication.                                                 authentication is only used
                                                                with WEP, and WEP has
                                                                already been deprecated. No
                                                                change is needed to deprecate
                                                                shared key authentication.

The informative NOTE            Combine the two paragraphs.     AGREE (EDITOR: 2009-07-02 EDITOR
apparently consists of two                                      11:06:56Z)
paragraphs, based on
formatting. It may not be
readily apparent that the
second paragraph is also
informative.
Annex C is not up to date.      Remove Annex C.                 AGREE IN PRINCIPLE                 EDITOR
Deprecating the annex would                                     (EDITOR: 2009-08-11
dramatically reduce the size of                                 14:16:06Z)
the document and improve its                                    Please see resolution of CID
readability. One downside is                                    1241.
that the chair might feel as if
he was leading a less
important group since its
output document would
become significantly smaller.

"<your name could go here!>" Increase type size to 72 points.   AGREE IN PRINCIPLE                 EDITOR
is not sufficiently noticeable to                               (EDITOR: 2009-07-01
attract attention, and thus,                                    10:11:41Z) -
people to the editorial team.                                   Editors are subtle creatures,
                                                                and easily offended by use of
                                                                72 pt type. Such a change
                                                                would be counter productive.

                                                                Add the following text after the
                                                                cited text: "Please contact
                                                                adrian.p.stephens@intel.com
                                                                if you wish to assist with
                                                                editing this standard. Some
                                                                knowledge of IEEE-SA style is
                                                                helpful, and access to
                                                                Framemaker is essential. On
                                                                the job training will be given."


Incorporate IEEE 802.11n into Add the ratified and published UNRESOLVABLE (EDITOR: EDITOR
REVmb.                        version of 802.11n to the      2009-08-06 08:13:22Z) - This
                              REVmb draft.                   comment is unresolvable
                                                             because at the time of ballot,
                                                             there is no published version
                                                             of the cited document. TGmb
                                                             cannot approve any instruction
                                                             to its editor that would resolve
                                                             the comment.
Incorporate IEEE 802.11w into Add the ratified and published UNRESOLVABLE (EDITOR:            EDITOR
REVmb.                        version of 802.11w to the      2009-08-06 08:17:38Z) -
                              REVmb draft.                   Please see resolution of CID
                                                             1109.




Incorporate IEEE 802.11z into Add the ratified and published UNRESOLVABLE (EDITOR:            EDITOR
REVmb.                        version of 802.11z to the      2009-08-06 08:18:07Z) -
                              REVmb draft.                   Please see resolution of CID
                                                             1109.




Come up with a better term           Be creative. Surprise me,       AGREE (EDITOR: 2009-12-01 EDITOR
than "non-AP STA" to refer to        since I don't have a good       02:54:22Z) - Changes given in
what is typically called a "client   suggestion. Go "creatively      11-09/1068r0
device." Adding qualifications       nuts," although that is scary
to the term "STA" is unwieldy.       marching orders.
Is there a better way to say
"non-AP non-QoS FT-capable
HT STA"?
The "data confidentiality"       Stop amusing me. Rename        DISAGREE (GEN: 2009-09-22 EDITOR
service refers to WEP. Calling   "data confidentiality" into    07:10:33Z) Decline. IEEE
WEP "data confidentiality" is    something that sounds like     802.11 provides a data
very funny.                      less of a lie, such as "WEP    confidentiality service,
                                 data scrambling".              described in 5.4.3.3, which
                                                                includes several alternatives.
                                                                The alternatives provide a
                                                                range between zero
                                                                confidentiality (which arguably
                                                                includes WEP) and currently a
                                                                high degree of confidentiality
                                                                (CCMP). The degree of
                                                                confidentiality utilized in a
                                                                particular wireless network is
                                                                determined by the network
                                                                operator.

Calling the 802.11               Decrease choking hazard by     DISAGREE (GEN: 2009-09-22 EDITOR
authentication protocol the      renaming "authentication       07:24:19Z) Decline. IEEE
"authentication service" is      service" as the "identity      802.11 provides an
almost as funny as calling       assertion service" or          authentication service,
WEP "data confidentiality." It   something else less amusing.   described in 5.4.3.1, which
makes readers of the standard                                   includes several alternatives.
choke on their beverages                                        The alternatives provide a
when they read it.                                              range between zero
                                                                authentication (Open System)
                                                                and a high degree of
                                                                authentication (Fast BSS
                                                                Transition). The degree of
                                                                authentication utilized in a
                                                                particular wireless network is
                                                                determined by the network
                                                                operator.
Make cipher suite extensible.     Adopt 11-09/0601r0 or a            AGREE IN PRINCIPLE                EDITOR
                                  similar proposal.                  (SECURITY: 2009-09-22
                                                                     23:53:32Z) -
                                                                     Make the changes given in
                                                                     document 11-09/601r2




It seems kind of silly to have    Reorder clauses as 1-2-3-4-5- DISAGREE (EDITOR: 2009-                EDITOR
the DSSS and HR/DSSS              7-9-8-11-11A-14-16-15-18-17- 07-27 08:03:19Z) -
clauses separated, or the         19-6-12-10-13.
OFDM and ERP clauses                                            Clauses and annexes will be
separated, and the                                              renumbered towards the end
MLME/PLME clauses are not                                       of working group ballot
widely needed by                                                following the scheme:
implementers.
                                                                     Clauses: 1-2-3-3A-4-5-6-10-
                                                                     12-13-7-9-11-8-11A-14-16-15-
                                                                     18-17-19
                                                                     Annexes: starting with
                                                                     Bibliography, then all
                                                                     normative Annexes, then all
                                                                     informative.

                                                                     Because a resolution cannot
                                                                     promise future action, this has
                                                                     to be marked as a disagree.

"Moving data consists of          Two options: (1) change the        AGREE IN PRINCIPLE (MAC: EDITOR
moving encapsulated MSDUs         definition of "encapsulate" in     2009-10-23 16:27:15Z) -
among the APs (including          3.49 so that it does not require   Remove the word
returning MSDUs to the source     cryptography, or (2) change        "encapsulate" from the cited
AP for MU-to-MU                   the usage of "encapsulate" in      text.
communications) and between       this clause to some other
the APs and the portal(s)." By    word.
definition, "encapsulated"
(3.49) refers only to encrypted
frames, which should be
decrypted at the logical AP
interface.
The chair prefers that his        Change "Matthew Gast" to        AGREE IN PRINCIPLE                 EDITOR
middle initial be used. He        "Matthew S. Gast"               (EDITOR: 2009-06-30
does, however, express                                            12:26:01Z) - And also note
gratitude that the editor knows                                   that somebody has taken the
that it has two "t"s, which                                       P out of Adrian P. Stephens.
seems to be a remarkably                                          Insert S. and P. as
difficult problem for many                                        appropriate.
people.
It states "Time zero is defined   Please clarify how Time Zero   AGREE IN PRINCIPLE                  EDITOR
to be a TBTT with the Beacon      is used. Please separate the   (ARCHITECTURE: 2009-11-
frame being a DTIM and            defintion of Time Zero for     19 17:48:21Z)in reply to the
transmitted at the                EDCA and HCCA.                 commenter: Accept in
beginning of a CFP." It's                                        Principle "TimeZero is defined
unclear in the draft how Time                                    to be a TBTT" is a non-
Zero is used. In addition, if                                    mathematical way of saying
only EDCA is used,                                               that TSF times that satisfy (tsf-
"transmitted at the beginning                                    time modulo
of a CFP." is not necessary                                      dot11BeadonPeriod) = 0 are
because there will not be a                                      TBTTs. Delete "And
CFP.                                                             transmitted at the beginning of
                                                                 the CFP".
"Time zero is defined to be a     Please clarify how Time Zero DISAGREE                              EDITOR
TBTT." It's not clear from the    is used.                       (ARCHITECTURE: 2009-11-
draft how Time Zero is used                                      19 17:51:32Z) : in reply to the
and why such a definition is                                     commenter:Disagree
necessary.                                                       "TimeZero is defined to be a
                                                                 TBTT" is a non-mathematical
                                                                 way of saying that TSF times
                                                                 that satisfy (tsf-time modulo
                                                                 dot11BeadonPeriod) = 0 are
                                                                 TBTTs
It's not clear what an "ATIM      Please clearly state that if a AGREE IN PRINCIPLE                  EDITOR
backoff timer" is. Presumably,    STA has a buffered ATIM        (EDITOR: 2009-08-06
it is a timer for sending ATIM    frame, it shall start          14:14:15Z) -
management frames. If a STA       decrementing the backoff       Add " if the STA has a buffered
does not have an ATIM frame,      timer for the ATIM frame.      ATIM frame" at the end of the
it shouldn't start decrementing                                  cited phrase.
a backoff timer.                                                 Add a note below bullet d)
                                                                 thus:
                                                                 NOTE—The buffered ATIM
                                                                 frame might be left over from a
                                                                 failed channel access attempt
                                                                 during an earlier ATIM window,
                                                                 or it may be a new ATIM
                                                                 generated by the operation of
                                                                 the protocol in 11.2.2.1 (Basic
                                                                 approach).
"STAs in an infrastructure        Please replace "other          AGREE IN PRINCIPLE                  EDITOR
network shall only use other      information" with "information (ARCHITECTURE: 2009-07-
information in received           that is not the CF Parameter   16 06:10:55Z) Need separate
Beacon frames, if the BSSID       Set". Or, move this paragraph paragraph to keep straight
field is equal to the MAC         to the end of the previous     from IBSS in the third
address currently in use by the   paragraph.                     paragraph. Accept changing
STA contained in the AP of the                                   "other information" to
BSS." What is "other                                             "information that is not the CF
information"?                                                    Parameter Set" and do the
                                                                 same in the third paragraph.
Because the value of           Replace "the STA's                      AGREE IN PRINCIPLE              EDITOR
dot11StationID can be          dot11StationID." with "the              (ARCHITECTURE: 2009-11-
changed, it better to use "the STA's default dot11StationID."          18 19:59:54Z) - MIB variable is
STA's default dot11StationID."                                         noted as changes take effect
                                                                       with the next MLME-
                                                                       START.request change. This
                                                                       was done in conjuction with
                                                                       CID 1005




Both Supported Rate                  Insert "Supported Rate            AGREE (ARCHITECTURE:         EDITOR
Information and Extended             Information and" before           2009-07-16 06:13:01Z)
Supported Information can be         "Extended Supported Rate
used in this case.                   Information"
In "it shall perform CCA", "it" is   Delete "it"                       DISAGREE (EDITOR: 2009- EDITOR
redundant.                                                             07-03 13:22:26Z)
                                                                       The commenter is incorrect.
                                                                       The text she cites is part of "in
                                                                       order to transmit shall perform
                                                                       CCA until". The "it" at the end
                                                                       of "transmit" is not redundant.

This statement does not              Please clarify whether there is   DISAGREE (MAC: 2009-09-25 EDITOR
clearly specify any normative        any normative behavior at the     03:16:30Z) - The end of the
behavior: "An unscheduled SP         STA and how a STA would           SP is signaled by the EOSP
ends after the AP has                know the SP has ended when        bit, and the More Data bit
attempted to transmit at least       multiple MSDUs are                signals when the AP has more
one MSDU or                          transmitted                       data for a particular AC. The
MMPDU associated with a                                                cited statement is an
delivery-enabled AC and                                                informative description of how
destined for the non-AP STA,                                           the STA interprets these bits.
but no more than the
number indicated in the Max
SP Length field if the field has
a nonzero value."
Furthermore, it's not clear how
a STA would know when an
unscheduled SP ends if there
are multiple buffered MSDUs
transmitted during the SP.
"The AP may modify the          Please describe in more detail         AGREE IN PRINCIPLE (MAC: EDITOR
service start time by           wrt how the response frame is          2009-09-30 14:24:00Z) - "The
indicating so in the Schedule formed                                   AP may modify the service
element in ADDTS Response                                              start time by indicating so in
frame and in Schedule                                                  the Schedule element in
frames." In this case, does the                                        successful ADDTS Response
AP accept the request or reject                                        frame and in Schedule
the request? What is the                                               frames."
status code in the ADDTS
Response frame?




"MSDUs, or management                Delete "MSDUs, or            AGREE (MAC: 2009-09-25        EDITOR
frames destined for PS STAs,         management frames, destined 03:16:43Z)
shall be temporarily buffered in     for PS STAs using APSD shall
the AP.                              be temporarily buffered in
MSDUs, or management                 the APSD-capable AP."
frames, destined for PS STAs
using APSD shall be
temporarily buffered in
the APSD-capable AP." The
second statement is exactly a
subset of the first statement.

"At every beacon interval, the       Please describe in more detail    DISAGREE (MAC: 2009-09-25 EDITOR
APSD-capable AP shall                how a partial virtual bitmap is   03:16:54Z) - Assembly of the
assemble the partial virtual         assembled in Annex L. Or, if      partial virtual bitmap is
bitmap                               Annex L provides sufficient       explained in normative text in
containing the buffer status of      information, refer to Annex L     7.3.2.6. Annex L is
nondelivery-enabled ACs (if          somewhere in this section.        informative, and therefore, not
there exists at least one                                              appropriate.
nondeliveryenabled
AC) per destination for non-AP
STAs in PS mode and shall
send this out in the TIM field of
the Beacon frame. When all
ACs are delivery-enabled, the
APSD-capable AP shall
assemble the
partial virtual bitmap
containing the buffer status for
all ACs per destination for non-
AP STAs." More detail should
be provided regarding how
partial virtual bitmap is
assembled because the
statement quoted here show
that the partial virtual bitmap is
assembled differently in
different situations. Is
providing a reference on
Annex L sufficient?
This paragraph is exactly the    Delete this paragraph            AGREE (EDITOR: 2009-07-03 EDITOR
duplicate of the second                                           13:25:12Z)
paragraph in this section.
Estimating the power             Please define additional rules   AGREE IN PRINCIPLE (MAC: EDITOR
management state of other        so that the notification of PS   2009-11-13 20:03:58Z) - Make
STAs through transmitting and    mode transition is more          the changes shown in
lossing packets can interfere    reliable.                        submission 11-09-1089-02-
with many rate adaptation                                         000m-lb149-comment-
algorithms, which rely on                                         resolution-cid-1131.doc, which
packet losses as an indication                                    improve the reliability of the
of bad channel.                                                   communication of PS states in
                                                                  IBSS, while preserving legacy
                                                                  compatibility.




This sentence is redundant.      Delete it.                       AGREE (EDITOR: 2009-08-07 EDITOR
                                                                  06:29:46Z) -

                                                                  Note, the sentence is
                                                                  redundant re the last sentence
                                                                  of 11.2.2.1.
Remove "Non-AP" from the         Delete "Non-AP" from the         AGREE IN PRINCIPLE               EDITOR
section title to make it more    section title                    (EDITOR: 2009-07-03
uniform wrt the rest of the                                       13:55:14Z)
section titles                                                    Aggree that there is
                                                                  inconsistency in the use of this
                                                                  term.

                                                                  Resolve the inconsistency by
                                                                  adding "non-AP" to the
                                                                  headings and in the first
                                                                  sentence of subclauses of
                                                                  11.3.2 as appropriate
                                                                  (i.e. where the rules are clearly
                                                                  specified for a non-AP STA).

what is the "corresponding       Replace "the corresponding       AGREE IN PRINCIPLE            EDITOR
QoS Action frame"? State it      QoS Action frame" with           (EDITOR: 2009-08-07
explicitly.                      "ADDTS Rquest frame and/or       14:12:01Z) - Replace cited
                                 ADDTS Response frame"            sentence with: "... are
                                                                  transported on the air by the
                                                                  ADDTS Request frame and
                                                                  the ADDTS Response frame,
                                                                  and across the MLME SAP ...".

This sentence doesn't read       Replace "where certain" with     AGREE IN PRINCIPLE           EDITOR
well.                            "which"                          (EDITOR: 2009-08-07
                                                                  08:27:48Z) - Replace cited
                                                                  sentence with: "However,
                                                                  K.3.2 (TSPEC construction)
                                                                  describes parameter choice."
There is no "ADDTS QoS           Replace "ADDTS QoS Action        AGREE (EDITOR: 2009-08-07 EDITOR
Action Request" frame.           Request" with "ADDTS             08:46:31Z)
                                 Request". Replace "ADDTS
                                 QoS Action Response" with
                                 "ADDTS Response"
The TGmb draft should not         Wait until 802.11n (and           UNRESOLVABLE (EDITOR:          EDITOR
proceed to Sponsor Ballot until   802.11w?) are ratified and        2009-08-06 08:18:49Z) -
more Amendments are               include them into this draft      Please see resolution of CID
included, especially 802.11n.     before Sponsor Ballot.            1109.




The term "ad hoc" used to         Replace "ad hoc" with             AGREE IN PRINCIPLE             EDITOR
describe an IBSS is only a        "independent" in 1.2, 2nd         (EDITOR: 2009-08-06
vernacular. So, stop using it,    paragraph, 1st bullet. Replace    11:12:54Z)
except as the hint provided in    "ad hoc" with "IBSS" in           As proposed by commenter,
Clause 3, 5.2.1, and N.2.         5.2.3.1(d). Delete the 2nd        except the last change,
                                  sentence in 5.6. Delete "ad       instead delete "or ad hoc
                                  hoc" in 11.2.2.1, 2nd sentence.   network" at cited location.
                                  Replace "ad hoc network" with
                                  "IBSS" in 14.4.2.2.

This paragraph (2nd in            Delete 2nd paragraph of           AGREE (EDITOR: 2009-07-03 EDITOR
11.2.2.1) is a duplicate of the   11.2.2.1.                         13:25:50Z)
previous paragraph.
2nd sentence, "In an ESS,         Replace "In an ESS" with "In      AGREE (SECURITY: 2009-07- EDITOR
there is one GTKSA, …" is         an infrastructure BSS".           14 21:51:56Z)
confusing. There is one
GTKSA per BSS, in
infrastructure mode.
The phrase "such as the           Replace "between MAC and  AGREE (ARCHITECTURE:                   EDITOR
interfaces between MAC and        MLME and between PLCP and 2009-07-16 06:13:44Z)
MLME and between PLCP and         PLME" with "between MLME,
PLME, represented as double       PLME and SME"
arrows within Figure 10-1
(GET and SET operations" is
confusing, since the double-
arrows in 10-1 are between
the LMEs and the SME.
Do we need references to both If possible, delete reference to AGREE (GEN: 2009-09-22         EDITOR
revesions FIPS PUB 180?       FIPS PUB 180-1-1995              22:26:17Z) Accept. Delete
                                                               normative reference to FIPS
                                                               PUB 180-1. Move footnote 2 to
                                                               FIPS PUB 180-2.
                                                               In 8.5.2 b)1)ii) change 180-1-
                                                               1995 to 180-2-2002.
Footnotes 13 and 25 seem      Delete footnotes 13 and 25.      AGREE (EDITOR: 2009-07-01 EDITOR
redundant with footnote 10 on                                  11:47:55Z)
page 6.


1st sentence of subclause      Replace first sentence with,      AGREE (EDITOR: 2009-07-02 EDITOR
doesn't read well.             "The FT Confirm frame in an       10:59:43Z)
                               RSN is confirmation to the
                               target AP of receipt of the
                               ANonce and indicates the
                               liveness of the PTKSA.
In 2nd paragraph, 2nd          Replace "the current BSS          AGREE (MAC: 2009-08-07    EDITOR
sentence, reference to "BSS    Load value" with "the Available   00:33:01Z)
Load value" is ambiguous.      Admission Capacity field value
Should be reference to AAC     of the BSS Load element".
field of BSS Load element(?)
The phrase "frame associated   Change "associated with" to       AGREE (MAC: 2009-09-25    EDITOR
with … AC" is confusing. For   "using" in both occurances in     03:28:30Z)
example, does it include       this paragraph, and both
Management frames              occurances in the 10th
transmitted using AC_VO?       paragraph (pg 590, line 32),
                               and both occurances in
                               11.2.1.5(d) that are
                               "associated with … AC(s)",
                               and four occurances in
                               11.2.1.5(h). Also change
                               "belonging to" to "using" in
                               11.2.1.5(d), 11.2.1.5(g) and
                               11.2.1.9(b). Also change
                               "belong to" to "use" in
                               11.2.1.5(g), and both
                               occurances in 11.2.1.9(d).
802.2 describes the expected       Revert MA-UNITDATA.confirm       AGREE IN PRINCIPLE (MAC: EDITOR
interface provided to LLC by       to MA-UNITDATA-                  2009-11-13 19:39:12Z) -
the MAC sublayer, and it has       STATUS.indication, consistent    Change any occurances of MA-
an MA-UNITDATA-                    with 802.2, X.210, and similar   UNITDATA.confirm to MA-
STATUS.indication primitive        to 802.11-1999                   UNITDATA-
and no MA-                                                          STATUS.indication.
UNITEDATA.confirm
primitive.. Also, X.210 does
not support the concept of a
".confirm" service primitive for
a connectionless data service.
The MA-UNITDATA-
STATUS.indication primitive
change to MA-
UNITDATA.confirm seemed
like a good idea at the time
(TGma), but it was actually in
error. This error has led to
confusion that the MA-
UNITDATA primitive set
provides what amounts to a
guaranteed delivery service,
which is not the case, nor the
intent. MA-UNITDATA is not a
confirmed facility. In fact, the
description of the .confirm
does not describe waiting for
successful transmission (and
ACK or other response) or
transmission exhaustion with
failure, as the name would
imply.
Section 9.9.3.1 says, "A non-     Clarify that the use of a EDCA     AGREE IN PRINCIPLE (MAC: EDITOR
AP STA may support                parameters for a lower priority    2009-11-19 16:26:57Z) -
admission control procedures      (non admission mandatory)          Incorporate the changes from
in 9.9.3.1.2 to send frames in    AC does not require                11-09/1063r1 and replace the
the AC where admission            modification of the QoS control    2 paragraphs starting at
control is mandated; but, if it   field.                             408.33:
does not support that
procedure, it shall use EDCA                                         "A non-AP STA may support
parameters of a lower priority                                       admission control procedures
AC, as indicated in Table 9-1,                                       in 9.9.3.1.2 (Procedure at non-
that does not require                                                AP STAs) to send frames in
admission control" and also "If                                      the AC where admission
a STA desires to send data                                           control is mandated; but, if it
without admission control                                            does not support that
using an AC that mandates                                            procedure and
admission control, the STA                                           dot11RejectUnadmittedTraffic
shall use EDCA parameters                                            is false or not present, it shall
that correspond to a lower                                           use EDCA parameters of a
priority and do not require                                          lower priority AC, as indicated
admission control." Nothing in                                       in Table 9-1 (UP-to-AC
this section discusses the                                           mappings), that does not
setting of the TID(UP) field in                                      require admission control.
the QoS control when this is                                         When a STA uses a lower
done.                                                                priority AC for this purpose,
                                                                     the lower priority AC affects
                                                                     only the EDCA parameters
                                                                     used for channel access, i.e., it
                                                                     has no effect on the contents
                                                                     of the transmitted frame. APs
                                                                     shall support admission
                                                                     control procedures, at least to
                                                                     the minimal extent of
Lack of punctuation makes         Replace "results" with             advertising PRINCIPLE
                                                                     AGREE IN that admission is        EDITOR
sentence confusing.               "results," (add comma).            (EDITOR: 2009-07-01
                                                                     14:50:35Z)
                                                                     Too many commas. Enclose
                                                                     "in the absence of
                                                                     transmission errors" in
                                                                     parentheses.
The Capability Information        Replace "when these bits are       AGREE IN PRINCIPLE                EDITOR
Field bits are now fully          fully allocated" with "since the   (EDITOR: 2009-07-02
allocated, we don't need the      CIF bits are fully allocated"      06:38:54Z)
anticipatory language                                                Replace ", intended to
anymore.                                                             augment the Capability
                                                                     Information field (CIF) when
                                                                     these bits are fully allocated."
                                                                     with " that augment the
                                                                     Capability Information field
                                                                     (CIF)"
Action Category value 17            Add a row to Table 7-24,           AGREE IN PRINCIPLE               EDITOR
(0x11) is being used by WFA         showing Category value with        (ARCHITECTURE: 2009-07-
for WMM signaling. To               code 17 as "Reserved for Wi-       19 02:31:37Z) There is no
prevent a usage collision in the    Fi Alliance use", changing the     need to mark the field as
future, this value should be        existing "Reserved" row to         reserved for use by another
explicitly listed as Reserved for   appropriately reserve values       body. This is an ANA issue.
this purpose in Table 7-24.         before and after 17.               ANA assignments are handled
                                                                       at the direction of the TG's
                                                                       technical editor, and the editor
                                                                       is working with the ANA
                                                                       representative to handle this.
                                                                       No text change.

With the addition of RSNA           Add the concept of RSNA             AGREE IN PRINCIPLE (GEN: EDITOR
capability, the term                authentication to the state        2009-11-19 05:15:59Z) The
"authentication" as it applies to   variables and state machine        Editor is instructed to
states like the ones in 11.3.0a,    shown in 11.3.0a. This will        incorporate into the REVmb
has taken on multiple               need a submission.                 draft document 11-09/705r4.
meanings. That's fine, except                                          (https://mentor.ieee.org/802.11
many people seem to get                                                /dcn/09/11-09-0705-04-000m-
confused by which                                                      proposed-corrections-to-11-3-
authentication is being referred                                       sta-authentication-and-
to in different contexts. This                                         association.doc)
could perhaps be alleviated by
showing the RSNA
authentication process in
these state tables, like the
simple authentication.

Disassociation is not only from     Delete "that is within an AP."     AGREE (ARCHITECTURE:          EDITOR
non-AP STA to AP, as implied                                           2009-07-16 06:14:15Z)
by the description.
How can a DISASSOCIATE              Delete TIMEOUT and                 AGREE (ARCHITECTURE:          EDITOR
request fail for either timeout     REFUSED as valid values for        2009-07-16 06:14:44Z)
or refusal?                         the ResultCode.
This behavior for MLME-             Delete the sentence describing     AGREE IN PRINCIPLE            EDITOR
EAPOL.confirm is not                the MLME-EAPOL.confirm             (SECURITY: 2009-08-14
consistent with a                   primitive in this subclause, and   15:41:50Z)
connectionless MAC and              delete 10.3.20.2.                  Change the last sentence of
X.210-based primitive                                                  the paragraph to: "MLME-
methods. It also does not                                              EAPOL.confirm primitive
appear to serve any real                                               indicates to the Supplicant
purpose in the EAPOL-Key                                               when the EAPOL-Key frame
exchanges since everything                                             has been transmitted." In
uses handshakes.                                                       clause 10.3.20.1, change
                                                                       "acknowledged" to
                                                                       "transmitted". In clause
                                                                       10.3.20.2, change
                                                                       "acknowledged by" to
                                                                       "transmitted to". In clause
                                                                       10.3.20.4, change
                                                                       "acknowledged" to
                                                                       "transmitted".10.3.20.4,
                                                                       change "acknowledged by" to
                                                                       "transmitted to".
What does the ResultCode of Delete                            AGREE (ARCHITECTURE:          EDITOR
TRANSMISSION_FAILURE             TRANSMISSION_FAILURE         2009-11-18 20:07:03Z)
mean? This sounds like it is     from the valid ResultCodes
reporting the lack of a MAC
layer ACK to the MLME-
ADDTS.request, which is not
consistent with a
connectionless MAC layer
service. Besides, this is better
reported as a TIMEOUT error,
and only after the timeout has
expired, since the sender has
no way of knowing if the
reciever got the request simply
because the ACK was not
received (which is why X.210-
based service primitives have
the style that they do).


The procedure for Vendor         Delete TIMEOUT and           AGREE IN PRINCIPLE            EDITOR
Specific Action frames is not    TRANSMISSION_FAILURE as      (ARCHITECTURE: 2009-11-
particularly clear, but there    valid values for the         18 20:10:17Z) Delete MLME-
does not appear to be any        ResultCode. (Or, delete      VSPECIFIC.confirm
response from the peer entity    MLME-VSPECIFIC.confirm       completely.
expected, beyond the MAC         completely.)
layer ACK. So, this should
follow the X.210 model for
connectionless service, which
has no .confirm primitive,
perhaps (in which case, delete
the .confirm completely). But,
at the very least, there is no
concept of a TIMEOUT or
TRANSMISSION_FAILURE
response to the request.

Since there is no immediate      Delete TIMEOUT and           AGREE IN PRINCIPLE            EDITOR
response from the peer entity    TRANSMISSION_FAILURE as      (ARCHITECTURE: 2009-11-
to a Neighbor Report Request     valid values for the         18 20:12:23Z) delete the
(the Response is handled by a    ResultCode. (Or, delete      Transmission_Failure result
completely different set of      MLME-                        code.
primitives), there can be no     NEIGHBORREPREQ.confirm
useful concept of TIMEOUT or     completely.)
TRANSMISSION_FAILURE in
a .confirm primitive. The
.confirm primitive itself is
probably not correct under the
X.210 model, and could
perhaps just be deleted.
There is no response from the       Delete                            AGREE IN PRINCIPLE         EDITOR
peer entity to a Neighbor           TRANSMISSION_FAILURE as           (ARCHITECTURE: 2009-11-
Report Request (beyond the          valid values for the              18 20:14:27Z) delete MLME-
MAC layer ACK). So, this            ResultCode. (Or, delete           NEIGHBORREPRESP.confirm
should follow the X.210 model       MLME-                             completely
for connectionless service,         NEIGHBORREPRESP.confirm
which has no .confirm               completely.)
primitive, perhaps (in which
case, delete the .confirm
completely). But, at the very
least, there is no useful
concept of a
TRANSMISSION_FAILURE
response to the request.
What does the ResultCode of         Delete                            AGREE IN PRINCIPLE          EDITOR
TRANSMISSION_FAILURE                TRANSMISSION_FAILURE              (ARCHITECTURE: 2009-11-
mean? This sounds like it is        from the valid ResultCodes.       18 20:17:27Z) Delete
reporting the lack of a MAC         Consider adding a TIMEOUT         TRANSMISSION_FAILURE
layer ACK at some point in the      ResultCode if the Link            from the valid ResultCodes
exchange, which is not              Measurement Response is not       and Add TIMEOUT
consistent with a                   received within some              ResultCode should be added.
connectionless MAC layer            described timeout (add this
service. Besides, this is better    concept to 11.10.10).
reported as a TIMEOUT error,
and only after a timeout has
expired, since the sender has
no way of knowing if the
reciever got the request simply
because the ACK was not
received (which is why X.210-
based service primitives have
the style that they do).


The non-AP STA has no way           Replace all this text with a      AGREE IN PRINCIPLE                EDITOR
of knowing if it is experiencing    simple description of a timeout   (EDITOR: 2009-11-19
case 1 in Figure 11-9 and the       mechanism that causes the         13:29:41Z) - AGREE IN
ACK is getting lost, or case 2.     MLME-ADDTS.confirm to             PRINCIPLE (MAC: 2009-08-
Therefore, it cannot definitively   report failure due to TIMEOUT.    07 15:21:43Z) - remove the
distinguish these two cases.        Delete Figure 11-9.               phrase "with a result code of
This is why                                                           TRANSMISSION_FAILURE in
connectionless/datagram                                               the former case and" as well
service primitives are not                                            as "in the latter case" following
designed with this sort of error                                      the word TIMEOUT. Also
reporting via .confirm                                                change the introductory
primitives. Reporting                                                 phrase of the next sentence to
transmission failures of                                              read "In either case". Do not
various types is either inexact                                       change the figure.
or impossible. There should
only be a single failure report
for all such errors, and
TIMEOUT seems to be the
best of the existing choices.
It is never made clear if            Add text to clarify that Medium    DISAGREE (MAC: 2009-11-18 EDITOR
admitted_time and used_time          Time is to include both uplink     20:49:10Z) - The commentor is
are meant to cover both uplink       and donwlink directions (so an     encouraged to provide more
and downlink directions. For         AP needs to account for both       details of any proposed
example, admitted_time would         directions in the computation      improvement, but without the
appear to be a total time used       like K.2.2), and that used_time    details of what is proposed,
on behalf of the non-AP STA          needs to capture time used on      the group cannot evaluate the
(for uplink or downlink), but the    behalf of the non-AP STA for       technical merit at this time.
used_time discussion is              both directions of data traffic.
focused on "time to transmit"
from the non-AP STA's
perspective ("the amount of
time used ... by the non-AP
STA" and "the time required to
transmit the MPDU
sequence"). K.2.2, in
discussing how an AP might
compute MediumTime does
not double the time if the
request is for a bi-directional
link, either.

What is "the wildcard                Add text to specify what is        AGREE IN PRINCIPLE           EDITOR
address"?                            meant here.                        (EDITOR: 2009-08-06
                                                                        11:25:55Z)
                                                                        Replace "wildcard" by
                                                                        "broadcast".
A STA does not have to be            Change the definition of STA       AGREE (GEN: 2009-11-18       EDITOR
contained within a single            to: "A logical entity that is a    01:46:21Z)
physical device (examples are        singly addressable instance of
"upper MAC" and "lower MAC"          an IEEE 802.11-conformant
implementations, "controller         medium access control (MAC)
based" APs, etc.). The point         and physical layer (PHY)
of a "STA" is that it is a single    interface to the wireless
instance of a MAC and PHY,           medium (WM)."
and that it is uniquely identified
and addressed by its MAC
address.




It isn't clear that an AP has        Change the definition of AP to:    AGREE IN PRINCIPLE (GEN: EDITOR
exactly one STA (that is, only       "Any entity that contains one      2009-11-18 01:47:29Z)
one STA). The current                station (STA) and provides         Change the definition of AP to:
defintion could be read such         access to the distribution         "An entity that contains one
that an AP contains more than        services, via the wireless         station (STA) and provides
one STA. But, if this is             medium (WM) for associated         access to the distribution
allowed, many, many                  STAs."                             services, via the wireless
assumptions within the                                                  medium (WM) for associated
Standard will fall apart.                                               STAs."
With no definition of Multiple       Add a definition of a Multiple     AGREE (GEN: 2009-11-18          EDITOR
BSSID Set, the concept just          BSSID Set: "A collection of        20:23:39Z)
sort of "happens" in 11.10.11.       cooperating APs, such that all
                                     the APs use a common
                                     regulatory class, channel, and
                                     antenna connector."
Multiple BSSID Set APs must        Add (at least), "Channel           AGREE IN PRINCIPLE                  EDITOR
share more facilities "in          Access Functions" to the list of   (SECURITY: 2009-08-14
common" than those listed.         common facilities in the first     15:50:00Z)
                                   bullet. There are probably         Add "Channel Access
                                   more things that should be         Functions" to the first bullet in
                                   listed. This will need study.      11.10.11. The commentor is
                                                                      encouraged to make a more
                                                                      detailed comment on future
                                                                      recirculation letter ballots.

The FH PHY is a poor               Mark the FH PHY as          AGREE IN PRINCIPLE (GEN: EDITOR
coexister in the 2.4 GHz band                                  2009-09-22 07:30:06Z) Agree
                                   deprecated for new designs, or
and offers low data rates with     remove this clause (and     in Principle -- Mark the FH
an inefficient MAC                 related MAC material and    PHY as deprecated and
                                   Annex B) entirely           subject to removal in a future
                                                               revision Editor to add
                                                               immediately following the
                                                               clause heading the following
                                                               new paragraph: This clause is
                                                               obsolete and is subject to
                                                               removal in a future revision.
The IR PHY offers low data      Mark the IR PHY as             AGREE IN PRINCIPLE (GEN: EDITOR
rates with a LOS technology     deprecated for new designs, or 2009-09-24 00:12:58Z) -
with an inefficient MAC         remove this clause (and        Agree in Principle -- Mark the
                                related MAC material) entirely IR PHY as obsolete and
                                                               subject to removal in a future
                                                               revision: instruct the editor to
                                                               insert the following line at the
                                                               beginning of clause 16:"This
                                                               clause is obsolete and is
                                                               subject to removal from a
                                                               future revision."
"Once PLCP preamble             Rewrite to "Once PLCP          AGREE (GEN: 2009-11-18           EDITOR
transmission is started, the    preamble transmission is       19:10:07Z)
PHY entity shall immediately    started, the PHY entity shall
initiate PLCP header encoding immediately initiate PLCP
then data scrambling and data header encoding then data
encoding. The data shall then scrambling and data encoding,
be exchanged between the        where the data shall be
MAC and the PHY through a       exchanged between the MAC
series of PHY-                  and the PHY through a series
DATA.request(DATA)              of PHY-DATA.request(DATA)
primitives issued by the MAC" primitives issued by the MAC"
is anti-causal as data encoding
commences before data is
exchanged to the PHY.


"TX training symbols. Followed     Rewrite to "TX training            AGREE (EDITOR: 2009-07-23 EDITOR
by the SIGNAL field, which         symbols followed by the            12:06:18Z)
consists of:" is not ideal since   SIGNAL field, which consists
the verb TX is needed to make      of:"
the "Followed" make sense.

The 1 and 2 Mbps DSSS PHY          Mark a clause-15-only PHY as       DISAGREE (GEN: 2009-09-22 EDITOR
offers low data rates and has a    deprecated for new designs:        07:35:54Z) Products are still
very inefficient preamble with     i.e. require that the minimum      being produced and
an inefficient MAC                 PHY be clause 18.                  developed using this PHY.
The FH PHY is a poor               Mark the FH PHY as          AGREE IN PRINCIPLE (GEN: EDITOR
coexister in the 2.4 GHz band                                  2009-09-22 07:32:37Z) Agree
                                   deprecated for new designs, or
and offers low data rates with     remove this clause (and     in Principle -- Mark the FH
an inefficient MAC                 related MAC material and    PHY as deprecated and
                                   Annex B) entirely           subject to removal in a future
                                                               revision Editor to add
                                                               immediately following the
                                                               clause heading the following
                                                               new paragraph: This clause is
                                                               obsolete and is subject to
                                                               removal in a future revision.
The IR PHY offers low data      Mark the IR PHY as             AGREE IN PRINCIPLE (GEN: EDITOR
rates with a LOS technology     deprecated for new designs, or 2009-09-24 00:10:33Z) Agree
with an inefficient MAC         remove this clause (and        in Principle -- Mark the IR PHY
                                related MAC material) entirely as obsolete and subject to
                                                               removal in a future revision:
                                                               instruct the editor to insert the
                                                               following line at the beginning
                                                               of clause 16:"This clause is
                                                               obsolete and is subject to
                                                               removal from a future
                                                               revision."
"Once PLCP preamble             Rewrite to "Once PLCP          AGREE (GEN: 2009-11-18            EDITOR
transmission is started, the    preamble transmission is       19:10:07Z)
PHY entity shall immediately    started, the PHY entity shall
initiate PLCP header encoding immediately initiate PLCP
then data scrambling and data header encoding then data
encoding. The data shall then scrambling and data encoding,
be exchanged between the        where the data shall be
MAC and the PHY through a       exchanged between the MAC
series of PHY-                  and the PHY through a series
DATA.request(DATA)              of PHY-DATA.request(DATA)
primitives issued by the MAC" primitives issued by the MAC"
is anti-causal as data encoding
commences before data is
exchanged to the PHY.


"TX training symbols. Followed     Rewrite to "TX training          AGREE (EDITOR: 2009-07-23 EDITOR
by the SIGNAL field, which         symbols followed by the          12:07:08Z)
consists of:" is not ideal since   SIGNAL field, which consists
the verb TX is needed to make      of:"
the "Followed" make sense.

The 1 and 2 Mbps DSSS PHY          Mark a clause-15-only PHY as     DISAGREE (GEN: 2009-09-22 EDITOR
offers low data rates and has a    deprecated for new designs:      07:37:28Z)Products are still
very inefficient preamble with     i.e. require that the minimum    being produced and
an inefficient MAC                 PHY be clause 18.                developed using this PHY.

The PBCC option is not widely Mark the PBCC option as               AGREE IN PRINCIPLE (GEN: EDITOR
used and is inferior to the   deprecated for new designs, or        2009-11-18 02:07:56Z) Insert
OFDM PHY                      remove this section (and              in 7.3.1.4 (P107.12), 18
                              related material) entirely            (P885.34), Annex A (P998.35
                                                                    PC17 under "Protocol
                                                                    Capability"):
                                                                    "The use of the PBCC option
                                                                    is obsolete, and this option
                                                                    may be removed in a later
                                                                    revision of the standard."
The channel agility option is    Mark the channel agility option   DISAGREE (GEN: 2009-11-18 EDITOR
not widely used and makes        as deprecated for new             02:05:08Z) While the indended
coexistence and frequency        designs, or remove this           requested outcome is clear,
planning much more difficult     section (and related material)    the changes to achieve this
                                 entirely                          outcome are substantial and
                                                                   non-obvious. The commenter
                                                                   is solicited to provide the
                                                                   changes in a submission.

The ERP-PBCC option is not       Mark the ERP-PBCC option as AGREE IN PRINCIPLE (GEN: EDITOR
widely used and is inferior to   deprecated for new designs, or 2009-09-22 07:43:04Z) Agree
the OFDM PHY                     remove this option entirely    in principle. Insert in 7.3.1.4
                                                                (P107.12), 9.6a (P389.50
                                                                under "Description"), 19
                                                                (p941.36), Annex A (P1063.63
                                                                under "PHY Features")
                                                                "The use of the ERP-PBCC
                                                                option is deprecated, and this
                                                                option may be removed in a
                                                                later revision of the standard."


The DSSS-OFDM option is not      Mark the DSSS-OFDM option         AGREE IN PRINCIPLE (GEN: EDITOR
widely used, introduces          as deprecated for new             2009-09-22 07:44:38Z)Agree
complexity, and is not           designs, or remove this option    in principle. Insert in 7.3.1.4
markedly better than OFDM +      entirely                          (P107.60), 9.6a (P389.52
MAC protection                                                     under "Description", 19
                                                                   (P941.36),
                                                                   Annex A (P998.40 under
                                                                   "Protocol Capability",
                                                                   P1064.13 under "PHY
                                                                   features")
                                                                   "The use of the DSSS-OFDM
                                                                   option is deprecated, and this
                                                                   option may be removed in a
                                                                   later revision of the standard."


The FH PHY is a poor             Mark the FH PHY as                AGREE IN PRINCIPLE (GEN: EDITOR
coexister in the 2.4 GHz band    deprecated for new designs, or    2009-09-22 07:27:11Z) -
and offers low data rates with   remove this clause (and           Agree in Principle -- Mark the
an inefficient MAC               related MAC material and          FH PHY as deprecated and
                                 Annex B) entirely                 subject to removal in a future
                                                                   revision Editor to add
                                                                   immediately following the
                                                                   clause heading the following
                                                                   new paragraph: This clause is
                                                                   obsolete and is subject to
                                                                   removal in a future revision.
The IR PHY offers low data         Mark the IR PHY as               AGREE IN PRINCIPLE (GEN: EDITOR
rates with a LOS technology        deprecated for new designs, or   2009-09-24 00:10:13Z) Agree
with an inefficient MAC            remove this clause (and          in Principle -- Mark the IR PHY
                                   related MAC material) entirely   as obsolete and subject to
                                                                    removal in a future revision:
                                                                    instruct the editor to insert the
                                                                    following line at the beginning
                                                                    of clause 16:"This clause is
                                                                    obsolete and is subject to
                                                                    removal from a future
                                                                    revision."
"Once PLCP preamble                Rewrite to "Once PLCP            AGREE (GEN: 2009-11-18            EDITOR
transmission is started, the       preamble transmission is         19:10:07Z)
PHY entity shall immediately       started, the PHY entity shall
initiate PLCP header encoding      immediately initiate PLCP
then data scrambling and data      header encoding then data
encoding. The data shall then      scrambling and data encoding,
be exchanged between the           where the data shall be
MAC and the PHY through a          exchanged between the MAC
series of PHY-                     and the PHY through a series
DATA.request(DATA)                 of PHY-DATA.request(DATA)
primitives issued by the MAC"      primitives issued by the MAC"
is anti-causal as data encoding
commences before data is
exchanged to the PHY.


"TX training symbols. Followed     Rewrite to "TX training          AGREE (EDITOR: 2009-07-23 EDITOR
by the SIGNAL field, which         symbols followed by the          12:07:55Z)
consists of:" is not ideal since   SIGNAL field, which consists
the verb TX is needed to make      of:"
the "Followed" make sense.

The 1 and 2 Mbps DSSS PHY          Mark a clause-15-only PHY as     DISAGREE (GEN: 2009-09-22 EDITOR
offers low data rates and has a    deprecated for new designs:      07:37:49Z) Products are still
very inefficient preamble with     i.e. require that the minimum    being produced and
an inefficient MAC                 PHY for 2.4GHz be clause 18.     developed using this PHY.

The PBCC option is not widely Mark the PBCC option as              AGREE IN PRINCIPLE (GEN: EDITOR
used and is inferior to the   deprecated for new designs, or       2009-11-18 02:07:56Z) Insert
OFDM PHY                      remove this section (and             in 7.3.1.4 (P107.12), 18
                              related material) entirely           (P885.34), Annex A (P998.35
                                                                   PC17 under "Protocol
                                                                   Capability"):
                                                                   "The use of the PBCC option
                                                                   is obsolete, and this option
                                                                   may be removed in a later
                                                                   revision of the standard."
The channel agility option is      Mark the channel agility option DISAGREE (GEN: 2009-11-18 EDITOR
not widely used and makes          as deprecated for new           02:05:08Z) While the indended
coexistence and frequency          designs, or remove this         requested outcome is clear,
planning much more difficult       section (and related material) the changes to achieve this
                                   entirely                        outcome are substantial and
                                                                   non-obvious. The commenter
                                                                   is solicited to provide the
                                                                   changes in a submission.
The ERP-PBCC option is not       Mark the ERP-PBCC option as AGREE IN PRINCIPLE (GEN: EDITOR
widely used and is inferior to   deprecated for new designs, or 2009-09-22 07:43:04Z) Agree
the OFDM PHY                     remove this option entirely    in principle. Insert in 7.3.1.4
                                                                (P107.12), 9.6a (P389.50
                                                                under "Description"), 19
                                                                (p941.36), Annex A (P1063.63
                                                                under "PHY Features")
                                                                "The use of the ERP-PBCC
                                                                option is deprecated, and this
                                                                option may be removed in a
                                                                later revision of the standard."


The DSSS-OFDM option is not      Mark the DSSS-OFDM option         AGREE IN PRINCIPLE (GEN: EDITOR
widely used, introduces          as deprecated for new             2009-09-22 07:44:38Z)Agree
complexity, and is not           designs, or remove this option    in principle. Insert in 7.3.1.4
markedly better than OFDM +      entirely                          (P107.60), 9.6a (P389.52
MAC protection                                                     under "Description", 19
                                                                   (P941.36),
                                                                   Annex A (P998.40 under
                                                                   "Protocol Capability",
                                                                   P1064.13 under "PHY
                                                                   features")
                                                                   "The use of the DSSS-OFDM
                                                                   option is deprecated, and this
                                                                   option may be removed in a
                                                                   later revision of the standard."


Phrase "frame reception"         Add "frame reception"             AGREE IN PRINCIPLE              EDITOR
omitted from the text            between "this" and                (EDITOR: 2009-07-02
                                 "transmission"                    15:13:40Z)
                                                                   Replace " and until this
                                                                   transmission occurs," with ",
                                                                   and until this Beacon frame is
                                                                   received,"
Space missing                    peerMAC should be peer MAC        AGREE (EDITOR: 2009-07-03 EDITOR
                                                                   13:12:42Z)
Table entries confusing          Table entries should line up      DISAGREE (EDITOR: 2009- EDITOR
                                 better for clarity: “Multiple     07-23 12:44:33Z)
                                 classes in Country information    This is an artefact of the long
                                 element” should line up with      cross-reference format.
                                 first “9.8.3” Reference and       When this is switched to the
                                 “CF15:M” Status; line up          short format (probably at the
                                 Support field “Multiple classes   start of sponsor ballot), the
                                 in Association and                reference and status rows will
                                 Reassociation frames” should      line up properly.
                                 line up with second “9.8.3”
                                 Reference and “CF15:M”
                                 Status; line up Support field
Table entries confusing   Table entries should line up        DISAGREE (EDITOR: 2009- EDITOR
                          better for clarity in RC5:          07-23 12:46:58Z) - This is an
                          “Coverage classes 0–31”             artefact of the long cross-
                          should line up with first “9.8.4”   reference format. When this
                          Reference and “CF15:M”              is switched to the short format
                          Status; line up Support field;      (probably at the start of
                          “Coverage class operation           sponsor ballot), the reference
                          when not associated” should         and status rows will line up
                          line up with second “9.8.4”         properly.
                          Reference and “CF15:M”
                          Status; line up Support field

Table entries confusing   Table entries should line up for    DISAGREE (EDITOR: 2009- EDITOR
                          clarity in RC6: “Power level,       07-23 12:46:40Z) - This is an
                          equivalent maximum transmit         artefact of the long cross-
                          power level and regulatory          reference format. When this
                          class” should line up with first    is switched to the short format
                          “9.8.4” Reference and               (probably at the start of
                          “CF15:M” Status; line up            sponsor ballot), the reference
                          Support field; “Power level         and status rows will line up
                          operation when not                  properly.
                          associated” should line up with
                          second “9.8.4” Reference and
                          “CF15:M” Status; line up
                          Support field
Table entries confusing   Table entries should line up for    DISAGREE (EDITOR: 2009- EDITOR
                          clarity in RC7: “Power level,       07-23 12:46:17Z)This is an
                          different maximum transmit          artefact of the long cross-
                          power level and regulatory          reference format. When this
                          class” should line up with first    is switched to the short format
                          “9.8.4” Reference and               (probably at the start of
                          “CF15:M” Status; line up            sponsor ballot), the reference
                          Support field; “Power level         and status rows will line up
                          operation when not                  properly.
                          associated” should line up with
                          second “9.8.4” Reference and
                          “CF15:M” Status; line up
                          Support field
Table entries confusing   Table entries should line up        DISAGREE (EDITOR: 2009- EDITOR
                          better for clarity in DSE4:         07-23 12:47:27Z) - This is an
                          “Transmission of DSE                artefact of the long cross-
                          measurement request by an           reference format. When this
                          AP” should line up with first       is switched to the short format
                          “11.11.15” Reference and            (probably at the start of
                          “(CF15&CF1):M” Status; line         sponsor ballot), the reference
                          up Support field;                   and status rows will line up
                          "Transmission of DSE                properly.
                          measurement report by a STA”
                          should line up with second
                          “11.11.15” Reference and
                          “(CF15&CF2):M” Status; line
                          up Support field
Table entries confusing   Table entries should line up       DISAGREE (EDITOR: 2009- EDITOR
                          better for clarity in DSE5:        07-23 12:48:04Z) - This is an
                          “Transmission of Association       artefact of the long cross-
                          Request frame with Supported       reference format. When this
                          Regulatory Classes element         is switched to the short format
                          by a STA” should line up with      (probably at the start of
                          “9.8.3 (Operation with             sponsor ballot), the reference
                          regulatory classes), 11.3.2.1      and status rows will line up
                          (STA association procedures)”      properly.
                          Reference and
                          “(CF15&CF2):M” Status; line
                          up Support field;
                          “Transmission of Association
                          Response frame with
                          Supported Regulatory Classes
                          element by an AP” should line
                          up with “9.8.3 (Operation with
                          regulatory classes), 11.3.2.2
                          (AP association procedures)”
                          Reference and
                          “(CF15&CF1):M” Status; line
                          up Support field


Table entries confusing   Table entries should line up for   DISAGREE (EDITOR: 2009- EDITOR
                          better clarity in DSE6:            07-23 12:48:23Z) - This is an
                          “Transmission of                   artefact of the long cross-
                          Reassociation Request frame        reference format. When this
                          with Supported Regulatory          is switched to the short format
                          Classes element by a STA”          (probably at the start of
                          should line up with “9.8.3         sponsor ballot), the reference
                          (Operation with regulatory         and status rows will line up
                          classes), 11.3.2.3 (STA            properly.
                          reassociation procedures)”
                          References and
                          “(CF15&CF2):M” Status; line
                          up Support field;
                          “Transmission of
                          Reassociation Response
                          frame with Supported
                          Regulatory Classes element
                          by an AP” should line up with
                          “9.8.3 (Operation with
                          regulatory classes), 11.3.2.4
                          (AP reassociation
                          procedures)” References and
                          “(CF15&CF1):M” Status; line
                          up Support field
Table entries confusing   Table entries should line up for   DISAGREE (EDITOR: 2009- EDITOR
                          better clarity in DSE9:            07-23 12:48:39Z) - This is an
                          “Transmission of extended          artefact of the long cross-
                          channel switch announcement        reference format. When this
                          and channel switch procedure       is switched to the short format
                          by an AP” should line up with      (probably at the start of
                          first “11.9a.3 (Selecting and      sponsor ballot), the reference
                          advertising a new channel          and status rows will line up
                          and/or regulatory class)”          properly.
                          Reference and
                          “(CF15&CF1):M” Status; line
                          up Support field;
                          “Transmission of extended
                          channel switch announcement
                          and channel switch procedure
                          by a STA” should line up with
                          second “11.9a.3 (Selecting
                          and advertising a new channel
                          and/or regulatory class)”
                          Reference and
                          “(CF15&CF2):M” Status; line
                          up Support field; Reception of
                          extended channel switch
                          announcement and channel
                          switch procedure by a STA”
                          should line up with third
                          “11.9a.3 (Selecting and
                          advertising a new channel
                          and/or regulatory class)”
                          Reference and “CF15:M”
                          Status; line up Support field

Table entries confusing   Table entries should line up for   DISAGREE (EDITOR: 2009- EDITOR
                          better clarity in DSE10:           07-23 12:48:52Z) - This is an
                          “Transmission of DSE power         artefact of the long cross-
                          constraint announcement by         reference format. When this
                          an enabling STA” should line       is switched to the short format
                          up with first “11.11.5             (probably at the start of
                          (Dependent STA operation           sponsor ballot), the reference
                          with DSE)” Reference and           and status rows will line up
                          “(CF15&CF1):M” Status; line        properly.
                          up Support field; “Reception of
                          DSE power constraint
                          announcement by a
                          dependent STA” should line up
                          with second “11.11.5
                          (Dependent STA operation
                          with DSE)” Reference and
                          “CF15:M” Status; line up
                          Support field
Typo                      “Station ManagemenT” should        DISAGREE (EDITOR: 2009-       EDITOR
                          be “Station Management             07-23 13:28:07Z)
                                                             The "T" is capitalized to
                                                             explain its presence in the
                                                             SMT acronym.
Reference for 5.25 - 5.35 and   In the row labeled “4 Part 15   AGREE IN PRINCIPLE (GEN: EDITOR
5.47 - 5.725 bands missing      License Exempt bands” add “,    2009-11-18 05:43:21Z) -
                                15.407” in the column labeled   Accept in Principle based on
                                “United States”                 discussion and editorial
                                                                instructions in 09/1111r2:
                                                                1054, 1055, 1059, 1216 and
                                                                1301.




Reference for 5.25 - 5.35 and   In the row labeled “10 Part 15 AGREE (GEN: 2009-11-16   EDITOR
5.47 - 5.725 bands missing      License Exempt bands” add “, 12:20:40Z)
                                15.407” in the column labeled
                                “United States”




Power limit is incorrect        In the row labeled “5.25–5.35“ AGREE (GEN: 2009-11-16   EDITOR
                                change “200” to “250” in the   12:20:54Z)
                                column labeled “United States
                                (Maximum output power with
                                up to 6 dBi antenna gain)
                                (mW)”



No power limit shown            In the row labeled           AGREE (GEN: 2009-11-16     EDITOR
                                “5.470–5.725 “insert “250    12:23:41Z)
                                (12.5 mW/MHz)” in the column
                                labeled “United States
                                (Maximum output power with
                                up to 6 dBi antenna gain)
                                (mW)”
This document explains in its Provide redlines for the      OUT OF SCOPE (EDITOR:           EDITOR
abstract "This revision         changes which are made in   2009-08-06 08:12:09Z) - This
specifies technical corrections this revision document.     comment is out of scope
and clarifications to IEEE Std                              because it does not relate to
802.11 for                                                  the contents of the draft being
wireless local area networks                                balloted (i.e. it does not
(WLANS) as well as                                          propose any change to that
enhancements to the existing                                draft).
medium access
control (MAC) and physical                                  Please also see the resolution
layer (PHY) functions."                                     of comment 1208.
However there are no
indications of the previous
state of the standard or what
"technical corrections and
clarifications" have been
introduced in this revision to
the standard. I do not believe
this document is ready to be
balloted in this state.

This document explains in the Provide redlines for the      OUT OF SCOPE (EDITOR:           EDITOR
Introduction "In addition, this changes which are made in   2009-08-06 08:12:09Z) - This
revision specifies technical    this revision document.     comment is out of scope
corrections and clarifications                              because it does not relate to
to IEEE Std 802.11 as well as                               the contents of the draft being
enhancements…" However,                                     balloted (i.e. it does not
there are no indications of the                             propose any change to that
previous state of the standard                              draft).
or what "technical corrections
and clarifications" have been                               In reply to the commenter:
introduced in this revision to
the standard. I do not believe                              This project is a revision of
this document is ready to be                                802.11. There is no
balloted in this state.                                     requirement during initial
                                                            balloting of a revision draft to
                                                            provide a redline to the
                                                            previous revision.

                                                            Draft 1.0 comprises the IEEE
                                                            STD 802.11-2007 standard
                                                            plus amendments IEEE STD
                                                            802.11k-2008, IEEE STD
                                                            802.11r-2008 and STD
                                                            802.11y-2008 plus changes
                                                            approved by TGmb as
                                                            documented in 11-09/1127r20.
                                                            There are incremental redlines
                                                            in the 802.11 members area
                                                            showing the following steps:
                                                            1. Incorporation of .11k
                                                            2. Incorporation of .11r
                                                            3. Incorporation of .11y
                                                            4. Incorporation of changes
Figure 7-73 and Table 7-73             Address how the current IEEE-     DISAGREE                      EDITOR
Only allow for 3 octet                 RAC assigned longer OUI           (ARCHITECTURE: 2009-11-
organization identifiers. Within       based organization identifiers    17 22:41:23Z) This is
the OUI identifier space, the          are to be supported so that the   addressed by TGp when it is
IEEE-RAC have been issuing             "entity that has defined the      rolled in.
OUI based identifiers to               content of the particular
organizations that are longer          Vendor Specific information
than 3 octets, specifically the        element" can be identified.
IAB (36 bits long) and OUI-36          (see also general comment by
(36 bits long). (see also              same commenter for more
general comment by same                information)
commenter for more
information)

 Within the OUI identifier             Address how the current IEEE-     DISAGREE                      EDITOR
space, the IEEE-RAC have               RAC assigned longer OUI           (ARCHITECTURE: 2009-11-
been issuing OUI based                 based organization identifiers    17 22:41:23Z) This is
identifiers to organizations that      are to be supported so that the   addressed by TGp when it is
are longer than 3 octets,              "entity that has defined the      rolled in.
specifically the IAB (36 bits          content of the particular
long) and OUI-36 (36 bits              Vendor Specific information
long). The OUI cannot in               element" can be identified.
itself identify the "the entity that   (see also general comment by
has defined the content of the         same commenter for more
particular Vendor Specific             information)
information element".

The bit ordering for the OUI is Add "The order of the                    AGREE IN PRINCIPLE            EDITOR
not specified.                  organizationally unique                  (ARCHITECTURE: 2009-11-
                                indentifier (OUI) field follows          17 22:59:05Z) See CID 1429
                                the ordering convention for              for proposed change
                                MAC addresses from 7.1.1
                                (Conventions)."




Figure 7-73 and Table 7-73             Address how the current IEEE-     DISAGREE                      EDITOR
Only allow for 3 octet                 RAC assigned longer OUI           (ARCHITECTURE: 2009-11-
organization identifiers. Within       based organization identifiers    17 22:41:23Z) This is
the OUI identifier space, the          are to be supported so that the   addressed by TGp when it is
IEEE-RAC have been issuing             "entity that has defined the      rolled in.
OUI based identifiers to               particular vendor specific
organizations that are longer          action" can be identified. (see
than 3 octets, specifically the        also general comment by
IAB (36 bits long) and OUI-36          same commenter for more
(36 bits long). The OUI                information)
cannot in itself identify the "the
entity that has defined the
content of the particular
Vendor Specific information
element".
The bit ordering for the OUI is Add "The order of the               AGREE IN PRINCIPLE           EDITOR
not specified.                  organizationally unique             (ARCHITECTURE: 2009-11-
                                indentifier (OUI) field follows     17 22:59:05Z) See CID 1429
                                the ordering convention for
                                MAC addresses from 7.1.1
                                (Conventions)."

Within the OUI identifier         Address how the current IEEE-     AGREE IN PRINCIPLE (GEN: EDITOR
space, the IEEE-RAC have          RAC assigned longer OUI           2009-09-22 22:04:14Z)Agree
been issuing OUI based            based organization identifiers    in Principle -- P802.11p
identifiers to organizations that are to be supported so that the   addresses this. The current
are longer than 3 octets;         organizations can be uniquely     plan of Record is that TGp
specifically the IAB (36 bits     defined. One possible option      would be finished in time for
long) and OUI-36 (36 bits         is proposed in P802.11pD7.0       inclusion into RevMB. Doc
long), where the first 24 bits of where OUI in sections 7.3.2.26    09/98r8 is the proposal made
each are an OUI allocated         and 7.4.5 is replaced by          to TGp. (note that we could
back to the IEEE-RA for the       Organization Identifier, which    include Doc 09/98r8 now but
purpose of creating IAB or OUI- is a new field defined in           when TGp is rolled in, any of
36 identifiers. This results in   7.3.1.21 to be a public unique    the changes we make may be
multiple organizations sharing organization identifier              subtly different in TGp and
the same OUI value, with the assigned by the IEEE, and is a         possibly overwrite any TGmb
last 12-bits of the IAB or OUI- variable length field, minimum      changes made early).
36 distinguishing between the 3 octets, which contains the
organizations that have the       organizationally unique
same first 24 bits in the         identifier, and follows the
identifier. A means is needed ordering convention for MAC
so that the unique organization addresses from 7.1.1. This
can be identified. This has       field can therefore take the
impact also to P802.11p,          form of an OUI, OUI-36 or IAB
P802.11u & P802.11v.              assigned by the IEEE. The
                                  first 3 octets always contain
                                  the OUI portion allowing a
                                  receiving STA to interpret
                                  whether the field contains an
                                  OUI, an OUI-36 or an IAB, or
                                  in the case of legacy STAs
                                  ignore the information
                                  including the vendor defined
                                  fields since the OUI will not
Typo                              Replace “the receive frame”
                                  match one it can support.         AGREE (EDITOR: 2009-07-03 EDITOR
                                  with “the received frame”.        12:59:36Z)
Annex J defines regulatory         Specify how 802.11 frames        AGREE IN PRINCIPLE (GEN: EDITOR
classes for a subset of regions    that include Regulatory Class    2009-11-16 12:27:36Z) -
(US, Europe, Japan). In            octet are to be used in places   Accept in Principle based on
theory, providing information      outside the three regions (US,   discussion and editorial
only for some regions in           EU, JP) defined in Annex J or    instructions in 09/1111r2: CIDs
802.11 seems reasonable.           make Annex J define              1054, 1055, 1059, 1205 and
However, the way that              regulatory classes for all       1216;
regulatory classes are now         countries.                       https://mentor.ieee.org/802.11/
used in couple of frames and                                        dcn/09/11-09-1111-02-000m-
will be used in future                                              lb149-proposed-regulatory-
amendments introduce a                                              comment-resolutions.doc.
serious limitation to the
applicability of the standard in
major areas like China,
Australia, South America,
Africa, and so on.
Furthermore, the way that the
regulatory class numbers are
defined by using a separate
numbering space for each
region can make it difficult to
use this number with a
channel number as an
identifier for a channel since
STAs would always need to
know in which region they are
(which may or may not be that
clear depending on whether
there are Beacon frames
available with Country IE).

"is set to TRUE" appears many make the upper/lower case             AGREE IN PRINCIPLE                  EDITOR
places, and "is true" appears "true" vs "TRUE" vs "True"            (EDITOR: 2009-07-30
many others.                  consistent throughout the             13:05:59Z) - For the
                              document. Make the "is set to"        capitalization issue - please
                              vs "is" consistent throughout         see response to CID 1535.
                              the document.
                                                                    Replace "is set to", "is set to a
                                                                    value", or "has the value of"
                                                                    with "is" in a conditional phrase
                                                                    (usually related to a MIB
                                                                    variable).

                                                                    Replace "if set to" with "if" in
                                                                    conditional phrases.
                                                                    Otherwise, remove "set to"
                                                                    where used as part of a
                                                                    conditional phrase.
                                                                    Reword as necessary to
                                                                    preserve syntax.
"is present within Association     change "withing Association      AGREE (EDITOR: 2009-07-01 EDITOR
Request frames only                Request frames only              16:12:34Z)
generated by STAs that have"       generated by STAs that have"
doesn't match wording agreed       to "if".
in 0433r1
"is present when" doesn't         change "when" to "if". Make       AGREE IN PRINCIPLE             EDITOR
match wording agreed in           similar changes throughout        (EDITOR: 2009-07-01
0433r1                            document, matching the style      16:17:36Z)
                                  given in 0433r1..                 Change any "present when" to
                                                                    "present if" that occur during
                                                                    "presence tables". There is
                                                                    one occurance in clause 7 and
                                                                    one in clause 10.

extraneous line break betweenremove extraneous line break AGREE (EDITOR: 2009-07-01 EDITOR
"MDIE" and "(i.e.,"                                        16:19:37Z)
Second sentence starts "This change to "These information AGREE IN PRINCIPLE               EDITOR
information element", but    elements", here and for the   (EDITOR: 2009-07-01
"This" refers to "One or moreVendor Specific rows          16:29:32Z) - Change cited
vendor-specific information  throughout                    sentence to "These
elements" (plural)                                         information elements follow all
                                                           other information elements."
                                                           throughout.
"If dot11RSNAEnabled is set change to "Fast bss transition AGREE IN PRINCIPLE              EDITOR
to TRUE fast BSS transition  and RSN are present if        (EDITOR: 2009-07-01
and RSN are present" doesn't dot11RSNAEnabled is set to 06:47:31Z)
follow agreed style in 433r1 TRUE." Similar changes        Change cited text to: "The
                             throughout Table 7-17.        Fast BSS Transition and RSN
                                                           information elements are
                                                           present if dot11RSNAEnabled
                                                           is set to TRUE.

                                                                    Make similar changes
                                                                    throughout Table7-17.

hanging paragraph                 insert a new subheading           AGREE IN PRINCIPLE        EDITOR
                                  7.4.8.0a with appropriate title   (EDITOR: 2009-07-02
                                                                    10:58:09Z)
                                                                    Add subclause heading
                                                                    "General"
numerous blank pages here to      as in comment                     AGREE (EDITOR: 2009-07-02 EDITOR
delete                                                              11:02:51Z)
"between Message 1 and            change "of a 4-Way                AGREE (SECURITY: 2009-07- EDITOR
Message 3 of a 4-Way              Handshake" to "of the             14 21:53:52Z)
Handshake." but the phrase        handshake"
should include the FT 4-Way
Handshake added earlier in
the sentence.
footnote duplicates the           delete this footnote; it was      AGREE (EDITOR: 2009-07-02 EDITOR
information given in footnote 8   included in the published         11:12:36Z)
on page 4                         802.11r as it was the first
                                  reference to Annex P, but not
                                  needed in the rollup. Also the
                                  footnote on page 4 should
                                  refer to Annex 0A, not P.

unclear whether normative         make the statements               AGREE IN PRINCIPLE              EDITOR
"shall" is neede here, or         consistent. In either case,       (SECURITY: 2009-07-14
whether a simple declarative      insert a hyphen into SHA-256      21:54:21Z)
statement "SHA-256 is as                                            Replace "SHA256 shall be as
defined in …" matching the                                          defined in" with "SHA-256 is as
style of the surrounding                                            defined in"
statements is sufficient
Inconsistent wording, "The first- make consistent. My             AGREE IN PRINCIPLE                EDITOR
level FT key hierarchy key…" preference is "The first-level       (EDITOR: 2009-07-02
(306.13), "The second-level       key in the FT key hierarchy…"   13:10:47Z)
key in the FT key hierarchy…" etc.                                Change initial phrase of
(307.4) and "The third level of                                   8.5.1.5.3-5 to match: "The first-
the key hierarchy" (307.32)                                       level key in the FT key
                                                                  hierarchy,"
footnote duplicates the            delete this footnote; it was   AGREE (EDITOR: 2009-07-02 EDITOR
information given in footnote      included in the published      13:12:17Z)
11 on page 7                       802.11r as it was the first
                                   reference to Clause 2, but not
                                   needed in the rollup
lines in upper left corner of      make straight instead of wavy UNRESOLVABLE (EDITOR: EDITOR
Figure 11-7 appear drunk.                                         2009-07-03 14:23:26Z)
                                                                  I haven't done anything to fix
                                                                  this, but in the source for the
                                                                  figure, the .wmf it produces,
                                                                  the frame-maker window and a
                                                                  trial print of clause 11, the
                                                                  innebriated lines did not make
                                                                  an appearance.

                                                                  So I can't do anything to fix it,
                                                                  because I can't reproduce the
                                                                  problem.

dot11FTOver-DSEnabled              drop hyphen here               AGREE (SECURITY: 2009-07- EDITOR
doesn't have the hyphen in                                        14 21:55:15Z)
MIB

some space is needed         add space, here and                  AGREE IN PRINCIPLE             EDITOR
between the message          throughout 11A                       (EDITOR: 2009-07-22
endpoint identifiers and the                                      10:02:30Z)
message contents, "STA-                                           Ensure each such occurance
>AP:<spaces/tab>Authenticati                                      consists of one space followed
on-Request…"                                                      by one tab after the colon.

The "Data(…)" notation came        drop "Data(" and ")" from these AGREE (SECURITY: 2009-07- EDITOR
from an early draft of 11i; it     four entries, and drop the note 14 21:55:47Z)
was dropped before                 at line 61
publication of 802.11i and
never appeared in REVma, but
was only caught in 11r at
publication time (too late).
entries in middle column of this   as in comment                  AGREE (EDITOR: 2009-07-22 EDITOR
table should follow the                                           10:21:53Z)
guidelines in 0433r1
update Chair's name and            as in comment                  AGREE (EDITOR: 2009-07-23 EDITOR
contact information                                               13:24:03Z)

update Editor's contact            as in comment                  AGREE IN PRINCIPLE            EDITOR
information                                                       (EDITOR: 2009-07-23
                                                                  13:24:37Z)
                                                                  Update email, remove
                                                                  address and telephone details
                                                                  as these are subject to
                                                                  change.
Comment forwarded, on          A discussion needs to occur,    OUT OF SCOPE (MAC: 2009- EDITOR
behalf of TGu, from TGu letter as to which clause deals with   07-14 21:27:47Z) - This is an
ballot LB148                   "rate limiting" as opposed to   issue with the TGu
                               "LLC" beahviour. There is       amendment which is not part
TGu rejected the following     some sympathy within TGu,       of REVmb draft 1.0.
comment (TGu CID #6034) as that some of the behaviour
it appeared to be a more       within clause 6.2.1 be moved
general issue with the base    to clause 9.
standard.

===

I have comment about
removing rate limiting from
6.2.1.2 which is rejected (in
TGu) with reason "This same
question also came up during
LB132 (see CID #421, 422 in
11-08-0722r27)". TGu, with
advice from WG vice-chair,
agreed that this clause is the
proper place for the text. The
text describes new behavior
for the primitive which is
responsible for sending data
frames from a STA to a peer
STA--the MA-Unitdata.request
primitive. TGu is not aware of
any other clause in IEEE
802.11 which is more
appropriate."

Let meappears to why putting A discussion needs to occur,
There show you be some                                         AGREE IN PRINCIPLE             EDITOR
inconsistency in the way that to decided which of these two    (EDITOR: 2009-07-29
octet and bit fields are drawn "styles" is appropriate.        14:17:04Z)
in figures such as Figure 7-95                                 Please see resolution of CID
and Figure 7-95a, although                                     1248, which attempts a
this is not restricted to these                                systematic improvement in
two figures alone. It appears                                  consistency.
that two drawing styles have
converged into this single
document.
Can the MIBs in Annex D and     Compile and correct any errors AGREE IN PRINCIPLE           EDITOR
Annex Q be compiled (or         in Annex D and Annex Q.        (EDITOR: 2009-08-04
processed by a MIB syntax                                      16:16:01Z) - Make changes as
checker), to ensure that the                                   shown in document 11-
MIB can be used.                                               09/0921r1. These result in a
                                                               combined MIB that compiles
                                                               without errors or warnings.

                                                                Note, this necessitated
                                                                renumbering
                                                                dot11RegulatoryClassGroup
                                                                (dot11Groups 29) to avoid
                                                                collision with
                                                                dot11RSNSMKcachingGroup.



                                                                Also correct any references
                                                                outside Clause Q from
                                                                "dot11RMStatisticsMeasaurem
                                                                entEnabled" to
                                                                "dot11RMStatisticsMeasureme
                                                                ntEnabled".
Spot the commentor who          1) I suggest that the annexes   DISAGREE (EDITOR: 2009- EDITOR
started his review with the     should be all clearly marked    07-27 08:03:47Z)
annexes !                       normative/informative (and
                                useless if you really have to). Please see resolution of
1) The annexes have built up Then order them with                 comment 1116.
over time to be many and        normative first and informative
varied. They also fall into 4   last, e.g. A, I, J, D, Q and then
classes: normative,             the informative ones.
informative, <blank> and
useless(Annex C).               2) Annex 0A should be re-
    Please can the annexes be named annex R (or annex S to
re-arranged into some sort of avoid the R=Bibliography, as
order - see column to right for opposed to R=Reference
a suggestion.                   confusion) and put at the end.

2) Annex 0A appears to be a
bit lost and needs a name
change - see column to right
for a suggestion
I think annex C has outstayed   Please remove this Annex, as    DISAGREE (EDITOR: 2009-        EDITOR
its welcome at the IEEE         it should not be present in a   09-23 18:50:52Z) - See
802.11 party.                   professional standards          comment resolution of CID
                                document any longer.            1369.
Ho, ho, another annex trying to Please remove this Annex, as    AGREE IN PRINCIPLE             EDITOR
keep its foot in the door.      it should not be present in a   (EDITOR: 2009-07-24
                                professional standards          08:40:20Z)
                                document any longer.            Add editor's note explaining
                                                                this will be removed in due
                                                                course.

                                                                Note to commenter - this
                                                                annex will be removed when
                                                                the major renumbering
                                                                exercise is performed,
                                                                probably serveral WG ballot
                                                                cycles in to the future.
Annex I and Annex J do           Adding a reference to Annex I    AGREE IN PRINCIPLE (GEN: EDITOR
provide some assistance with    and J at this point may be        2009-11-18 01:53:43Z) - The
country specific issues.        useful for the country specific   Editor will fix the hanging
                                requirements sentence.            paragraph at 5.1a. The editor
                                                                  shall delete the last two
                                                                  sentances in that paragraph
                                                                  (the hanging one).
Replace the phrase "station-to- Change to "STA-to-STA"            DISAGREE (EDITOR: 2009- EDITOR
station"                                                          07-01 12:52:03Z)
                                                                  There are no occurances of
                                                                  STA-to-STA and 19
                                                                  occurances of station-to-
                                                                  station in the standard.

                                                              STA and station are
                                                              synonyms. Therefore the
                                                              change does not correct an
                                                              error, and introduces
                                                              inconsistency.
I think the words "space" and   Change "space" to "location" AGREE IN PRINCIPLE                 EDITOR
"location" imply the same       to maintain consistency. Then (EDITOR: 2009-07-01
entity here. Clause 5.2.4       perhaps change the result of 12:56:03Z)
further confuses this issue by  this to "area".               Change cited space to
stating that "area" should be                                 "location".
used P36L28.
A reference to Annex I or J     Add a reference to Annex I        AGREE IN PRINCIPLE            EDITOR
may be appropriate here. This and/or J to indicate more           (SECURITY: 2009-07-14
also applies to clause 5.4.4.2. information is available for      21:56:08Z)
                                country radio regulations.         Update the first sentence of
                                                                  Clause 5.4.4 as follows:
                                                                  "Two services are required to
                                                                  satisfy requirements in some
                                                                  regulatory domains ( See
                                                                  Annex I and Annex J for more
                                                                  information) for operation in
                                                                  the 5 GHz band."



Comment forwarded on behalf Consider all occurances of            DISAGREE                      EDITOR
of TGu:                         OUIs in the document and          (ARCHITECTURE: 2009-11-
                                decide whether they should be     17 22:41:23Z) This is
Recent work in TGp, has         adapted to be either 3 or 5       addressed by TGp when it is
shown that the length of OUIs octet versions.                     rolled in.
is no longer 3 octets, as the
IEEE now caters for 5 octet
long values to be shared over
multiple organizations (OUI-
36/IAB). Hence all references
to OUIs should now consider
the new extended 32 bit (5
octet) version and even the
EUI 48 bit varient
<http://standards.ieee.org/rega
uth/oui/tutorials/EUI48.html>
Figures 7-76 and 7-77 have    Determine which style is         AGREE IN PRINCIPLE           EDITOR
inconsistent styles on the    consistent and change all        (EDITOR: 2009-07-29
Octets row, one using arrows, figures accordingly.             14:16:20Z) - This was
the other not.                                                 analysed in 11-09-0714 and
                                                               discussed in the July 2009
                                                               TGmb meeting. The
                                                               consensus of the meeting was
                                                               to improve consistency by
                                                               replacing the arrowed styles
                                                               with non-arrowed ones,
                                                               except where arrows are used
                                                               to indicate/span structure.

                                                               For octet-aligned structures,
                                                               use single ruling. "Octets:" in
                                                               plain text.
                                                               Redraw figures:
                                                               7-37, 7-38, 7-39, 7-40, 7-41, 7-
                                                               42, 7-43, 7-44, 7-45
                                                               7-51, 7-73, 7-77, 7-78, 7-79, 7-
                                                               82, 7-85, 7-86, 7-87, 7-88, 7-
                                                               89, 7-90, 7-91, 7-92, 7-93, 7-
                                                               95
                                                               7-95o11, 7-95o13, 7-95o14, 7-
                                                               101h1, 7-101h2, 7-101h3, 7-
                                                               101h4, 7-101h5, 7-101h6, 7-
                                                               101h8
                                                               Adjust any other figures
                                                               already in this style for
                                                               consistency.

                                                               Convert figures using a
Figures 7-76 and 7-77 have      Determine which style is       mixture of octet/bit notation to
                                                               AGREE IN PRINCIPLE                 EDITOR
inconsistent styles regarding   consistent and change all      (EDITOR: 2009-07-02
the value of the Element ID.    figures accordingly.           07:58:09Z)
One includes this in the                                       Remove any such values
diagram (Figure 7-77) whilst                                   embedded values.
the other includes the value in
the text P183L62.                                              These occur in: BSS Load,
                                                               EDCA Parameter Set, TSPEC,
                                                               TCLAS, TS Delay, TCLAS
                                                               Processing, Schedule and
                                                               QoS Capability elements.

The abbreviation US is not     Add US "United States" as an    AGREE IN PRINCIPLE                 EDITOR
defined. Additionally, the     abbreviation. Replace U.S.      (EDITOR: 2009-07-22
abbreviation U.S. is           with US throughout the          09:46:49Z) - There are 15
sometimes used, e.g. P40L64    document, although this cause   occurances of U.S. and 5 of
                               problems with some of the       US in the draft.
                               normative reference footnotes   Furthermore there are 3
                               on page 3                       occurances of U.S. and none
                                                               of US in the 2009 style
                                                               guide.

                                                               For consistency change all
                                                               "US" to "U.S.".
The GTK is wrapped in the       Correct the If value 2 refers to   AGREE IN PRINCIPLE               EDITOR
FTIE. It's length should be 16- the wrapped GTK, its range         (ARCHITECTURE: 2009-07-
43. It is wrapped (with AES)    should be changed to 35-51.        19 02:33:25Z) Make several
there is an extra 8 octet to                                       changes:
make the range 24-51. The                                          1. In Table 7-43g, change
field must include the padding.                                    "contents of data field" for
                                                                   value 2 from "GTK" to "GTK
                                                                   subelement"
                                                                   2. In Table 7-43g, change
                                                                   length of data field for value 2
                                                                   from "15-42" to "35-51"
                                                                   3. In Figure 7-95o6, change
                                                                   name of field "Key" to
                                                                   "Wrapped Key"
                                                                   4. In Figure 7-95o6, change
                                                                   length of Wrapped Key field to
                                                                   24-40 octets.
                                                                   5. In between the paragraphs
                                                                   at 212.28 and 212.31, before
                                                                   the paragraph beginning
                                                                   "When sent by a non-AP
                                                                   STA,...", add a new paragraph
                                                                   reading: "The Wrapped Key
                                                                   field contains the encrypted
                                                                   GTK as described in 11A.8.5."




During the FT-Initial             Add reason codes in Table 7- AGREE (ARCHITECTURE:              EDITOR
Association, there are cases      22 for:                         2009-11-18 20:25:09Z)
where the STA can give            - Invalid FT Action frame count
feedback to the AP on failed      - Invalid pairwise master key
FT attempts. There should be      identifier (PMKID)
reason codes added to table 7-    - Invalid MDIE
22 to allow the STA to            - Invalid FTIE
communicate errors to the AP.

The Length field does not exist   Remove the sentence              AGREE (ARCHITECTURE:          EDITOR
in this IE. Therefore this        beginning with "The Length       2009-07-16 06:15:19Z)
description does not exist.       field equals …."
This looks like an important      Either add a statement that   AGREE IN PRINCIPLE            EDITOR
place to state that WEP and       TKIP and WEP are              (SECURITY: 2009-08-14
TKIP are deprecated.              deprecated in this clause, or 15:54:24Z)
                                  refer to clause 6.1.2.        Take the text that appears in
                                                                the last two paragraphs of
                                  Alternative, move the         Clause 6.1.2 and copy them to
                                  statement that WEP and TKIP end of Clause 8.1.0a.
                                  are deprecated to this clause
                                  and add a reference in clause
                                  6.1.2.
The 4-way handshake is also        Add the following text after the AGREE (SECURITY: 2009-07- EDITOR
used for FT Initial Association.   first paragraph.                 14 21:58:31Z)
It would be beneficial to add      "The FT Initial Mobility Domain
some text and a cross-             Association uses the FT 4-way
reference to clause 11A.4.2.       handshake to establish an
                                   initial FT Security Association,
                                   that is based on this protocol.
                                   The FT 4-way handshake
                                   protocol is described in Clause
                                   11A.4."

The paragraph states that if       Clarify the use of AP Channel    AGREE IN PRINCIPLE            EDITOR
the Channel Number field is        Report in the Beacon Report      (SECURITY: 2009-09-22
255, the STA conducts              as follows:                      05:57:26Z)
measurements on all channels       1) If the Channel Number Field   Changes as given in
included in the AP Channel         is 0, the STA shall use uses     document 11-09/982r2.
Report. However it does not        the regulatory domain
indicate where the STA             information.
receives the Channel Report (I     2) If the Channel Number Field
assume the Beacon). In the         is 255, the STA uses the AP
next paragraph, the text states    Channel report sub-element(s)
that an optional Channel           (if included) or the last AP
Report sub-element can be          Channel Report IE received in
used to supply a list of           the last Beacon frame.
channels in the Beacon             3) If the Channel Number Field
Report.                            specifies any other channel
                                   number, the STA will generate
                                   a Beacon Report response
                                   using that channel number.

                                   I can prepare a submission to
                                   clean up the last paragraph on
                                   pg 644 and first two
                                   paragraphs on pg. 645.


FT-Transition-Auth (R1KH-ID)       Move "FT-Transition-Auth         AGREE (SECURITY: 2009-07- EDITOR
to CALC-PMK_R1 S0KH SM             (R1KH-ID) to CALC-PMK_R1         14 21:58:54Z)
occurs too early. The              S0KH SM" to the FT-PTK-
supplicant may not know the        CALC state, after the
R1KH-ID at this point so it        Reassociationdeadlinetimer.
cannot calculate the PMK-R1.

It would be beneficial to          Change the text from:            AGREE IN PRINCIPLE            EDITOR
include the RFC reference as       "defined by FIPS SP800-38B"      (SECURITY: 2009-11-06
well as the FIPS publication       to:                              16:07:28Z) -
reference.                         "defined by FIPS SP800-38B       Change the text as proposed
                                   and also found in RFC 4493."     and add an inormative
                                   and add RFC 4493 to the          reference to RFC 4493.
                                   references.
The "Key Length field" in the    Key Length field is the actual       AGREE IN PRINCIPLE             EDITOR
description is ambiguous.        length of the Key field in           (ARCHITECTURE: 2009-07-
                                 octets.                              16 06:15:51Z) It seems pretty
                                                                      clear, with the next sentence.
                                                                      But, if change is desired, the
                                                                      proposed change doesn't
                                                                      really help much. Need to
                                                                      combine the two sentences:
                                                                      Change to, "The Key Length
                                                                      field is the length of the Key
                                                                      field in octets, not including
                                                                      any padding (see 11A.8.5)."

The RSN IE in message 2 of       Modify the text as follows:          AGREE IN PRINCIPLE                  EDITOR
the FT Intial Association will   2) If the MIC is valid, the          (SECURITY: 2009-08-14
not bitwise match the RSN IE     Authenticator checks that the        16:05:32Z)
used in the Reassociation        RSN information element bit-         Change clause 8.5.3.2 b) 2) on
Request.                         wise matches that from the           page 320, line 23 as follows:
                                 (Re)Association Request              Change "If the MIC is valid," to
                                 message. For FT Intial               "If the MIC is valid and it is part
                                 Association, the RSN IE              of a Fast BSS-Transition Initial
                                 cannot be bit-wised compared         Mobility Domain Association,
                                 because the PMKR1Name will           see 11A.4.2. If the MIC is valid
                                 be included in the RSN IE field      and it is not part of the Fast
                                 as part of Message 2. In that        BSS-Transition Initial Mobility
                                 case, the remainder of the           Domain Association,"
                                 RSN IE in message 2 is
                                 checked against the RSN IE
                                 included in the Reassociation
                                 Request.
                                 i) If these are not exactly the
                                 same, the Authenticator uses
                                 MLME-DEAUTHENTICATE.
                                 request primitive to terminate
                                 the association.
                                 ii) If they do match bit-wise, the
                                 Authenticator constructs
                                 Message 3.
The RSN IE in message 3 of         Modify the text as follows:        AGREE IN PRINCIPLE                 EDITOR
the FT Intial Association will     Verifies the RSNIE. If it is not   (SECURITY: 2009-08-14
not match the RSN IE used in       identical to that the STA          16:15:34Z)
the Beacon or Probe                received in the Beacon or          Modify Clause 8.5.3.3 a) on
Response.                          Probe Response frame, the          page 321 line 49 as follows:
                                   STA shall disassociate. For FT     Change: "If it is not identical"
                                   Initial Association, the RSN IE    to "If it is part of a Fast BSS-
                                   will differ from the RSN IE in     Transition Initial Mobility
                                   Beacon and Probe Response          Domain Association, see
                                   messages becuse it will            11A.4.2. Otherwise if it is not
                                   contain the PMKR1Name in           identical"
                                   the PMKID field. For FT Initial
                                   Association, the PMKID field is
                                   ignored in the RSN IE
                                   comparison. If a second RSN
                                   information element is
                                   provided in the message,the
                                   Supplicant uses the pairwise
                                   cipher suite specified in the
                                   second RSNIE or
                                   deauthenticates.

The description of the             Modify the text as follows:        DISAGREE                           EDITOR
Management Count field is          The Measurement Count field        (ARCHITECTURE: 2009-07-
confusing. It would be better to   contains a number of MSDUs.        16 06:16:42Z) Commenter's
not provide text in this sub-      This value is used to calculate    proposal is same as current
clause and rely on the             an average discard count for       text?
description in Clause 11.          the Average trigger condition.
                                   It is also used in place of
                                   measurement duration in
                                   determining the scope of the
                                   reported results when a report
                                   is triggered; see 11.10.8.8
                                   (Transmit Stream/Category
                                   Measurement Report).


It makes sense that the            Modify the first sentence of the   AGREE (SECURITY: 2009-07- EDITOR
Measurement Count field            paragraph as follows:              14 21:59:54Z)
would be interpreted as the the    Traffic stream metrics reported    Note only "successfully and
total of successfully and          in a triggered transmit            unsuccessfully" was added to
unsuccessfully transmitted         stream/category measurement        the sentence.
MSDU's. The current text is        report shall be the values
ambiguous.                         accumulated over the number
                                   of successfully and
                                   unsuccessfully transmitted
                                   MSDUs prior to the trigger
                                   event given in the
                                   Measurement Count field of
                                   the transmit stream/category
                                   measurement request that
                                   established the trigger
                                   condition.
802.11mb D1.0 is 1602 pages       Now is the time to delete large    AGREE IN PRINCIPLE (GEN: EDITOR
long. Much of the text is         sections of text, particularly     2009-09-22 07:15:02Z) -
obsolete, useless and poorly      those self contained sections      Agree in Prinicple: TGmb is
written                           are obsolete.                      processing comments to
                                                                     address "obsolete, useless
                                  Ideally all obsolete features will and poorly written" sections of
                                  be removed. Unfortunately,         the draft. Each Comment
                                  many obsolete features are         submitted shall have due
                                  too intertwining with useful       diligence done to determine
                                  features, eg PCF                   the best response and
                                                                     disposition. No specific
                                                                     change requested, but the new
                                                                     draft will be an improvement.

There have been suggestions Do not add any new non trivial             UNRESOLVABLE (GEN: 2009- EDITOR
that the revision process   functionality to the standard in           09-22 07:13:29Z)
should be used to add new   TGmb                                       Unresolvable: Comment does
features to the standard.                                              not address the draft under
                                                                       consideration. No Specific
However, new features should                                           change to the draft requested.
only be added when supported                                           TGmb is processing
by a fully developed and                                               comments to address all
validate set of market                                                 sections of the draft. Each
requirements.                                                          Comment submitted shall
                                                                       have due diligence done to
This is a function that is much                                        determine the best response
better considered in a SG                                              and disposition. No specific
                                                                       change requested.

Clause 10 has virtually no        Reduce clause 10 to a few            DISAGREE                       EDITOR
value because all the material    pages that describes the             (ARCHITECTURE: 2009-07-
is (or should be ) covered        MLME structure and the               15 03:25:14Z) There are
elsewhere in the standard.        interfaces in very general           normative dependencies on
Worse, too much time is spent     terms and notes that it is left to   this clause. These are the
developing clause 10 which        the implementor to determine         bones of the architecture, and
almost no one reads, even         the details.                         are needed to support the rest
during the ballot process                                              of the normative text. The
                                                                       behavior defined based on
                                                                       these interfaces is not
                                                                       intended to be implementation,
                                                                       but is meant to be the
                                                                       structure for describing
                                                                       important behavior, and helps
                                                                       focus on one part of the whole
                                                                       of an 802.11 STA. The
                                                                       Standard needs to define end-
                                                                       point behavior, too, not just
                                                                       over-the-air protocol.
The IR PHY clause is obsolete Remove it      AGREE IN PRINCIPLE (GEN: EDITOR
                                             2009-09-23 23:53:20Z)Agree
                                             in Principle -- Mark the IR PHY
                                             as obsolete and subject to
                                             removal in a future revision:
                                             instruct the editor to insert the
                                             following line at the beginning
                                             of clause 16:"This clause is
                                             obsolete and is subject to
                                             removal from a future
                                             revision."




The SDL spec has almost no       Remove it   DISAGREE (EDITOR: 2009-     EDITOR
connection to the current                    09-23 18:51:35Z) - See
standard - and it is full of                 comment resolution of CID
errors                                       1369.




The procedure to select a new Remove it      DISAGREE (SECURITY: 2009- EDITOR
channel in an IBSS is only                   07-14 21:35:44Z)
claimed to be "best effort" at               The proposed change may
best. At worst, it may not even              make existing 802.11 devices
work.                                        non-compliant with the
                                             standard. The comment has
The reality is that after 5+                 not justified the change.
years there is no known
implemenation of this feature,
indicating it is unnecessary
This annex has no value as      Remove it                       DISAGREE (MAC: 2009-07-14 EDITOR
part of the standard                                            21:16:34Z) It is believed there
                                                                is value in the standard.



This annex is empty             Remove it                       AGREE IN PRINCIPLE (GEN: EDITOR
                                                                2009-09-22 07:20:33Z) see
                                                                resolution of CID 1242: Add
                                                                Editor note that this Annex will
                                                                be removed in due course.

This informative annex is no   Remove it                       AGREE IN PRINCIPLE (GEN:           EDITOR
longer relavant given the very                                 2009-09-22 07:49:57Z) Agree
small number of FH systems                                     in Principle -- Mark the FH
                                                               PHY as deprecated and
                                                               subject to removal in a future
                                                               revision Editor to add
                                                               immediately following the
                                                               clause heading the following
                                                               new paragraph: This clause is
                                                               obsolete and is subject to
                                                               removal in a future revision
This annex has no value as     Remove it                       DISAGREE (GEN: 2009-09-22          EDITOR
part of the standard                                           06:20:12Z) Annex O gives
                                                               the abstracts desription of the
                                                               DS SAP and is considered of
                                                               value.
This annex is empty            Remove it                       AGREE (GEN: 2009-09-22             EDITOR
                                                               07:19:58Z) see resolution of
                                                               CID 1242: Add Editor note that
                                                               this Annex will be removed in
                                                               due course.
FHSS is not longer in use (or Add the following subclause: AGREE IN PRINCIPLE (GEN:               EDITOR
perhaps never was). We         14.0a General                   2009-09-22 07:31:15Z) Agree
should not waste energy        This clause is no longer        in Principle -- Mark the FHSS
maintaining this clause or     maintained and may not be       PHY as deprecated and
making sure that other clauses compatible with all features of subject to removal in a future
are compatible with this       this standard.                  revision Editor to add
clause.                                                        immediately following the
                                                               clause heading the following
                                                               new paragraph: This clause is
                                                               obsolete and is subject to
                                                               removal in a future revision.
sometimes ".indicate" is used pick one and unify usage in      AGREE IN PRINCIPLE                 EDITOR
in the draft (225 times) and   the draft                       (EDITOR: 2009-07-22
sometimes ".indication" is                                     10:28:14Z)
used (300 times).                                              Change all ".indicate" to
                                                               ".indication" as this appears to
                                                               be the commonest usage.
                                                               Do not make any changes in
                                                               Annex C.
Aren't the required PHY         please clarify                          AGREE IN PRINCIPLE             EDITOR
parameters in the TXVECTOR                                              (ARCHITECTURE: 2009-11-
listed in the corresponding                                             17 21:53:13Z) change in
subclause (i.e. 17). There                                              12.3.4.4 (page 712 line 63)
seem to be more PHY                                                     "the parameter values" to "the
parameters required then                                                minimum parameter values"
identified in Table 12-4.
What's the point of table 12-4?




Aren't the required PHY     please clarify                              AGREE IN PRINCIPLE             EDITOR
parameters in the TXVECTOR                                              (ARCHITECTURE: 2009-11-
listed in the corresponding                                             17 21:50:06Z) - Editor to
subclause (i.e. 17).                                                    change 12.3.5.4.2 (page 717
                                                                        line 18) by changing "required
                                                                        PHY parameters" to "minimum
                                                                        required PHY parameters.

"The PHY maintains the              Perhaps something more              DISAGREE                       EDITOR
channel busy indication until       generic like, "… until the          (ARCHITECTURE: 2009-07-
the period indicated by the         period indicated by fields in the   16 06:56:04Z) Superseded
LENGTH field in a valid PLCP        signal signal field…"               by resolution to CID 1280.
header has expired." Its not
really just LENGTH. In Clause
17, the period is based on
RATE and LENGTH. Seeing
into the future, in Clause 20 it
will be based on lots of
parameters.
In clause 17, the PHY also          adding here all the conditions      AGREE IN PRINCIPLE             EDITOR
maintains the channel busy in       when PHY maintains channel          (ARCHITECTURE: 2009-07-
the presense of energy above        busy is too combursome. I           16 06:18:43Z) Accept
a threshold (energy detect).        suggest deleting "The PHY           deletion. Also add sentence in
This language could lead to         maintains the channel busy          its place, "Refer to specific
the misinterpretation that ED is    indication until the period         PHY clauses for details about
not being performed.                indicated by the LENGTH field       CCA behavior for a given
                                    in a valid PLCP header has          PHY."
                                    expired." and forcing people to
                                    look at the specific PHY
                                    subclauses to learn about
                                    CCA behavior.
In eq 17-1 fix the font of "<t>",                                       AGREE IN PRINCIPLE             EDITOR
it looks like a subscript                                               (EDITOR: 2009-07-23
                                                                        10:54:57Z)
                                                                        Promote <t> inline to equals
                                                                        sign
Eq 17-3 is partially cut off                                            AGREE (EDITOR: 2009-07-23      EDITOR
                                                                        10:56:09Z)
Eq 17-7 is partially cut off                                            AGREE (EDITOR: 2009-07-23      EDITOR
                                                                        10:56:44Z)
Eq 17-9 is partially cut off                                            AGREE (EDITOR: 2009-07-23      EDITOR
                                                                        10:57:10Z)
Lots of discussion took place define                      AGREE IN PRINCIPLE (GEN: EDITOR
in 11n about what was the                                 2009-11-18 19:04:47Z) -
default value of the reserve bit.                         Agree in Principle: See Doc
Confusion regarding what was                              09/1233r0 for editing
the default value lead to it not                          instructions.
being used for future use.




A bunch of acronyms in Fig 17- define unless they are already AGREE IN PRINCIPLE (GEN: EDITOR
12 are not defined: IQ, HPA,   IEEE standards terms           2009) - Agree in principle.
LNA,                                                          Add "IQ       In phase and
                                                              Quadrature" to abbreviations
                                                              Add "HPA       High power
                                                              amplifier" to abbreviations
                                                              Add "LNA       Low noise
                                                              amplifier" to abbreviations

                                                          Comment:
                                                          IQ is not in IEEE.100.
                                                          HPA is not in IEEE.100.
                                                          LNA is in IEEE.100 meaning
                                                          "launch numerical aperture"


I don't think IF is defined    define unless they are already DISAGREE (GEN: 2009-09-24 EDITOR
anywhere                       IEEE standards terms           23:18:41Z) Disagree. IF is
                                                              defined in IEEE.100.
guessing that the F in IF is   delete frequency               AGREE (EDITOR: 2009-07-23 EDITOR
frequency, then "low IF                                       10:57:47Z)
frequency" has an extra
frequency
The language here is              This section needs to be       AGREE IN PRINCIPLE (GEN: EDITOR
misleading. "If the preamble      cleaned up as described in my 2009-11-18 19:07:20Z) -
portion was missed, the           comment.                       Replace the note at the end of
receiver shall hold the CCA                                      17.3.10.5 as follows:
signal busy for any signal 20     It was also clear from 11n     Replace: "NOTE -- CCA-ED
dB above the minimum              discussions that non-802.11    can be used in bands when
modulation and coding rate        people do not understand that not required by Annex J. In
sensitivity" is energy detect     basic clause 17 functionality  these cases, the
and is part of the basic clause   requires energy detect of non- recommended CCA-ED
17 CCA mechanism. "For            802.11 systems. Perhaps a      threshold is equal to 20 dB
improved spectrum sharing,        note stating this would be     above the minimum
CCA-ED is required in some        sufficient.                    modulation and coding rate
bands..." makes it sound like                                    sensitivity (-62 dBm for 20
sometimes energy detect is                                       MHz channel spacing, -65
not performed with clause 17,                                    dBm for 10 MHz channel
which is not true.                                               spacing, and -68 dBm for 5
                                                                 MHz channel spacing)."
                                                                 with
                                                                 "NOTE--The requirement to
                                                                 hold the CCA signal busy for
                                                                 any signal 20dB above the
                                                                 minimum modulation and
                                                                 coding rate sensitivity (-62
                                                                 dBm for 20 MHz channel
                                                                 spacing, -65 dBm for 10 MHz
                                                                 channel spacing, and -68 dBm
                                                                 for 5 MHz channel spacing) is
                                                                 a mandatory energy detect
                                                                 requirement on all Clause 17
                                                                 receivers. Support for CCA-
                                                                 ED is an additional
                                                                 requirement that relates
                                                                 specifically to the sensivitities
"...PHY_CCA.indicate(BUSY)          clarify the CCA text to highlight   AGREE IN PRINCIPLE (GEN: EDITOR
shall be issued for reception of    that energy detection is            2009-11-18 19:11:09Z) Please
a signal prior to correct           performed even on non-              see the resolution to CID
reception of the PLCP               802.11 systems. Perhaps a           1289, which adds a NOTE a
frame. The PMD primitive            note is appropriate                 suggested.
PMD_RSSI is issued to update
the RSSI and parameter
reported to the MAC.

After PHY-CCA.indicate is
issued, the PHY entity shall
begin receiving the training
symbols...".

My interpretation of this text is
again that basic energy
detection is required by clause
17. That fact that this is
spread out between 17.3.6,
17.3.10.5, and 17.3.12 has
made it very difficult for non-
802.11 people to understand
that 802.11 clause 17 does in
fact require energy detection
of non-802.11 systems.



In 17.3.12 "The OFDM PHY         please clarify                         AGREE IN PRINCIPLE (GEN: EDITOR
will ensure that the CCA                                                2009-11-18 19:13:26Z) See
indicates a busy medium for                                             09/1233r0 for editing
the intended duration of the                                            instructions.
transmitted packet." and
12.3.5.10.3 "The PHY
maintains the channel busy
indication until the period
indicated by the LENGTH field
in a valid PLCP header has
expired." it makes is sound like
its required to maintain CCA
busy based on rate/lengh in
sig field. However in
17.3.2.0a, "In addition, the
CCA mechanism can be
augmented by predicting the
duration of the packet from the
contents of the RATE and
LENGTH fields, even if the
data rate is not supported by
the STA." makes is sound like
its optional. But in none of
these citations is there any
normative language.
Line 34 says that Eq 17-29    please clarify                AGREE IN PRINCIPLE (GEN: EDITOR
shall be used to compute                                    2009-09-24 23:19:57Z) Agree
TXTIME, but then line 46 says                               in principal.
the Eq. 17-30 may be used.                                  1. Replace "Ceiling(...)" with
This seems illogical to me.                                 N_SYM
Wouldn't a shall always                                     2. Remove parenthetical
supersede a may?                                            sentence on P873.41
                                                            3. Add ", according to Table
                                                            17-13" after "is derived from
                                                            the DATARATE parameter"
                                                            4. Remove lines 46-53 (i.e. "A
                                                            simplified ... T_SYM/2.")




Do any implementers even       perhaps get rid of it        DISAGREE (GEN: 2009-11-18 EDITOR
pay attention to PMD                                        02:05:08Z) While the indended
sublayer?                                                   requested outcome is clear,
                                                            the changes to achieve this
                                                            outcome are substantial and
                                                            non-obvious. The commenter
                                                            is solicited to provide the
                                                            changes in a submission.

what happens when with an    please clarify                 DISAGREE (GEN: 2009-11-18 EDITOR
invalid signal? For ERP-OFDM                                02:31:45Z) - The commentor is
do we default to clause 17                                  invited to provide more
rules?                                                      information of what is being
                                                            requested. The Clause 19
                                                            description of CCA defines
                                                            what is done with a "valid
                                                            signal" and does not describe
                                                            what is done with an "invalid
                                                            signal" in the CCA clause.

transmit masks moved back to change to "The transmit        AGREE (EDITOR: 2009-07-01 EDITOR
clause 17                    spectral mask for the ERP-     09:48:01Z)
                             OFDM modes shall follow
                             17.3.9.2 (Transmit spectrum
                             mask) and is shown in Figure
                             17-12a therein."
"MODU-LATION"                change to MODULATION           AGREE (EDITOR: 2009-07-01 EDITOR
                                                            09:49:14Z)
"MODU-LATION"                    change to MODULATION           AGREE (EDITOR: 2009-07-01       EDITOR
                                                                09:49:41Z)
"DISALBED"                       change to DISABLED             AGREE (EDITOR: 2009-07-01       EDITOR
                                                                09:50:35Z)
"inter-operability"              change to interoperability     AGREE (EDITOR: 2009-07-24       EDITOR
                                                                08:43:13Z)
there is no tx power or EIRP      add tx power or EIRP level    AGREE (GEN: 2009-11-16          EDITOR
level for US in Table I.4 for the                               12:22:19Z) - see discussion
5.47-5.725 band. It may be                                      and editorial instructions in
implied that operation in this                                  09/1111r2
band in the US is not
permitted, which is not true.




we have transmit power           pick one location and unify    AGREE IN PRINCIPLE (GEN: EDITOR
regulatory information in both   information in the draft       2009-11-16 12:26:50Z) --
Annex I (Tables I.4-6) and                                      Accept in Principle based on
Annex J (Tables J.1-3).                                         discussion and editorial
                                                                instructions in 09/1111r2:
                                                                changes noted in section for
                                                                CID1054, 1055, 1059, 1205
                                                                and 1216;
                                                                https://mentor.ieee.org/802.11/
                                                                dcn/09/11-09-1111-02-000m-
                                                                lb149-proposed-regulatory-
                                                                comment-resolutions.doc.



everywhere else in the tables,   remove the dash and write out AGREE (EDITOR: 2009-07-24 EDITOR
channel numbers are explicit     the channel number            08:52:53Z)
written
everywhere else in the tables,   remove the dash and write out AGREE (EDITOR: 2009-07-24 EDITOR
channel numbers are explicit     the channel number            08:53:40Z)
written
Make cipher suite text more     Incorporate changes from doc AGREE IN PRINCIPLE         EDITOR
general to allow for other      09/0601                       (SECURITY: 2009-09-22
ciphers to be more easily                                     01:38:24Z)
added.                                                        Make the changes given in
                                                              document 11-09/601r2
MIC calculation includes the IE Delete “Contents of the” from AGREE (SECURITY: 2009-07- EDITOR
headers.                        RSNIE, MDIE, and FTIE.        14 22:00:09Z)

MIC calculation includes the IE Delete “Contents of the” from   AGREE (SECURITY: 2009-07- EDITOR
headers.                        RSNIE, MDIE, and FTIE.          14 22:00:15Z)
Does MDID globally unique?     Add explanation       DISAGREE                        EDITOR
                                                     (ARCHITECTURE: 2009-11-
                                                     17 22:52:04Z) MDID is not
                                                     globally unique.




Table 7-57e instead of Table 7- modify accordingly   AGREE (EDITOR: 2009-07-02 EDITOR
57c                                                  10:56:20Z)
where is the other              modify accordingly   DISAGREE                        EDITOR
measurement types: Basic,                            (ARCHITECTURE: 2009-11-
CCA and RPI?                                         18 20:36:54Z) - The
                                                     commentor is encouraged to
                                                     provide more details of any
                                                     proposed improvement, but
                                                     without the details of what is
                                                     proposed, the group cannot
                                                     evaluate the technical merit at
                                                     this time.
the measurement report mode modify accordingly       DISAGREE                        EDITOR
in section 7.3.2.22 figure 7-64                      (ARCHITECTURE: 2009-07-
page 153 indicates that                              16 06:20:23Z) ChannelLoad,
latebit(0), but here it indicates                    being an RRM measurement,
a success bit?                                       cannot be "Late" per 7.3.2.22

the measurement report mode modify accordingly       DISAGREE                      EDITOR
in section 7.3.2.22 figure 7-64                      (ARCHITECTURE: 2009-07-
page 153 indicates that                              16 06:23:26Z)
latebit(0), but here it indicates                    NoiseHistogram, being an
a success bit?                                       RRM measurement, cannot be
                                                     "Late" per 7.3.2.22
the measurement report mode modify accordingly       DISAGREE                      EDITOR
in section 7.3.2.22 figure 7-64                      (ARCHITECTURE: 2009-07-
page 153 indicates that                              16 06:24:30Z) Beacon report,
latebit(0), but here it indicates                    being an RRM measurement,
a success bit?                                       cannot be "Late" per 7.3.2.22

Should dot11FrameRprtRSNI      modify accordingly    AGREE (ARCHITECTURE:            EDITOR
be dot11FrameRprtLastRSNI                            2009-07-16 06:25:30Z)
to make more consistent with
section 7.3.2.22.7 page 163
line 33 (figure 7-68g)
Should dot11FrameRprtRSNI      modify accordingly    AGREE IN PRINCIPLE              EDITOR
be dot11FrameRprtLastRSNI                            (ARCHITECTURE: 2009-11-
to make more consistent with                         16 15:54:34Z) - Change
section 7.3.2.22.7 page 163                          dot11FrameRprtRSNI to
line 33 (figure 7-68g)                               "dot11FrameRprtLastRSNI"
                                                     globally.
the measurement report mode modify accordingly       DISAGREE                        EDITOR
in section 7.3.2.22 figure 7-64                      (ARCHITECTURE: 2009-07-
page 153 indicates that                              16 06:26:03Z) Frame report,
latebit(0), but here it indicates                    being an RRM measurement,
a success bit?                                       cannot be "Late" per 7.3.2.22
the measurement report mode modify accordingly         DISAGREE                          EDITOR
in section 7.3.2.22 figure 7-64                        (ARCHITECTURE: 2009-07-
page 153 indicates that                                16 06:26:54Z) STAStatistics,
latebit(0), but here it indicates                      being an RRM measurement,
a success bit?                                         cannot be "Late" per 7.3.2.22

the measurement report mode modify accordingly         DISAGREE                          EDITOR
in section 7.3.2.22 figure 7-64                        (ARCHITECTURE: 2009-07-
page 153 indicates that                                16 06:27:49Z) LCI report,
latebit(0), but here it indicates                      being an RRM measurement,
a success bit?                                         cannot be "Late" per 7.3.2.22

It is more consistent with        modify accordingly   AGREE (ARCHITECTURE:         EDITOR
Reporting Reason field in                              2009-07-16 06:28:41Z)
Figure 7-68q, section                                  replace as noted in comment.
7.3.2.22.10 page 174 line 5 if
averageTrigger,
consecutiveTrigger and
delayTrigger are used instead
of averageError,
consecutiveError and
delayError
the measurement report mode modify accordingly         DISAGREE                     EDITOR
in section 7.3.2.22 figure 7-64                        (ARCHITECTURE: 2009-07-
page 153 indicates that                                16 06:28:57Z)
latebit(0), but here it indicates                      TransmitStream report, being
a success bit?                                         an RRM measurement, cannot
                                                       be "Late" per 7.3.2.22
table 7-43b in section 7.3.2.37 modify accordingly     AGREE IN PRINCIPLE           EDITOR
page 198 line 50 has                                   (ARCHITECTURE: 2009-11-
Measurement Pilot                                      17 22:16:52Z)change Table 7-
Transmission information                               43b from "Measurement Pilot
(refer to section 7.3.2.42)                            Transmission information" to
instead of Measurement Pilot                           "Measurement Pilot
interval (refer to section                             Transmission"
7.3.1.18)
Page 248-252, 578, 727 are      See comment.           AGREE IN PRINCIPLE                EDITOR
empty pages. Shall be deleted.                         (EDITOR: 2009-07-02
                                                       11:00:29Z)

                                                       Delete superfluous pages at
                                                       the end of Clause 7.

                                                       Note to commenter: these
                                                       pages may come back. Frame
                                                       is set to delete superflous
                                                       pages on save, but this
                                                       doesn't always appear to work,
                                                       for reasons not know to the
                                                       REVmb editor. The other cited
                                                       pages are required to allow the
                                                       following clause to start on a
                                                       right hand page, and are
                                                       deliberate.
I don’t think we need to include   1. P230l62 - P231L28 and        DISAGREE                      EDITOR
Optional Subelements field in      P232L14-L45 shall be            (ARCHITECTURE: 2009-11-
this frame to make this frame      removed.                        16 15:41:04Z) The description
to be extensible, for the          2. Remove the Optional          of the frame includes the
following reasons:                 subelements field from Figure   optional subelements to make
1. From my understanding, all      7-101c and Figure 7-101d        the description complete.
action frames (management
frames) can be inserted
additional information element
when it is needed in future
amendments.
2. Vendor Specific element
can be inserted in any action
frames according to 7.2.3.12.
There is no need to restate
here.
This comment shall be applied
to 7.4.6.4 as well.


Vendor Specific element may L15: add VendorSpecificInfo            AGREE (ARCHITECTURE:         EDITOR
be included in all action frames in MLME-                          2009-07-16 06:30:06Z)
according to 7.2.3.12.           LINKMEASURE.request. Also
                                 VendorSpecificInfo shall be
                                 added in MLME-
                                 LINKMEASURE.confirm.
It appears that only two         Add MLME-                         DISAGREE                        EDITOR
primitives MLME-                 LINKMEASURE.indication and        (ARCHITECTURE: 2009-11-
LINKMEASURE.request and MLME-                                      18 20:37:24Z) The
MLME-                            LINKMEASURE.request               commentor is encouraged to
LINKMEASURE.confirm are          primitives.                       provide more details of any
defined. Indication primitive                                      proposed improvement, but
and Response primitives shall                                      without the details of what is
be defined.                                                        proposed, the group cannot
                                                                   evaluate the technical merit at
                                                                   this time.

It is unnecessary to               1. Add SSID in Figure 7-101e    DISAGREE                      EDITOR
include/define Optional            and remove the Optional         (ARCHITECTURE: 2009-11-
Subelements field. For the         subelements field from Figure   16 15:41:04Z) The description
following reasons:                 7-101e.                         of the frame includes the
1. SSID element can be             2. P233L46 change "SSID         optional subelements to make
optionally included in Neighbor    subelement can be included in   the description complete.
Report Request frame.              a Neighbor Report Request
2. all action frames               frame ..." to "SSID element
(management frames) can be         can be included in a Neighbor
inserted additional information    Report Request frame...".
element when it is needed in       3. remove P233 L9-L43.
the future amendments.
3. Vendor Specific element
can be inserted in any action
frames according to 7.2.3.12.
There is no need to restate
here.
It is unnecessary to              1. Add Multiple BSSID in          DISAGREE                      EDITOR
include/define Optional           Figure 7-101g and remove          (ARCHITECTURE: 2009-11-
Subelements field, for the        the Optional subelements field    16 15:41:04Z) The description
following reasons:                from Figure 7-101g.               of the frame includes the
1. Multiple BSSID element         2. remove P235 L55 to             optional subelements to make
can be optionally included in     P236L27.                          the description complete.
Neighbor Report Request
frame, directly.
2. all action frames
(management frames) can be
inserted additional information
element when it is needed in
the future amendments.
3. Vendor Specific element
can be inserted in any action
frames according to 7.2.3.12.
There is no need to restate
here.

  Define a generic format for     Define a generic format for the   DISAGREE                      EDITOR
the extensible element to         extensible element to include     (ARCHITECTURE: 2009-11-
include optional subelements.     optional subelements.             16 15:24:56Z) the commentor
If any new element (defined in    Commenter would be                is encouraged to provide more
11k, 11r, 11y and any future      interested in preparing a         details of any proposed
element) is the extensible        submission if the idea is         improvement, but without the
element, it shall be extensible   accepted in principle.            details of what is proposed,
by including optional                                               the group cannot evaluate the
subelements. IMHO, all new                                          technical merit at this time.
elements defined in 11k, 11r,
and 11y shall be extensible.

Why are the following             clarify it, or include optional   DISAGREE                        EDITOR
elements extensible?              subelements.                      (ARCHITECTURE: 2009-11-
RCPI, RSNI, BSS Average                                             18 20:38:13Z) The
Access Delay, Antenna                                               commentor is encouraged to
Information, BSS Available                                          provide more details of any
Admission Capacity, BSS AC                                          proposed improvement, but
Access Delay.                                                       without the details of what is
                                                                    proposed, the group cannot
                                                                    evaluate the technical merit at
                                                                    this time.
According to 7.2.3.12, Vendor see comment.                          AGREE (ARCHITECTURE:            EDITOR
Specific element may be                                             2009-07-16 06:30:54Z)
included in all action frames.
The VendorSpecificInfo
parameter shall be added in all
primitives defined in 10.3.25.

According to 7.2.3.12, Vendor see comment.                          AGREE (ARCHITECTURE:         EDITOR
Specific element may be                                             2009-07-16 06:31:12Z)
included in all action frames.
The VendorSpecificInfo
parameter shall be added in all
primitives defined in 10.3.27.
Is Vendor-Specific action          Define a public vendor-specific    DISAGREE                      EDITOR
frame a class 1 frame or class     action, or clarify it. Commenter   (ARCHITECTURE: 2009-11-
3 action frame? If it is class 3   would be interested in             18 20:39:33Z) The commentor
action frame, a public Vendor-     preparing a submission if the      is encouraged to provide more
Specific action frame shall be     idea is accepted in principle.     details of any proposed
defined.                                                              improvement, but without the
                                                                      details of what is proposed,
                                                                      the group cannot evaluate the
                                                                      technical merit at this time.

I think the service "Radio         L39, change "Radio                 DISAGREE (GEN: 2009-11-18 EDITOR
measurement" shall be applied      measurement" to "Radio             18:39:50Z)There is no
to "RRM facility only", and        measurement (RRM facility          definition of the meaning of the
"DSE" shall be applied "DSE        only)". L40 and L63: Change        "<something> facility only"
facility only".                    "DSE" to "DSE (DSE facility        terms that occur in these
                                   only)".                            related subclauses. The
                                                                      proposed change corrects no
                                                                      error and introduces the
                                                                      undefined terms "RRM facility"
                                                                      and "DSE facility"

Vendor Specific Action frame       change "Any valid individual       AGREE (ARCHITECTURE:        EDITOR
could be transmitted as a          MAC address" to "Any valid         2009-11-18 20:26:42Z)
broadcast frame. Peer MAC          individual MAC
Address could be group MAC         address, or any valid group
address.                           MAC address." Apply the
                                   same change to P539L23.




Extended Channel Switch            change "Any valid individual       AGREE (ARCHITECTURE:        EDITOR
frame can be transmitted as a      MAC address" to "Any valid         2009-11-18 20:27:19Z)
broadcast frame. Peer MAC          individual MAC
Address could be group MAC         address, or any valid group
address.                           MAC address."
Channelswitch frame can be          change "Any valid individual    DISAGREE                       EDITOR
transmitted as a broadcast          MAC address" to "Any valid      (ARCHITECTURE: 2009-11-
frame. Peer MAC Address             individual MAC                  16 16:00:59Z) The Peer MAC
could be group MAC address.         address, or any valid group     address is the sender of the
                                    MAC address."                   frame even if the Channel
                                                                    Switch is sent to the Group.

The distinction between          Clarify use of                     DISAGREE (MAC: 2009-10-23 EDITOR
NonERP_Present and               NonERP_present bit or              16:13:46Z) - NonERP_Present
Use_Protection bit is not clear. replace all occurances of          is informative to the receiver in
                                 NonERP_present bit with            that a STA may decide to use
                                 Use_Protection bit                 protection, but is not required
                                                                    to. Use_Protection is
                                                                    mandatory and requires that
                                                                    the receiver use protection for
                                                                    transmissions. The proposed
                                                                    comment resolution does not
                                                                    include sufficient detail to
                                                                    clarify this behavior. However,
                                                                    the commenter is encouraged
                                                                    to bring a submission to TGmb
                                                                    for consideration and
                                                                    discussion in a future ballot.


The following text                  Add the following text at the   DISAGREE                        EDITOR
"STAs in an infrastructure          begenning of clause 11.1.2.3    (ARCHITECTURE: 2009-11-
network shall only use other        "While doing scan STA may       18 20:54:28Z) The text “in an
information in received             process all the received        infrastructure network” already
Beacon frames, if the BSSID         beacons, while not doing scan   means the STA is associated,
field is equal to the MAC           the following rules apply."     and therefore is not doing a
address currently in use by the                                     scan.
STA contained in the AP of the
BSS.
STAs in an IBSS shall use
other information in any
received Beacon frame for
which the IBSS subfield of the
Capability field is set to 1, the
content of the SSID element is
equal to the SSID of the IBSS,
and the TSF value is later than
the receiving STA’s TSF
timer." disallows processing of
beacon information received
from other BSS.
There might be some
information element contained
in the received beacon that
should be processed
irrespective of BSS, e.g., ERP
information element (clause
7.3.2.13). In partiuclar,
7.3.2.13 statement that "A
NonERP infrastructure or
independent BSS is
overlapping (a NonERP BSS
may be detected by the
In the following text "The           Extend the WEP rules for RSN      AGREE IN PRINCIPLE (MAC: EDITOR
length of a fragment shall                                             2009-10-23 16:01:16Z) -
never be larger than                                                   Change cited sentence to
dot11FragmentationThreshold                                            read: "The length of a
unless WEP is invoked for the                                          fragment shall never be larger
MPDU. If WEP is active for the                                         than
MPDU, then the MPDU shall                                              dot11FragmentationThreshold
be expanded by IV and ICV                                              unless security encapsulation
(see 8.2.1); this may result in a                                      is invoked for the MPDU. If
fragment larger than                                                   security encapsulation is
dot11FragmentationThreshold.                                           active for the MPDU, then the
", it is not clear if this appies to                                   MPDU shall be expanded by
TKIP/AES as well?                                                      the encapsulation overhead
                                                                       and this may result in a
                                                                       fragment larger than
                                                                       dot11FragmentationThreshold.
                                                                       "

The following text "The length      Correct the definition of          AGREE (MAC: 2009-09-24            EDITOR
of a fragment shall never be        dot11FragmentationThreshold        21:43:49Z) - Change definition
larger than                         to allow security fields like IV   of
dot11FragmentationThreshold         and ICV to be not counted for      dot11FragmentationThreshold
unless WEP is invoked for the       the threshold                      to read: "This attribute
MPDU. If WEP is active for the                                         specifies the current maximum
MPDU, then the MPDU shall                                              size, in octets, of the MPDU
be expanded by IV and ICV                                              that may be delivered to the
(see 8.2.1); this may result in a                                      security encapsulation. An
fragment larger than                                                   MSDU is broken into
dot11FragmentationThreshold.                                           fragments if its size exceeds
", is not consistent with the the                                      the value of this attribute after
definition of MIB                                                      adding MAC headers and
dot11FragmentationThreshold                                            trailers. Fields added to the
clause Annex D text "This                                              frame by security
attribute shall specify the                                            encapsulation are not counted
current maximum size, in                                               against the limit specified by
octets, of the MPDU that may                                           this attribute. An MSDU or
be delivered to the PHY. An                                            MMPDU is fragmented when
MSDU shall be broken into                                              the resulting frame has an
fragments if its size exceeds                                          individual address in the
the value of this attribute after                                      Address1 field, and the length
adding MAC headers and                                                 of the frame is larger than this
trailers. An MSDU or MMPDU                                             threshold, excluding security
shall be fragmented when the                                           encapsulation fields."
resulting frame has an
individual address in the
Address1 field, and the length
of the frame is larger than this
threshold." Similar text is
present in Annex-D, pp 1351,
line 19
"STAs receiving Probe             Delete "STAs receiving Probe      AGREE IN PRINCIPLE              EDITOR
Request frames shall respond      Request frames shall respond      (EDITOR: 2009-07-03
with a probe response when        with a probe response when        13:19:17Z)
the SSID in the probe request     the SSID in the probe request     Aggree that the paras at line 7
is the wildcard SSID or           is the wildcard SSID or           and 16 contain duplicate text.
matches the specific SSID of      matches the specific SSID of      The entire contents of the para
the STA. Probe Response           the STA." and                     at line 7 is reproduced in line
frames shall be sent as           Delete "Probe Response            30 on.
directed frames to the address    frames shall be sent as
of the STA that generated the     directed frames to the address    The cleanest solution is to
probe request. The probe          of the STA that generated the     delete the whole para at line
response shall be sent using      probe request. The probe          7.
normal frame transmission         response shall be sent using
rules. An AP shall respond to     normal frame transmission         Editor: Delete the para at line
all probe requests meeting the    rules. An AP shall respond to     7: "Probe Response Frames
above criteria. In an IBSS, the   all probe requests meeting the    shall be sent ... request."
STA that generated the last       above criteria. In an IBSS, the
Beacon frame shall be the         STA that generated the last
STA that responds to a probe      Beacon frame shall be the
request." is redundant.           STA that responds to a probe
Compare with lines 7-11.          request."


The sentence "When all ACs Clarify.                                 DISAGREE (MAC: 2009-09-25 EDITOR
associated with the non-AP                                          03:29:46Z) - The first cited
STA are delivery-enabled, the                                       sentence refers to delivery-
More Data field shall be set to                                     enabled ACs and the second
indicate the presence of                                            cited sentence refers to non-
further buffered MSDUs or                                           delivery-enabled ACs. There
management frames                                                   is no consistency problem.
belonging to delivery enabled
ACs" is not consistent with the
previous sentence "For a non-
AP STA using U-APSD, the
More Data field shall be set to
indicate the presence of
further buffered MSDUs or
management frames that do
not belong to delivery-enabled
ACs.".
The definitions of class 1 data Clarify.                            AGREE IN PRINCIPLE (GEN: EDITOR
frame and class 3 data frame                                        2009-11-19 05:15:59Z) The
are not clear especially in                                         Editor is instructed to
IBSS networks. A data frame                                         incorporate into the REVmb
with FromDS = ToDS = 0                                              draft document 11-09/705r4.
belongs to class 1 in IBSS and                                      (https://mentor.ieee.org/802.11
class 3 in other cases. The                                         /dcn/09/11-09-0705-04-000m-
question is how to determine                                        proposed-corrections-to-11-3-
whether a data frame belongs                                        sta-authentication-and-
to class 1 in the IBSS or not                                       association.doc)
when STA is in state 1? For
example, if STA resets, it may
lose state information and
subsequently a data frame
received from peer STA
cannot be marked as IBSS or
BSS frame, and therefore
cannot be classified whether
belongs to class 1 or 3.

Paragraph 1 and Paragraph 2 Delete paragraph 2.                     AGREE (EDITOR: 2009-07-03 EDITOR
are identical.                                                      13:25:20Z)

"A STA shall be capable of        Modify "A STA shall be            AGREE IN PRINCIPLE (MAC: EDITOR
receiving fragments of            capable of receiving fragments    2009-09-22 19:09:38Z).
arbitrary length." Here instead   of arbitrary length." as "A STA   Change "A STA shall be
of allowing arbirarty length      shall be capable of receiving     capable of receiving fragments
frame reception capability,       fragments of arbitrary length     of arbitrary length." to read "A
STA should check if the length    that is less than max allowed     STA shall be capable of
is valid < Max MSDU size          MSDU size." Modify figures 7-     receiving fragments of
(2304 octets). Similar issues     1, and 7-18 appropriately         arbitrary length that is less
exist in                                                            than maximum allowed MSDU
Clause 7.1.2 (pp 71, ln 55):                                        size, plus any encapsulation
MSDU size is not consistent                                         headers." Figures 7-1 and 7-
with figure 7-1                                                     18 show a strikethrough for
Clause 7.2.3.0a (pp 90):                                            Frame Body length, and
Frame body size is not                                              should be corrected to be
consistent with Figure 7-18                                         "2324".
The last paragraph in this          One solution is to replace PHY- DISAGREE (MAC: 2009-09-24 EDITOR
clause states that "A STA that      RX-START.indication with         21:05:19Z) - For CCK/DSSS
used information from an RTS        PHY-CCA.indication (BUSY)        STAs, the (CTS_Time)
frame as the most recent basis      Replace text with "A STA that included in the calculation
to update its NAV setting is        used information from an RTS provides enough time to
permitted to reset its NAV if no    frame as the most recent basis protect the OFDM exchange
PHY-RXSTART.indication is           to update its NAV setting is     because the OFDM exchange
detected from the PHY during        permitted to reset its NAV if no will be transmitted at a higher
a period with a duration of (2 ×    PHY-CCA.indication (BUSY) is rate than the RTS/CTS.
aSIFSTime) + (CTS_Time) +           detected..."
aPHY-RX-START-Delay + (2 ×
aSlotTime) starting at the PHY-
RXEND.indication
corresponding to the detection
of the RTS frame. The
“CTS_Time” shall be
calculated using the length of
the CTS frame and the data
rate at which the RTS frame
used for the most recent NAV
update was received."
If RTS frame is sent at a
CCK/DSSS rate to protect
subsequent MPDUs sent at
OFDM rates in presence of
11b STAs, the 11b STAs will
not set their NAV due to lack
of PHY-RXSTART.indication
after the "duration". This may
defeat the purpose of using
RTS in the first place.

"A TXOP limit value of 0            Clarify, or replace "A TXOP         AGREE IN PRINCIPLE (MAC: EDITOR
indicates that a single MSDU        limit value of 0 indicates that a   2009-10-16 15:15:43Z) - Insert
or MMPDU, in addition to a          single MSDU... " with "A TXOP       "When the TXOP limit is non-
possible RTS/CTS exchange           limit value of 0 indicates that a   zero, . . ." at the beginning of
or CTS to itself, may be            single MPDU..."                     the paragraph on page 396
transmitted at any rate for                                             line 50.
each TXOP."
As per the fourth paragraph "A
STA shall fragment a unicast
MSDU so that the
transmission of the first MPDU
of the TXOP does not cause
the TXOP limit to be exceeded
at the PHY rate selected for
the initial transmission attempt
...".
MSDU may consist of multiple
fragments and therefore it
would be appropriate to
replace text "A TXOP limit
value of 0 indicates that a
single MSDU " with "A TXOP
limit value of 0 indicates that a
single MPDU. "
The list above this text "If the   Number the list (list items a-d)   AGREE IN PRINCIPLE             EDITOR
backoff procedure is invoked       above the text "If the backoff     (EDITOR: 2009-07-02
for reason a) above, the value     procedure is invoked for           15:44:12Z) - See resolution to
of CW[AC] shall be left            reason a) above, the value of      CID 1651, which addresses
unchanged. If the                  CW[AC] shall be left               this issue.
backoff procedure is invoked       unchanged. If the
because of reason b) above,        backoff procedure is invoked
the value of CW[AC] shall be       because of reason b) above,
reset to CWmin[AC]." is not        the value of CW[AC] shall be
numbered.                          reset to CWmin[AC]."
The list above this text "If the   Number the list (list items a-d)   AGREE IN PRINCIPLE             EDITOR
backoff procedure is invoked       above the text "If the backoff     (EDITOR: 2009-07-02
because of a failure event         procedure is invoked for           15:44:33Z) - See resolution to
[either reason c) or d) above],"   reason a) above, the value of      CID 1651, which addresses
is not numbered.                   CW[AC] shall be left               this issue.
                                   unchanged. If the
                                   backoff procedure is invoked
                                   because of reason b) above,
                                   the value of CW[AC] shall be
                                   reset to CWmin[AC]."
The sentence "The RA field of      Modify sentence "The RA field      DISAGREE (EDITOR: 2009- EDITOR
the frames shall be the            of the frames shall be the         07-03 10:43:13Z)
recipient’s unicast address.",     recipient’s unicast                The term "recipient" in this
in the first paragraph does not    address." in the first paragraph   context is unambiguous, as
clearly state that whether RA is   with "The RA field of the          determined by the last
the ADDBA recipient or not. To     frames shall be the ADDBA          sentence of 9.10.1: "In this
make pragraph consistent this      recipient’s unicast address."      subclause, the STA with data
RA shall be ADDBA recipient.                                          to send using the Block Ack
                                                                      mechanism is referred to as
                                                                      the originator, and the receiver
                                                                      of that data as the recipient. "
It seems the sentence "After       Modify as follows-              AGREE IN PRINCIPLE (MAC: EDITOR
setting up for the Block           "If no protective mechanism is  2009-11-13 19:43:23Z) -
exchange following the             used, the first frame that is   Change cited text to read:
procedure in 9.10.2, the           sent in the block shall be sent "After setting up for the Block
originator may transmit a block    as a QoS Data frame with Ack    exchange following the
of QoS data frames separated       Policy subfield in the QoS      procedure in 9.10.2 (Setup
by SIFS period," in paragraph      Control field set to Normal     and modification of the Block
one conflicts with the sentence    Ack. The duration field of such Ack parameters), and having
"If no protective mechanism is     a first frame should be set so  gained access to the medium
used, then the first frame that    that the response frame shall   and established protection, if
is sent as a block shall have a    have the Duration field to set  necessary, the originator may
response frame and shall have      NAV with appropriate values at  transmit a block of QoS data
the Duration field set so that     all STAs in the BSS."           frames separated by SIFS
the NAVs are set to                                                period, with the total number of
appropriate values at all STAs                                     frames not exceeding the
in the BSS." in paragraph four.                                    Buffer Size subfield value in
It is assumed that after setting                                   the associated ADDBA
up Block Ack, transmitter                                          Response frame and .subject
transmits a series of frames                                       to any additional duration
each separated by SIFS                                             limitations based on the
without any immediate Ack,                                         channel access mechanism.
however, later transmitter                                         Each of the frames shall have
requests for a response frame                                      the Ack Policy subfield in the
from the receiver.                                                 QoS Control field set to Block
                                                                   Ack. The RA field of the
                                                                   frames shall be the recipient’s
                                                                   unicast address. The originator
                                                                   requests acknowledgment of
                                                                   outstanding QoS data frames
                                                                   by sending a BlockAckReq
                                                                   frame. The recipient shall
                                                                   maintain a Block Ack record
It would be more appropritate Move sentence "The More              for the block."
                                                                   AGREE IN PRINCIPLE               EDITOR
to move sentence "The More Data field is set to 0 in all other (EDITOR: 2009-07-01
Data field is set to 0 in all other directed frames" to the end of 06:38:46Z)
directed frames" at the end of this subclause.                     Move the last para of 7.1.3.1.7
this subclause.                                                    to before the cited para. This
                                                                   ensures that all specification
                                                                   for directed frames is
                                                                   described before the
                                                                   "otherwise". The para
                                                                   following the cited para is
                                                                   unrelated as it refers to
                                                                   broadcast, and should
                                                                   therefore not separate the
                                                                   directed cases and the
                                                                   directed "other" statement.
Table 7-58, allows                  Remove Disassociation frame AGREE IN PRINCIPLE                  EDITOR
disassociation frame in an          in case of IBSS; Add a dash in (ARCHITECTURE: 2009-11-
IBSS. Why is this allowed           IBSS column correspoding to 16 15:49:39Z) - Note that
here? In fact subclause 10.3.8 row disassociation.                 Clause 7.5 is removed by
and 11.3.2.6 do not describe                                       TGn, so no change is required
how this is used in IBSS.                                          by the Editor.
"For the purpose of                "For the purpose of              AGREE (MAC: 2009-08-06   EDITOR
determining the proper AC for      determining the proper AC for 22:51:02Z)
an RTS frame, the RTS frame        an RTS frame, the RTS frame
shall inherit the UP of the data   shall inherit the UP of the data
or management frame(s) that        or AC of management
are included in the frame          frame(s) that are included in
exchange sequence where the        the frame exchange sequence
RTS is the first frame."           where the RTS is the first
UP may not be an appropriate       frame."
term for management frames.


There is no rule to derive AC      Replace ""For the purpose of AGREE (MAC: 2009-08-06       EDITOR
for CTS2Self frame.                determining the proper AC for 22:49:05Z)
                                   an RTS frame, the RTS frame
                                   shall inherit the UP of the data
                                   or management frame(s) that
                                   are included in the frame
                                   exchange sequence where the
                                   RTS is the first frame." with
                                   "When the first frame in the
                                   frame exchange sequence is
                                   an RTS or CTS, the RTS or
                                   CTS frame shall inherit the UP
                                   of the data or AC of
                                   management frame(s) of the
                                   frame exchange sequence."

Grammar Error in table 7-28:       It should be "….requesting the AGREE (EDITOR: 2009-07-02 EDITOR
The transmitting STA is            destination STA not send       06:12:36Z)
indicating to the destination      autonomous…." --- delete the
STA that it can accept             "to"
measurement requests and is
requesting the destination STA
not to send autonomous or
triggered measurement
reports of the type indicated in
the Measurement Type field
(see NOTE)."
Grammar Error: "A STA shall        Change to "A STA shall report AGREE (EDITOR: 2009-07-15 EDITOR
report it is incapable a           it is incapable of performing a 02:29:03Z)
measurement request if any of      measurement request if any of
the following conditions           the following conditions
exists:"                           exists:" -- add "of performing"

The specification of STA       Change as shown in doc:11-       AGREE (GEN: 2009-11-19          EDITOR
authentication and association 09/0705                          05:12:46Z) instruct the editor
in section 11.3 is incomplete,                                  to incorporate into the REVmb
ambiguous, inconsistent and                                     draft document 11-09/705r4.
sometimes just wrong.                                           (https://mentor.ieee.org/802.11
                                                                /dcn/09/11-09-0705-04-000m-
                                                                proposed-corrections-to-11-3-
                                                                sta-authentication-and-
                                                                association.doc)
The word "frame" is used too        Add "Also known as a frame."     DISAGREE (EDITOR: 2009-        EDITOR
loosely. Sometimes it refers to     to the definition of MPDU in     07-27 10:04:41Z)
a MSDU or MMPDU, rather             section 3.
than an MPDU forming part of        Throughout the spec, change      This was discussed at length
a fragmented MSDU or                uses of "[data/management]       in TGmb, and no consensus
MMPDU. This affects, for            frame" to "MSDU or               was present for making any
example, whether the PM             MMPDU"/"MMPDU"/"MSDU"            changes. (see 11-09-0714r2
mode can change during a            where appropriate.               for background).
fragmented MSDU or MMPDU.           Simplify "Management frame
                                    of subtype Foo" to "Foo          The proposed change "as
                                    MMPDU".                          appropriate" gives inadequate
                                                                     detail. Changing from a frame
                                                                     to an MSDU/MMPDU is a
                                                                     technical change. The
                                                                     commenter is invited to
                                                                     provide specific details about
                                                                     which locations need to be
                                                                     changed as technical
                                                                     comments in a later ballot.
The definitions of "unicast" and    In the two definitions, remove   AGREE IN PRINCIPLE (MAC: EDITOR
"multicast" are unclear; this       the "or control frame"s and      2009-09-23 03:58:06Z)
makes understanding the             replace the "(RA)"s with         Review all uses of broadcast,
exact intent of e.g. "unicast       "(Address 1)"s.                  multicast and unicast and
Probe Request" difficult.                                            replace as follows:
Specifically, it is not clear how                                    (1) "Unicast" changes to
these are defined for                                                "individual" or "individually
MMPDUs, and there is a                                               addressed" according to
confusing special mention of                                         context
control frames as distinct from                                      (2) "multicast", "broadcast /
other MPDUs.                                                         multicast" or "broadcast or
                                                                     multicast" changes to "group"
                                                                     or "group addressed"
                                                                     according to context. This
                                                                     specifically applies to MIB
                                                                     variables of the form
                                                                     {something}Multicast{somethin
                                                                     gelse}, which change to
                                                                     {something}Group{somethinge
                                                                     lse}
                                                                     (3) "broadcast" remains the
                                                                     term to use when specifically
                                                                     referring to the broadcast
                                                                     address

                                                                     See also CID 1086.
The rules for the BSSID in      Change as follows:                  AGREE IN PRINCIPLE                EDITOR
management frames are           The BSSID of the                    (ARCHITECTURE: 2009-11-
unclear. Specifically, the      management frame is                 16 15:30:39Z) - Change to:
BSSID to use in an ESS when     determined as follows:              "The BSSID of the
not associated, and the         a) If the STA is an AP or is        management frame is
meaning of "a member of an      associated withtransmitting the     determined as follows:
IBSS" and "a specific BSSID",   management frame to an AP,              a) If the STA is an AP or is
are unclear.                    the BSSID is the address            transmitting the management
                                currently in use by the STA         frame to an AP, the BSSID is
                                contained in the AP.                the address currently in use by
                                b) If the STA is transmitting the   the STA contained in the AP.
                                management frame to one or              b) If the STA is transmitting
                                morea members of an IBSS,           the management frame to one
                                the BSSID is the BSSID of the       or more members of an IBSS,
                                IBSS.                               the BSSID is the BSSID of the
                                c) In management frames of          IBSS.
                                subtype Probe Request, the               c) In management frames
                                BSSID is either a specific          of subtype Probe Request, the
                                BSSID as specified in (a) or        BSSID is either a specific
                                (b), or the wildcard BSSID as       BSSID as specified in (a) or
                                defined in the procedures           (b), or the wildcard BSSID as
                                specified in 11.1.3 (Acquiring      defined in the procedures
                                synchronization, scanning).         specified in 11.1.3 (Acquiring
                                                                    synchronization, scanning)."
TGmb-agreed changes to        Change the draft as previously AGREE IN PRINCIPLE             EDITOR
TCLAS element text missing    agreed in CIDs 48-50. See      (EDITOR: 2009-08-06
from D1.0.                    Doc: 11-08/1127r18             13:01:12Z) -
                                                             Make changes as shown for
                                                             CID 48 in document 11-08-
                                                             1127r20 as amended thus:
                                                             1. The inserted table is an
                                                             octet-aligned structure. Sizes
                                                             are in octets.
                                                             2. Remove the note in square
                                                             brackets.

                                                             CID 49 proposes adding "as in
                                                             IEEE 802.1Q-2003 [Bxx]", but
                                                             the text describing the Type 2
                                                             classifier states: "For
                                                             Classifier Type 2, the
                                                             Classifier Parameter is the
                                                             IEEE 802.1Q-2003 [B14]
                                                             VLAN Tag TCI." Adding "as
                                                             in IEEE 802.1Q-2003 [Bxx]"
                                                             would be redundant. Instead
                                                             add the following:
                                                             "The endianness of the
                                                             802.1Q VLAN TCI field is as
                                                             defined IEEE 802.1Q-2003
                                                             [B14] for the VLAN Tag TCI."

                                                            Likewise for CID 50, add after
                                                            "For Classifier Type 0, ... and
                                                            Type ("Ethernet" [B4])." add:
                                                            "The endianness of the Type
It is not clear what the      Add "The Power Management field is as defined in Ethernet EDITOR
                                                            AGREE IN PRINCIPLE (MAC:
meaning of the PM bit is in   bit shall be ignored in frame 2009-09-25 03:33:24Z) - Insert
MSDUs/MMPDUs which are        exchanges initiated by the AP the text: "The Power
not acknowledged.             or which do not elicit an ACK Management bit shall be
                              from the AP." to the          ignored in frame exchanges
                              penultimate paragraph of this initiated by the AP. The non-
                              section.                      AP STA shall not change
                                                            power management state
                                                            using a frame exchange that
                                                            does not receive an ACK."
                                                            before the last sentence in the
                                                            penultimate paragraph of
                                                            11.2.1.1.

It is not clear how the wildcard Add "When the wildcard            AGREE (ARCHITECTURE:       EDITOR
BSSID is to be used.             BSSID is used in such a           2009-07-16 06:31:51Z)
                                 frame, the Address 1 (DA) field
                                 is also set to all 1s to indicate
                                 the broadcast address." to the
                                 end of the last paragraph of
                                 this section.
Disassociation,                    Change so that only Action       AGREE (MAC: 2009-09-30          EDITOR
Deauthentication and Probe         frames (both unicast and         14:53:09Z)
Response frames should not         group) are buffered.
be buffered.




This section does not account      Change to cover all types and    DISAGREE (MAC: 2009-11-18 EDITOR
for U-APSD, e.g. if there are      scenarios of power               20:50:05Z) The commentor is
MSDUs on delivery-enabled          management, or delete            encouraged to provide more
ACs only but not all ACs are       sentences which duplicate        details of any proposed
delivery-enabled, then the TIM     information in other sections,   improvement, but without the
will not signal their presence.    and replace with general         details of what is proposed,
                                   statement.                       the group cannot evaluate the
                                                                    technical merit at this time.

Category code 17 needs to be       Have a dedicated line for 17,    AGREE (ARCHITECTURE:            EDITOR
reserved in a permanent way,       and inform the assignment        2009-07-16 06:32:10Z)
as it is used for a widely-        authority.
deployed spec (*cough* WMM
*cough*).
The use of underscores in the      Replace underscores with         AGREE (EDITOR: 2009-07-01 EDITOR
MLME-                              hyphens.                         10:07:03Z)
RESOURCE_REQUEST,
MLME-
RESOURCE_REQUEST_LOC
AL and MLME-
REMOTE_REQUEST
primitives is inconsistent with
existing usage.
The conventions described in       Extend section 7.1.1 to          DISAGREE (EDITOR: 2009-         EDITOR
7.1.1 are not clear and            describe conventions             07-27 08:05:10Z)
complete enough. E.g.:             pertaining to the term "data     The proposed change does
- Does "data frame" mean           frame" and related terms.        not include enough detail to
"frame of type Data" or "frame     Ensure that text in other        determine what specific
of subtype Data (+ whatever)",     sections conforms to these       changes would resolve this
and if the latter (i.e. excludes   conventions.                     comment.
the CF-only ones) does it or
does it not include QoS? Note                                       The commenter is invited to
a distinction between "data                                         submit additional detail in a
frame" and "Data frame" is                                          subsequent ballot.
poor, because the distinction
vanishes at the start of a
sentence.
- Does "QoS data frame" (note
lowercase d) include e.g. "QoS
Null"?
Some of this may be helped by
saying "MSDU" instead of
"frame", but not all.
While I will be the first to claim   With a new revision, the        AGREE IN PRINCIPLE            EDITOR
that for a historical value, this    Annexes should be               (EDITOR: 2009-09-23
annex should be left in, I am        renumbered as necessary and     18:33:57Z) - Add to Annex C
willing to concede and allow         the deprecated and reserved     immediately after the heading
not only it, but Annex E and P       Annexes removed.                the following: "This Annex is
should be removed.                                                   obsolete and may be removed
                                                                     in a future revision of this
                                                                     standard."

                                                                     Note, this allows time to
                                                                     determine if there is any
                                                                     behaviour in Annex C that
                                                                     needs to be moved to other
                                                                     Clauses.



The definition of QoS facility is Please clarify which function is   DISAGREE (GEN: 2009-11-18 EDITOR
vague. Does this implies that mandatory for a QoS STA.               22:52:44Z) Functions that are
the QoS facility means the use                                       mandatory for a QoS STA are
of EDCA as a minimum set?                                            reported in the PICs and
If the STA is in IBSS, there are                                     defined in the Normative text.
no HCF and HCCA is not
used. However, if we look at
the PICS table in A.4.16, all
the HCCA rules are mandatory
for a QoS STA. It looks like a
contradiction.




The title of the clause reads        Rename the title of this        AGREE (EDITOR: 2009-07-01 EDITOR
"IBSS ATIM frame format".            subclase to be ATIM frame       15:53:51Z)
However, other part of the           format.
specification call out this frame
as ATIM frame.
The first paragraph of 11.2.2.1      Remove the second               AGREE (EDITOR: 2009-07-03 EDITOR
and the second paragraph of          paragraph of 11.2.2.1.          13:25:39Z)
11.2.2.1 contain the same text.
Must be a copy and paste
error.
The table in A.4.4.2 does not     Please clarify.                DISAGREE (GEN: 2009-11-18 EDITOR
contain all the defined frame                                    02:01:58Z) The table in A.4.4.2
types. Why is that?                                              only contains those frame
                                                                 types that the baseline
                                                                 standard and its amendments
                                                                 have seen fit to describe here,
                                                                 and the table makes no claims
                                                                 to be totally inclusive.




Are square brackets               Add comma after "STAs" and     AGREE (EDITOR: 2009-07-01 EDITOR
necessary?                        remove square brackets         14:32:57Z)
Belongs with text in 7.0a         Move paragraph to section      AGREE IN PRINCIPLE        EDITOR
                                  7.0a and delete heading. The   (EDITOR: 2009-07-01
                                  adjective compliant is         14:35:39Z)
                                  superfluous.                   Move the cited text as
                                                                 specicied.

                                                                 Do not change "compliant".
                                                                 This text was drafted during a
                                                                 TGmb telecon. The text is the
                                                                 best compromise between the
                                                                 various views expressed to
                                                                 this group, and the adjective,
                                                                 while it may be superflous
                                                                 according to the opinion of the
                                                                 commenter, does no harm.

This sentence is inaccurate   Change to "…pending data,          AGREE (ARCHITECTURE:              EDITOR
since the sequence RTS-CTS- management or control                2009-07-16 06:32:28Z)
BAR-BA is permitted, i.e. the frame."
pending frame is a control
frame. See p420 l22.




The convention is to capitalize   Capitalize as Probe Request.   AGREE (EDITOR: 2009-07-01 EDITOR
references to specific frame                                     14:41:26Z)
type/subtypes
It is not clear why the           Remove reference or clarify    AGREE IN PRINCIPLE                EDITOR
reference to 9.9.3.0a is          with an additional statement   (EDITOR: 2009-07-01
needed. 9.9.3.0a makes            why the reader is being        14:48:40Z)
general statements about          directed to this section.      Remove the reference.
admission control and a
reference here seems out of
place.
This paragraph has clumsy            Rephrase paragragh as            AGREE (ARCHITECTURE:     EDITOR
phrasing. A) the use of "STA         follows "The TXOP Duration       2009-07-16 06:32:42Z)
desires for its next TXOP" in        Requested subfield is present
first sentence and then              in QoS data frames sent by
"calculated TXOP duration            non-AP STAs associated in a
requested" in the 3rd                BSS with bit 4 of the QoS
sentence. B) The sentence            Control field set to 0. The
describing when the field            TXOP Duration Requested
appears in a frame (sentence         subfield is an 8-bit field that
4) is mixed in with descriptions     indicates the duration, in units
of content. C) The newly             of 32 us, that the sending STA
inserted sentence ("If the           determines it needs for its next
calculated TXOP... is not a          TXOP for the specified TID. A
multiple of 32... that is a factor   value of 0 indicates that no
of 32 us") inconsistently uses       TXOP is requested for the
the terms multiple and factor        specified TID in the current
(multiple is the correct term).      SP. A non-zero value
                                     represents a requested TXOP
                                     duration in the range 32 us to
                                     8160 us in increments of 32
                                     us. See 9.9.2.3.1."


For consistency with other           Insert section heading      DISAGREE (EDITOR: 2009- EDITOR
sections at this level, there        "7.2.2.0a Format of data    07-01 14:55:10Z) -
should be a section 7.2.2.0a         frames"                     While this may get an extra
inserted. I suspect this is                                      level of nesting when 11n is
awaiting 11n.                                                    incorporated, as the ballot
                                                                 draft stands, there is no error.
                                                                 Furthermore, introducing a
                                                                 single heading at any level is
                                                                 an error according to IEEE-SA
                                                                 style.
This statement is possibly      Change to "The format of a       AGREE (ARCHITECTURE:             EDITOR
incorrect and at a minimum      data frame is defined in Figure 2009-07-16 06:33:07Z)
incomplete (that the format is 7-17. The Frame Control,
dependent on the QoS            Duration/ID, Address 1,
subfield). In addition to being Address 2, Address 3 and
dependent on the QoS            Sequence Control fields are
subfield, the format is         present in all data frame
dependent on the To DS and subtypes. The presence of the
From DS fields (and Order       Address 4 field is determined
subfield when 11n is            by the setting of the To DS and
incorporated). A more explicit From DS subfields in the
statement can be made up        Frame Control field (see
front concerning when certain below). The QoS Control field
fields are present.             is present in when the QoS
                                subfield of the Subtype field is
                                set to 1." A similar statement
                                concerning the HT Control
                                field can be added when 11n
                                is incorporated. Delete the last
                                sentence in the second
                                paragraph (p88 l45): "Data
                                frames with a value of 0...".
It is not necessary to state that   Change to "The format of a   AGREE (ARCHITECTURE:         EDITOR
the management frame format         management frame is defined 2009-07-16 06:33:22Z)
is independent of the subtype.      in Figure 7-18. The Frame
It is sufficient, when describing   Control, Duration, Address 1
generic frame formats, to           (DA), SA, BSSID and
indicate that certain fields may    Sequence Control fields are
not be present (as is done for      present in all management
the generic frame format and        frame subtypes."
data frames).

Duplicate 'present'                 Unduplicate 'present'        AGREE (EDITOR: 2009-07-01 EDITOR
                                                                 15:52:43Z)

The bracketed text "(as well as     Delete the text "(as well as      AGREE (ARCHITECTURE:    EDITOR
STAs in IBSSs)" is not              STAs in IBSSs)" from this         2009-07-16 06:33:41Z)
comprehensive treatment of          paragraph. Add a subsequent
optional short preamble use in      paragraph dealing with IBSS
IBSSs. Also, this paragraph         operation following the
does not make sense when            paragraph on p107 l1: "STAs
applied to IBSS STAs;               within an IBSS set the Short
specifically reference to BSS       Preamble subfield in
at end of sentence and              transmitted Beacon frames
reference to Probe Response,        according to the setting of their
Association Response, etc.          dot11ShortPreambleOptionIm
which are not used in an IBSS.      plemented MIB atrribute. If this
                                    attribute is true, the Short
                                    Preamble subfield is set to 1,
                                    otherwise it is set to 0."
                                    Normative text is probably
                                    needed elsewhere to deal
                                    IBSSs where a mix of short
                                    capable and non-capable
                                    STAs operate (I suspect that
                                    there are no or very few STAs
                                    that are not short capable).


The addition of bracket text    See previous comment.            AGREE (ARCHITECTURE:         EDITOR
"(as well as STAs in IBSSs)" is                                  2009-07-16 06:33:58Z) See
not comprehensive treatment                                      CID 1384.
of optional PBCC use in
IBSSs.
The use of "as well as STAs in See previous comment.             AGREE (ARCHITECTURE:        EDITOR
IBSSs" is not comprehensive                                      2009-07-16 06:34:13Z) See
treatment of DSSS-OFDM                                           CID 1384.
operation in an IBSS.




The last sentence should refer Change last sentence of           AGREE (EDITOR: 2009-07-01 EDITOR
to non-AP STAs, not just       paragraph to "Non-AP STAs         16:32:17Z)
STAs.                          always set this subfield to 0."

It is not clear why there is a   Remove reference or clarify   AGREE IN PRINCIPLE               EDITOR
reference to 9.14.0c here.       with an additional statement  (ARCHITECTURE: 2009-07-
                                 why the reader is being       16 06:34:31Z) Remove
                                 directed to this section.     reference.
Grammer                          "                             AGREE IN PRINCIPLE               EDITOR
                                                               (EDITOR: 2009-07-01
                                                               16:58:08Z)
                                                               Add quotes around "Yes" and
                                                               "Subelements" in lines 52 and
                                                               54.
The value of the Dialog Token Change paragraph text to: "A AGREE IN PRINCIPLE (MAC: EDITOR
field is NOT arbitrary. A STA Dialog Token is an integer       2009-09-24 21:35:59Z) -
should select a unique dialog value that assits a STA in       Replace only first sentence in
token. Also, its use is not   grouping management frames paragraph with proposed text,
limited to action frame       sent or received at different    while correcting spelling of the
request/response exchanges times as part of the same           word "assists" (9th word in
(see timing measurement       dialog. The algorithm by which proposed change).
feature in 11v).              the integer value for the dialog
                              is selected is implementation
                              specific but should be selected
                              in a manner that minimizes the
                              probability of a frame
                              associated with one dialog
                              being incorrectly associated
                              with another dialog."
Comment submitted per TGv           This may be a TGmb problem        DISAGREE                         EDITOR
LB140 comment resolution;           however. If so, send it on.       (ARCHITECTURE: 2009-11-
LB140 CID 447 below                 TGv TG discussed and agreed       16 15:35:12Z) STAs may
(submitter R. Roy)addressed         that it is a TGmb issue. TGv      assign Antenna ID numbers to
TGk Text:This clause states         chair will forward the issue on   "antenna configurations" which
that for example "If during         to the TGmb group.                can represent the multiple
frame reception, different                                            antenna/smart antenna
antennas are used to receive                                          processing situations, by
the preamble and body, the                                            assigning unique numbers to
antenna ID identifies the                                             the (meaningfully) different
antenna that receives the                                             configurations. If the system is
frame body." and allocates a                                          too complex to still be
byte for describing all possible                                      represented in this fashion, the
antenna configurations. What                                          STA can return 255. Any
happens when smart antenna                                            further complication in
signal processing is used to                                          description is probably not
receive the frame (e.g., with                                         useful.
multi-dimensional (i.e., multi-
antenna) decision directed
feedback)? This section
needs work.

Comment submitted per TGv           Remove sentence and update        DISAGREE                        EDITOR
LB146 comment resolution;           draft with any other changes      (ARCHITECTURE: 2009-07-
LB146 CID below (submitter          required to convey duration of    16 06:35:04Z) 7.3.2.22.10
G. Venkatesan):The sentence         a measurement period for          seems to be okay already. So
"In a triggered STA statistics.."   triggered reporting.              does 7.3.2.21.20. The field is
suggests the duration field is      Resolution in TGv was as          defined in 7.3.2.22.10 and the
reserved for triggered report.      follows:                          behaviour in 11.10.8.8
Why? Is it not useful to convey     Delete the sentence as            descripes setting this to 0. No
the duration it took to trigger     recommended. Delete P29L9-        change required.
the report?                         10: "In a triggered STA
                                    Statistics report the
                                    Measurement Duration field is
                                    reserved."
                                    Also replace P201L56-58 with
                                    the following:

                                    "Measurement duration shall
                                    not be specified when
                                    requesting a triggered STA
                                    statistics measurement and
                                    the Measurement Duration
                                    field in the corresponding
                                    Measurement Request shall
                                    be set to 0."

                                    To make this consistent, the
                                    corresponding text in
                                    7.3.2.22.10 (P802.11k-2008)
                                    needs to be deleted (P54). If
                                    this is not in scope for TGv,
                                    this should be submitted as a
                                    comment to TGmb.
The sentence "This clause is        Corresponding edits need to it AGREE IN PRINCIPLE
                                    Convert or reposition so that                                 EDITOR
no longer maintained..."            doesn't appear in the TOC.     (EDITOR: 2009-07-23
appears in the TOC.                                                12:56:18Z) - See resolution of
                                                                   CID 1241, which removes this
                                                                   Annex.
"an protected"                      change to "a protected"          AGREE (EDITOR: 2009-07-01   EDITOR
                                                                     11:54:19Z)
The abbreviation LCI is used        expand/re-order as necessary. AGREE IN PRINCIPLE             EDITOR
before being defined.                                                (EDITOR: 2009-07-01
                                                                     11:59:33Z)
                                                                     Expand LCI in p12.37 and
                                                                     p12.38 and reorder.
This note is redundant              Remove it.                       AGREE (EDITOR: 2009-07-01   EDITOR
                                                                     12:01:37Z)
The last sentence of 3.84 is        Move it into a NOTE-- to follow AGREE (EDITOR: 2009-07-01    EDITOR
802.11-specific                     3.84.                            12:04:13Z)
The last sentence of 3.42 is        Move it into a NOTE-- to follow AGREE (EDITOR: 2009-07-01    EDITOR
802.11-specific                     3.42.                            11:53:40Z)
This definition appears to be       Either move to 3A, or reword AGREE IN PRINCIPLE              EDITOR
802.11-specific                     to remove 802.11.                (EDITOR: 2009-07-01
                                                                     11:56:45Z)
                                                                     Delete: "non-IEEE-802.11"
"This key is at least 64            Replace with a NOTE: "NOTE- AGREE (EDITOR: 2009-07-01        EDITOR
octets..." is specific to 802.11    -In 802.11, this key is at least 12:03:16Z)
                                    64 octets in length."
"A medium access control            Replace with "... set to 1."     AGREE (EDITOR: 2009-07-01   EDITOR
(MAC) address that has the                                           12:05:08Z)
group bit set." - set to what?
", employed by some IEEE            Replace with a NOTE:          AGREE (EDITOR: 2009-07-01 EDITOR
802.11 security protocols." -       "NOTE, a per-frame encryption 12:06:35Z)
802.11 specific                     key is employed by some ..."

"A static key that is distributed   Replace with: "A static key         AGREE (EDITOR: 2009-07-01 EDITOR
to the units in the system by a     that is distributed to the units in 12:07:35Z)
method outside                      the system by some out-of-
the scope of this standard,         band means."
always by some out-of-band
means." - implicit reference to
802.11.
"3.133 selector: An item            Move to Clause 3A            AGREE (EDITOR: 2009-07-01 EDITOR
specifying a list constituent in                                 12:10:00Z)
an IEEE 802.11 Management
Message information
element." - specific to 802.11
"3.136 station (STA): Any       I would say move to 3A,        AGREE (EDITOR: 2009-07-01 EDITOR
device that contains an IEEE    however all dependent          12:23:38Z)
802.11-conformant medium        definitions would also have to
access control (MAC)            move. Replace with:
and physical layer (PHY)        "3.136 station (STA): Any
interface to the wireless       device that contains a medium
medium (WM)." - specific to     access control (MAC)
802.11                          and physical layer (PHY)
                                interface to the wireless
                                medium (WM)."

                                Add in clause 3A:"3a.x IEEE
                                802.11 station (STA): Any
                                station that is conformant to
                                IEEE 802.11. Any reference to
                                the term station (STA) in this
                                standard where not qualfied by
                                the term IEEE 802.11 implicitly
                                refers to an IEEE 802.11
                                station.

"However, such classification   Turn into a NOTE--.               AGREE (EDITOR: 2009-07-01 EDITOR
is beyond the scope of this                                       12:25:49Z)
standard." - 802.11 specific
WEP is specific to 802.11.      Move it and its dependent      AGREE (EDITOR: 2009-07-01 EDITOR
                                defintions into 3A: These are: 12:41:56Z)
                                TSN and all definitions
                                dependent on RSN: 3.75,
                                3.97b, 3.97f, 3.97i, 3.97k,
                                3.126, 3.127, 3.130, 3.132,

802.11-specific.                Move to Clause 3A                AGREE (EDITOR: 2009-07-01 EDITOR
                                                                 12:27:20Z)
Annex C serves no useful         Fell Annex C, split it into its DISAGREE (EDITOR: 2009- EDITOR
purpose. It is out of date and component parts and lovingly 09-23 18:52:05Z) - See
potentially misleading. It takes feed them to a virtual fire,    comment resolution of CID
up 200 pages of virtual tree.    SDL statement by SDL            1369.
                                 statement.

The abbreviation for DSSS-      Replace with "Direct sequence     AGREE (EDITOR: 2009-07-01 EDITOR
OFDM is self referential        spread spectrum othogonal         12:46:00Z)
                                frequency division
                                multiplexing" and move a
                                matching definition to 3A.
The abbreviation for ERP is     Add an abbreviation, and          AGREE (EDITOR: 2009-07-01 EDITOR
more like a definition          move this definition to 3A.       12:50:32Z)

Same comment for ERP-*,
NonERP
While I expect this comment to Excoriate the concept of the   DISAGREE (GEN: 2009-09-22 EDITOR
get rejected, it is worth      DS from the standard.          06:20:12Z) The concept of the
getting it off my chest.                                      DS by definition is described in
                                                              "other" places. Removing the
The concept of the DS is                                      concept would not facilitate the
unhelpful. Describing it in the                               interface without the notion of
abstract, without providing                                   a DS. The concept of removal
concrete interfaces to allow                                  of the DS would not
interoperable implementations,                                necessarily be any more
is without value, unless                                      helpful.
someone else has taken up
the burden of providing this
instantiation. In current
practice, almost every AP is
also a portal, and "distribution"
takes place according to 802.1
bridging (or in the network
layer), where it is invisible to
us.

The exception to "every AP is
also a portal" is when a
manufacturer create an
instance of the DS between its
APs. There, the APs need
not contain portals. However,
the APs must necessarily
instantiate the abstract DS
interface provided in Annex O,
so that they can talk together.
The result is that the user
cannot mix and match APs
that shareexpanded heading of
Keep the a DS.                      As in comment.            AGREE (EDITOR: 2009-07-01 EDITOR
5.2.3.2 (for consistency with                                 12:56:54Z)
previous heading) and remove
the note.
"The integration service is         Remove "frame format         AGREE IN PRINCIPLE (GEN: EDITOR
responsible for any addressing      changes" and replace "frames 2009-11-18 01:57:04Z)
or frame format changes that        pass" with "MSDUs pass".     Remove " or frame format
might be required when                                           changes" and replace "frames
frames pass between the DS                                       pass" with "MSDUs pass"
and the integrated LAN."

Frame do not pass above the
MAC SAP. Although it is
unclear from the architecture
diagram where the MAC SAPs
are, it is certainly beneath the
interface of the portal and the
external network.
"A comprehensive statement          On the understanding that any AGREE (MAC: 2009-07-16       EDITOR
on mandatory and optional           statements about mandatory / 16:37:32Z)
functionalities is available in     optional QoS features are
Annex A."                           already present in clauses 6-
                                    11, remove the cited text.
While the PICS is normative,
it is not definitive. Statements
about mandatory or optional
features should exist in the
body proper.
"either in the APs or in the        Change "individual devices" to AGREE (EDITOR: 2009-07-01 EDITOR
individual devices" - 'individual   "non-AP STAs". Also remove 12:58:28Z)
devices' is not defined, and        the two redundant "the's".
could reasonably include the
AP
"health and efficiency" is a        If anybody is going to confuse    DISAGREE (SECURITY: 2009- EDITOR
possibly trademarked term,          the 802.11 standard with a        07-16 15:35:18Z)
being the name of a Naturist        Naturist publication, this term   The phrase does not appear to
magazine.                           should be changed. e.g. to        infringe on any trademarks.
                                    "efficiency and health".

The problem with this             Add to figure 5-7 a designation     DISAGREE (GEN: 2009-11-18 EDITOR
"architecture" is that it doesn't to show where the MAC Data          20:40:26Z) - The commentor
map onto the architecture         SAPs are.                           is encouraged to provide more
diagram in figure 6. We have                                          details of any proposed
some services for which no                                            improvement, but without the
behaviour (and certainly no                                           details of what is proposed,
interfaces) is defined in                                             the group cannot evaluate the
802.11. It would be nice to                                           technical merit at this time.
know where these services
sat. Then we can discover
whether we have truly failed to
describe a bit of functionality
within our scope, or whether
the non-existent services are
unnecessary myths.

It would also be nice to know
where the MAC SAP is. For
example, is the DS below or
above the MAC Data SAP?
"While IEEE Std 802.11 does        Remove cited paragraph, or      DISAGREE (GEN: 2009-09-22 EDITOR
not specify DS                     replace with a statement that   06:40:50Z) While the
implementations, it does           there is no standardized way    commenter may disagree, the
recognize and support the use      to use the 4-address frame to   group believes that the
of the WM as the DSM. This is      provide a wireless DS.          sentence is correct.
specifically supported by the
IEEE 802.11 frame formats."

Come off it. Just defining a
frame format doesn't ensure
interoperability. There is no
interoperable way for APs of
different manufacturers to use
the 4-address format frames to
provide a wireless DS. Until
such a mechanism is defined,
the use of 4-address format as
a wireless DS should be
considered a proprietary
extension.


"While IEEE Std 802.11 does Rewrite to acknowledge the             DISAGREE (GEN: 2009-09-22 EDITOR
not specify DS                limitation of the DS.                06:51:54Z) The commenter is
implementations, it does                                           sollicited to provide a
recognize and support the use                                      submission. The DS within the
of the                                                             AP is not essentially an
WM as the DSM. This is                                             Association Table.
specifically supported by the
IEEE 802.11 frame formats."

This is not how it works. The
DS within an AP is essentially
its association table. An AP
decides to relay within its BSS
or send it up to its MAC SAP
based on this table. The
802.1 bridging component
above the MAC SAP decides
which interfaces of any
attached integrated LAN
media the MSDU is sent to.
When two STAs within two
BSSs are members of the
same ESS (notionally the
same DS according to our
architecture), a message from
one to the other exits the DS,
is bridged by 802.1, and re-
enters the DS at the AP
supporting.

The notion of ESS is
important, because it probably
implies that all APs of this ESS
There are a handful of shalls    Consider moving normative     AGREE IN PRINCIPLE (GEN: EDITOR
and mays in clause 5.            statements out of clause 5.   2009-09-24 19:38:53Z) --
                                                               Agree in principle -- all the
Please consider whether                                        listed instances of "shall" in
normative requirements                                         clause 5 already have
should be allowed in Clause 5.                                 normative text in other
If it is considered that this                                  sections, so the cited changes
material is introductory,                                      do not change any normative
people may miss normative                                      behavior.
requirements there.
                                                               Editor is instructed to make
                                                               following changes:
                                                               5.2.2, change "STA shall
                                                               become" to "STA becomes"
                                                               5.2.6, penultimate paragraph,
                                                               change "shall not use" to "do
                                                               not use"
                                                               5.2.6, final paragraph, change
                                                               "shall act" to "acts"
                                                               5.4.1.2, change "shall invoke"
                                                               to "invokes"
                                                               5.4.2, change "shall be" to
                                                               "is"
                                                               5.4.2.2, second paragraph,
                                                               change "shall first become" to
                                                               "first becomes"
                                                               5.4.2.4, final paragraph,
                                                               change "STAs shall attempt" to
                                                               "STAs attempt"
                                                               5.4.3.1, second paragraph,
                                                               change "shall not be
                                                               established" to "is not
"Two services are provided to Delete cited text.               established"
                                                               AGREE (SECURITY: 2009-08- EDITOR
bring the IEEE 802.11                                          14 16:29:04Z)
functionality in line with wired
LAN assumptions:
authentication and data
confidentiality. Authentication
is used instead of the wired
media physical
connection. Data
confidentiality is used to
provide the confidential
aspects of closed wired
media."

This material has been
superseded by the following
two paras.
"Management information        Remove cited text, or replace       AGREE IN PRINCIPLE       EDITOR
base (MIB) functions are       it with something meaningful.       (SECURITY: 2009-08-14
provided in Annex D to support                                     16:30:24Z)
the standardized                                                   Delete the cited text.
authentication schemes."

What does this mean? I
haven't the foggiest, and I
suspect that TGmb won't
either.
If the SME is a separate part of   Review clause 10 and 11 for     DISAGREE (GEN: 2009-11-18 EDITOR
our architecture, we should        normative requirements on the   20:41:02Z) - The commentor
have a separate clause             SME and move them into a        is encouraged to provide more
devoted to specifying its          new clause called "SME".        details of any proposed
normative requirements.                                            improvement, but without the
                                                                   details of what is proposed,
At the present there are a                                         the group cannot evaluate the
number of normative                                                technical merit at this time.
requirements on the SME,
usually couched in terms of "a
STA shall...", e.g. A STA shall
authenticate before it
associates.

These are usually in clause 10
or 11. Clause 11 is definitely
the wrong place for them, and
nobody reads clause 10.
The use of EAPOL requires         Add a SAP at the top of the      DISAGREE (GEN: 2009-11-18 EDITOR
that data frames encode the       MLME with a MLME-                20:41:24Z) - The commentor
data using a specific             ManagementData.request           is encouraged to provide more
Ethertype. The multiplexing       primitive that takes the usual   details of any proposed
or demultiplexing by Ethertype    parameters, plus an              improvement, but without the
must occur above the MAC          EtherType as parameters.         details of what is proposed,
data SAP, because it is part of                                    the group cannot evaluate the
the MSDU, and a service        Add descriptive text split into     technical merit at this time.
must consider its data to be   the usual primitive sections
arbitrary and opaque.          something like: "This primitive
                               is generated by the higher
The MLME is the recipient of layers to route MSDUs that
these EAPOL frames, because actually carry MAC
it later emits various MLME-   management information back
EAPOL primitives to the SME. into the MAC. The MLME
                               uses the EtherType parameter
So how does the data get back to determine which
from the demultiplexing entity encapsulation protocol is being
to the MLME?                   employed. The entity in the
                               link layer that demultiplexes
                               received MSDUs on
                               EtherType sends those
                               carrying one of the EtherTypes
                               used by 802.11 to carry
                               management information to
                               this SAP."

                                  Recommend this issue is
                                  discussed with ARC before
                                  adopting a resolution.

The VSPECIFIC primitives          Change the description of the    AGREE (ARCHITECTURE:     EDITOR
describe the                      VendorSpecificParmeter to        2009-07-16 06:35:52Z)
VendorSpecificContent thus:       something like:
"A set of information elements
as                                "Determined by the entity to
defined in 7.3.2 (Information     whom the OUI is registered."
elements). A set of vendor-
specific fields specifying the
required fields for the Vendor
Specific Action frame."

The implication is that the
frame following the OUI can be
parsed as a set of information
elements. This is not the
consistent with Clause 7.
"If the SME wants to set up a      Remove cited sentence, or           DISAGREE (SECURITY: 2009- EDITOR
security association to the        add appropriate SAP                 08-14 16:32:52Z)
peer STA, but does not             interfaces to support this          The SME can use the
know the security policy of the    function.                           MLME.Scan primitive to
peer, it should send a Probe                                           determine the security policy
Request frame to the peer                                              on the peer STA.
STA to find its
security policy before setting
up a security association to the
peer STA."

How does it achieve this?
What SAP interfaces does the
SME use to send this probe
request.
"defragmentation if security is    change to: defragmentation if       AGREE (EDITOR: 2009-07-01 EDITOR
used" - missing a "not"            security is not used                14:34:04Z)
"The order of the                  Seeing that the OUI doesn't         AGREE (ARCHITECTURE:      EDITOR
organizationally unique            have an individual/group bit        2009-11-17 22:58:38Z)
indentifier (OUI) field follows    and is not specified as an
the ordering convention for        ordered sequence of bits, this
MAC                                specification is utterly useless.
addresses from 7.1.1
(Conventions)."                   Add: "OUIs are specified in
                                  two forms: an ordered
But in 7.1.1, the only thing that sequence of octets, and a
is said about MAC addresses numeric form. Treating the
is: "MAC addresses are            OUI as an ordered sequence
assigned as ordered               of octets, the leftmost octet is
sequences of bits. The            always transferred first. This
Individual/Group bit is always is equivalent to transmitting
transferred                       the most significant octet of
first and is bit 0 of the first   the numeric form first."
octet."
                                  Add reference to this to
                                  replace the first cited text in
                                  the comment, and perform the
                                  same on p312.62.
"The exact functions of the   Another of my comments             AGREE IN PRINCIPLE            EDITOR
SME are not specified in this suggests bundling all of the       (ARCHITECTURE: 2009-11-
standard,"                    SME requirements into a new        18 20:28:21Z) - Replace cited
                              clause. If this is done, the       text with: "Some of the
This is misleading. There are cited text can be replaced by a    functions of the SME are
many requirements expressed reference to this clause.            specified in this standard"
as "a STA shall..." that are
executed by the SME. For      Otherwise replace cited text
example, the need to          with: "Some of the functions of
authenticate before           the SME are specified in this
association.                  standard", or perhaps:

                                "We were too lazy to sort this
                                out for ourselves, but some
                                bits of the SME are specified
                                and others are not - but we're
                                not going to tell you which is
                                which. You go figure."


"In particular, PHY             Remove cited text.               AGREE (ARCHITECTURE:        EDITOR
implementations are not                                          2009-07-16 06:36:08Z)
required to have separate
interfaces
defined other than their
interfaces with the MAC and
MLME."

This is misleading an
unnecessary. The only
requirments on a PHY
implementation are its OTA
behaviour. The PHY-MAC
and PHY-SME interfaces are
not exposed.
"SAP primitives are of the   Replace cited text with: "SAP AGREE (ARCHITECTURE:              EDITOR
general form ACTION.request primitives are of the general  2009-11-18 20:29:41Z)
followed by ACTION.confirm." form ACTION.request followed
                             by ACTION.confirm (for an
What about                   exchange initiated by the SAP
indication/response?         client) and ACTION.indication
                             followed by ACTION.response
                             (for an exchange initiated by
                             the MLME)."

What we have here is a table   Separate out capability and     AGREE IN PRINCIPLE               EDITOR
that provides a mixture of     status information into two MIB (SECURITY: 2009-09-22
static capability and active   variables.                      00:44:12Z)
status as the encoding for a                                   Delete the first sentence in the
MIB variable.                                                  first two rows in the "Notes"
                                                               column, and change the table
This is confusing, and counter                                 title to match any renaming of
to the ARC group's policy on                                   the MIB variable.
MIB variables.
"Present only if the value of Replace "greater than 1" with            AGREE (ARCHITECTURE:         EDITOR
dot11RRMMeasurementPilotC "non-zero".                                  2009-07-16 06:36:23Z)
apability is greater than 1."

This excludes the case of 1,
which includes a STA
receiving measurement pilots.

"The parameter sets relevant       List, for each attached PHY,        DISAGREE                        EDITOR
to the PHY from the received       which are the relevant              (ARCHITECTURE: 2009-11-
Beacon or Probe Response           parameters.                         18 20:41:45Z) - The
frame."                                                                commentor is encouraged to
                                                                       provide more details of any
This is inadequate                                                     proposed improvement, but
specification.                                                         without the details of what is
                                                                       proposed, the group cannot
                                                                       evaluate the technical merit at
                                                                       this time.
"The STA must be able to           Remove cited text in both           AGREE (ARCHITECTURE:            EDITOR
receive at each of the data        rows.                               2009-11-19 01:20:16Z) -
rates listed in
the set."

This is odd - certainly when
BSS Description relates to a
scan confirm primitive. Which
STA? "Must" is deprecated by
the IEEE-SA style guide.

Ditto in the previous row.

This table references "the         Add the following after             AGREE (ARCHITECTURE:         EDITOR
STA" - but the antecedent is       "elements" on line 48:              2009-11-19 01:16:07Z)
not clear. Is it the local STA,
or some other STA? In some         ", in which the term
cases it is the local STA (Local   <italic>peer STA</italic> refers
Time), and in others a             to the STA transmitting the
property of the BSS                Beacon frame or Probe
(BSSBasicRateSet) or the STA       Response frame from which
transmitting the                   the BSSDescription was
Beacon/ProbeResponse               determined and the term
(OperationalRateSet).              <italic>local STA</italic> refers
                                   to the STA performing the
                                   scan"

                                   Insert peer at 432.30, 432.38.
                                   Insert local at 432.3.
This table references "the        Add the following after             AGREE (ARCHITECTURE:              EDITOR
STA" - but the antecedent is      "elements" on line 48:              2009-11-19 01:16:34Z)
not clear. Is it the local STA,
or some other STA?                ", in which the term
                                  <italic>peer STA</italic> refers
                                  to the STA transmitting the
                                  Measurement Pilot frame from
                                  which the BSSDescription was
                                  determined and the term
                                  <italic>local STA</italic> refers
                                  to the STA performing the
                                  scan"

                                  Insert peer at 434.44, 434.50.
                                  Insert local at 434.36.



"only present" is wrong           Change to "present only" and        AGREE (EDITOR: 2009-07-03 EDITOR
                                  move sentence to end of cell.       12:54:53Z)
Often one or both of the          For each entry where this           AGREE IN PRINCIPLE            EDITOR
Type/Valid Range columns          occurs, replace "as defined in      (EDITOR: 2009-07-03
have "As defined in frame         frame format" in the Type entry     13:27:31Z) - Replace each "as
format".                          with the name of the type "e.g.     defined in frame format" or
                                  EDCA Parameter Set element"         "frame format" as follows:
This is lazy specification.       and replace "as defined in
                                  frame format" in the Valid          Where this occurs in the Type
                                  range entry with "As defined        entry, replace with the name of
                                  in 7.x.x.x." with reference to      the type "e.g. EDCA
                                  the subclause where the             Parameter Set element".
                                  element is defined.                 Where this occurs in the Valid
                                                                      Range entry, replace with "As
                                                                      defined in 7.x.x.x." with
                                                                      reference to the subclause
                                                                      where the element is
                                                                      defined.

                                                                      Merge with any existing
                                                                      additional specification in
                                                                      these cells.

                                                                      However, do not modify BSS
                                                                      Description / PHY Parameter
                                                                      Set, as it is not obvious from
                                                                      the description what are the
                                                                      appropriate
                                                                      structures/references.

                                                                      In 10.3.14.1.2, 10.3.13.2.2,
                                                                      10.3.14.3.2
                                                                      replace:
                                                                       "as defined in the
Some newlines missing from        Insert missing newlines and         Measurement Report element EDITOR
                                                                      AGREE (EDITOR: 2009-07-03
RCPI,...                          align text                          12:57:13Z)
"Shared Key authentication          Replace with: "Shared Key           AGREE (SECURITY: 2009-07- EDITOR
can be used if and only if WEP authentication may be used if            14 22:01:14Z)
has been selected."                 WEP has been selected and
                                    shall not be used otherwise."
"can" and "if and only if" are
conflicting - one implies
information, the other
expresses a constraint.
There's a lot of "if and only if" Change "if and only if" as            AGREE (ARCHITECTURE:     EDITOR
going on in clause 10.              follows:                            2009-11-16 15:56:54Z)
                                    p446.05 -> if
These uses are often wrong or p448.51 -> only if
unnecessary. In a request or p451.19 & 26 -> only if
response, it is more                p453.25 & 32 -> if
appropriate to use "if" - i .e.     p455.4 -> if
expressing a requirement to         p455.51 -> only if
be present. In an indication or p460.31 & 36 -> only if
confirmation, it is more            p462.27 & 35 -> if
appropriate to use "only if" -      p469.37 -> if
meaning that this information
is not availble if not some
condition (and there are often
additional reasons for it not to
be present that are not
admitted in the "if and only if"
construct).
Incorrect use of "if and only if" - Replace "if and only if" with       AGREE (SECURITY: 2009-07- EDITOR
which implies logical               "only if" on line 5 and line 23.    14 22:01:40Z)
correspondance. i.e. line 5
implies that all frames are
class 2 if the STA is
authenticated - which is clearly
rubbish.
Incorrect use of "if and only if" - Replace cited sentence with:      AGREE IN PRINCIPLE (GEN: EDITOR
which implies logical                                                 2009-11-19 05:15:59Z) The
correspondance, not a               "The state variable for the AP    Editor is instructed to
sequence of dependent               shall be set to State 2 if it was incorporate into the REVmb
events.                             not State 1, and shall not be     draft document 11-09/705r4.
                                    modified otherwise."              (https://mentor.ieee.org/802.11
                                                                      /dcn/09/11-09-0705-04-000m-
                                                                      proposed-corrections-to-11-3-
                                                                      sta-authentication-and-
                                                                      association.doc)
Incorrect use of "if and only if" - Replace cited sentence with: AGREE IN PRINCIPLE (GEN: EDITOR
which implies logical                                                 2009-11-19 05:15:59Z) The
correspondance, not a               "The state variable for the AP Editor is instructed to
sequence of dependent               shall be set to State 2 if it was incorporate into the REVmb
events.                             not State 1, and shall not be draft document 11-09/705r4.
                                    modified otherwise."              (https://mentor.ieee.org/802.11
                                                                      /dcn/09/11-09-0705-04-000m-
                                                                      proposed-corrections-to-11-3-
                                                                      sta-authentication-and-
                                                                      association.doc)
Incorrect use of "if and only if"   Note, cited text already      AGREE (SECURITY: 2009-07- EDITOR
in the following: "A STA shall      contains a normative          14 22:01:49Z)
accept a Measurement                requirement to reject
Request with the parallel bit       "otherwise" so the wrong "and
field enabled if and only if        only if" is also redundant.
dot11RRMParallelMeasurenm
entEnabled is true; otherwise,      Delete: "and only if" from the
the STA shall reject the            cited text.
Measurement Request by
returning a Measurement
Report with the Incapable bit
set in the Measurement Report
Mode field."

Incorrect use of "if and only if" Replace "A STA will use the       AGREE IN PRINCIPLE              EDITOR
                                  defined TPC and DFS               (EDITOR: 2009-07-23
Same comment line 56.             procedures if and only if this    14:18:42Z)
                                  attribute is TRUE."               Replace cited sentence with:
                                                                    "A STA will use the defined
                                    With: "A STA will use the       TPC and DFS procedures if
                                    defined TPC and DFS             this attribute is TRUE;
                                    procedures if this attribute is otherwise it will not use the
                                    TRUE, otherwise it will not use defined TPC and DFS
                                    the defined TPC and DFS         procedures."
                                    procedures."
                                                                    Replace sentence at 1317.55
                                    Make matching change in line with: "A STA will use the
                                    55.                             defined regulatory classes
                                                                    procedures if this attribute is
                                                                    TRUE; otherwise it will not use
                                                                    the defined regulatory classes
                                                                    procedures.(#1448)"
"The default values are             Clarify how the default values DISAGREE                         EDITOR
implementation dependent."          can be implementation           (ARCHITECTURE: 2009-11-
                                    dependent, while many of        18 20:42:03Z) - The
If this is true, why do we have     them are also specified in      commentor is encouraged to
defval statements in Annex D?       Annex D.                        provide more details of any
                                                                    proposed improvement, but
                                                                    without the details of what is
                                                                    proposed, the group cannot
                                                                    evaluate the technical merit at
                                                                    this time.
What point is there in having a     Remove ResultCode               AGREE (ARCHITECTURE:            EDITOR
parameter which carries an a-       parameter.                      2009-07-16 06:37:12Z)
priori known value?
The MIB is a mess.                    This confusion can be              AGREE IN PRINCIPLE             EDITOR
Specifically there is confusion       remedied by labelling each         (ARCHITECTURE: 2009-11-
as to which entity writes many        MIB variable as described in       17 22:26:14Z) See CID 1005 --
variables, and the effect of          11-09/0533r1.                      "Editor is instructed to make
this writing.                                                            the changes as recorded in 11-
                                 Where no such labelling can             09/910r6."
                                 be applied, consider either
                                 removing the MIB variable, or
                                 splitting it into multiple
                                 variable, each with a clear
                                 label.
There are lots of "shalls" in    Clarify, in the case of control         AGREE IN PRINCIPLE           EDITOR
Annex D: "shall specify", "shall variables, which entity polices         (ARCHITECTURE: 2009-11-
indicate", "shall be", "shall    the "shall"s. Or remove the             17 22:29:16Z) Remove the
include".                        shalls.                                 shalls.

In cases where this is a status
or capability, I suppose that it
is clear that the normative
requirement is on the local
entity to fill that variable with a
value as specified. Although
puttin a normative requirement
into the description text seems
a bit off.

In the case where the variable
is a control, written by a
remote entity, the question
arises as to who is responsible
for ensuring compliance to any
normative requirement
expressed in the description.
Is it the user (who can read the
description), the remote
management entity, or the
local entity?


"or IBSS (where the MAC               I think the RESET request          AGREE IN PRINCIPLE              EDITOR
entity was the first STA in the       does everything you need for       (ARCHITECTURE: 2009-11-
IBSS)."                               the IBSS case, so I'd make         19 01:17:40Z) Delete cited text
                                      this primitive specific to the     and the fourth and fifth
While it is possible to stop          infrastructure case.               sentances in 10.3.10a.1.4
operation of the local STA in
an IBSS, once a STA has               Alternatively describe it as
started an IBSS, it has no            having local significance only
control over the continued            in the IBSS case and take out
existence of the IBSS in the          the contraint in the parenthesis
case that other STAs have             of the cited text.
joined the IBSS.
"Note that..."                     If not, turn into a proper         AGREE IN PRINCIPLE               EDITOR
                                   "NOTE--". If so, use the           (ARCHITECTURE: 2009-11-
Does this text introduce any       proper normative languge.          16 15:58:29Z) Just delete the
new normative requirements?                                           cited Text




Text earlier in 10.3.11            Remove the MLME-                AGREE (ARCHITECTURE:                EDITOR
indicates these figures are        CHANNELSWITCH.cmf at the 2009-11-19 01:18:28Z)
illustrative only. .confirms are   bottom right of figure 10-6 and
(by convention) associated         the box "channel switch
with matching .requests. This      complete".
figure shows a .confirm without
a matching .request. There
are no normative statements
that describe this behaviour.

I wonder how many will notice Translate caption into English. AGREE (EDITOR: 2009-07-03 EDITOR
this one.                                                     12:58:01Z)

Anyway, it's all greek to me.
This primitive highlights a   Add at least a parameter                AGREE IN PRINCIPLE            EDITOR
weakness in the MLME-SME indicating the rate of the                   (ARCHITECTURE: 2009-11-
interface. The question is    request frame in the .confirm.          18 21:18:43Z) Add a
who selects the rate at which                                         parameter indicating the rate
frames (and in particular the                                         of the measured request frame
TPC Request frame) are sent?                                          to the .confirm parameters.

Knowing a link margin is of no
use without also knowing what
rate or MCS it relates to.


"Authenticator/Supplicant or        Replace with "Is Authenicator".   AGREE (ARCHITECTURE:             EDITOR
Initiator/Peer"                     Replace description with:         2009-11-18 21:18:23Z) (note
                                    "Indicates whether the key is     typo -- "configures" should be
Taking the "/" as "or" - there      configures by the                 "configured")
are two levels of or in this. It is Authenticator or Supplicant.
not immediately clear whether True indicates Authenticator."
the boolean value selects the
innermost "/" or the outmost
level.
If the SME is required to           Consider adding reference to      AGREE (ARCHITECTURE:             EDITOR
respond to MIC failures in          8.3.2.4                           2009-07-16 06:37:38Z) Add
some way, this should be                                              "(see 8.3.2.4)".
referenced here.
"Rx: Specifies that data frames Replace with: "Rx: Specifies        AGREE IN PRINCIPLE             EDITOR
from MAC address is               that data frames from MAC         (ARCHITECTURE: 2009-07-
protected."                       address are protected (i.e.,      31 15:47:09Z) - As specified
                                  any data frames without           by commenter. Also, insert
Surely it is specifying that data protection received from the      "the" ahead of "MAC address"
frames received from the MAC MAC address will be                    where necessary in all bullets
address without protection will discarded)."                        in this list.
be discarded? It cannot affect
whether the peer chooses to
use protection or not, it can
only determine what the local
entity does with those frames.


Grammar: "is" should be "are" As in comment.                        AGREE (EDITOR: 2009-07-03 EDITOR
throughout this list.                                               13:01:26Z)
Encryption is limiter to per-link, Replace "SA" with "TA".          AGREE (ARCHITECTURE:      EDITOR
so the correct address to use                                       2009-11-18 21:22:12Z)
for Address1 is the transmitter
address, not the source
address.

"It is valid at the non-AP STA" -   the -> a                        AGREE (EDITOR: 2009-07-03 EDITOR
no antecedent has been                                              13:02:37Z)
established
The "(0 or more)" against           Remove cited text. Add "Zero AGREE (EDITOR: 2009-07-03 EDITOR
TCLAS should be in the              or more TCLAS elements." at 13:07:24Z)
Description column for              the front of the Description
consistency.                        column.

                                    Make same change wherever
                                    this occurs in Clause 10.

                                    Likewise, remove "(HC only)"
                                    in the Name column and
                                    replace "(At the HC only)" in
                                    the Description column with
                                    "Present only at the HC."
                                    throughout Clause 10.

"as a result of receipt of an Replace cited text with "having AGREE IN PRINCIPLE             EDITOR
                              received a DELTS frame from (EDITOR: 2009-08-11
initiation to delete a TS ..." -
ah, truly awesome English.    the specified peer MAC entity" 12:26:33Z) - Replace cited text
                                                              with "when it receives a
                                                              DELTS frame from the
                                                              specified peer MAC entity"
"Specifies the operational    Replace cited text with:        AGREE (ARCHITECTURE:           EDITOR
capability definitions to be  "Specifies the capabilities of  2009-07-16 06:38:20Z)
used by the peer MAC entity." the peer MAC entity."

We cannot specify the peer's
capabilities.

Same comment at 519.26
This fails to specify what           Indicate what happens to     DISAGREE                        EDITOR
happens to any buffered              buffered MPDUs when this is  (ARCHITECTURE: 2009-11-
MPDUs at the time of the             received.                    18 20:43:03Z) - The
delete.                                                           commentor is encouraged to
                                     To avoid creating any        provide more details of any
                                     backwards-compliance issues, proposed improvement, but
                                     this should be phrased as a  without the details of what is
                                     recommendation.              proposed, the group cannot
                                                                  evaluate the technical merit at
                                     For example: "The STA        this time.
                                     should pass up the protocol
                                     stack any MPDUs for this
                                     Block Ack agreement held in
                                     the reordering buffer.

Review and remove any                As in comment.                    AGREE (EDITOR: 2009-06-29 EDITOR
Editor's Note that relates to                                          11:39:49Z)
interpretations of the k,r,y
amendments.
"On receipt of this primitive the                              AGREE IN PRINCIPLE
                                     If they do, the cited statement                           EDITOR
SME should operate according                                   (ARCHITECTURE: 2009-11-
                                     is unnecessary. In that case
to the procedure in 11.11.2."                                  19 01:19:10Z) - Change
                                     replace "should operate" with
                                     "operates".               "should operate" to "operates",
Either the procedures in                                       and change cross reference to
11.11.2 adequately            If they don't, extend 11.11.2 so 11.10.9.2.
normatively describe what     that they do, and also make
should be done on receiving a the change indicated above.
Neighbor Report request, or
they do not.                  Make similar changes
                              whereever similar language is
                              used in Clause 10.

"On receipt of this primitive,       Replace cited text with "No       AGREE (ARCHITECTURE:     EDITOR
the SME evaluates the                effect is specfied for the        2009-11-18 21:23:36Z)
ResultCode."                         receipt of this primitive."

Oh whoopty do. I sense               Scan all primitives and replace
straws being clutched: "what         similar nugatory specification
shall we specify for this bit?".     with a similar phrase.

If no effect is specified - say as
such.

superfluous space before             Remove it.                        AGREE (EDITOR: 2009-07-03 EDITOR
"element"                                                              13:10:49Z)
Generally in clause 10 "only         Replace with "present only"       AGREE (EDITOR: 2009-07-03 EDITOR
present" is incorrect.               globally.                         12:51:00Z)
superfluous space before "(s)"       Remove it.                        AGREE (EDITOR: 2009-07-03 EDITOR
                                                                       13:11:48Z)
"This primitive is a request by   remove "by the LME".                AGREE IN PRINCIPLE           EDITOR
the LME to reset the PHY"                                             (ARCHITECTURE: 2009-11-
                                                                      17 21:39:13Z) Change "LME"
1. There is no such thing as                                          to "SME" in the following
an LME                                                                clauses:
2. The client is not important,                                       10.4.1.1 and 10.4.2.1,
and could be MLME or SME                                              10.4.2.3, 10.4.5.1, and
                                                                      14.4.3.2.
Ditto comment p570.06,
p170.19




Spurious left paren.              Remove it.                          AGREE (EDITOR: 2009-07-03 EDITOR
                                                                      13:13:40Z)

A normative requirement           Replace "shall be" with "are".      AGREE (ARCHITECTURE:         EDITOR
cannot be placed on more                                              2009-07-16 06:38:38Z)
than one STA.

The sentence here doesn't
add to any existing normative
statment.
"All STAs shall maintain a local remove "shall".                      AGREE (ARCHITECTURE:         EDITOR
TSF timer."                                                           2009-07-16 06:38:53Z)

Adds nothing to line 48.
There are 15 instances of         Replace all "shall always" with AGREE (GEN: 2009-09-22           EDITOR
"shall always". But a shall       "shall"                         22:03:00Z)
statement is normative, not
normative some of the time.
"shall always" is therefore
unnecessary.
"If a STA that does not support   Indicate this rule is specific to   AGREE (ARCHITECTURE:         EDITOR
Short Slot Time associates,       a Clause 19 AP.                     2009-07-16 06:39:08Z)
the AP shall use long slot time
beginning at the
first Beacon subsequent to the
association of the long slot
time STA."

This should be specific to PHY
"shall adopt that beacon       Relate to some observable               AGREE IN PRINCIPLE              EDITOR
period" - what does this mean? change in state or behaviour.           (ARCHITECTURE: 2009-11-
                                                                       19 17:49:47Z) Change cited
Same comment for any other                                             text "and STAs shall adopt that
use of "shall adopt"                                                   beacon period when joining
                                                                       the BSS."
                                                                       To
                                                                       "and a STA shall adopt that
                                                                       beacon period when joining
                                                                       the BSS, i.e., the STA sets its
                                                                       dot11BeaconPeriod variable to
                                                                       that beacon period".

"wildcard SSID" appears to be    Ajust font as necessary.         AGREE (EDITOR: 2009-07-03 EDITOR
in a smaller font                                                 13:14:56Z)
"The probe response shall be     Either remove cited sentence, AGREE (ARCHITECTURE:           EDITOR
sent using normal frame          or adjust it to cite which rules 2009-11-18 21:24:45Z)Delete
transmission rules." - i.e.,     are to be used.                  the cited text
stop using abnormal rules :0)

This is not specific enough
"In an IBSS, the STA that        Replace with: "In an IBSS, a AGREE (ARCHITECTURE:                  EDITOR
generated the last Beacon        STA that transmitted a Beacon 2009-11-18 21:24:57Z)
frame shall be the STA that      frame since the last TBTT
responds to a probe request."    shall respond to probe
                                 requests."
This may not be correct.
There may be more than one
STA, so "the STA" is
incorrect.



"Wait until the ProbeDelay       I think we should at least            DISAGREE                        EDITOR
time has expired" - what         recommend a default value             (ARCHITECTURE: 2009-11-
constraints are there on the     for this, otherwise there is little   18 20:43:32Z) The
SME in choosing a value for      value in having the delay.            commentor is encouraged to
this parameter? (answer:                                               provide more details of any
none).                                                                 proposed improvement, but
                                                                       without the details of what is
What value do manufacturers                                            proposed, the group cannot
typically choose (some choose                                          evaluate the technical merit at
zero delay)?                                                           this time.

The purpose of ProbeDelay is
to avoid damaging onging
communications that the
scanning STA cannot receive
(either range or unsupported
options). As such, it should
be scaled to a "typical packet
size" - whatever that is.
"using normal frame              Cite the specific rules.      AGREE IN PRINCIPLE (MAC: EDITOR
transmission rules," - it is                                   2009-09-25 03:49:24Z) -
unclear which rules are                                        Remove all references to
abnormal, and therefore also                                   "normal" access rules.
which are normal.                                              Change the cited sentence to
                                                               read: "...AP shall transmit
                                                               buffered broadcast/multicast
                                                               MSDUs, before transmitting
                                                               any unicast frames." Also,
                                                               strike sentences at 583.8 and
                                                               583.31 using the phrase
                                                               "normal transmission rules"
                                                               because the phrase has no
                                                               normative meaning. At
                                                               596.19, change the sentence
                                                               regarding "normal DCF access
                                                               procedure" to read "These
                                                               frames shall be transmitted
                                                               using the DCF or EDCAF." At
                                                               618.65, delete the phrase
                                                               "using the normal access
                                                               mechanisms." At 619.2,
                                                               delete the phrase "using the
                                                               normal access mechanisms."
                                                               At 366.23, delete the word
                                                               "normal".

"The AP may modify the            Replace cited text with: "The AGREE (MAC: 2009-09-25   EDITOR
service start time by             AP may modify the service      03:50:19Z)
indicating so in the Schedule     start time by indicating so in
element in ADDTS Response         the Schedule element in an
frame and in Schedule frames"     ADDTS Response frame
                                  (which is sent in response to
It is not clear if this is giving an ADDTS Request frame)
the AP permission to transmit and in Schedule frames (which
unsolicited ADDTS Response are sent at other times)."
frames.

"temporarily buffer the MSDU     replace "management frame"    AGREE (MAC: 2009-09-30    EDITOR
or management frame              with MMPDU                    14:54:20Z)
destined to the STA" - chalk
and cheese                       Make similar changes
                                 throughout 11.2.1.5 in this
                                 context.




"shall buffer frames" - but it is Change to "shall buffer      AGREE (MAC: 2009-09-25    EDITOR
MSDUs and MMPDUs that are MSDUs"                               03:50:51Z)
buffered.
"For a non-AP STAs" -             STAs -> STA                  AGREE (EDITOR: 2009-07-03 EDITOR
grammar                                                        13:23:55Z)
"For a non-AP STAs using U-        Replace "frame" with "MSDU" AGREE IN PRINCIPLE (MAC: EDITOR
APSD, the AP transmits one                                     2009-07-14 16:24:30Z) - The
frame destined for the non-AP                                  unit of buffering is the
STA from any AC that is not                                    MSDU/MMPDU. The editor is
delivery-enabled in response                                   instructed to make similar
to PS-Poll from the non-AP                                     changes to "frame" language
STA."                                                          in 7.3.2.6, 9.3.2.1, 9.9.2.0a,
The unit of buffering is the                                   11.2.1.4, and 11.2.1.5.
MSDU, not the frame.
When all ACs associated with       Replace "frame" with "MSDU" AGREE (MAC: 2009-08-07        EDITOR
the non-AP STA are delivery-                                   00:11:31Z)
enabled, AP transmits one
frame from the highest priority
AC.
The unit of buffering is the
MSDU, not the frame
"If there are buffered frames to   Replace "frames" with         AGREE IN PRINCIPLE (MAC: EDITOR
transmit to the STA" - unit of     "MSDUs or MMPDUs"             2009-07-14 16:24:30Z) - The
buffering is wrong                                               unit of buffering is the
                                   Make same change to           MSDU/MMPDU. The editor is
                                   "pending frames" (line 52 and instructed to make similar
                                   line 55).                     changes to "frame" language
                                                                 in 7.3.2.6, 9.3.2.1, 9.9.2.0a,
                                                                 11.2.1.4, and 11.2.1.5.

Multiple occurances of             Replace frames with "MSDUs AGREE IN PRINCIPLE (MAC: EDITOR
buffered frames - unit of          or MMPDUs" on lines:       2009-07-14 16:24:30Z) - The
buffering is wrong.                8,10,15,18,20, 47.         unit of buffering is the
                                                              MSDU/MMPDU. The editor is
                                                              instructed to make similar
                                                              changes to "frame" language
                                                              in 7.3.2.6, 9.3.2.1, 9.9.2.0a,
                                                              11.2.1.4, and 11.2.1.5.

An MSDU is not                     In "If the AP does not receive   AGREE (MAC: 2009-08-07   EDITOR
acknowledged - a Data frame        an acknowledgment to a           01:16:51Z)
is.                                directed MSDU or
                                   management frame sent"
                                   replace "MSDU" with "data
                                   frame"

                               Make same change on line 39
                               and on 594.41, 594.44
"An AP shall, depending on     The "shall buffer" related to    AGREE (MAC: 2009-08-07       EDITOR
the Power Management mode management frames should              01:16:31Z)
of the STA, temporarily buffer be restricted to action frames
the MSDU or management         only - i.e. "shall ... buffer an
frame destined to the STA."    MSDU or MMPDU that will be
                               transmitted using an Action
                               frame."

                                   Make similar changes
                                   throughout 11.2, making
                                   adjustment for grammar as
                                   necessary.
The unit of buffering is the  Replace frames with "MSDUs          AGREE IN PRINCIPLE (MAC: EDITOR
MSDU/MMDPU, not the           or MMPDUs" on lines:                2009-07-14 16:24:30Z) - The
frame.                        21.                                 unit of buffering is the
                              Replace "MSDUs" with                MSDU/MMPDU. The editor is
Action frames may be          "MSDUs and MMPDUs" on               instructed to make similar
buffered, and these may have lines 23, 24, 25 and 594.11,         changes to "frame" language
a broadcast receiver address, 594.13, 594.15, 594.32,             in 7.3.2.6, 9.3.2.1, 9.9.2.0a,
so MSDU needs to includ       594.34, 594.35, 594.36              11.2.1.4, and 11.2.1.5.
MMPDU.

The unit of buffering is the      Replace "buffered broadcast     AGREE IN PRINCIPLE (MAC: EDITOR
MSDU/MMDPU, not the               and multicast frames" with      2009-07-14 16:24:30Z) - The
frame.                            "buffered MSDUs and             unit of buffering is the
                                  MPDUs" on line 33.              MSDU/MMPDU. The editor is
                                                                  instructed to make similar
                                                                  changes to "frame" language
                                                                  in 7.3.2.6, 9.3.2.1, 9.9.2.0a,
                                                                  11.2.1.4, and 11.2.1.5.

"MSDUs and MMPDUs                 What are the rules for          AGREE IN PRINCIPLE (MAC: EDITOR
belonging to those ACs" - so      determination of the AC of an   2009-09-30 14:57:21Z) - The
what AC does an MMPDU             MMPDU? They should be           "belonging to" language is
belong to?                        referenced here.                changed by CID 1146. In D1.0
                                                                  clause 9.1.3.1, the text states
                                                                  that "...management frames
                                                                  shall be sent using the access
                                                                  category AC_VO without being
                                                                  restricted by admission control
                                                                  procedures."


"The non-AP STA shall remain      replace "QoS data frame" with AGREE (MAC: 2009-08-07         EDITOR
awake until it receives a QoS     "QoS data frame or            01:17:13Z)
data frame addressed to it,       management Action frame".
with the
EOSP subfield in the QoS
Control field set to 1." - this
can also be terminated by a
management frame
"deliver-enabled ACs" -type       deliver -> delivery             AGREE (MAC: 2009-09-25         EDITOR
                                                                  03:54:15Z)
The description in this     Add MMPDUs to the                     AGREE IN PRINCIPLE (MAC: EDITOR
subclause does not          description here.                     2009-11-13 20:03:05Z) - Add
acknowledge power-saving of                                       "and MMPDU" or "or MMPDU"
MMPDUs.                                                           as appropriate throughout this
                                                                  subclause after "MSDU",
                                                                  making any changes
                                                                  necessary to preserve
                                                                  grammar.

"Transmission of these frames Replace "the normal DCF         AGREE (MAC: 2009-08-07           EDITOR
shall be done using the normal access procedure" with "either 00:12:50Z)
DCF access procedure."         the DCF (for non-QoS STAs)
                               or the EDCAF (for QoS
Strictly, this prevents QoS    STAs)."
STA from supporting power-
savers, because they do not Make same change in 598.8
use DCF for delivery of data. and 598.22.
"ATIM management frames             "shall only be transmitted" ->   AGREE IN PRINCIPLE                EDITOR
shall only be transmitted           "shall be transmitted only"      (EDITOR: 2009-07-03
during the ATIM Window." -                                           13:27:35Z)
grammar
                                                                     "shall only" is (except in
                                                                     exceptional circumstances) an
                                                                     error. **

                                                                     Globally replace "shall only
                                                                     <verb> if/when <condition>"
                                                                     with "shall <verb> only if/when
                                                                     <condition>"

                                                                     **Consider the statement: "the
                                                                     pedestrian shall only cross the
                                                                     road when the light is green."
                                                                     This is incorrect unless is the
                                                                     the intention of the statement
                                                                     to also stop him from
                                                                     breathing, his heart from
                                                                     beating etc... when the light is
                                                                     green.
"the STA shall retain the       Change "shall" to "should"           AGREE (EDITOR: 2009-08-07 EDITOR
buffered MSDU(s) and attempt                                         06:54:48Z)
to transmit the ATIM during the
next ATIM Window."

But a STA is allowed to
discard buffered data for
various reasons - e.g.
incoming traffic exhausts
buffer, or timout. The cited
statement is conflicts with this.


"Immediately following the          Add "any" before "buffered"..    AGREE (EDITOR: 2009-08-07 EDITOR
ATIM Window, a STA shall                                             08:23:00Z)
begin transmission of buffered
broadcast/multicast frames for
which an ATIM was previously
transmitted."
This is only true if the MSDU
has not been expunged - e.g.
due to a timeout.
"In no case shall a frame be        Replace "In no case shall a      AGREE (MAC: 2009-07-14            EDITOR
discarded that has been             frame" with "A frame should      16:36:48Z)
buffered for less than              not"
dot11BeaconPeriod."

A STA with finite resources
may be saturated with MSDUs
for a power-saving STA in less
than this time. This
requirement is not
implementable.
"Data frames between STAs in Change BSS to "infrastructure DISAGREE (SECURITY: 2009- EDITOR
a BSS" - it means            BSS".                         07-14 22:02:15Z)
infrastructure BSS                                         The text cited applies to an
                                                           IBSS.




BlockAck and BlockAckReq   Change cited location to be       AGREE IN PRINCIPLE (GEN: EDITOR
are permitted in an IBSS   specified to infrastructure and   2009-11-19 05:15:59Z) The
                           add them as Class 1 frames        Editor is instructed to
                           for IBSS.                         incorporate into the REVmb
                                                             draft document 11-09/705r4.
                                                             (https://mentor.ieee.org/802.11
                                                             /dcn/09/11-09-0705-04-000m-
                                                             proposed-corrections-to-11-3-
                                                             sta-authentication-and-
                                                             association.doc)
"The SME shall establish an       Replace with: If policy within AGREE (ARCHITECTURE:         EDITOR
RSNA, or it shall enable WEP      the SME requires secure        2009-07-16 06:39:33Z)
by calling                        communication, the SME shall
MLMESETPROTECTION.requ            establish an RSNA, or it shall
est primitive with ProtectType    enable WEP by calling
set to “Rx_Tx,” or it shall do    MLMESETPROTECTION.requ
nothing if it does not wish to    est primitive with ProtectType
secure communication."            set to “Rx_Tx,”.

This is very odd - "you shall do Make similar change to
this, unless you don't want to". 603.41, 604.18 and 604.55
It has no normative effect.

Furthermore, SMEs don't
have desires, wishes,
aspirations, wants.... The
language used is
anthropomorphic, and used to
hide the condition under which
the rule obtains.




"normal access mechanisms". replace "using normal access         AGREE (EDITOR: 2009-08-07 EDITOR
Jolly good we're not using  mechanisms" with "within its         08:48:27Z)
abnormal ones.              own TXOP". Make same
                            change at 619.02.G123

"EDCA or HCCA or HEMM."         Replace with: "EDCA, HCCA,       AGREE (EDITOR: 2009-07-03 EDITOR
                                or HEMM."                        14:17:19Z)
This is dumb and                Replace line 18-25 with: "The    AGREE (MAC: 2009-08-07    EDITOR
overcomplicated. You need value of the Minimum PHY               00:19:28Z)
any rate to be in both peer's   Rate in a TSPEC shall be in
operational rate sets, or there both the AP's operational rate
will be no communication at     set and non-AP STA's
that rate.                      operational rate set."

The lowermost state should be Change as in comment.              AGREE (EDITOR: 2009-07-03 EDITOR
"suspended", not "suspend"                                       14:33:37Z)
                                 Also make capitalization of
                                 state names consistent.
"Higher layer timer              Replaced cited sentence with    DISAGREE                        EDITOR
synchronization is beyond the a description of what is, and      (ARCHITECTURE: 2009-11-
scope of this standard" - It may what is not in scope.           18 20:44:00Z) - The
be life, but not as we know it,                                  commentor is encouraged to
Jim.                                                             provide more details of any
                                                                 proposed improvement, but
If it's beyond the scope of the                                  without the details of what is
standard, why have we got                                        proposed, the group cannot
clause 10 interfaces to support                                  evaluate the technical merit at
it? And why have we got                                          this time.
some itsey-bitsey polka-dot
shall statements in 11.6 (e.g.
620.19).
"The last symbol of the Sync       In .11n, we discovered that        AGREE IN PRINCIPLE            EDITOR
frame is indicated by the PHY      the Clause 19 state machines       (ARCHITECTURE: 2009-11-
using the PHY-TXEND.confirm        were inadquate to shed light       18 19:28:59Z) - See CID 1556
and PHYRXEND.                      on this subject. We modified       that is resolved with changes
indication primitives in the       the Clause 20 state machines       as documented in 11-
transmitter and receiver of the    to explicitly show that the        09/1233r0.
Sync frame, respectively."         signal extension occurs prior
                                   to any TXEND/RXEND.
Does the TXEND/RXEND
occur before or after any          I think the assumption of this
signal extension in ERP            sublclause is that it is the
STAs?                              physical end, not the logical
                                   end of the packet that is
                                   significant. But it's not clear.

                                   Can I request that REVmb
                                   create a place to record
                                   comments pending some draft
                                   being rolled in. I would like to
                                   squirrel this one away marked
                                   "when TGn is incorporated".
                                   We can then review if TGn is
                                   inconsistent with this
                                   subclause.


"A MAC that supports the           Add "and that has room to       AGREE (ARCHITECTURE:           EDITOR
MLME-HL-SYNC primitives            record another group address 2009-11-19 01:22:26Z)
shall respond to a MLME-HL-        for the purpose of Higher layer
SYNC.request                       timer synchronization" before
primitive with an MLME-HL-         "shall respond".
SYNC.confirm primitive
containing a result code of        Add a status code of "too
SUCCESS." - resource limits        many addresses" to the HL-
may prevent this - e.g., if 2^46   SYNC.confirm primitive.
multicast addresses were
registered.
"In general, STAs are not       Remove cited sentence and            AGREE IN PRINCIPLE (MAC: EDITOR
allowed to transmit frames      "However, " of following             2009-08-07 00:30:01Z) -
directly to other STAs in a BSS sentence.                            Replace cited sentence with
and should always rely on the                                        an editor note reading "Editor
AP for the delivery of the                                           Note -- update the following
frames."                                                             when 802.11z is rolled in." and
                                                                     the following sentence: "In an
I don't know what "in general"                                       infrastructure network, non-AP
means. And it certainly                                              STAs are not allowed to
doesn't allow for IBSS.                                              transmit frames directly to
                                                                     other non-AP STAs, except
                                                                     when using DLS."

"differnent"                         Spell check the whole           AGREE (EDITOR: 2009-07-15 EDITOR
                                     document.                       01:57:29Z)


"Not a STA" - a pretty odd           Change to "Not a QoS STA"       AGREE IN PRINCIPLE           EDITOR
error code                           and update any matching         (EDITOR: 2009-07-15
                                     status/enumeration in Clause    02:01:55Z)
                                     7 and Clause 10.                Change "Not a STA" to "Not a
                                                                     QoS STA".

                                                                     No other changes are
                                                                     necessary, as the result code
                                                                     in clause 7 already uses this
                                                                     phrase.
NOTE--s should not carry             Change as follows:              AGREE (GEN: 2009-09-24        EDITOR
normative verbs "may" or             254.19 & 35: may->can           23:13:14Z)
"shall" (e.g. 625.09)                289.62: "may attempt" ->
                                     "attempts"
Note that I had an email             292.52: may->can
exchange with our IEEE-SA            293.14: may->might
project editor on this topic,        328.08: may->might
and specifically whether             580.05: shall be->are
"should" should be included in       625.09: may->can
the list of verbs that are           636.53: may->might
deprecated in informative text.      641.52: may->can
She is of the opinion that it's      649.22: may->can
OK to include "should" in            649.51 & 53: may->can
informative text because it has      652.28: may->can
no absolute normative effect.        652.30: may-> can
So, I have not included any          653.59: may not->cannot
"should"s in the list of things to   653.60: may->can
change.                              656.39: may->might
                                     1479.48: may be->is set to
NOTE uses the wrong format           Set using the correct style     AGREE (EDITOR: 2009-07-15 EDITOR
                                                                     02:22:34Z)
"shall be commenced" - it's          "shall start"                   AGREE (EDITOR: 2009-07-15 EDITOR
English, Jim, but not as we                                          02:15:40Z)
know it
"defined in this subclause" -        Replace "this subclause" with   AGREE (EDITOR: 2009-07-15 EDITOR
with the addition of heading         "subclauses 11.9.0a to          02:18:50Z)
...0a, the reference is              11.9.7a"
incorrect.
The word "bit" is used,               Replace all uses of the word       DISAGREE (EDITOR: 2009-        EDITOR
wrongly, as a synonym for             "bit" that are not dependent in    07-27 11:07:30Z)
"field" in a 1-bit sized field.       that context on the field being
This confuses purpose (a field)       precisely 1 bit in size and that   TGmb does not support this
with representation (a single         are not calling out individual     change - i.e., it was discussed
bit).                                 bits from a bitfield.              at length in July 2009, but no
                                                                         consensus emerged in
                                                                         support.
It is not exactly clear which of      Indent the para starting "A        AGREE (SECURITY: 2009-07- EDITOR
the three dashed list items are       STA may operate when..."           14 22:02:34Z)
part of the exception.
"Only the STA starting an IBSS        Change to: "Only the STA that AGREE (SECURITY: 2009-07- EDITOR
may specify a schedule of             is the DFS owner in an IBSS 14 22:02:42Z)
quiet intervals" - isn't it the job   may specify a schedule of
of the DFS owner? The STA             quiet intervals"
that started the IBSS may be
long dead and buried.

"A STA shall not transmit in a        Relate to observable state or      AGREE IN PRINCIPLE             EDITOR
channel unless it has been            on-the-air signalling.             (SECURITY: 2009-08-14
tested for the presence of                                               16:45:51Z)
radars according to                                                      In Clause 11.9.3, replace
regulatory requirements."                                                "shall not" with "does not".
                                                                         In Clause 11.9.4, replace
Presumably it uses its well-                                             "shall discontinue" with
honed telepathic abilities to                                            "discontinues".
determine if the channel has
been tested.
The author has forgotten that         p630.53: BSS->infrastructure       AGREE (SECURITY: 2009-07- EDITOR
the term BSS applies both to          BSS                                14 22:02:57Z)
infrastructure and                    p630.58: "BSS or IBSS" ->
indepdendent.                         BSS (make change globally)
STAs are not living, breathing There are 3 "desire"s, 16         AGREE IN PRINCIPLE              EDITOR
entities. They have no wants, "wants". Replace as                (EDITOR: 2009-07-01
desires, aspirations etc..     appropriate with non-             14:31:45Z) - In 3.77: desired-
                               anthropomorthic language.         >required
Remove anthropomorhpic                                           p38.36: delete "desired"
language                                                         p44.27: desired->intended
                                                                 p59.01: Replace "If the SME
                                                                 wants to set up a security
                                                                 association to the peer STA,
                                                                 but does not know the security
                                                                 policy of the peer, it should
                                                                 send..." with
                                                                 "In order to set up a security
                                                                 association to the peer STA, a
                                                                 SME that does not know the
                                                                 security policy of the peer
                                                                 should send..."
                                                                 p59.09: Replace "If a STA
                                                                 received a 4-Way Handshake,
                                                                 wants to set up a security
                                                                 association to the peer STA,
                                                                 but does not know the security
                                                                 policy of the peer, it should
                                                                 send..."
                                                                 with " In order to set up a
                                                                 security association to the
                                                                 peer STA, a STA that received
                                                                 a 4-Way Handshake but does
                                                                 not know the security policy of
                                                                 the peer should send"
                                                                 p 59.21 & 22: wants-
                                                                 >intends
The equation on line 62 is hard   Set as a display equation.     p 59.28: (EDITOR: 2009-07-20 EDITOR
                                                                 AGREE Replace "If the SME
to parse with all the brackets    Move units into the where      11:29:41Z)
and microseconds.                 clause
"defined in dBm using the         remove "units and"             AGREE (SECURITY: 2009-07- EDITOR
same units"                                                      14 22:03:01Z)

But dBm are the units.
"shall be as required for         Turn para into note, and add   DISAGREE (SECURITY: 2009- EDITOR
operation in the regulatory       references to any known        08-21 15:29:25Z)
domain"                           regulations on this matter.    The value is dependent on the
                                                                 regulatory domain that the
- this is a useless statement.                                   STA is operating in. There is
If regulations require                                           no single reference for this
something, this says                                             value.
effectively "you shall do what
you shall do", without actually
specifying what that is.
"If                            Change cited text to: If              AGREE (SECURITY: 2009-07- EDITOR
dot11RRMTriggeredTransmitS     dot11RRMTriggeredTransmitS            14 22:03:10Z)
treamCategoryMeasurementE      treamCategoryMeasurementE
nabled is true, a QoS STA      nabled is true and has no
shall accept a triggered       resource contraint that
Transmit Stream/Category       prevents it from being able to
Measurement and shall reject   make the requested
it otherwise."                 measurement, a QoS STA
                               shall accept a
This contradicts the previous triggered Transmit
sentence that allows a         Stream/Category
resource limit to generate a   Measurement and shall reject
rejection.                     it otherwise.
"A Neighbor Report is sent by Describe what "validated"              AGREE IN PRINCIPLE              EDITOR
an AP and it contains          means in this context.                (SECURITY: 2009-07-14
information on validated AP’s"                                       22:03:33Z)
                                                                     "Propose Counter.
The concept of a valid or                                            Replace ""on valdiated AP's""
invalid AP is not known to me.                                       with
                                                                     ""on neighboring AP's"""

There are ~1000 instances of     Research rules for                  AGREE IN PRINCIPLE              EDITOR
"true" of which, 3/4 use the     capitalization of true and false,   (EDITOR: 2009-07-27
lower-case form and 1/4 use      and then apply them                 10:40:37Z)
the upper case form. There       consistently throughout the
appears to be no rhyme or        standard.                           	 ake all “true” and “false”
                                                                     M
reason as to which to use for                                        lower case, except where they
any particular purpose.                                              are part of or reference
                                                                     pseudo-code or code.
"A serving AP shall include a      Scan the entire draft for        AGREE IN PRINCIPLE               EDITOR
TSF information field in the       occurances of "shall <verb>      (SECURITY: 2009-08-21
Neighbor Report element only       only if <condition>" and for     15:35:10Z)
if it is able to                   each convert to one of these     Change the following
guarantee an accumulated           unambiguous forms.               occurences as indicated:
error of 1.5 TU or better on the                                    p379.58: "shall inspect the
TSF Offset subfield."              In this case (and, I suspect,    frame body only if the frame
                                   in most), form A is              is"
"... shall <verb> only if          appropriate.                     ->
<condition> " is highly                                             "shall not inspect the frame
ambiguous.                                                          body unless the frame is"

What does it mean?                                                  p643.58: "the STA shall
A: "shall not <verb> if not                                         respond with a Beacon Report
<condition>"                                                        only if the indicated Beacon
B: "may <verb> if <condition>                                       Reporting Condition is true."
and shall not <verb>                                                ->
otherwise"                                                          "the STA shall respond with a
C: "shall <verb> if <condition>                                     Beacon Report if the indicated
and shall not <verb>                                                Beacon Reporting Condition is
otherwise"                                                          true. Otherwise, the STA shall
                                                                    not respond with a Beacon
                                                                    Report."

                                                                  p645.65: "the STA shall create
                                                                  and transmit a Beacon Report
                                                                  element for that measured
                                                                  frame only if the condition
                                                                  indicated in Table 7-29g
                                                                  (Reporting Condition for
                                                                  Beacon Report) is true.
                                                                  Otherwise, a Beacon Report
It is difficult to read the inline                                AGREE is not created for that
                                   Convert to a display equation element (EDITOR: 2009-07-20         EDITOR
equation.                          with a where clause.           11:36:39Z)
I'm sure that there are            Work out the actual constraint AGREE IN PRINCIPLE                 EDITOR
constraints within the system and insert it here.                 (SECURITY: 2009-08-21
(e.g. in TIM encoding, or                                         15:44:36Z)
where per-BSSID information                                       Change
is packed into a single                                           "The set has a maximum size
MMPDU) that limits the                                            of 2n for at least one n, where
number of BSSIDs to less                                          1 ≤ n ≤ 46."	
2**46 - which is a guzumpingly                                    To
large number.                                                     "The set has a maximum
                                                                  range of 2n for at least one n,
                                                                  where 1 ≤ n ≤ 46."
This equation split over two       Convert to a display equation AGREE (EDITOR: 2009-07-20           EDITOR
lines is ugly                      over 1 line.                   11:47:45Z)
Spurious hyphen in                 de-hyphenify it                AGREE (EDITOR: 2009-07-22          EDITOR
dot11RRM...                                                       08:39:11Z)

"using the DCF or EDCA" -          Change to "the DCF or the        AGREE IN PRINCIPLE               EDITOR
EDCA is not a noun                 EDCAF"                           (EDITOR: 2009-08-10
                                                                    13:40:03Z) - Globally replace
                                                                    all uses of "DCF or EDCA"
                                                                    with "DCF or EDCF"
"For the BSS AC Access             insert "infrastructure" before   AGREE (MAC: 2009-08-07           EDITOR
Delay measurement" - we're         BSS                              00:31:17Z)
missing an adjective
"The DSE procedures may       may->might                             AGREE IN PRINCIPLE           EDITOR
also satisfy needs in other                                          (EDITOR: 2009-08-13
frequency bands and be useful                                        10:51:31Z) - Make the change
for other purposes."                                                 as specified, and similar
                                                                     change to 11.9.0a, second
This was surely not intended to                                      para, second sentence.
be a normative statement.
It is unnecessary to indicate      In bullet a), change         AGREE (GEN: 2009-11-16          EDITOR
the type, subtype, category        "enablement message" to      12:11:21Z)
and action fields for this         "DSE Enablement frame".
message. It suffices to say        Delete the Dashed list items
that it formats a DSE              for message type and subtype
Enablement frame. Further          and direction of message.
the direction "from requester to
responder" is unnecessary,         This now leaves a single
because the procedure is           dashed list entry. Collapse
describing a frame transmitted     that entry into item 1) as
by the requester.                  follows: "Specific information
                                   items in the enablement
                                   message are as follows:", and
                                   promote the four bulleted
                                   items up one level of nesting,
                                   while changing the style to the
                                   proper style for a 3-nested
                                   ordered list.

                                   Make matching changes in
                                   11.11.2.3 and 11.11.2.4


No value is specified for the      Specify how this is set.          AGREE IN PRINCIPLE (GEN: EDITOR
Enablement identifier                                                2009-11-16 12:13:28Z) Accept
                                                                     in Principle based on
                                                                     discussion and editorial
                                                                     instructions in 09/1111r2:
                                                                     1545, 1547, 1548, 1549 and
                                                                     1550
No value is specified for the     Specify how this is set.        AGREE IN PRINCIPLE (GEN: EDITOR
Reason result code                                                2009-11-18 05:40:33Z) Accept
                                                                  in Principle based on
                                                                  discussion and editorial
                                                                  instructions in 09/1111r2:
                                                                  1545, 1547, 1548, 1549 and
                                                                  1550




A confirm should be indicated Change the logic so that a          AGREE IN PRINCIPLE (GEN: EDITOR
for every .request, including   confirm is issued in all cases.   2009-11-16 12:16:50Z) Accept
when the enablement state                                         in Principle based on
variable is not set to Enabled.                                   discussion and editorial
                                                                  instructions in 09/1111r2:
                                                                  1545, 1547, 1548, 1549 and
                                                                  1550




According to this logic, the      Assuming that the DSE           AGREE IN PRINCIPLE (GEN: EDITOR
confirm is issued at the end of   Enablement frame is             2009-11-16 12:12:18Z) Accept
the management frame              acknowledged:                   in Principle based on
transmission, before receiving    1. Add "On receipt of an Ack    discussion and editorial
any Ack, and regardless of        frame that acknowledges the     instructions in 09/1111r2
whether an Ack is ever            DSE Enablement frame, "
received or not.                  before item b).
                                  2. Add a new item c) "If no
                                  acknowledgement is received
                                  for the DSE Enblement frame
                                  within a period of
                                  EnablementTimeLimit TUs
                                  measured from the receipt of
                                  the MLME-
                                  ENABLEMENT.request
                                  primitive, issue an MLME-
                                  ENABLEMENT.confirm
                                  primitive with ResultCode set
                                  to TIMEOUT.
Under what conditions can the    Define in items 1) and 2) what    AGREE IN PRINCIPLE (GEN: EDITOR
deenablement not be              comprises successful              2009-11-16 12:17:18Z) Accept
successful? According to the     deenablement. For instance,       in Principle based on
logic shown, there are no        is this the receipt of an Ack     discussion and editorial
such conditions.                 frame to the DSE                  instructions in 09/1111r2 for
                                 Denablement frame within an       CIDs 1548, 1549, and 1550
                                 unspecified timeout?


"A registered STA that is not Describe in more detail what         AGREE IN PRINCIPLE (GEN: EDITOR
an enabling STA may operate this relay is.                         2009-11-16 12:18:05Z) -
as an AP in an infrastructure                                      Accept in Principle based on
BSS and relay Public Action                                        discussion and editorial
frames (specifically, DSE                                          instructions in 09/1111r2 for
Enablement, DSE                                                    CIDs 1548, 1549, and 1550
Deenablement, DSE
Measurement Request, DSE
Measurement Report, DSE
Power Constraint) from a
dependent STA to its enabling
STA."

This is underspecified. During
the "relay" what fields of the
DSE frames are preserved,
and what updated? Is the
scope of the relay within the
AP's BSS, or its BSA?


If the terms defined in this note Promote material in note to      AGREE (EDITOR: 2009-08-07 EDITOR
are used in normative text, it body (i.e., regular text)           08:50:26Z)
is not sufficient to define them
in an informative note.

In the ERP phy, there is an      Change the last half of the       AGREE IN PRINCIPLE            EDITOR
extension field that occurs      para starting "immediately" as    (ARCHITECTURE: 2009-11-
after the physical end of the    follows:                          18 19:28:59Z) - See CID 1556
packet that is the timing        "... immediately after the        that is resolved with changes
reference.                       symbol containing the last data   as documented in 11-
                                 octet has been transmitted and    09/1233r0.
                                 any signal extension has
                                 expired."
"This primitive is an indication   Replace with: "This primitive    AGREE (ARCHITECTURE:           EDITOR
by the PHY to the local MAC        is an indication by the PHY to   2009-07-16 06:39:52Z) At
entity that the PLCP has           the local MAC entity that the    these prices, I've stopped
received a valid start frame       PLCP has received a valid        buying lard.
delimiter (SFD) and PLCP           start of a PPDU, including a
header."                           valid PLCP header."

This was written in those
charmingly quaint days of yore
when tuppence would buy a
pound of lard, PHY rates could
be expressed in an octet field
with a resolution of 500kbps,
and packets had SFD fields.

Unfortunately - this is no
longer true - the price of lard
has risen.

The editor is an idiot. He says Add an "s" after "parameter".       AGREE (EDITOR: 2009-07-23 EDITOR
he corrected this line for                                          10:42:09Z)
grammar, but forgot all about
plural and singular forms.

In the case of a signal            Add a note: "NOTE--When a        AGREE IN PRINCIPLE                EDITOR
extension, this primitive must     signal extension is present      (EDITOR: 2009-08-07
be delayed until the end of the    after the physical end of the    08:52:05Z)
signal extension - because         PPDU, this primitive is issued   Add note as specified after first
that is the timing reference for   at the end of the signal         para of 12.3.5.12.3.
the MAC.                           extension."

A note here would usefully
clarify this point.
TGn found it necessary to     Either:                               AGREE IN PRINCIPLE (GEN: EDITOR
modify the PLCP tx and rx     1. Introduce state machines for       2009-11-18 19:16:27Z) see
state machines to represent   clause 19 (a lot of work) or          09/1233r0 for editing
the timing of the signal      2. Make normative statements          instructions.
extension related to the      in 12.3.5.7.3 and 12.3.5.12.3
RXEND and TXEND               that achieves this effect. See
primitives.                   also my other two comments
                              to these subclauses which will
There is no normative         need to be adjusted as they
statement that shows the      assume option 1, or
RXEND.indication or           3. Make normative statements
TXEND.confirm for a clause    in 19.3.4 and 19.3.6 that
19 PHY occuring at the end of achieves this effect.
the signal extension.
RSNA Security services            Promote to its own bullet. Or,   AGREE IN PRINCIPLE             EDITOR
management is a sub-item of       if PC34 suffices, remove         (EDITOR: 2009-08-07
WEP!                              PC2.3.                           09:24:36Z) - Remove PC2.3.
There is confusion in the         Add a CF2.1 and a CF2.2          AGREE IN PRINCIPLE (GEN: EDITOR
definition of CF2 as to whether   which are "operation in an       2009-09-24 19:49:52Z) -
it applies to a non-AP STA in     infrastructure BSS" and          Accept in principle -- In
an infrastructure BSS, or a       "operation in an IBSS", with     addition to defining CF2.1 and
STA in an IBSS. I believe it is   status CF2:M for the first and   CF2.2 as in proposed change:
quiet reasonable to have a        CF2:O for the second..
STA that is not capable of        Review all all uses of CF2 in    "Add a CF2.1 and a CF2.2
operating in an IBSS, but         the status column and change     which are "operation in an
PC11.2 says any non-AP STA        to CF2.1 or CF2.2 where they     infrastructure BSS" and
has to be able to perform IBSS    are specific to either mode of   "operation in an IBSS", with
timing.                           operation.                       status CF2:M for the first and
                                                                   CF2:O for the second,
                                  Note PC11.3 should not be
                                  required for a non-IBSS-Adjust other PICS as follows:
                                  capable non-AP STA.     PC5CF2.1
                                                          PC11.2CF2.2
                                                          PC11.6CF2.2
                                                          PC11.7CF2.1 or CF2.2
                                                          PC11.8CF2.1 or CF2.2
                                                          PC12.1CF2.1 or CF2.2
                                                          PC12.5CF2.1 or CF2.2
                                                          PC13CF2.2
                                                          PC13.1CF2.2
                                                          PC13.2CF2.2
                                                          PC13.3CF2.2
                                                          PC14.2       CF2.1
                                                          PC14.4       CF2.1
                                                          PC34.1.9CF2.2
                                                          FT1CF2.1
                                                          FT3CF2.1
                                                          FT5CF2.1 or CF2.2
                                                          FT8CF2.1 or CF2.2
A date format of dd/mm/yy has Change format to yyyy-mm-dd FT12CF2.1
                                                          AGREE (EDITOR: 2009-07-23 EDITOR
a couple of problems with it:                             12:40:59Z)
1. it is ambiguous with respect
to centuries and millenia
2. It may be misread by those
who use mm/dd/yy


There's a lot of duplicate        Review the draft and replace     AGREE IN PRINCIPLE               EDITOR
specification of how to treat     all phrases such as "set to 0    (EDITOR: 2009-08-06
fields that are reserved under    on transmission and ignored      08:22:56Z)
all or certain circumstances.     on reception" with "reserved".   Please see resolution of CID
                                                                   1707, which performs this
7.1.1 suffices to define a                                         review in Clause 7.
treatment for all reserved
fields. It is not necessary to
repeat this elsewhere.
The "N/A" entry it not            Remove the "N/A" option.         AGREE (EDITOR: 2009-07-23 EDITOR
appropriate to a mandatory                                         12:41:52Z)
feature
The "heading" OF10 has            Join them up.                    AGREE (EDITOR: 2009-07-23 EDITOR
gotten separated from the                                          12:43:28Z)
following two rows.
Whereever the Status column Review Annex A and insert            AGREE IN PRINCIPLE               EDITOR
is not an unqualified M, "N/A" missing N/A options where the     (EDITOR: 2009-07-23
should be one of the options. Status is not a plain "M".         12:14:19Z)
It is not always present (e.g.                                   Add "N/A" where item is
1071.08)                                                         optional. An item is optional if
                                                                 any of the chain items
                                                                 referenced in the Status
                                                                 column is itself optional.

                                                                 In A4.7, add missing "No"
                                                                 options where Status contains
                                                                 only "Yes"
                                                                 Add missing Yes/No to
                                                                 HRDS9
Two blank pages                     Remove them                  AGREE (EDITOR: 2009-07-23 EDITOR
                                                                 12:49:57Z)




The SDL hasn't been updated         Remove Annex C and any       AGREE IN PRINCIPLE             EDITOR
for a long time (at least 10        references to it. Trim the   (EDITOR: 2009-09-23
years). While it used to have       Bibliography to remove the   18:52:42Z) - The bibliograpy
normative value in answering        SDL references.              has been trimmed as in
some questions, any relevant                                     comment resolution to CID
such answers should now be                                       1026. See also comment
part of the text through REVma                                   resolution of CID 1369.
comment resolution.

It is at best just an annoying
padding of 200 pages of
diagrams.

It is, at its worst, misleading -
where normative rules it
expressed from the early
802.11 mesolithic era were
modified by subsequent
amendments.

Annex E one line 4 claims to        Change "informative" to      AGREE (EDITOR: 2009-08-07 EDITOR
be informative.                     "uninformative".             09:26:38Z)

I beg to differ. This, one a
scale that encompasses the
literary output of a newt's brain
at one end (rating zero) and
the collected works of Vogon
poetry at the other (rating 10),
scores about -1.
Channel agility was added for Deprecate this feature in no         AGREE IN PRINCIPLE (GEN: EDITOR
political reasons during the  uncertain terms - or remove it       2009-09-24 01:11:00Z) Agree
early days of 802.11b. As far entirely.                            in Principle -- Mark this Annex
as I know, nobody ever used                                        as deprecated and subject to
it.                                                                removal in a future revision
                                                                   Editor to add immediately
Furthermore, coexistence of a                                      following the clause heading
wide-band frequency hopper                                         the following new paragraph:
and wide-band non frequency                                        This annex is obsolete and is
hoppers is likely to be very                                       subject to removal in a future
bad. So if anybody was daft                                        revision
enough to actually use this,
most of the time they would
encounter a partial overlap
with static 802.11b/g devices.

"However, if a TSPEC is          In annex K, replace all "may"     AGREE (EDITOR: 2009-08-07 EDITOR
generated subsequently by the    with "can" and all "shall be"     14:12:08Z)
SME, the TSPEC generated         with "is".
autonomously by the MAC
shall be overridden"             From my research on the
                                 topic, I see nothing that calls
A Normative verb is not          out "should" as a word that
allowed in an informative        cannot be used in an
Annex.                           informative annex, so I think
                                 these can stand.
The top of this equation is      Untruncate it                     AGREE (EDITOR: 2009-07-24 EDITOR
truncated                                                          08:55:06Z)
The top of this equation is      Untruncate it                     AGREE (EDITOR: 2009-07-24 EDITOR
truncated                                                          11:18:23Z)
This equation and the          Restructure it.            AGREE IN PRINCIPLE                EDITOR
following one and the previous                            (EDITOR: 2009-07-24
text should be restructured as                            11:33:23Z)
necessary to give a "where"                               Replace the paragraph at
paragraph that fully describes                            1504.20 with the following:
the variables of the equation.                            "For the calculation of the
                                                          TXOP duration for an admitted
                                                          stream, the scheduler uses the
                                                          following parameters: Mean
                                                          Data Rate and Nominal MSDU
                                                          Size; and from the negotiated
                                                          TSPEC, the Scheduled
                                                          Service Interval calculated
                                                          above, Physical Transmission
                                                          Rate, Maximum Allowable Size
                                                          of MSDU, and Overhead. The
                                                          Physical Transmission Rate is
                                                          the minimum PHY rate
                                                          negotiated in the TSPEC. If the
                                                          minimum PHY rate is not
                                                          committed in the ADDTS
                                                          Response frame, the
                                                          scheduler can use the
                                                          observed PHY rate as the
                                                          Physical Transmission Rate.
                                                          The Overhead includes IFSs,
                                                          ACK frames and CF-Poll
                                                          frames. For simplicity, details
                                                          for the Overhead calculation
                                                          are omitted in this description.
                                                          The TXOP duration is
                                                          calculated as follows: First, the
The top of this equation is     Untruncate it             scheduler calculates the
                                                          AGREE (EDITOR: 2009-07-24 EDITOR
truncated                                                 11:42:42Z)
I find the naming of "WLAN      Rename "WLAN system" to   DISAGREE (MAC: 2009-08-07 EDITOR
system" confusing. I'd expect   "WLAN infrastructure"     00:39:31Z) Definition 3.171
the MU to be part of that                                 defines a WLAN system as
system, i.e. they are clearly                             excluding mobile units.
part of a WLAN, but
apparently not part of a WLAN
system.
2 blank pages                   remove                    AGREE (EDITOR: 2009-07-24 EDITOR
                                                          11:43:47Z)

This describes the use of Add NDIS expansion to           AGREE IN PRINCIPLE             EDITOR
NDIS. However NDIS is not abbeviations. Add NDIS          (EDITOR: 2009-08-07
defined.                  reference to Bibliography and   10:22:57Z) - Delete cited
                          cite from here.                 sentence.
This describes the use of Add SNMP expansion to           AGREE IN PRINCIPLE             EDITOR
SNMP. However SNMP is not abbeviations. Add SNMPv2        (EDITOR: 2009-08-07
defined.                  reference to Bibliography and   10:30:45Z) -
                          cite from here.                 Add RFC1157 to the
                                                          Bibliography and reference
                                                          from here.
It is dangerous to define an         Move definition of this identifier   AGREE IN PRINCIPLE            EDITOR
object identifier using              to Annex D, add comment              (ARCHITECTURE: 2009-11-
dot11smt away from where the         there saying that the object         18 00:35:20Z) Annex Q will be
other identifiers are defined,       itself is defined in Annex Q.        merged into Annex D.
because somebody may not             Add comment at cited location
check this separate Annex and        to say this identifier is defined
attempt to re-use the same           in Annex D.
number.




"It shall update this attribute to   Move description of how the          DISAGREE                      EDITOR
a proper value other than 0 as       SME maintains the RRM MIB            (ARCHITECTURE: 2009-11-
soon as it is capable of             to a normative clause outside        18 20:44:41Z) The commentor
receiving new measurement            the SME MIB.                         is encouraged to provide more
requests."                                                                details of any proposed
                                     This will involve searching for      improvement, but without the
As I understand it, the              shalls in this Annex and             details of what is proposed,
purpose of the description is to     moving/restructuring text as         the group cannot evaluate the
carry information to help the        appropriate.                         technical merit at this time.
user of the object understand
how to interact with it. This is
normative specification for the
SME, and belongs in a
normative subclause outside
the MIB.
unwanted linebreak                   remove                               AGREE (EDITOR: 2009-07-24 EDITOR
                                                                          11:46:26Z)
Wrong font for "Annex J", ditto fix font                                  AGREE (EDITOR: 2009-07-24 EDITOR
line 18.                                                                  11:49:54Z)

Ditto 1553.56
What't the point in defining an Somebody explain to me the                DISAGREE                         EDITOR
enumeration of only one         value of this MIB entry - or              (ARCHITECTURE: 2009-07-
member?                         remove it.                                16 06:40:31Z) Typical future
                                                                          looking stuff, this.
Awkward line break                   fix it                               AGREE (EDITOR: 2009-07-24        EDITOR
                                                                          11:54:28Z)
Wrong indent                         fix it                               AGREE IN PRINCIPLE               EDITOR
                                                                          (EDITOR: 2009-07-24
                                                                          11:57:02Z) - Adjust indent and
                                                                          change "filed" to "field".
Wrong indent - 3 lines               fix it                               AGREE (EDITOR: 2009-07-24        EDITOR
                                                                          11:58:48Z)
It is dangeration defining       Add comment in AnnexD in         AGREE IN PRINCIPLE            EDITOR
children of the dot11Groups      appropriate place so that it's   (ARCHITECTURE: 2009-11-
object in Annex Q.               painfully clear where the        18 00:35:20Z) Annex Q will be
                                 numbering has to restart. Or     merged into Annex D.
                                 move these definitions into
                                 AnnexD, with a comment here
                                 indicating that these objects
                                 are defined in AnnexD.

The contact information is      Remove WG Email. Update           AGREE IN PRINCIPLE          EDITOR
incorrect.                      chair.                            (EDITOR: 2009-07-23
1. The chair details have                                         13:23:32Z)
changed                                                           As specified, also update
2. It is useless to quote WG E-                                   Tech Editor and remove
mail as only those within the                                     unknown details.
WG have access to this, and
they already know about it.

Either explain this reference or As in comment.                   AGREE IN PRINCIPLE          EDITOR
remove it.                                                        (EDITOR: 2009-08-07
                                                                  09:26:17Z) - remove cited
                                                                  reference.
", and is accessed big-endian." Remove cited text.                AGREE (ARCHITECTURE:        EDITOR
                                                                  2009-07-16 06:41:04Z)
This makes no sense.               Same action on lines 52, 64,
Endianness is only of a            1346.10, 22, 24, 55, 1347.2,
concern when extracting a          15, 29, 44
smaller field from a larger field.
Here we have an integer of
range 0..63, and that's all that
it is necessary to say.
There's a number of MIB           Wherever possible, move all      AGREE IN PRINCIPLE               EDITOR
variables that define a default   statements of default value      (EDITOR: 2009-08-07
value in the description, but     solely into a DEFVAL part.       14:10:48Z) - Add any missing
have no DEFVAL statement.                                          defval statements, and
                                                                   remove any specification of
There are other variables that                                     default value in the description
do both - which creates a                                          in the following variables:
maintenance issue.
                                                                   Annex D:
                                                                   dot11MediumOccupancyLimit

                                                                   dot11PrivacyOptionImplement
                                                                   ed
                                                                   dot11MultiDomainCapabilityIm
                                                                   plemented
                                                                   dot11MultiDomainCapabilityEn
                                                                   abled
                                                                   dot11SpectrumManagementIm
                                                                   plemented
                                                                   dot11SpectrumManagementR
                                                                   equired
                                                                   dot11RegulatoryClassesImple
                                                                   mented
                                                                   dot11RegulatoryClassesRequi
                                                                   red
                                                                   dot11QosOptionImplemented

                                                                   dot11ImmediateBlockAckOptio
                                                                   nImplemented
                                                                   dot11DelayedBlockAckOptionI
                                                                   mplemented
                                                                   dot11DirectOptionImplemente
"The value of this attribute      Remove cited text.               d
                                                                   AGREE (ARCHITECTURE:        EDITOR
shall never be less than 256."                                     2009-07-16 06:41:21Z)

This is unnecessary, because
the syntax already captures
this.

The description should be         Replace superscript with ^.      AGREE IN PRINCIPLE         EDITOR
readable as ascii text.           Ditto on line 55, and 1360.65,   (EDITOR: 2009-07-23
                                  and 1363.06, 24                  14:30:38Z)
                                                                   As specified and make same
                                                                   change at 1360.47.
Bad formatting                    Fix                              AGREE (EDITOR: 2009-07-24 EDITOR
                                                                   08:37:54Z)
"Valid values are:              If we are allowed to change       AGREE IN PRINCIPLE                EDITOR
energy detect only (ED_ONLY)    this, change the syntax to an     (ARCHITECTURE: 2009-11-
= 01,                           enumeration with these            16 15:52:45Z) Remove the
carrier sense only (CS_ONLY)    values, and remove values         meaningless "or the logical ...
= 02,                           from the description.             values"
carrier sense and energy
detect (ED_and_CS)= 04          In any case remove the
or the logical sum of any of    meaningless "or the logical ...
these values."                  values"
The term "logical sum" is
poorly defined.

Speaking logically, we can
only have 3 meaningful values,
and these have already been
enumerated.
There are more notifications    Update the description toDISAGREE                        EDITOR
                                                         (ARCHITECTURE: 2009-11-
than these defined in this MIB. indicate the basis of selection
                                of this group (i.e. those18 20:44:57Z) - The
                                supported by all STA).   commentor is encouraged to
                                                         provide more details of any
                                                         proposed improvement, but
                                                         without the details of what is
                                                         proposed, the group cannot
                                                         evaluate the technical merit at
                                                         this time.
The SNMP-v2 RFCs indicate Update the description of each AGREE IN PRINCIPLE              EDITOR
that when an object-group is  deprecated object group to (ARCHITECTURE: 2009-11-
marked as deprecated, the     indicate "superseded by    18 19:21:38Z) - see 09/1233r0
description should be updated <object-name>".            for editing instructions.
to indicate why.
How can REVmb be sure that Run a MIB compiler on it and          AGREE IN PRINCIPLE           EDITOR
the MIB is syntactically   correct any syntactic errors.         (EDITOR: 2009-08-04
correct?                                                         16:16:01Z) - Make changes as
                                                                 shown in document 11-
                                                                 09/0921r1. These result in a
                                                                 combined MIB that compiles
                                                                 without errors or warnings.

                                                                 Note, this necessitated
                                                                 renumbering
                                                                 dot11RegulatoryClassGroup
                                                                 (dot11Groups 29) to avoid
                                                                 collision with
                                                                 dot11RSNSMKcachingGroup.



                                                                 Also correct any references
                                                                 outside Clause Q from
                                                                 "dot11RMStatisticsMeasaurem
                                                                 entEnabled" to
                                                                 "dot11RMStatisticsMeasureme
                                                                 ntEnabled".
dot11FTComplianceGroup           The three missing entries are   AGREE IN PRINCIPLE            EDITOR
object number is not             in Annex Q. Move them here      (ARCHITECTURE: 2009-11-
contiguous                       or reference them from here     18 00:35:20Z) Annex Q will be
                                 so that the numbering is        merged into Annex D.
                                 explained.




Numerous references in the       Check every reference in the    AGREE IN PRINCIPLE              EDITOR
standard are not "live" - i.e.   draft and replace non-live      (EDITOR: 2009-06-30
they do not show a link in the   references with live ones.      11:11:58Z) -
.pdf when the cursor is                                          Update references at at least
hovered over them.                                               the following locations: 52.10,
                                                                 361.31, 365.44, 401.04,
This is dangerous, as it                                         423.13, 597.06, 597.10,
means that any future                                            597.14, 735.27, 735.45,
renumbering may result in an                                     766.64, 786.10, 786.15,
incorrect reference.                                             801.18, 802.17, 803.17,
                                                                 812.05, 817.09, 817.16,
                                                                 820.52, 822.24, 886.13,
                                                                 938.47, 1388.29, 1390.58,
                                                                 1391.04, 1391.15, 1391.26,
                                                                 1391.37, 1391.48 and
                                                                 1423.16.

                                                                 Note, this does not address
                                                                 any references in Annex C.
The correct treatment of a        Either show the two missing    DISAGREE                        EDITOR
deprecated attribute is to show   attributes, or replace the     (ARCHITECTURE: 2009-11-
the definition with a status of   comment that these entries     18 20:45:12Z) - The
deprecated.                       are not in use.                commentor is encouraged to
                                                                 provide more details of any
                                                                 proposed improvement, but
                                                                 without the details of what is
                                                                 proposed, the group cannot
                                                                 evaluate the technical merit at
                                                                 this time.
There are a number of places      Remove trailing blank          AGREE (EDITOR: 2009-06-29 EDITOR
where a DEFVAL line ends          comments from all MIB lines.   11:54:34Z)
with a blank comment. This is
unnecessary.
There's a note embedded in       Replace "Note, however, " with AGREE IN PRINCIPLE             EDITOR
the para in the wrong format.    "NOTE--" and format            (EDITOR: 2009-07-02
                                 appropriately.                 13:18:39Z)
                                                                Convert to note as follows:
                                                                "NOTE--This collision behavior
                                                                does not..."
"An AP may indicate              Replace with: "An AP may       AGREE (MAC: 2009-07-14         EDITOR
availability of CF-Polls to non- transmit a CF-Poll to a non-   15:32:20Z). Accept the
QoS STAs"                        QoS STA"                       proposed change.

This is not what it means.
"Only MPDUs with a unicast        Delete cited text.             AGREE (MAC: 2009-07-14       EDITOR
receiver address shall be                                        15:33:09Z)
fragmented."

This is problematical. Which
of the three possible
interpreations of "only
<condition> shall <verb>"
apply here?

It's also redundant given the
next sentence.
"that would result in a length       Replace cited text with: "that AGREE (MAC: 2009-07-14           EDITOR
greater than                         would result in an MPDU of     15:33:57Z)
dot11FragmentationThreshold          length greater than
when the                             dot11FragmentationThreshold
MAC header and FCS are               "
added"

This ignores the effect of any
other encapsulations done in
the MAC layer, for example,
security or tunnelling of
MMPDUs.




The last sentence of p361 up         Merge the conditions for        AGREE IN PRINCIPLE (MAC: EDITOR
to line 7 of 362 appear to say       sending fragments of a single   2009-09-24 21:40:13Z) -
almost-but-not-quite-the-same-       MSDU or MMPDU into a single     Change cited paragraph as
thing twice - i.e. they are partly   list.                           follows:
redundant and partly
inconsistent.                                                        "The MPDUs resulting from
                                                                     the fragmentation of an MSDU
                                                                     or MMPDU are sent as
                                                                     independent transmissions,
                                                                     each of which is separately
                                                                     acknowledged. This permits
                                                                     transmission retries to occur
                                                                     per fragment, rather than per
                                                                     MSDU or MMPDU. The
                                                                     fragments of a single MSDU or
                                                                     MMPDU are either
                                                                     - Sent during a CFP as
                                                                     individual frames obeying the
                                                                     rules of the PC medium
                                                                     access procedure or
                                                                     - Sent as a burst in an EDCA
                                                                     or HCCA TXOP, subject to
                                                                     TXOP limits and medium
                                                                     occupancy limits for the
                                                                     attached PHY"
Some bits of the DCF have       Create a new subclause "Bits    AGREE (MAC: 2009-11-13       EDITOR
been reused by EDCA, and        of DCF used by EDCA" and        19:44:43Z) - Create a new
some superseded. There is       move the bits of DCF that are   subclause
no clear distinction between    used by EDCA into this          9.2.5.0a (Procedures common
these.                          subclause. This should          to the DCF and EDCAF), with
                                include:                        the following new subclause:
                                CS Mechanism, IFS, Setting
                                and resetting the NAV,          "9.2.5.0a.1 (Introduction)
                                RTS/CTS with fragmentation,     Subclause 9.2.5.0a contains
                                CTS procedure, Ack              procedures common to the
                                Procedure, Duplicate            operation of the CSMA/CA
                                detection and recovery, DCF     channel access mechanisms
                                timing relationships, NAV       defined in this standard, i.e.,
                                distribution, operation of      the DCF and the EDCAF."
                                aSlotTime.
                                                                Move the following subclauses
                                                                from 9.2.5 into 9.2.5.0a,
                                                                renumbering appropriately.
                                                                -CS mechanism
                                                                -MAC-Level
                                                                Acknowledgements
                                                                -IFS
                                                                -Setting and resetting the
                                                                NAV
                                                                -RTS/CTS with
                                                                fragmentation
                                                                -CTS procedure
                                                                -ACK procedure
                                                                -Duplicate detection and
                                                                recovery
                                                                -NAV distribution
                                                                -Operation of aSlotTime
"All STAs...". A normative    Delete "shall" in cited           AGREE IN PRINCIPLE (MAC: EDITOR
requirement cannot be placed sentence.                          2009-09-24 21:11:10Z) -
on more than one STA.                                           Rewrite sentence as: "A STA
Furthermore, "shall learn" is                                   receiving either the RTS (sent
not defined.                                                    by the originating STA) or the
                                                                CTS (sent by the destination
                                                                STA) shall process the
                                                                medium reservation."


"The medium reservation         Replace "BSA" with "BSS".       AGREE (MAC: 2009-09-24            EDITOR
mechanism works across the                                      21:34:26Z)
BSA boundaries."

Actually it doesn't. It works
across BSS boundaries in the
same or partly overlapping
BSA.
"The RTS/CTS mechanism            Replace "need" with "is".      AGREE IN PRINCIPLE (MAC: EDITOR
need not be used for every                                       2009-09-24 21:13:01Z) -
data frame transmission."                                        Replace "need not be used"
                                                                 with "is not used".
This appears to give license
not to use the mechanism, but
the following paragraph
indicates that the mechanism
is controled solely through a
MIB variable. So to whom is
the "not always justified"
directed? Surely the
management entity that sets
this MIB variable, and not the
MAC sublayer.

"This attribute may be set on a Remove cited text.               DISAGREE (MAC: 2009-09-24 EDITOR
per-STA basis."                                                  20:56:38Z) - "May" is
                                                                 informative language, and the
This is true, but doesn't                                        language may offer useful
require this statement to make                                   guidance to implementers.
it so.
"A STA configured not to         Remove normative language       AGREE (MAC: 2009-09-24         EDITOR
initiate the RTS/CTS             and turn into a NOTE--.         20:58:47Z) - Replace sentence
mechanism shall still update                                     with an informative note
its virtual CS mechanism with                                    reading: "NOTE-- A STA
the                                                              configured not to initiate the
duration information contained                                   RTS/CTS mechanism updates
in a received RTS or CTS                                         the virtual CS mechanism with
frame, and shall always                                          the duration information
respond to an RTS addressed                                      contained in a received RTS or
to it with a CTS if permitted by                                 CTS frame, and responds to
medium access rules."                                            an RTS addressed to it with a
                                                                 CTS if permitted by medium
But the rules specified                                          access rules."
elsewhere for these protocols
make no exception for a STA
that doesn't transmit RTS, so
this statement is unnecessary.


"To the initiator of the frame    Change the cited sentence to   AGREE (MAC: 2009-09-24         EDITOR
exchange, this                    something that is true.        21:31:03Z) - Change the cited
condition is indistinguishable                                   sentence to read: "When an
from an error occurring in the                                   ACK is lost, the MAC that
initial frame."                                                  initiated the frame exchange
                                                                 does not receive a protocol
Actually, it's not true. In the                                  indication whether the initial
case of a corrupted Ack, the                                     frame was correctly received."
initiator will see at least
energy, and probably PHY-
RXSTART at the expected
time.

We rely on the PHY-
RXSTART behaviour in a
number of places in the spec.
"A STA using the DCF shall be Replace "shall be allowed to"     AGREE (MAC: 2009-09-24           EDITOR
allowed to transmit if its CS   with "may". That wasn't too     21:31:12Z)
mechanism (see 9.2.1)           painful was it?
determines that the medium is
idle at the TxDIFS slot
boundary as defined in 9.2.10
after a correctly received
frame, and its backoff time has
expired."

"Shall be allowed" is
wonderfully opaque and of
doubtful normative relevance.
"The AIFS shall be used by    Add "that access the medium       AGREE IN PRINCIPLE (MAC: EDITOR
QoS STAs to transmit all data using the EDCAF" after            2009-09-24 21:21:38Z) -
frames"                       "STAs".                           Change cited text to read "The
                                                                AIFS shall be used by QoS
Too broad. For example it                                       STAs that access the medium
creates a conflict with data                                    using the EDCAF to transmit:
transmitted under HCCA.                                         all data frames, . . ."

                                                                Note to editor: a colon is
                                                                added after the word transmit,
                                                                which is why the resolution is
                                                                an agree in principle.


"the EDCA" - EDCA is an         Globally replace any "the     AGREE (EDITOR: 2009-07-02 EDITOR
adjectival phrase, not a noun   EDCA" with "the EDCAF"        13:31:12Z)
                                where not followed by a noun.

This para "A STA using the      Delete cited para.              AGREE (MAC: 2009-09-24           EDITOR
EDCA..." is talking about EIFS,                                 21:31:21Z)
not AIFS.

Furthermore, the content is
redundant with 9.2.3.5.
"A STA desiring to initiate   Insert: "using the DCF" after     AGREE (MAC: 2009-09-24           EDITOR
transfer of data MPDUs and/or MMPDUs.                           21:31:31Z)
MMPDUs shall invoke the CS
mechanism (see 9.2.1) to
determine the busy/idle state
of the medium."

This is only true for DCF.

"Basic access refers to the     Insert "using the DCF" at the   AGREE (MAC: 2009-10-30           EDITOR
core mechanism a STA uses       end.                            16:00:30Z)
to determine whether it may
transmit." - too general

"may not" is not the intent here may not -> might not           AGREE (EDITOR: 2009-07-02 EDITOR
                                                                13:34:38Z)
"This duplicate MSDU shall be      Replace cited text with a       AGREE (EDITOR: 2009-08-07 EDITOR
filtered at the receiving STA      footnote:                       14:11:31Z)
using the normal duplicate         "This duplicate MSDU is
frame                              filtered at the receiving STA
filtering mechanism."              using the duplicate frame
                                   filtering mechanism."
There are several problems:
1. The duplicate cache is of
limited depth, filtering cannot
be guaranteed
2. There is no need for a
normative statement here,
becuase there is nothing
special in this case about
duplicate detection
3. "normal" implies there's
also an "abnormal"
"A STA shall use an RTS/CTS        Replace with: "A STA using     AGREE (MAC: 2009-09-24       EDITOR
exchange for individually          the DCF shall use an           21:31:37Z)
addressed frames only when         RTS/CTS exchange for
the length of the MPDU             individually addressed frames
is greater than the length         when the length of the MPDU
threshold indicated by the         is greater than the length
dot11RTSThreshold attribute."      threshold indicated by the
                                   dot11RTSThreshold attribute,
A "shall ... only" statement.      or when required to do so to
Which of the possible three        achieve protection (see 9.13).
meanings are intended here?        Otherwise a STA using the
Also, other reasons to use         DCF shall not use the
RTS exist when protection is       RTS/CTS exchange."
required - is this statement too
broad.


"The dot11RTSThreshold             "shall be" -> "is"; "may" ->    AGREE (EDITOR: 2009-08-07 EDITOR
attribute shall be a managed       "can".                          14:11:39Z)
object within the MAC MIB,
and its value may be set
and retrieved by the MLME."

The MIB syntax determines
whether such variables exist or
not, not statements such as
this.
"The value 0 shall be used to Replace "shall be used to            AGREE IN PRINCIPLE            EDITOR
indicate..."                    indicate" with "indicates".        (EDITOR: 2009-08-07
                                                                   14:11:55Z) - "If
Exactly who is this "shall"                                        dot11RTSThreshold is 0, all
aimed at? The SME? The                                             MPDUs shall be delivered with
MAC?                                                               the use of RTS/CTS."
This is unnecessary.
"shall indicate"              Replace "shall indicate" with      AGREE IN PRINCIPLE            EDITOR
                              "indicates".                       (EDITOR: 2009-08-07
Who is the target of this shall?                                 06:26:05Z) - Rewrite sentence
Where shall that entity                                          to read: "If the value of
indicate: at the top of a very                                   dot11RTSThreshold is larger
tall building in flashing neon,                                  than the maximum MSDU
on the blinking turn lights of                                   length, all MPDUs shall be
the nearest automobile?                                          delivered without RTS/CTS
                                                                 exchanges."
"No regard shall be given to     Either replace "shall be" with AGREE IN PRINCIPLE (MAC: EDITOR
the busy or idle status of the   "is" and format as a NOTE--, 2009-09-23 04:06:15Z) Accept
medium when transmitting this or define the verb of regarding the first proposed change.
data frame"                      (presumably with the aid of my
                                 nurgling iron), define the
Which entity is steadfastly      qualified verb of not regarding
ignoring this signal? (use of    and cite that definition from
passive voice considered         here.
dangerous). The act of
paying regard and not paying
regard has not been specified.

"the asynchronous data frame" Remove "asynchronous" here          AGREE IN PRINCIPLE            EDITOR
                               and in lines 44 and 47.            (EDITOR: 2009-08-25
This term has not been         (These are the only 3              10:41:44Z) - Make the change
defined. It hearkens back to occurances in the standard.)         as indicated, and also remove
the dim and dark past of                                          "asynchronous" from 1.2,
802.11 when it included                                           6.1.1, and 14.3.2.0a.
isochronous data services
(aka time-bounded data
services). That was removed
well before the publication of
the first 802.11 standard.


"To DS field clear"           replace "clear" with "set to 0"     AGREE (MAC: 2009-09-24      EDITOR
                                                                  21:31:44Z)
This field takes only two     Review all uses of "clear" and
values: 0 and 1. "Clear" is   change those related to the
not one of these.             value of a field in a similar
                              fashion. (there are about 10
                              such changes necessary).

                              Likewise, do the same with all
                              the word "set" where used by
                              itself to indicate a field set to
                              the value 1.
"The STA originating the           Change the first sentence to:     AGREE (MAC: 2009-08-06      EDITOR
message shall receive the          "The STA originating the          23:23:35Z). Note to editor:
message as a                       message receives the              broadcast/multicast is
broadcast/multicast message.       message as a                      replaced by another comment
Therefore, all STAs shall filter   broadcast/multicast message       resolution.
out broadcast/multicast            (prior to any filtering)."
messages that contain their
address as the source
address."

I'm confused. Doesn't the first
sentence say that the STA
shall receive its own
broadcasts with ToDS set,
and the second say it shall
throw them away? Which is
correct?

"The sole exception is that      Prepend: "Under the DCF, " to AGREE (EDITOR: 2009-08-07 EDITOR
recognition of a valid data      cited text.                   06:27:34Z)
frame sent by the recipient of a
PS-Poll frame shall also be
accepted
as successful
acknowledgment of the PS-
Poll frame."

There are other exceptions.
For example, places where a
STA sends an Ack or a QoS
Data+CF-Ack.
"Such duplicate frames shall       Replace cited text with: "The     AGREE (MAC: 2009-09-24      EDITOR
be filtered out within the         procedures defined in this        21:31:51Z)
receiver MAC."                     subclause attempt to filter out
                                   these duplicates."
This is only possible with a
cache of infinite size - well,
OK, not infinite, but a really
really big size.
"and different MSDUs shall       Either replace with "...should      AGREE (MAC: 2009-09-24        EDITOR
(with a high probability) have a (really really most of the time,    21:32:17Z) - Adopt the second
different sequence number."      honest guv)..." or "... MSDUs       proposed resolution from the
                                 have (with high probability) a      commenter, as the first one
hmmm. 'Shall (with a high        different..."                       uses an English colloquialism
probability)' is not a normative                                     which is not well understood
verb I recognize.                                                    by most members of the
                                                                     802.11 WG, excepting (with
                                                                     high probability) those
                                                                     Americans that watch too
                                                                     much British TV on PBS.
"The receiver STA shall      Turn into a NOTE--. and "shall AGREE (EDITOR: 2009-08-07 EDITOR
perform the ACK procedure on perform" -> "performs".        06:27:58Z)
all successfully received
frames requiring
acknowledgment, even if the
frame is discarded due to
duplicate filtering."

There is nothing in the Ack
procedure that excuses
duplicate frames, so this
statement is unnecessary.
"STAs employing a NAV              Either provide an interface that   AGREE (MAC: 2009-11-13           EDITOR
distribution mechanism should      allows CTS-to-self to be           19:41:16Z) - Changing 9.26, p
choose a mechanism such as         managed by the SME, or             274.30 as follows:
CTS-to-self or RTS/CTS that is     provide precidence rules for       "A STA shall use an RTS/CTS
appropriate for the given          the setting of the                 exchange for individually
network conditions"                RTSThreshold variable.             addressed frames only when
                                                                      the length of the MPDU is
Which entity makes this                                               greater than the length
decision?                                                             threshold indicated by the
If it's the SME, the SME has                                          dot11RTSThreshold attribute.
no means of determining the                                           A STA may also use an
use of CTS-to-self (i.e. no MIB                                       RTS/CTS exchange for
variable controls this).                                              individually addressed frames
                                                                      when it is necessary to
If it's the MLME, it means that                                       distribute the NAV or when it is
it is writing to the                                                  necessary to establish
RTSThresholdVariable, and                                             protection (see 9.13)."
no rules are defined to
determine precidence between
an SME write and a local
MLME write of this variable.


"The PC shall reside in the        Either define the normative        AGREE IN PRINCIPLE                EDITOR
AP."                               significance of "shall reside",    (EDITOR: 2009-09-22
                                   or change to "resides".            03:09:07Z) -
I reside in Cottenham, a nice                                         Delete cited sentence. Add:
little town of 4,000 people,                                          "A non-AP STA shall not
elevation 50 feet. How nice                                           become a PC." after the
that we've provided a place for                                       sentence: "It is an option for an
the PC to stay. Pity we don't                                         AP to be able to become the
let it get out and about though.                                      PC.".

What's the normative
significance of "shall reside".

"that all STAs are able to         Either define "proper              AGREE IN PRINCIPLE (MAC: EDITOR
operate properly"                  operation", or remove              2009-07-31 16:13:20Z)
                                   "properly".                        Remove "properly"
Ah how nice. A protocol that
guarantees nothing improper
will ever happen. But what
does this mean?
"are able to receive all frames remove "all".                 AGREE (EDITOR: 2009-09-22 EDITOR
sent under PCF control."                                      03:04:37Z)

Ah. Mechanism to banish
packet errors. How nice.

", but shall inspect the frame   Remove cited text.           DISAGREE (MAC: 2009-07-31 EDITOR
body only if the frame is of                                  16:35:29Z) - Removing the
subtype Data, Data+CF-Ack,                                    cited phrase would leave the
Data+CF-Poll, or Data+CF-                                     previous phrase hanging with
Ack+CF-Poll"                                                  uncertain technical effect.

This duplicates the first
sentence of the para, and the
normative effect of "shall
inspect" is not defined.


There is MA-UNIDATA.             It should be MA-UNITDATA       AGREE IN PRINCIPLE              EDITOR
                                                                (EDITOR: 2009-07-03
                                                                10:45:09Z)
                                                                Make change as indicated in
                                                                this comment twice in this
                                                                subclause.
There is no need for the italics Remove the italics             AGREE (EDITOR: 2009-07-02       EDITOR
in this para                                                    15:06:00Z)
"If a STA desires to change      Replace cited text with:       AGREE IN PRINCIPLE              EDITOR
the PC’s record of               "NOTE--A STA can perform a (EDITOR: 2009-08-07
CFPollability,                   reassociation in order to      06:28:27Z) -
that STA shall perform a         change the PC’s record of      Replace cited text with:
reassociation."                  CFPollability." & add para     "NOTE—A STA can perform a
                                 breaks before and after.       reassociation in order to
There is no need for this as a                                  change the PC’s record of its
normative statement. It is                                      CF-Pollability." and add para
already true.                                                   breaks before and after.
"The length of a fragment shall Indicate how other security     AGREE IN PRINCIPLE              EDITOR
never be larger than             encapsulations are treated wrt (EDITOR: 2009-11-19
dot11FragmentationThreshold fragmentation.                      13:29:50Z) - AGREE IN
unless WEP is invoked for the                                   PRINCIPLE (MAC: 2009-10-
MPDU. If WEP is active for the                                  23 16:01:16Z) - Change cited
MPDU, then the MPDU shall                                       sentence as instructed in CID
be expanded by IV and ICV                                       1338 to extend fragmentation
(see 8.2.1 (Wired equivalent                                    rules for non-WEP
privacy (WEP))); this may                                       encapsulations.
result in a fragment larger than
dot11FragmentationThreshold.
"

This is incomplete because it
misses out other possible
encapsulations. i.e. Does the
MIC extend the size of an
MPDU containing a fragment
or not.
"If WEP has been applied to      Define how to treat the other      AGREE IN PRINCIPLE (MAC: EDITOR
the fragment, it shall be        security encapsulations,           2009-10-23 16:05:35Z).
decrypted before the fragment    ideally by describing in generic   Change cited sentence to
is used for defragmentation of   terms.                             read: "If security encapsulation
the MSDU or MMPDU."                                                 has been applied to the
                                                                    fragment, it shall be de-
What about the other security                                       encapsulated and decrypted
encapsulations?                                                     before the fragment is used for
                                                                    defragmentation of the MSDU
                                                                    or MMPDU."

"There is also an attribute,     Define this attribute              Change the paragraph at      EDITOR
aMaxReceiveLifetime..."          somewhere, or remove any           387.58 as follows:
                                 reference to this term.
No there isn't.                                                     "The destination STA shall
                                                                    maintain a Receive Timer for
                                                                    each MSDU or MMPDU being
                                                                    received, for a minimum of
                                                                    three MSDUs or MMPDUs.
                                                                    The STA may implement
                                                                    additional timers to be able to
                                                                    receive additional concurrent
                                                                    MSDUs or MMPDUs. The
                                                                    receiving STA shall discard all
                                                                    fragments that are part of an
                                                                    MSDU or MMPDU for which a
                                                                    timer is not maintained. The
                                                                    receive MSDU or MMPDU
                                                                    timer starts on the reception of
                                                                    the first fragment of the MSDU
                                                                    or MMPDU. If the receive
                                                                    MSDU timer exceeds
                                                                    an implementation-defined
                                                                    value, then all received
                                                                    fragments of this MSDU or
                                                                    MMPDU are discarded by the
                                                                    destination STA. If additional
                                                                    fragments of an individually
                                                                    addressed MSDU or MMPDU
                                                                    are received after received
                                                                    fragments of an MSDU or
                                                                    MMPDU have been discarded
                                                                    because of the operation of a
Heading is missing a space       fix                                receive timer, those fragments EDITOR
                                                                    AGREE (EDITOR: 2009-07-02
                                                                    15:07:36Z)
"When this mechanisms is      mechanisms->mechanism                 AGREE (EDITOR: 2009-07-02 EDITOR
active" - grammar                                                   15:08:23Z)
Is this a requirement for the If the former change "a STA"          AGREE IN PRINCIPLE (GEN: EDITOR
SME, or a requirement for the to "The SME of a STA..."              2009-07-15
MAC to ignore the ScanType                                          00:42:58Z)Change "shall
parameter of the                                                    default to" to "uses".
SCAN.request?
"A STA shall save the TXOP         Specify unambiguously, under   AGREE IN PRINCIPLE (MAC: EDITOR
holder address for the BSS in      all permitted frame exchange   2009-10-16 15:26:58Z) -
which it is associated, which is   sequences, how to determine    Replace the sentence clause
the MAC address                    this.                          "...which is the MAC address
from the Address 2 field of the                                   from the Address 2 field of the
frame that initiated a frame                                      frame that initiated a frame
exchange sequence."                                               exchange sequence." with
                                                                  "which is the MAC address
How does it know? For                                             from the Address 2 field of the
example, can it tell the                                          frame that initiated a frame
difference between a CTS-to-                                      exchange sequence except
self that initializes a TXOP and                                  when this is a CTS frame, in
a CTS response?                                                   which case the TXOP holder
                                                                  address is the Address 1
                                                                  field.".

"Following AIFSN[AC] ×             Change to "Following        AGREE (MAC: 2009-09-24          EDITOR
aSlotTime –                        AIFSN[AC] × aSlotTime –     21:52:57Z)
aRxTxTurnaroundTime of idle        aSIFSTime -
medium after SIFS"                 aRxTxTurnaroundTime of idle
                                   medium after SIFS"
Is this correct? It is
inconsistent with figure 9-18.
This formula includes two
SIFS, one inside the AIFSN
and one explicitly.

Same comment line 56 and
61.
"EIFS – DIFS + AIFSN[AC] × Remove "+ aSIFSTime"                   AGREE (MAC: 2009-09-24       EDITOR
aSlotTime + aSIFSTime –                                           21:56:13Z)
aRxTxTurnaroundTime of idle
medium"

Why is the extra aSIFSTime
here? It's already in the
AIFSN.
"Following AIFSN[AC] ×          Remove "+ aSIFSTime"              AGREE (MAC: 2009-09-24       EDITOR
aSlotTime + aSIFSTime –                                           21:56:49Z)
aRxTxTurnaroundTime of idle
medium after the last indicated
idle medium as indicated by
the CS mechanism"

This double-counts SIFS.

"If the backoff procedure is    Change preceding list to          AGREE IN PRINCIPLE             EDITOR
invoked for reason a) above," - lettered, and following list to   (EDITOR: 2009-07-02
but there is no a) above.       dashed.                           15:40:50Z)
                                                                  Make following list dashed and
                                                                  then indented bullets, which
                                                                  appears to be a style used
                                                                  elsewhere for this purpose.
"All backoff slots occur            Add: ", except as defined in     AGREE (MAC: 2009-09-24     EDITOR
following an AIFS[AC] period        9.9.1.3, which allows the        21:48:52Z)
during which the medium is          medium to be busy during the
determined to be idle for the       initial aSIFSTime of this period
duration of the AIFS[AC]            under certain conditions" to the
period"                             end of this sentence.

This is inconsistent with
397.42: "(not necessarily idle
medium during the SIFS
duration)"
"After transmitting a frame that Add "immediate" before          AGREE IN PRINCIPLE (MAC: EDITOR
requires acknowledgment" -       "acknowledgement"               2009-09-24 21:57:42Z) add
there are multiple methods of                                    "an immediate" before
acknowledgement                                                  acknowlegement.

"can" - wrong verb                  can->might           AGREE (EDITOR: 2009-07-02 EDITOR
                                                         15:49:13Z)
"When the WM is determined Replace with a statement that AGREE IN PRINCIPLE (MAC: EDITOR
to be idle for one PIFS period," is true.                2009-10-16 15:35:40Z) -
                                                         Replace "When the WM is
This is not strictly true. By                            determined to be idle for one
analogy with 9.9.1.3, under                              PIFS period," with "When the
certain circumstances the                                WM is determined to be idle at
medium may be busy during                                the TxPifs slot boundary as
the initial SIFS, and the HC is                          defined in 9.2.10," The editor
blind to the state of the                                is instructed to make a similar
medium for the final                                     change to page 403 line 02.
RxTxTurnaround time of this
period.

Same comment p403.02


"PIFS after the end of the HC’s Clarify.                         AGREE (MAC: 2009-10-16            EDITOR
last transmission only if PHY-                                   16:01:25Z) - Replace bullet a)
CCA.indication primitive is                                      with: "If the transmitting STA is
clear."                                                          the HC, it may initiate recovery
                                                                 by transmitting at the TxPifs
The timing of when CCA                                           slot boundary after the end of
needs to be clear is unclear.                                    the HC’s last transmission only
In particular, the HC is blind to                                if the PHY-CCA.indication
this during the last                                             primitive is clear during the
RxTxTurnaround time of the                                       CCAdel period preceding the
PIFS.                                                            TxPifs slot boundary as shown
                                                                 in Figure 9-12."


These procedures do not say Relate to the counters in            AGREE (MAC: 2009-10-23          EDITOR
what happens if a fragment of 9.9.1.6.                           15:45:32Z) - Rewrite sentence
an MPDU is retried during both                                   on P403L38 to read: "When
EDCA and HCCA txops.                                             there is a transmission failure
                                                                 within a polled TXOP, the long
Do the same retry counters                                       or short retry counter (as
increment?                                                       described in 9.9.1.6)
                                                                 corresponding to the AC of the
                                                                 failed MSDU or MMPDU shall
                                                                 be incremented."
point b) doesn't allow for an   Add exception in the case that AGREE (MAC: 2009-09-24            EDITOR
MSDU being retired due to       there is no MPDU to transmit. 22:03:39Z) - Replace point b
excessive retries or timeout.                                  with: "If the transmitting STA is
                                                               a non-AP QoS STA, and there
                                                               is an MPDU for transmission, it
                                                               shall initiate recovery by
                                                               transmitting at a PIFS after the
                                                               end of the last transmission, if
                                                               the polled TXOP limit is
                                                               greater than 0 and at least one
                                                               frame (re)transmissions can
                                                               be completed within the
                                                               remaining duration of a
                                                               nonzero polled TXOP limit."

"then the HC shall assume that Rewrite relating to obsevable      AGREE (MAC: 2009-09-24         EDITOR
the transmitted QoS (+)CF-Poll behaviour, or replace "shall       22:06:57Z) - Accept second
frame was successfully         assume" with "assumes".            option in proposed change.
received by the polled non-AP
STA."

The normative effect of
"assume" is unclear.
This is an over-long para.      Split it into smaller paras, if   AGREE IN PRINCIPLE                EDITOR
                                possible.                         (EDITOR: 2009-07-03
                                                                  10:21:50Z)
                                                                  Restructure as follows:
                                                                  1. Reword first sentence as:
                                                                  "Within a polled TXOP, the
                                                                  unused portion of TXOPs shall
                                                                  be returned back to the HC as
                                                                  follows:"
                                                                  2. Format "The recipient of the
                                                                  final frame, with the Ack Policy
                                                                  ... QoS Control field set to 0."
                                                                  as list item a).
                                                                  3. Format "If a PHY-
                                                                  CCA.indication(busy) primitive
                                                                  occurs ... HC may be
                                                                  incorrectly received." as
                                                                  nested item 1).
                                                                  4. Format "Note that while
                                                                  PHY-CCA.indication(busy)
                                                                  primitive is used in this
                                                                  instance to determine the
                                                                  control of the channel, it is not
                                                                  used for determining the
                                                                  success or failure of the
                                                                  transmission." as a footnote to
                                                                  item 1)
                                                                  5. Format "If the beginning of
                                                                  the reception of an expected
                                                                  ACK response frame to the
                                                                  final frame does not occur, ...
                                                                  TXOP for sending such a
                                                                  frame." as nested item 2).
"Within a polled TXOP, the    Clarify or turn into an      AGREE IN PRINCIPLE (MAC: EDITOR
unused portion of TXOPs shall informative statement.       2009-09-24 22:08:06Z) rewrite
be returned back to the HC."                               as ". . . any unused portion of
                                                           the TXOP shall not be used by
Passive voice considered                                   the STA, and may be
dangerous. What is the                                     reallocated by the HC."
normative effect of "shall be
returned". Who is the subject
responsible for returning?


"slot following SIFS after the    insert "a"               AGREE IN PRINCIPLE              EDITOR
end" - missing article                                     (EDITOR: 2009-07-03
                                                           10:28:02Z)
                                                           Replace "following SIFS" with
                                                           "following a SIFS" globally.

"prevent its transmitting" -      its->it                  AGREE IN PRINCIPLE (MAC: EDITOR
genative is inappropriate                                  2009-09-24 22:08:56Z) -
                                                           Replace "prevent its
                                                           transmitting" with "prevent it
                                                           from transmitting"
"it may reset the NAVs of all Add the word "QoS" before    AGREE (MAC: 2009-09-24         EDITOR
STAs in the BSS by sending a "STAs".                       22:11:38Z)
QoS CF-Poll frame with the
RA matching its own MAC
address and with the
Duration/ID field set to 0."

As I understand it, this will
only affect QoS STA. So the
statement is at least
misleading.

It also begs the question
whether it is fair to reset the
NAVs of only the QoS STAs.
"A non-AP STA that receives a Resolve the inconsistency.   AGREE (MAC: 2009-10-23          EDITOR
CF-End frame containing the                                15:24:01Z). Delete the cited
BSSID of the BSS, in which                                 sentence, and add a note to
the non-AP STA is associated,                              clause 9.9.2.2a following the
shall reset the NAV value to                               paragraph where the first cited
0."                                                        sentence was present that
                                                           reads: "NOTE--A STA resets
appears to be inconsistent with                            its NAV when it receives a CF-
(382.38 9.3.2.2): "The PC                                  End or CF-End+ACK frame
shall transmit a CF-End or CF-                             according to the procedures
End+ACK frame at the end of                                described in 9.3.2.2."
each CFP. A STA that
receives either of
these frames, from any BSS,
shall reset its NAV."
"If a CF-Poll is piggybacked     Relate frame TID carrying the   AGREE (MAC: 2009-10-23        EDITOR
with a QoS data frame, then      TSID of a TS for which a        15:37:26Z) - "If a CF-Poll is
the                              minimum phy rate was            piggybacked with a QoS data
MSDU may be transmitted at       specified with the RA of that   frame, then the MSDU may be
the rate that is below the       frame.                          transmitted at a rate that is
negotiated minimum PHY                                           below the negotiated minimum
rate."                                                           PHY rate in the TSPEC related
                                                                 to that data."
Negotiated how? With
whom?
"and it has to send more         replace with "and it has more   AGREE (EDITOR: 2009-07-03          EDITOR
MPDUs." - grammar                MPDUs to send."                 10:37:34Z)
"in the QoS data or QoS Null     replace with "in a QoS data     AGREE (EDITOR: 2009-07-03          EDITOR
frame" - grammar                 frame or a QoS Null frame"      10:39:11Z)
(Submitted on behalf of Carlos   As noted                        AGREE IN PRINCIPLE                 EDITOR
Cordeiro) For completeness,                                      (EDITOR: 2009-07-02
9.14 (MAC Frame Processing)                                      13:14:53Z)
should be included at the end                                    Add "Rules for processing
of the paragraph+F275                                            MAC frames are described in
                                                                 9.14 (MAC frame
                                                                 processing(11k))." to the end
                                                                 of the cited text.
(Submitted on behalf of Carlos Rewrite removing the "shall"      AGREE (MAC: 2009-07-14             EDITOR
Cordeiro) The sentence: "The                                     15:25:29Z). Change sentence
use of a smaller IFS implies                                     to read "The use of a smaller
that point-coordinated traffic                                   IFS implies that point-
shall have priority access to                                    coordinated traffic has priority
the medium over STAs in                                          access to the medium over
overlapping BSSs operating                                       STAs in overlapping BSSs
under the DCF access                                             operating under the DCF
method." The use of "shall"                                      access method."
here seems improper. How
can this be tested? What is the
normative behavior here?

(Submitted on behalf of Carlos Add " and (Re)Association         AGREE IN PRINCIPLE (MAC: EDITOR
Cordeiro) The EDCA             Response" after "… Probe          2009-09-24 22:13:00Z) -
parameter set can also be      Response"                         change end of cited sentence
changed in a (Re)Association                                     to read ". . .Beacon frame,
Response frame                                                   Probe Response frame, and
                                                                 (Re)Association Response
                                                                 frame."

Replace "nonbeacon" by "non As noted                             AGREE IN PRINCIPLE                 EDITOR
Beacon"                                                          (EDITOR: 2009-07-02
                                                                 13:31:59Z)
                                                                 Replace by non-Beacon
                                                                 globally (2 occurances).
(Submitted on behalf of Carlos Replace "shall" by "may"          AGREE IN PRINCIPLE (MAC: EDITOR
Cordeiro) The sentence: "…                                       2009-09-24 22:26:08Z) -
then the STA shall retry the                                     Remove ",at its convenience"
sequence, by transmitting                                        from the cited sentence.
another PS-Poll frame, at its
convenience." This is not
enforcable. The sentence
states "shall" but "at its
convenience". If the intention
is to allow the STA to decide to
retransit when it sees fit (or not
retransmit at all), "shall" should
not be used here

(Submitted on behalf of Carlos As noted                          AGREE IN PRINCIPLE               EDITOR
Cordeiro) Replace "nonbasic"                                     (EDITOR: 2009-07-02
by "non basic"                                                   13:34:58Z)
                                                                 Replace by non-basic.
(Submitted on behalf of Carlos 1) Replace "so that" by "if"      DISAGREE (EDITOR: 2009- EDITOR
Cordeiro) Propose to rewrite   2) Replace "does not cause"       07-02 15:36:08Z)
this sentence to make the      by "causes"                       The change results in "if
intent clear, which is not the                                   transmission of the first mpdu..
case now                                                         causes the txop limit to be
                                                                 exceeded". The point is that
                                                                 we want to prevent this
                                                                 occuring, not respond to it.

                                                                 The implication of the change
                                                                 is to try transmission, and if
                                                                 you observe the TXOP limit is
                                                                 exceeded, then fragment.
                                                                 This is not the desired
                                                                 behaviour.

(Submitted on behalf of Carlos Change the enumeration of         AGREE IN PRINCIPLE          EDITOR
Cordeiro) There are no "a)",   the bullets from dash to "a)",    (EDITOR: 2009-07-02
"b)", "c)" or "d)". The        "b)", "c)" and "d)"               15:42:57Z)
enumeration needs to change                                      See resolution to CID 1651,
                                                                 which addresses this issue.
(Submitted on behalf of Carlos    Delete comma                   AGREE (EDITOR: 2009-07-02 EDITOR
Cordeiro) Although I am not a                                    15:48:25Z)
native english speaker (but a
native ESL), I am pretty sure
that the comma in this
sentence is grammatically
wrong. In this case, one
cannot separate the verb with
a comma
(Submitted on behalf of Carlos    Insert ", including a CF-End   AGREE IN PRINCIPLE (MAC: EDITOR
Cordeiro) It would be desirable   frame (see 9.9.2.2a (NAV       2009-09-24 22:18:51Z)
to explicitly state that the HC   operation during a TXOP)),"    Change last phrase in cited
can transmit a CF-End (or a       following "… other             sentence to read: ". . .and the
QoS CF-Poll with the duration     transmissions"                 HC may initiate other
set to 0) to end the CFP                                         transmissions, send a CF-End
                                                                 frame (see 9.9.2.2.a), or allow
                                                                 the channel to go into the CP."
(Submitted on behalf of Carlos As noted                      AGREE IN PRINCIPLE              EDITOR
Cordeiro) Replace                                            (EDITOR: 2009-07-03
"transmitting" by                                            10:35:46Z)
"transmission"                                               Replace "its transmitting" with
                                                             "it from transmitting" in cited
                                                             location.
(Submitted on behalf of Carlos Move note 34 to page 407      DISAGREE (EDITOR: 2009- EDITOR
Cordeiro) Note 34 should                                     07-03 10:39:44Z)
appear on this page, but is on                               Moving Note 34 to the
the next one                                                 preceding page would force
                                                             the text containing the
                                                             reference onto the next page,
                                                             so the note would then
                                                             preceed the reference.

                                                             The editor has no control over
                                                             the precise placement of these
                                                             notes. However, in this case,
                                                             the Frame tools are doing
                                                             precisely the right thing.

Is "lifetime" of a BSS defined? Clarify                      The statement indicates that     EDITOR
Is it the time in between power                              an AP does not change the
up events? I believe this is the                             value of this bit during the
intent and wonder if this                                    lifetime of its BSS. This bit is
should be called out to                                      part of the EDCA Parameter
distinguish it from, for                                     Set element, which is a
example, when the AP stops                                   parameter of the MLME-
functioning altogether                                       START.request primitive. The
                                                             "lifetime of its BSS" may be
                                                             interpreted as the time
                                                             between the start of the MLME-
                                                             START.request primitive and a
                                                             subsequent MLME-
                                                             STOP.request or MLME-
                                                             RESET.request.
(Submitted on behalf of Carlos Replace "a local matter" by   AGREE (EDITOR: 2009-07-27 EDITOR
Cordeiro) "local matter" is a  "implementation dependent"    11:13:41Z)
weird term.
(Submitted on behalf of Carlos    Suggest to include the           AGREE IN PRINCIPLE (MAC: EDITOR
Cordeiro) A STA can only          conditional statement that the   2009-11-13 19:59:37Z) -
continue transmitting MPDUs       total number of frames shall     Change the cited paragraph to
after transmission of the         not exceed the reordering        read: "The originator may
BlockAckReq frame provided        buffer                           continue to transmit MPDUs
the total number of                                                (subject to the negotiated
outstanding frames do not                                          buffer size constraint) to the
exceed the reordeing buffer at                                     recipient after transmitting the
the receiver (Buffer Size field                                    BlockAckReq frame, but
in the ADDBA Response                                              before receiving the BlockAck
frame)                                                             frame (applicable only to
                                                                   delayed Block Ack). The
                                                                   bitmap in the BlockAck frame
                                                                   shall include the status of
                                                                   frames received between the
                                                                   start sequence number and
                                                                   the transmission of the
                                                                   BlockAckReq frame. A
                                                                   recipient sending a delayed
                                                                   BlockAck frame may update
                                                                   the bitmap with information on
                                                                   QoS data frames received
                                                                   between the receipt of the
                                                                   BlockAckReq frame and the
                                                                   transmission of the BlockAck
                                                                   frame."

MDIE should be refered to as      Delete the word "information"    AGREE IN PRINCIPLE               EDITOR
the Mobility Domain element.      as appropriate throughout this   (EDITOR: 2009-07-28
                                  clause for consistency with      11:12:25Z) - Replace all
                                  clause 7.3.2.                    “information element” with
                                                                   “element” – except in the
                                                                   heading of 7.3.2. and 7.3.1
                                                                   Remove redundant
                                                                   “information” from name of
                                                                   elements in table 7-26 and
                                                                   make matching changes to
                                                                   references throughout the
                                                                   standard, except in
                                                                   dot11RMAntennaInformationE
                                                                   nabled, replace "Antenna
                                                                   Information" with "Antenna
                                                                   information", and in
                                                                   dot11RMMeasurementPilotTra
                                                                   nsmissionInformationEnabled
                                                                   description, lower case the
                                                                   "information".
                                                                   Globally replace any
                                                                   abbreviations that expand to
                                                                   <something> information
                                                                   element with new names (e.g.
                                                                   MDIE->MDE), excepting TIE,
                                                                   which is already correct for the
                                                                   new terminology.
The text states "A non-AP STA      Specify that the TID value is        AGREE IN PRINCIPLE (MAC: EDITOR
may support admission control      changed to correspond to the         2009-11-19 16:19:13Z) -
procedures in 9.9.3.1.2            next lower AC that doesn't           Instruct the editor to apply the
(Procedure at non-AP STAs)         require admission control and        changes in 11-09/1063r1.
to send frames in the AC           that the frame is enqueued in
where admission control is         that lower AC.
mandated; but, if it does not
support that procedure, it shall   This change means that the
use EDCA parameters of a           priority carried in the
lower priority AC, as indicated    QoS_control field properly
in Table 9-1 (UP-to-AC             reflects the over-the-air priority
mappings), that does not           on the link. The EDCA
require admission control."        parameters used by an
This text is ambiguous since it    EDCAF are not observable to
does not describe whether the      a receiver; neither is the fact
TID subfield in the                that the frame is downgraded
QoS_control field in the MAC       to a lower AC as there is no
header is changed.                 indication in the MAC header
                                   that downgrading has occurred
                                   UNLESS the TID is also
                                   changed. Any HC attempting
                                   to manage the WM needs this
                                   information (i.e., WM usage by
                                   AC); note that the HC needs to
                                   know WM usage by AC for
                                   BSSs other than the BSS of
                                   the AP containing the HC.

                                   This change is required for
                                   proper operation of the
                                   standard.
The text states "If a STA          Specify that the TID value is        AGREE IN PRINCIPLE (MAC: EDITOR
desires to send data without       changed to correspond to the         2009-11-19 16:19:13Z) -
admission control using an AC      next lower AC that doesn't           Instruct the editor to apply the
that mandates admission            require admission control and        changes in 11-09/1063r1.
control, the STA shall use         that the frame is enqueued in
EDCA parameters that               that lower AC.
correspond to a lower priority
and do not require admission       This change means that the
control." This text is             priority carried in the
ambiguous since it does not        QoS_control field properly
describe whether the TID           reflects the over-the-air priority
subfield in the QoS_control        on the link. The EDCA
field in the MAC header is         parameters used by and
changed.                           EDCAF are not observable to
                                   a receiver; neither is the fact
                                   that the frame is downgraded
                                   to a lower AC as there is no
                                   indication in the MAC header
                                   that downgrading has occurred
                                   UNLESS the TID is also
                                   changed. Any HC attempting
                                   to manage the WM needs this
                                   information (i.e., WM usage by
                                   AC); note that the HC needs to
                                   know WM usage by AC for
                                   BSSs other than the BSS of
                                   the AP containing the HC.

                                   This change is required for
                                   proper operation of the
                                   standard.

The text states "The               Change the text to "The              DISAGREE (MAC: 2009-09-23 EDITOR
admitted_time and used_time        admitted_time and used_time          03:10:46Z) - The proposed
shall be set to 0 at the time of   shall be set to 0 at the time of     change has potentially large
(re)association."                  association."                        ripple effects because it
Reassociation to the same AP                                            eliminates the ability to reset
should not cause these times                                            the state of a QoS STA
to be set to 0--for example, a
non-AP STA may wish to
reassociate in order to change
the QoS Info field in the EDCA
parameter element included in
a reassociation request frame.


The text states "However, a        Add text indicating that the         AGREE IN PRINCIPLE (MAC: EDITOR
non-AP STA may choose to           priority is not changed (else        2009-09-23 03:16:10Z) The
temporarily replace the EDCA       the EDCAF would change and           text is not ambiguous because
parameters for that EDCAF          frame re-ordering could              it does not need to specify that
with those specified for an AC     occur).                              the TID field is unchanged.
of lower priority, if no                                                However, this could be
admission control is required                                           clarified by adding the
for those ACs." This text is                                            following note: "NOTE -- when
ambiguous since it does not                                             a frame is transmitted using
describe whether the TID                                                temporary EDCA parameters,
subfield in the QoS_control                                             the TID field of that frame is
field in the MAC header is                                              not modified"
changed.
What is the definition of an    Provide a definition.          AGREE IN PRINCIPLE            EDITOR
"inactive TS". Is this the same                                (EDITOR: 2009-08-07
as unadmitted traffic?                                         08:36:54Z) -
                                                               Replace the sentence reading:
                                                               "A STA shall not transmit any
                                                               QoS data frames using an
                                                               inactive TS." with one that
                                                               reads:
                                                               "A STA shall not transmit any
                                                               QoS data frames in which the
                                                               TID subfield of the QoS
                                                               Control field matches an
                                                               inactive TS."

                                                               In reply to the commenter, the
                                                               change clarifies that no traffic
                                                               whatsever may be transmitted
                                                               using an inactive TS.

The text states "Following a      Clarify the text.            AGREE (EDITOR: 2009-11-19 EDITOR
successful TS setup initiated                                  13:30:00Z) - AGREE (MAC:
by the non-AP STA, the TS                                      2009-08-07 15:14:10Z)
becomes active, and either the                                 change "transmit QoS data
non-AP                                                         frames using this TSID" to
STA or the HC may transmit                                     "transmit QoS data frames
QoS data frames using this                                     whose TID contains this
TSID". How does a STA                                          TSID."
transmit a frame using a
TSID? The TSID is a TSPEC
identifier and is not part of any
frame of type=data that is
transmitted when the access
mechanism is EDCA.

There is no text stating when a   Add rules which define the   UNRESOLVABLE (MAC: 2009- EDITOR
result code of                    interaction of TSID, user    11-19 16:58:10Z) - Comment
INVALID_PARAMETERS                priority, direction and      withdrawn on 11/18 AM2
should be used.                   successful/rejected          session because no action is
                                  replacement.                 required.
The text states "After the setup     Change the text.   DISAGREE (MAC: 2009-09-24 EDITOR
of a TSPEC, MSDUs are                                   19:27:08Z) - The priority
classified above the MAC and                            parameter takes a TSID, which
are sent to the MAC through                             is a number in the range 8-15
the MAC_SAP using the                                   which identifies a TS. Over
service primitive MA-                                   the air this is for EDCA
UNITDATA.request with the                               converted to a UP in the range
priority parameter encoded to                           0-7. The union of UPs and
the TSID." In the MA-                                   TSIDs are TIDs, but this is not
UNITDATA.request primitive,                             what is passed in MA-
the priority should be encoded                          UNITDATA in the case of
to the TID (not TSID)--see                              MSDUs belonging to a TS.
6.1.1.2.
The text states "The MAC             Change the text.   AGREE IN PRINCIPLE             EDITOR
delivers the MSDUs based on                             (EDITOR: 2009-11-19
a schedule using QoS data                               13:30:04Z) - AGREE IN
frames. In the case of a non-                           PRINCIPLE (MAC: 2009-08-
AP STA, the MSDUs are                                   07 15:27:51Z) - Delete the two
transmitted using QoS data                              cited sentences because they
frames, when the non-AP STA                             do not have a normative
is polled by the HC." Polling is                        requirement.
only used in HCCA and HEMM
access mechanisms, but not
EDCA. The text should be
corrected.
The abbreviation TSID is             Change the text.   AGREE (EDITOR: 2009-11-19 EDITOR
incorrect--the priority is carried                      13:30:09Z) - AGREE (MAC:
in the TID. This same mistake                           2009-08-07 00:26:57Z)
is propagated throughout the                            Change "TSID" to TID"
paragraph.
The text states "When an             Per comment.       AGREE IN PRINCIPLE (MAC: EDITOR
MSDU arrives from the                                   2009-09-23 03:39:51Z) -
MAC_SAP with a TSID for                                 Delete the final paragraph in
which there is no associated                            clause 11.4.6 on page 612.
TSPEC, then the MSDUs shall
be sent using EDCA using the                            Add the statement "See
access category AC_BE."                                 6.1.1.2 for the treatment of an
                                                        MSDU with a TSID for which
First, the MA-                                          there is no associated
UNITDATA.request primitive                              TSPEC." to the end of the
doesn't use TSID, it uses                               second paragraph in in 11.4.6.
priority.

Secondly, this text is
ambiguous because it doesn't
state what value should be
placed in the TID subfield in
the QoS_control field in the
MAC header. The text should
state that the TID should be
set to 0 (best effort) in this
case.
The text states "When the     Delete this paragraph.                 AGREE IN PRINCIPLE          EDITOR
Processing subfield of the                                           (EDITOR: 2009-11-19
TCLAS Processing information                                         13:30:15Z) - AGREE IN
element is set to 1, then the                                        PRINCIPLE (MAC: 2009-08-
receiver cannot recover the                                          07 15:50:21Z) - Replace the
original UP unless it does a                                         cited paragraph with the
reverse mapping based on the                                         statement: "When an MSDU is
TCLAS parameters." Even if                                           classified using a TCLAS
the receiver attempts to                                             information element, the
perform the reverse mapping,                                         original UP cannot be
how will it know the original                                        recovered by the receiver."
UP? A non-AP STA does not
know the CoS to UP mapping
used by the LAN.

Reassociation to the same AP Change the text.                        DISAGREE (EDITOR: 2009- EDITOR
should not cause the TSs to                                          11-19 13:30:20Z) - DISAGREE
be deleted--for example, a non-                                      (MAC: 2009-08-07 15:59:47Z) -
AP STA may wish to                                                   Reassociation may change the
reassociate in order to change                                       capabilities of a non-AP STA,
the QoS Info field in the EDCA                                       which may have change the
parameter element included in                                        validity of existing TSs. The
a reassociation request frame.                                       proposed resolution does not
                                                                     provide enough detail to
Also, association to the same                                        implement this change.
AP should cause the TSs to be
deleted--that way the non-AP
STA can always get back to a
known state (this is critical
because U-APSD operation
sets non-AP queuing state on
AP and if this gets out-of-sync
for any reason, there should
be a way to reset it).

This change is required for
proper operation of the
standard.


"A special BSSID". Define         Change to "A BSSID value (all      AGREE (GEN: 2009-09-24     EDITOR
"special"? Somehow the IEEE       binary 1s) used to represent all   23:14:35Z)
spec has feelings?                BSSIDs"
"A special SSID". Define          Change to "A SSID value (null)     AGREE IN PRINCIPLE         EDITOR
"special"? Somehow the IEEE       used to represent all SSIDs"       (EDITOR: 2009-08-06
spec has feelings?                                                   11:17:50Z)
                                                                     Make change as proposed,
                                                                     and similar change for
                                                                     "wildcard BSSID".
11k text states for Power  Fix                                DISAGREE (EDITOR: 2009- EDITOR
Constraint "and can be                                        07-01 15:50:10Z)
present                                                       Since .11k was rolled in,
if                                                            changes have been made to
dot11RadioMeasurementEnab                                     unify the "presence" language
led is true." whereas 11mb                                    according to document 11-09-
states "and is optionally                                     0433r1.
present present if                                            The change cited is part of a
dot11RadioMeasurementEnab                                     process to improve the
led is true".                                                 consistency of language used
                                                              in Clause 7.
DS Parameter set is              Include regulatory domain    DISAGREE                      EDITOR
insufficient to identify the     whenever DS Parameter set is (ARCHITECTURE: 2009-11-
channel uniquely. Regulatory     included.                    17 22:47:26Z) making such a
domain must be included. As                                   change would change
supported reg class is only                                   behaviour and break legacy
included when extended                                        devices.
channel switch is true then it
seems there is a whole if DS
Parameters are included but
ECSA is false.
"The Measurement Pilot frame Delete this sentence.           AGREE (EDITOR: 2009-07-01 EDITOR
is a compact Action frame                                    12:59:29Z)
transmitted periodically by an
AP at a small interval relative
to a Beacon Interval." This
sentence is redundant. The
next sentence conveys this
information in a better way.

"ongoing traffic stream link". Is Replace "ongoing traffic   AGREE IN PRINCIPLE             EDITOR
there one such term? Ongoing stream link" with a more        (SECURITY: 2009-07-14
traffic stream or ongoing traffic appropriate term.          22:04:34Z)
stream over the link is                                      Replace the text with "ongoing
appropriate.                                                 traffic stream".
Use of Radio Measurement            Use either Radio                AGREE IN PRINCIPLE           EDITOR
and Radio Resource                  Measurement or Radio            (EDITOR: 2009-07-01
Measurement. Are they the           Resource Measurement in all     13:00:39Z)
same or different? Cl. 5.2.7        places. It appears that Radio
uses Radio Resource                 Measurement (206) is used in    Change all "radio resource
Measurement while it is             more instances than Radio       measurement" to "radio
referred to as Radio                Resource Measurement (19).      measurement".
Measurement here.
                                                                    Change all "RRM" to "RM".
                                                                    (about 740 instances)

                                                                    Also remove any embedded
                                                                    hyphens in these names
"The Power Constraint               Remove the extra 'present' in   AGREE (EDITOR: 2009-07-01 EDITOR
element is present if               the Notes column.               14:58:01Z)
dot11SpectrumManagementR
equired is true and is
optionally present present if
dot11RadioMeasurementEnab
led is true."
The need for the prefix "MIB        Remove the prefix "the MIB      AGREE (ARCHITECTURE:         EDITOR
attribute". Why is this used in     attribute"                      2009-11-16 15:28:29Z)
some cases and not in others?
For instance:

"A STA sets the Radio
Measurement subfield in the
Capability Information field to 1
when the MIB attribute
dot11RadioMeasurementEnab
led is true, and sets it to 0
otherwise."

If the prefix is needed here,
why is it not needed in the
Notes column corresponding
to Antenna Information in
Table 7-15?
Consistency in describing          Limit description of reserved    AGREE IN PRINCIPLE             EDITOR
Reserved bits. There are three fields/ bits to "is/are reserved".   (EDITOR: 2009-07-27
variations:                                                         08:07:06Z)
(i) All other bits are reserved.                                    Review Clause 7 for use of the
(ii) All other bits are reserved                                    term "reserved" and remove
and are set to 0.                                                   any spurious specification of
(iii) All other bits are reserved;                                  behaviour or value for a
and are set to 0 upon                                               reserved field in Clause 7,
transmission and ignored upon                                       excepting 7.1.1 and any
reception.                                                          Notes.

In most cases, (i) is what                                          Note the contradiction at the
should be used. Cl. 7.1.1                                           end of 7.1.3.5, which defines
clearly describes what                                              a reserved field as having an
reserved means.                                                     unspecified value, when 7.1.1
                                                                    clearly indicates that a
                                                                    reserved field is set to 0. This
                                                                    contradiction is resolved by
                                                                    removing the last phrase of
                                                                    7.1.3.5.

                                                                    In the 5th para of 7.3.2.19,
                                                                    replace: "The Link Margin field
                                                                    is(11k) set to 0 and is(#29)
                                                                    ignored" with "The Link Margin
                                                                    field is reserved"

                                                                    In the last phrase of 7.3.2.50,
                                                                    replace: "Status Code field is
                                                                    set to 0 and ignored upon
                                                                    receipt" with "Status Code field
                                                                    is reserved"
The Note in Table 7-28 is mis-   Moce the note to the               AGREE (ARCHITECTURE:             EDITOR
placed. This applies to the      "Measurement Request               2009-07-16 06:41:41Z)
"Measurement Request             Meaning" cell corresponding to
Meaning" cell for the last row   the last row in Table 7-28.
in the table.




extra characters after "STA                                         AGREE (EDITOR: 2009-07-02 EDITOR
statistics request"                                                 06:13:38Z)
What is the requirement on          Specify that the fields are     AGREE (ARCHITECTURE:      EDITOR
Average Error Threshold,            reserved if the corresponding   2009-07-16 06:42:01Z)
Consecutive Error Threshold bits are set to 0.
and Delay Threshold, if the
corresponding bits in the
trigger conditions bit-field is set
to 0?
Two issues with the                Make the description        DISAGREE                      EDITOR
description of the                 consistent with other       (ARCHITECTURE: 2009-11-
Measurement Duration field in      measurement request         18 20:49:49Z) The commentor
the STA statistics request         elements. Add the special   is encouraged to provide more
element:                           case of what it means to    details of any proposed
                                   specify a measurement       improvement, but without the
(a) While all other request        duration of 0.              details of what is proposed,
elements describe                                              the group cannot evaluate the
Measurement Duration as                                        technical merit at this time.
"The Measurement Duration
field is set to the preferred or
mandatory duration of the
requested measurement,
expressed in units of TUs. See
11.10.3 (Measurement
Duration).", description in STA
statistics request is "The
Measurement Duration field is
set to the duration of the
requested measurement in
TUs." Why is the choice of
preferred/mandatory duration
and the reference to clause
11.10.3 missing?
(b) STA statistics request has
a special case for
Measurement Duration --
when the specified
Measurement Duration is 0,
the reporting STA (assuming it
supports STA statistics
reporting), is expected to
report a snapshot of the
There appears to be nothing       Recommend having the               DISAGREE                        EDITOR
optional about the optional sub- measuring STA report a frame        (ARCHITECTURE: 2009-11-
elements in the Frame Report count in the Frame Report at            19 17:22:59Z) - the requested
Information Element. A Frame all times. The Frame Report             change is not compatible with
Request IE without a Frame        sub-element may report             legacy devices. On the
Request Type is invalid (it is a additional values based on          optional sub-elements item:
mandatory field). This means optional sub-elements                   Disagree. This is for general
that the corresponding Frame specified in the Frame                  structure and future use of the
Report is required to include a Request. In addition, specify        Frame Report when a
Frame Count Report (at all        (in Cl. 11) that the reporting     subelement may not be
times) which is described as      STA shall respond with             required. On the wastefulness
an optional sub-element.          'Incapable' if the requesting      of transmitting values that
                                  STA were to request reporting      cannot be reported: Disagree,
In addition, a reporting STA      of a measurement (using the        because it is a bad idea to
may not have support for all      optional sub-element in the        make the frame format overly
the information described in      request) that the reporting STA    complex to support this
the Frame Count Report sub- does not support.                        suggested change.
element (for instance, a STA
may not have the ability to
measure RCPI, RSNI, etc).
Although there are specific
RCPI/RSNI values defined to
indicate that it is 'unknown', it
is wasteful to send the value in
a frame report when the STA
has already advertised that it
cannot report these values via
the RRM Enabled Capabilities
element.



Inconsistency between the        Fix Figure 7-68l to use a 1-        AGREE IN PRINCIPLE               EDITOR
length of                        octet sub-field for                 (ARCHITECTURE: 2009-07-
dot11BSSAverageAccessDela        dot11STAStatisticsStationCou        16 06:42:24Z) The MIB
y group statistics in Table 7-   nt.                                 defines this to have values up
31f (specifies length as 7                                           to 64K, so it needs to be 2
octets) and in Figure 7-68l                                          octets. Figure 7-68l is correct.
(shows 8 octets)                                                     Change Table 7-31f to show
                                                                     the length as 8 octets.

Should the 'Bin 0 Range'         Clarify if the report should just   DISAGREE                        EDITOR
returned in the report be the    echo the value in the request.      (ARCHITECTURE: 2009-11-
same as the one in the           Or could the reporting STA          18 20:50:14Z) - The
request? There is no             adjust the Bin 0 value in such      commentor is encouraged to
requirement on what is           a way that the histogram            provide more details of any
allowed and what is not as far   covers a range where there is       proposed improvement, but
as Bin 0 Range goes both         something to report.                without the details of what is
here in Clause 7 and in Clause                                       proposed, the group cannot
11.10.8.8.                       In cases where the report is        evaluate the technical merit at
                                 generated autonomously the          this time.
                                 reporting STA can determine a
                                 Bin 0 Range that makes the
                                 most sense and report that
                                 accordingly.
Bin 0 Range is a perfect             Move Bin 0 Range to Optional        DISAGREE                        EDITOR
candidate for the Optional           Subelements in the request          (ARCHITECTURE: 2009-11-
Subelements. This provides           and the corresponding               19 17:22:59Z) - on first
the flexibility of reporting         elements/fields to the Optional     appearance the requested
stream statistics for TID            Subelements in the report.          change is not compatible with
versus reporting stream                                                  legacy devices. The
statistics and the distribution of                                       commentor is solicited to
corresponding delays for a                                               provide a submission that
TID.                                                                     explains the proposal in a way
                                                                         that provides backwards
                                                                         compatibility.
"Element ID is 48 decimal (30        Delete this description. Or         AGREE IN PRINCIPLE              EDITOR
hex)". All elements described        Make the description of             (EDITOR: 2009-07-02
in Clause 7.3.2 do not include       Element ID consistent across        06:17:04Z)
a description of the element ID      all the elements.                   Replace any statement in
since the element ID is defined                                          7.3.2 of the form "Element ID
in Table 7-26 which is at the                                            is <some value>" with
start of Clause 7.3.2. Why is it                                         "Element ID is set to the value
explicitly described (re-                                                for <name of element>,
described) for the RSN IE?                                               specified in Table 7-26"

Similar issue with 7.3.2.27                                              Note - this affects the Country,
(Extended Capabilities IE)                                               Hopping Pattern Table,
                                                                         Request, RSN and Extended
Some elements do describe                                                Capabilities elements.
the Element ID field as follows:
"The Element ID field is equal
to the <xxx> value in Table 7-
26 (Element IDs)."

Task Group v has                                                         DISAGREE                     EDITOR
clarified/corrected several                                              (ARCHITECTURE: 2009-11-
issues in the TCLAS element                                              16 15:32:27Z) -- No proposed
description. These changes                                               resolution, Comment not
were done in TGv only                                                    complete.
because they were identified
after TGma closed. It would be
appropriate for the work to be
included in TGmb for two
reasons: (a) get wider review
of the changes and (b)
Where is the description for         Add description of the EDCA         AGREE IN PRINCIPLE              EDITOR
the "EDCA Parameter Set              Parameter Set Update Count          (ARCHITECTURE: 2009-11-
Update Count" subfield in the        or refer to where it is described   18 20:55:03Z) Insert at line 64
QoS Info field (Clause               (Clause: 7.3.2.29)                  "EDCA Parameter Set Update
7.3.1.17)?                                                               Count is described in 9.1.3.1."

length of RRM Enabled                                                    AGREE (ARCHITECTURE:               EDITOR
Capabilities should be 5 (See                                            2009-07-16 06:42:53Z)
7.3.2.45 RRM Enabled
Capabilities Element)
Inconsistency in how "element"                               AGREE IN PRINCIPLE                EDITOR
is used in the title of sub-                                 (EDITOR: 2009-07-01
clauses -- it is Element in                                  16:33:25Z)
some and element in others.
                                                             Change upper cased Element
                                                             to lower-case, except where
                                                             an initial E is required at the
                                                             start of a sentence, or where
                                                             "Element" forms part of a field
                                                             name.

                                                             Change Element->element in
                                                             heading of 7.3.2.46, 7.3.2.45

"Station Bridge" functionality is Add support for "Station   DISAGREE (GEN: 2009-11-13 EDITOR
not supported in 802.11.          Bridge" in 802.11          16:54:58Z) - Disagree: New
                                                             features and functions such as
In a device that includes a                                  this should be presented and
802.11 non-AP STA interface                                  vetted in the 802.11 WNG-SC.
and a 802.2.3 wired LAN                                      A submission would be
interface, internally bridged                                needed as well as the
together, a broadcast                                        proposal
message for instance an ARP
Request, that ingresses via the
802.3 interface where the
Target MAC Address does not
resolve to the device, gets
sent out via the 802.11
interface to the BSS that the
device is associated with. In
such cases, the AP receiving
ARP request (assuming that
the Target MAC Address does
not resolve to the AP)
broadcasts the ARP message
to all the STAs associated with
it (including the one that sent it
in the first place). Without
proprietary non-standard
counter measures, this causes
the ARP broadcast to egress
off of the 802.3 interface
through which the ARP
originated. This violates the
expected behavior --
broadcast/multicast messages
that ingressed via an interface
As pointed out by other            I suggest, minimally,              Insert: "In each Annex G         EDITOR
comments (and my own) the          incorporating the data tables of   Table which has "Binary Val"
CRC value for the Annex G.2,       802.11n, Annex G.1 into the        columns, the bit positions of
Table G.1, is incorrect. The       .11mb draft.                       the binary values are specified
last four bytes should be:                                            in the header of the Table. " at
0x67, 0x33, 0x21, 0xB6,                                               the end of G.1.
instead of 0xDA, 0x57, 0x99,
0xED. This has a "rippling                                            Replace table G.1 with that in
effect" that cause the data                                           P802.11n D11.0.
tables for the last symbol, i.e.
"Last 144 DATA bits" to be                                            In G.5.1, replace: "The data
incorrect throughout the                                              bits are shown in Table G.13
remainder of Annex G.                                                 (First 144 DATA bits) and
                                                                      Table G.14 (Last 144 DATA
In 802.11n, Draft 11.0, the                                           bits). For clarity, only the first
correct information is present                                        and last 144 bits are shown."
for the BCC example. The                                              with "The DATA bits are
format has been changed to                                            shown in Table G.13."
include the all the symbols, as
well as pointing out that the                                         Replace Table G.13 with that
FEC code being used is BCC                                            in P802.11n D11.0 and delete
(as opposed to LDPC for                                               Table G.14.
802.11n) throughout. (This
became necessary to illustrate                                        In G.5.2, replace: "The first
the various pre-processing                                            and last 144 scrambled bits
techniques: padding,                                                  are shown in Table G.16 (First
shortening, and repetition. It                                        144 bits after scrambling) and
was also necessary to                                                 Table G.17 (Last 144 bits after
renumber the subclauses,                                              scrambling), respectively." with
inserting a higher level G.1-                                         "The scrambled DATA bits are
G.3 numbering, for the three                                          shown in Table G.16."
examples in 802.11n).
"during operation" should be    as noted.                             AGREE Table G.16 as with
                                                                      Replace (EDITOR: 2009-07-01 EDITOR
"during the operation"                                                11:46:36Z)
"a gap…exist between" should as noted.                                AGREE (EDITOR: 2009-07-02 EDITOR
be "a gap exists between"                                             13:16:08Z)

"using eight different UPs"      as suggested.                        DISAGREE (MAC: 2009-09-24 EDITOR
should state "using up to eight                                       22:22:07Z) - The cited text
different UPs", since "using" is                                      refers to the EDCA
different from "supporting" and                                       mechanism, which provides
a STA can use only a subset                                           eight UPs.
of the allowed UPs.

"to use RTS/CTS" should be       as suggested.                        AGREE (MAC: 2009-07-14               EDITOR
"to initiate RTS/CTS" since the                                       15:42:52Z)
dot11RTSThreshold is only for
triggering the initial RTS/CTS
frame.
In the figure, if by "DIFS/AIFS" as noted.                            AGREE IN PRINCIPLE            EDITOR
we mean "DIFS or AIFS", it                                            (EDITOR: 2009-07-02
should be stated as such.                                             13:27:32Z) - replace "Medium
Also, "Medium is free" is not                                         is free >= DIFS/AIFS[i]" with
the same as the "medium is                                            "Medium is idle >= DIFS or
idle" description used in the                                         AIFS[i]" in figure 9-3.
rest of the document.
"a HC" should be "an HC" to    as noted.                    AGREE IN PRINCIPLE           EDITOR
be consistent and correct.                                  (EDITOR: 2009-07-02
                                                            15:46:31Z)
                                                            Make this change globally (3
                                                            occurances)
Expand clause heading to       as noted.                    AGREE (EDITOR: 2009-07-01 EDITOR
"Extended Rate PHY (ERP)                                    09:45:21Z)
Specification"
In previous ballot, my         Delete subclause 14.8.2.4    AGREE (GEN: 2010-01-21     EDITOR
comment, #1000 regarding                                    00:30:00Z)
operating temperature, was
approved, but not all of the
changes were made.


In previous ballot, my         Delete FH8.20, FH8.20.1, and DISAGREE (GEN: 2010-01-20 EDITOR
comment, #1000 regarding       FH8.20.2 (while row for each) 07:46:55Z) PICS entries for
operating temperature, was                                   temperature were intentionally
approved, but not all of the                                 kept. See resolution to CID
changes were made.                                           #1000 in LB149.

In previous ballot, my         Delete DS12, DS12.1, DS12.2, AGREE IN PRINCIPLE (GEN: EDITOR
comment, #1000 regarding       and DS12.3 (while row for    2010-01-21 01:08:34Z) - Move
operating temperature, was     each)                        the PICS entries for DS12 (
approved, but not all of the                                temperature Items) from A.4.6
changes were made.                                          to A.4.3. Renaming the items
                                                            appropriately.




In previous ballot, my         Delete IR24 (while row)      AGREE (GEN: 2010-01-21     EDITOR
comment, #1000 regarding                                    01:12:00Z) -
operating temperature, was
approved, but not all of the
changes were made.
In previous ballot, my         Delete OF3.10, OF3.10.1,     DISAGREE (GEN: 2010-01-20 EDITOR
comment, #1000 regarding       OF3.10.2, and OF3.10.3       07:50:40Z) -- PICS entries for
operating temperature, was     (while row for each)         temperature were intentionally
approved, but not all of the                                kept. See resolution to CID
changes were made.                                          #1000 in LB149.

In previous ballot, my         Delete HRDS15, HRDS15.1,     DISAGREE (GEN: 2010-01-20 EDITOR
comment, #1000 regarding       and HRDS15.2(while row for   07:51:35Z) - PICS entries for
operating temperature, was     each)                        temperature were intentionally
approved, but not all of the                                kept. See resolution to CID
changes were made.                                          #1000 in LB149
In previous ballot, my         Delete                        AGREE IN PRINCIPLE         EDITOR
comment, #1000 regarding       dot11PHYdot11TempType and     (EDITOR: 2010-03-15
operating temperature, was     dot11TempType rows of Table   20:35:50Z)
approved, but not all of the   15-1                          Agree in principle, remove
changes were made.                                           "dot11Temp" from the
                                                             dot11PHYdot11TempType and
                                                             remove the following row.




In previous ballot, my         Delete dot11TempType row of AGREE (GEN: 2010-01-21      EDITOR
comment, #1000 regarding       Table 16-8                  00:32:19Z)
operating temperature, was
approved, but not all of the
changes were made.




In previous ballot, my         Delete dot11TempType row of AGREE (GEN: 2010-01-21      EDITOR
comment, #1000 regarding       Table 18-4                  00:33:26Z)
operating temperature, was
approved, but not all of the
changes were made.
In previous ballot, my         Delete "synonym              DISAGREE (GEN: 2010-01-20 EDITOR
comment, #1000 regarding       dot11TempType Integer = 01;" 07:56:29Z) Reject. Annex C is
operating temperature, was                                  not maintained
approved, but not all of the
changes were made.
In previous ballot, my         Delete dot11TempType line   AGREE IN PRINCIPLE             EDITOR
comment, #1000 regarding       from Dot11PhyOperationEntry (EDITOR: 2010-03-16
operating temperature, was                                 20:51:56Z) - Mark it
approved, but not all of the                               Deprecated (page 1420 line 3)
changes were made.                                         change status of
                                                           dot11TempType object to
                                                           "Deprecated" -Insert in the
                                                           beginning of the description:
                                                           "The use of dot11TempType is
                                                           deprecated, because
                                                           references to this variable
                                                           have been removed from the
                                                           normative text of IEEE Std
                                                           802.11-<year>, and this entity
                                                           may be removed in a later
                                                           revision of the standard."

In previous ballot, my         Delete all of dot11TempType   AGREE IN PRINCIPLE             EDITOR
comment, #1000 regarding       OBJECT-TYPE                   (EDITOR: 2010-03-16
operating temperature, was                                   20:51:56Z) - Mark it
approved, but not all of the                                 Deprecated (page 1420 line 3)
changes were made.                                           change status of
                                                             dot11TempType object to
                                                             "Deprecated" -Insert in the
                                                             beginning of the description:
                                                             "The use of dot11TempType is
                                                             deprecated, because
                                                             references to this variable
                                                             have been removed from the
                                                             normative text of IEEE Std
                                                             802.11-<year>, and this entity
                                                             may be removed in a later
                                                             revision of the standard."

In previous ballot, my         Delete dot11TempType from AGREE IN PRINCIPLE (GEN: EDITOR
comment, #1000 regarding       dot11PhyOperationComplianc 2010-01-20 08:27:05Z) --
operating temperature, was     eGroup OBJECT-GROUP        Accept in principle. Create a
approved, but not all of the                              new
changes were made.                                        dot11PhyOperationComplianc
                                                          eGroup with dot11TempType
                                                          not included and deprecate
                                                          existing
                                                          dot11PhyOperationComplianc
                                                          eGroup.
In previous ballot, my             Delete dot11TempType row           AGREE (GEN: 2010-01-21    EDITOR
comment, #1000 regarding           from Table 14-22                   00:28:28Z)
operating temperature, was
approved, but not all of the
changes were made.
CID 1001 in LB149 highlighted      Please decide if BSSID should      AGREE IN PRINCIPLE (MAC: EDITOR
a conflict between NAV reset       ever be checked for a NAV          2010-03-17 19:09:27Z).
in clauses 9.3.2.2, 9.3.3.1 and    reset from a CF-End. Once          Change 9.9.2.2a to read:
9.9.2.2a. The changes made         this decision has been made,       "When the AP contains a PC,
in draft 2 has changed the         make all three sited clauses       during the CFP, it may reset
clause that is the "odd one out"   follow the chosen behaviour.       the NAVs of all receiving STAs
but alas not removed                                                  by sending a CF-End frame,
conflicting normative                                                 regardless of how the NAVs
behaviour. Clause 9.3.3.1 says                                        have been originally set."
"All STAs of the BSS receiving                                        Additionally change 9.3.3.1 to
a CF-End or CF-End+ACK                                                read: "A STA receiving a CF-
shall reset their NAVs", clause                                       End or CF-End+ACK shall
9.3.2.2 says "The PC shall                                            reset its NAV."
transmit a CF-End or CF-
End+ACK frame at the end of
each CFP. A STA that
receives either of these
frames, from any BSS, shall
reset its NAV." and clause
9.9.2.2a says "When the AP
contains a PC, during the
CFP, it may reset the NAVs of
all STAs within the BSS (i.e.,
corresponding to the same
BSSID) by sending a CF-End
frame, regardless of how the
NAVs have been originally
set."

Does "The value of the             Change to "The value of the        AGREE IN PRINCIPLE (MAC: EDITOR
Minimum PHY Rate in a              Minimum PHY Rate in a              2010-01-20 02:15:00Z).
TSPEC shall be in both the         TSPEC shall be in both the         Revert changes made in
AP’s operational rate set and      AP’s operational rate set and      response to CID 1512 to
non-AP STA’s operational rate      non-AP STA’s operational rate      restore directionality of
set." need to mention the          set of the direction of the TS."   transmission rates.
direction, because operational
rates can be different in each
direction?
dot11ExtendedChannelSwitch         per comment                        AGREE IN PRINCIPLE         EDITOR
Enabled should be                                                     (SECURITY: 2010-01-12
dot11ExtendedChannelSwitch                                            21:31:08Z)
Activated                                                             Change
                                                                      dot11ExtendedChannelSwitch
                                                                      Enabled to
                                                                      dot11ExtendedChannelSwitch
                                                                      Activated.
Note 1 b) refers to "Supported per comment                            AGREE (EDITOR: 2010-01-20 EDITOR
RM Capabilities Enabled                                               14:51:58Z)
bitmask", but should refer to
"RM Enabled Capabilities
bitmask" (see 7.3.2.25).
dot11MultiDomainCapabilityIm       per comment   AGREE (GEN: 2010-01-20   EDITOR
plemented is a capability, and                   07:59:38Z)
should have MAX-ACCESS of
"read-only" instead of "read-
write"
dot11RegulatoryClassesImple        per comment   AGREE (GEN: 2010-01-20   EDITOR
mented is a capability, and                      08:02:49Z)
should have MAX-ACCESS of
"read-only" instead of "read-
write"
Description "BSS Availabele"       per comment   AGREE (EDITOR: 2010-01-20 EDITOR
should be "BSS Available"                        14:53:00Z)
dot11ExtendedChannelSwitch         per comment   AGREE IN PRINCIPLE (GEN: EDITOR
Activated. Description "It is                    2010-01-20 08:07:02Z);.
written by the SME when the                      Change to "It is written by the
device is initialized." is                       SME when the device is
incomplete, and should be "It                    initialized for operation in a
is written by the SME when the                   band defined by a Regulatory
device is initialized for                        Class."
operation in a band defined by
a Regulatory Class." Multi-RC
operation will commonly
change DFS/TPC and
Extended Channel Switch as
the STA changes channels
(5.725 GHz does not have
radar detection requirements,
but 5.6 GHz does).
dot11ERPBCCOptionActivated         per comment   AGREE (GEN: 2010-01-20   EDITOR
. Should have MAX-ACCESS                         08:21:01Z)
of "read-write", and description
should match
dot11DSSSOFDMOptionActiv
ated - "It is written by an
external management entity.
Changes take effect for the
next MLME-START.request or
MLMEJOIN.
request."
dot11RMRqstTimeStamp           per comment   AGREE IN PRINCIPLE                 EDITOR
should have MAX-ACCESS of                    (EDITOR: 2010-03-16
"read-create" like the rest of               20:59:50Z) - Make change as
RMRqst.                                      indicated.

                                             Also change "It is written by an
                                             external management entity
                                             when requesting a
                                             measurement(#1005)." to "It is
                                             written by the SME when
                                             dot11RMRequestRowStatus is
                                             set to Active."

                                             Also delete: "Changes take
                                             effect when
                                             dot11RMRqstRowStatus is set
                                             to
                                             Active(#1005)." and "This
                                             attribute is(#1452) set by this
                                             STA
                                             or AP automatically, not by an
                                             SNMP manager."
dot11FrequencyBandsImplem per comment        AGREE IN PRINCIPLE (GEN: EDITOR
ented. Description of                        2010-01-21 22:22:51Z) Add to
deprecated entry should begin                description "Superseded by
"Superseded by subband-                      subband-specific supported
specific supported regulatory                regulatory classes."
classes." and remove the text
that D2.0 inserted - "This is a
capability variable.
Its value is determined by
device capabilities."

dot11RegDomainsSupportedE per comment        AGREE IN PRINCIPLE (GEN: EDITOR
ntry should have status                      2010-01-21 22:17:25Z)
"deprecated" as it does not                  Change the status to
function with channel switching              Deprecated and Add the
and                                          following to the description:
SupportedRegulatoryClasses.                  "Superceded by
It is deprecated is because                  dot11RegulatoryClassesTable.
determining legal operation is               "
above the PLCP and PMD
(clause 9.8) - checking validity
of channel switch commands
is above the PHY.
The open authentication and     I'm hoping the editor will      AGREE IN PRINCIPLE            EDITOR
shared key authentication       provide guidance if I have to   (SECURITY: 2010-03-05
handshake description can be    make a submission about         16:28:29Z)
be streamlined like 11.11.2.2   anything in clause 8 ;-)        Incorporate the changes given
DSE Enablement has been                                         in document 11-10/206r0.
changed in D2.0 - remove
message type, subtype and
direction of message. Noone
should use 8.2.2.2 or 8.2.2.3
as a template for a handshake
specification, and I request
that someone submit the text
changes.

D1.0 CID 1053 resolution        per comment                     DISAGREE (MAC: 2010-01-19 EDITOR
incomplete. The other                                           06:10:14Z). It is already
deprecated modulations (FH                                      marked as such. No need to
PHY and ERP-PBCC PHY)                                           separately mark every
should have similar end of life                                 occurrence in the text of the
statements as what was added                                    feature.
to the DSSS-OFDM "The use
of the DSSS-OFDM option is
deprecated, and this option
may be removed in a later
revision of the standard."

D1.0 CID 1051 resolution         per comment                    AGREE IN PRINCIPLE (GEN: EDITOR
incomplete. MD7 (and other                                      2010-01-21 23:20:10Z) CID
deprecated modulations) did                                     1051 did indicate that the
not receive the agreed                                          statement was to be placed in
resolution text. Please indicate                                the "cited locations". Add the
in Multi-Domain PICS each                                       sentence "The use of hopping
deprecated PHY with text like                                   patterns is obsolete, and may
appears in A.4.14 ERP ERP2.                                     be removed in a later revision
                                                                of the standard."




D1.0 CID 1052 resolution         per comment                    DISAGREE (MAC: 2010-01-19 EDITOR
incomplete. Channel agility                                     06:11:16Z). It is already
description (and other                                          marked as such. No need to
deprecated capabilities)                                        separately mark every
should be followed by text like                                 occurrence in the text of the
that added after ERP-PBCC -                                     feature.
"The use of the ERP-PBCC
option is deprecated, and this
option may be removed in a
later revision of the standard."
dot11RegulatoryClassesRequi        End the description text with    AGREE (GEN: 2010-01-20        EDITOR
red changed description adds       "is true." and delete ";         08:03:54Z)
new requirement - "; otherwise     otherwise it will not use the
it will not use the defined        defined regulatory classes’
regulatory classes’                procedures."
procedures." - that is not
compatible with legacy
systems that use
SupportedRegulatoryClasses
when
dot11ExtendedChannelSwitch
Activated is true in the 2.4 GHz
and 5 GHz bands.
The PICS does not describe         per comment                      AGREE (GEN: 2010-01-21        EDITOR
operational combinations of                                         01:18:49Z)
mandatory and optional
elements, only what element
implementation is claimed.
Add a warning after the third
sentence - "This clause may
not be compatible with
operation in any Regulatory
Domain or describe
combinations of usable
features in any Regulatory
Domain."
PICS The reference in the first    Fix the reference.               AGREE IN PRINCIPLE               EDITOR
sentence is incorrect "claimed                                      (EDITOR: 2010-01-29
to conform to IEEE Std 802.11-                                      14:16:20Z) - Replace 2007 by
2007"                                                               "<year>" and move the
                                                                    following editorial note (occurs
                                                                    later in Annex A) to just after
                                                                    the A.1 heading: "<year> will
                                                                    be replaced with the year of
                                                                    publication during publication
                                                                    of this standard by the IEEE-
                                                                    SA editorial staff."

D1.0 CID 1055 resolution           Add a row to Table I-1 China :   AGREE (GEN: 2010-01-20        EDITOR
incomplete. The Regulatory         Ministry of Industry and         08:27:41Z)
information for China 2.4 GHz      Information Technology (MIIT)
and 5.8 GHz is missing.            : Xin Bu Wu [2002] #353, Xin
                                   Bu Wu [2002] #277 : MIIT
ETSI Fixed operation in 5.725-     Change the last row/last         AGREE (GEN: 2010-01-20        EDITOR
5.875 GHz allows 4W EIRP.          column of Table I.4 from         08:28:23Z)
                                   emdash to "4 W"
Table J.3 Japan. RC 1 - The        add channels 36-48 to RC 1       AGREE (GEN: 2010-01-20        EDITOR
old channels 34, 38, 42, 46 are    and add a footnote for           08:29:39Z)
only allowed until 2012, and       channels 34, 38, 42 and 46
the normal 36, 40, 44, 48 have     indicating they cannot be used
been allowed since 2005. The       after 2012.
old channels should have a
footnote indicating they cannot
be used after 2012 (MIC EO
49.20).

Table I.2 Japan regulator for      Change reference to MIC here AGREE (EDITOR: 2010-01-29 EDITOR
Emissions limits 4 is MIC, not     and in table I.3 P1627 line 30. 15:44:45Z)
MPHPT (prior name)
No reference in clause 2 or       Update and provide correct       AGREE IN PRINCIPLE              EDITOR
Annex 0A describes the            reference for definition of IEEE (EDITOR: 2010-01-28
current standard "address as      MAC address.                     12:08:15Z)
defined in 5.2 of IEEE Std 802-                                    Update reference to: "9.2 of
1990"                                                              IEEE Std 802-2001".
No reference in clause 2 or       Update and provide correct       AGREE IN PRINCIPLE              EDITOR
Annex 0A describes the            reference for definition of IEEE (EDITOR: 2010-01-27
current standard "address as      MAC address here and             15:26:06Z)
defined in 5.2 of IEEE Std 802-   7.1.3.3.2.                       Change reference to "9.2 of
1990"                                                              IEEE Std 802-2001".
dot11xxxIfIndex are Integer32     Change Annex D IfIndex           Agree in principle. Make the    EDITOR
almost everywhere, but should     SYNTAX to be one value           changes as shown in
not be negative. In SNMP          throughout.                      document 11-10/0216r2.
(RFC-2587) terms, ifIndex
could be "SYNTAX
InterfaceIndex", which could
be unsigned 32 but not
negative. "It is recommended
that values are assigned
contiguously " starting from 1.

It is time to get rid of Annex    Add an Editorial note that the   AGREE IN PRINCIPLE              EDITOR
styles for tables and figures,    Editor will change all Annex     (EDITOR: 2010-01-29
and make standards creation       table and figure numbering to    14:44:44Z)
easier for ourselves. The main    match the main text "clause-     Adjust Annex table and figure
body text names tables with       number" when the draft is        labelling to replace dot with
"clause-number" but Annex B       renumbered.                      hyphen.
uses "clause.number". The
IEEE 2009 Style Manual says
be consistent in clause 12.

Japan permits unlicensed          Insert final row in Table I.6 for AGREE (GEN: 2010-01-20         EDITOR
Fixed operation in 5.47-5.725     this band per comment             08:28:04Z)
GHz at power < 10 mW/MHz
EIRP.
Japan permits unlicensed          Insert Regulatory Class 33 : 5 : AGREE (GEN: 2010-01-20          EDITOR
Fixed operation in 5.47-5.725     20 : 100, 104, 108, 112, 116, 08:30:03Z)
GHz at power < 10 mW/MHz          120, 124, 128, 132, 136, 140 :
EIRP.                             (22 transmit power column
                                  gets deleted) : 1 : 1, 3, 4, 6, 10




RC 32 Channel starting            per comment                      AGREE (EDITOR: 2010-01-29 EDITOR
frequency is "5.0" and should                                      15:47:13Z)
be "5"
ETSI Fixed operation in 5.725- Insert Regulatory Class 5 : 5 : AGREE (GEN: 2010-01-20                  EDITOR
5.875 GHz allows 4W EIRP.      20 : 149, 153, 157, 161, 165, 08:29:18Z)
                               169 : (4 transmit power column
                               gets deleted) : 3, 4




D1.0 CID 1301 resolution           per comment                       AGREE (GEN: 2010-01-20            EDITOR
incomplete. The transmit                                             08:28:45Z)
power columns in Annex J.1
tables J.2 and J.3 should be
removed, as that information is
in tables I.4 and I.6 - D1.0
approved resolutions
09/1111r2 says "Propose
Accept in Principle CID 1301
and remove transmit power
from Annex J.1" - with editing
instruction "Delete seventh
paragraph text and Table
Columns labelled “Transmit
power limit” in Annex J.1 "
Annex A tables are not             Add an Editorial note that the    DISAGREE (EDITOR: 2010- EDITOR
labeled, unlike main body text.    Editor will change all Annex      01-29 14:20:38Z)
Tables should have labels.         table numbering to match the      While acknowledging that the
                                   main text "clause-number"         IEEE-SA style guide
                                   convention when the draft is      recommends all tables have
                                   renumbered.                       titles, this is unnecessary here
                                                                     because each table occupies
                                                                     its own subclause. Reference
                                                                     to each table as a whole can
                                                                     be made through its
                                                                     subclause.

                                                                     Each entry is identified in the
                                                                     first column, so that reference
                                                                     to any entry can be made
                                                                     unambiguously.

                                                                     The table titles would exactly
                                                                     mirror the subclause title -
                                                                     adding no value. Adding table
                                                                     titles would also necessitate a
                                                                     sentence to reference it, i.e.
                                                                     "The Implementation
                                                                     identification is shown in Table
                                                                     A-1", which adds text with no
                                                                     value.
Clause 10 tables are not           Add an Editorial note that the    UNRESOLVABLE (EDITOR: EDITOR
labeled, unlike the rest of main   Editor will label all clause 10   2010-01-28 11:58:31Z)
body text. Tables should have      tables to match the main text     Withdrawn by commenter
labels.                            convention when the draft is      2010-01-27 in email to editor.
                                   renumbered.
dot11MultiDomainCapabilityAc     Remove final sentence and       AGREE (GEN: 2010-01-20      EDITOR
tivated changed description      leave it unspecified what parts 08:00:43Z) Accept. Remove
adds new requirement - "The      of MultiDomainCapability (e.g. final sentence.
capability is disabled           Country information) are
otherwise." - that is not        available when not "activated".
compatible with legacy
systems that have
implemented
MultiDomainCapability. I think
there are some parts of
MultiDomainCapability that are
used (e.g. Country
information) even when
MultiDomainCapability is not
"Required", and want this new
requirement justified by
analysis of legacy STAs or
removed.
I object to the resolution of    Remove p1502 line 14 Editor's AGREE IN PRINCIPLE (GEN: EDITOR
D1.0 CID 1588. Some location     note about big-endian.        2010-01-20 08:25:40Z) -
variables are more than one                                    Accept in principle. The value
octet                                                          of the MIB variable is an
(e.g.dot11LCIDSELatitudeInte                                   integer. Endianness only
ger), and SNMP access has                                      matters when values are
endianness. Editor's note                                      stored as sequences of bytes.
about D1.0 CID 1588 "and is                                    Remove Editor's Note.
accessed big-endian" should                                     Additional changes given for
be removed, as the editor did                                  CID 2203.
the right thing in D2.0.
dot11LCIDSE Table is               Commenter will make a             UNRESOLVABLE (GEN: 2010- EDITOR
inadequate, containing an          submission with separate MIB      03-08 19:46:45Z) - GEN:
entry from the STA's               entries for the STA itself, and   2010-03-08 19:44:27Z - From
management entity and entries      dot11LCIDSE table for             the comment submitter:
from received beacons and          observed IEs from other STAs.     I submitted CID 2050 about
public action frames. There                                          the MIB dot11LCIDSETable:
needs to be another set of MIB
variables for the STA itself,                                        "dot11LCIDSE Table is
and this table remains for                                           inadequate, containing an
observed LCIDSE information                                          entry from the STA's
elements.                                                            management entity and entries
                                                                     from received beacons and
                                                                     public action frames. There
                                                                     needs to be another set of MIB
                                                                     variables for the STA itself,
                                                                     and this table remains for
                                                                     observed LCIDSE information
                                                                     elements."

                                                                       After more closely looking at
                                                                     the scenarios for enabling
                                                                     STAs and dependent STAs, I
                                                                     see that each STA picks one
                                                                     entry to be active for itself, and
                                                                     the others are for/from other
                                                                     STAs. A dependent STA does
                                                                     not know it’s location, but uses
                                                                     the location in the enablement
                                                                     message.

                                                                      I request that my CID 2050
                                                                   be withdrawn from the LB160
dot11EDThreshold should be         per comment                     list of active comments.
                                                                   AGREE (EDITOR: 2010-01-29 EDITOR
dot11OFDMEDThreshold.                                              14:08:43Z)
dot11OFDMEDThreshold "It is        Make this change wherever       AGREE IN PRINCIPLE (GEN: EDITOR
written by the SME when the        the MIB entry value is affected 2010-01-20 08:20:41Z) -
device is initialized" should be   by a channel switch action.     Accept in principle. Change to
"It is written by the SME when                                     "It is written by the SME when
the device is initialized for                                      the device is initialized for
operation in a particular band                                     operation in a band defined by
or regulatory class, and can be                                    a Regulatory Class, or written
written by an external                                             by an external management
management entity."                                                entity."
dot11OFDMCCAEDRequired. Make this change wherever                   AGREE IN PRINCIPLE (GEN: EDITOR
The MIB description "It is        the MIB entry value is affected   2010-01-20 08:18:35Z) -
written by the SME when the by a channel switch action.             Accept in principle. Change to
device is initialized." is                                          "It is written by the SME when
incorrect. Many multiband                                           the device is initialized for
STAs with multiple Regulatory                                       operation in a band defined by
Classes will use different radio                                    a Regulatory Class."
modes depending on
Regulatory Classes, and will
update the MIB when changing
channels, not "when the
device is initialized.". The text
should read "It is written by the
SME when the device is
initialized for operation in a
particular band or regulatory
class."

dot11RMRqstToken MAX-             Describe when it is created.      AGREE IN PRINCIPLE (GEN: EDITOR
ACCESS is read-create, how                                          2010-02-26) Global change all
does it get written?                                                "It is written by an external
                                                                    management entity when
                                                                    requesting a measurement."
                                                                    To "It is written by an external
                                                                    management entity when the
                                                                    table entry is created, i.e.,
                                                                    when requesting a
                                                                    measurement."


"It is written by an external                                       AGREE IN PRINCIPLE (GEN: EDITOR
management entity", and it is                                       2010-01-20 08:23:25Z) -
written by the SME too. The                                         Accept in principle. Change to
description is inaccurate. Fix                                      "It is written by an external
the description whenever the                                        management entity when
MIB item is alse written by the                                     requesting a measurement,
STA.                                                                and by the SME when
                                                                    accepting a measurement
                                                                    request."
dot11RMRqstRowStatus is a           Change to read "This is a         AGREE IN PRINCIPLE (GEN: EDITOR
status, not a control variable. I   status variable." If it remains   2010-01-20 08:23:05Z) Accept
don't know why it appears in        as a control variable, add        in principle. Change to "It is
the Rqst table, but it can only     descriptive text noting that it   written by an external
have the value "NotInService"       shall be written as               management entity when
at the time of a request.           "NotInService".                   requesting a measurement,
                                                                      and by the SME when
                                                                      accepting a measurement
                                                                      request."




"ReasResultCode" should be          per comment                       AGREE (EDITOR: 2010-01-20 EDITOR
"ReasonResultCode"                                                    14:52:20Z)
DS12 - PICS for DSSS                per comment                       AGREE IN PRINCIPLE (GEN: EDITOR
temperature should be                                                 2010-01-21 01:08:34Z) - Move
removed.                                                              the PICS entries for DS12 (
                                                                      temperature Items) from A.4.6
                                                                      to A.4.3. Renaming the items
                                                                      appropriately.

OF3.10 - PICS for OFDM              per comment                       DISAGREE (GEN: 2010-01-20 EDITOR
temperature should be                                                 07:50:08Z) PICS entries for
removed.                                                              temperature were intentionally
                                                                      kept. See resolution to CID
                                                                      #1000 in LB149.

HRDS15 - PICS for HRDS              per comment                       DISAGREE (GEN: 2010-01-20 EDITOR
temperature should be                                                 07:51:11Z) PICS entries for
removed.                                                              temperature were intentionally
                                                                      kept. See resolution to CID
                                                                      #1000 in LB149.
dot11TempType should be           per comment          AGREE IN PRINCIPLE             EDITOR
deprecated and text referring                          (EDITOR: 2010-03-16
to setting it should be                                20:51:56Z) - Mark it
preceeded by text like "The                            Deprecated (page 1420 line 3)
use of dot11TempType is                                change status of
deprecated, and this entity                            dot11TempType object to
may be removed in a later                              "Deprecated" -Insert in the
revision of the standard." . It's                      beginning of the description:
value is specified in each PHY                         "The use of dot11TempType is
clause, and it is part of                              deprecated, because
dot11PhyOperation, which is                            references to this variable
part of                                                have been removed from the
dot11PhyOperationComplianc                             normative text of IEEE Std
eGroup.                                                802.11-<year>, and this entity
                                                       may be removed in a later
                                                       revision of the standard."

IR24 - PICS for IR temperature per comment             AGREE (GEN: 2010-01-21       EDITOR
should be removed.                                     01:13:35Z)

SM18 CF2.1 should be CF2.2 per comment                 AGREE (GEN: 2010-01-20       EDITOR
since DFS owner only exists in                         07:54:17Z)
IBSS (see 11.9.7.2).




SM10 CF2.1 should be CF2, per comment                  AGREE (GEN: 2010-01-20       EDITOR
since reporting maximum                                07:53:20Z) -- Change to
transmit power levels also is                          "CF2.1 or CF2.2"
required in IBSS operation. I
think there are several other
CF2 modifications made in
D2.0 that are not correct (e.g.,
SM20), and trust the comment
resolution committee will
rigorously correct those errors,
or make the PICS informative.
RIP
SM19 CF2.1 should be CF2.2 per comment                 AGREE (GEN: 2010-01-20       EDITOR
since DFS owner only exists in                         07:54:55Z)
IBSS.
In D2.0, CF2 is changed to       per comment           DISAGREE (GEN: 2010-01-20 EDITOR
add CF2.1 and CF2.2 without                            07:44:51Z) -- Changes are
showing changebars in the                              shown in the way that
redlined D2.0. For D3.0                                FrameMaker shows changed
redlined, show the changebars                          tables.
everywhere CF2.1 and CF2.2
exist, as the changes should
be flagged to reviewers, or
change Annex A to
informative.

There are two figures labeled   Fix figure numbering   AGREE (EDITOR: 2010-01-20 EDITOR
Figure 7-95o7 (TIE format is                           14:25:45Z)
the other one).
The size of the Local Power       Change Figure 7-101h8 to        AGREE (MAC: 2010-01-19           EDITOR
Constraint field should be 1      show the field size to be one   06:12:31Z).
octet.                            octet.




"It is written by an external     Change to "It is also written by AGREE IN PRINCIPLE (GEN: EDITOR
management entity", and it is     external management entities." 2010-01-20 07:59:04Z) Accept
written by the SME too. The                                        in principle. Change to "It is
description is inaccurate both                                     written by the SME or external
in number of writers and                                           management entity"
identity of the writers - e.g.,
CAPWAP has several
management entities.
I disagree with the change of     Restore D1.0 frame types for    AGREE IN PRINCIPLE (MAC: EDITOR
frame types from                  power save action.              2010-01-19 23:35:27Z).Insert
"management frames of the                                         the following paragraph within
following subtypes: Action,                                       clause 11.2.1.0a:
Disassocation,                                                    "A bufferable management
Deauthentication, or Probe                                        frame is a unicast
Response (when sent in                                            management frame,
response to a unicast Probe                                       addressed to an associated
Request)" to "an Action                                           STA, of the following subtypes:
frame", and want this                                             Action, Disassociation,
unchanged in REVmb.                                               Deauthentication, or Probe
                                                                  Response (when sent in
                                                                  response to a unicast probe
                                                                  request); or a group-
                                                                  addressed management frame
                                                                  of the following subtypes:
                                                                  Action, Disassociation, or
                                                                  Deauthentication. A bufferable
                                                                  MMPDU is an MMPDU that will
                                                                  be transmitted using a
                                                                  bufferable management
                                                                  frame."

                                                                  Wherever "Action frame" is
                                                                  used in clause 11.2.1, replace
                                                                  with "bufferable management
                                                                  frame". Wherever "MMPDU"
                                                                  is used in clause 11.2.1,
                                                                  replace with "bufferable
                                                                  MMPDU." Make changes for
                                                                  consistency or to remove and
                                                                  do away with redundancy
                                                                  following these changes.
dot11SpectrumManagementR Change the description to               AGREE IN PRINCIPLE (GEN: EDITOR
equired can be set or cleared include extended channel           2010-01-20 08:02:24Z) -
by the SME when changing          switch.                        Accept in principle. There is no
channels, and is a                                               such thing as a control/status
control/status variable. If set                                  variable. Change to "It is
by an external management                                        written by the SME or external
entity, then "It is written by an                                management entity"
external management entity.
Changes take effect for the
next MLME-START.request.",
otherwise the SME may
change it when changing
regulatory classes.

dot11MultiDomainCapabilityAc Change the description to           AGREE IN PRINCIPLE (GEN: EDITOR
tivated can be set or cleared     include extended channel       2010-01-20 08:00:15Z) Accept
by the SME when changing          switch.                        in principle. There is no such
channels, and is a                                               thing as a control/status
control/status variable. If set                                  variable. Change to "It is
by an external management                                        written by the SME or external
entity, then "It is written by an                                management entity"
external management entity.
Changes take effect for the
next MLME-START.request.",
otherwise the SME may
change it when changing
regulatory classes.

dot11CountryString can be           Change the description to be a AGREE (GEN: 2010-01-20       EDITOR
changed by the SME when             status variable written by the 08:01:37Z) Accept. Change to
changing channels, and is           SME.                           "It is written by the SME"
read-only. It is NOT a control
variable, not written by an
external management entity.
dot11RegulatoryClassesRequi         Change the description to    AGREE IN PRINCIPLE (GEN: EDITOR
red can be set or cleared by        include extended channel     2010-01-20 08:03:16Z) Accept
the SME when changing               switch.                      in principle. There is no such
channels, and is a                                               thing as a control/status
control/status variable. If set                                  variable. Change to "It is
by an external management                                        written by the SME or external
entity, then "It is written by an                                management entity"
external management entity.
Changes take effect for the
next MLME-START.request.",
otherwise the SME may
change it when changing
regulatory classes.
dot11LCIDSERequired can be Change the description to         AGREE (GEN: 2010-01-20           EDITOR
changed by the SME when        include extended channel      08:04:15Z) - Accept. Change
changing channels, and is      switch.                       to "It is written by the SME".
read-only. It is NOT a control                               Change to read-only.
variable, not written by an
external management entity.




dot11DSERequired can be          Change the description to   AGREE (GEN: 2010-01-20           EDITOR
changed by the SME when          include extended channel    08:04:39Z) - Accept. Change
changing channels, and is        switch.                     to "It is written by the SME".
read-only. It is NOT a control                               Change to read-only.
variable, not written by an
external management entity.




dot11ExtendedChannelSwitch Change the description to         AGREE IN PRINCIPLE (GEN: EDITOR
Activated can be changed by include Regulatory Classes       2010-01-20 08:07:47Z)
the SME when initializing for a Required.                    Accept. Change to "It is written
band defined by a Regulatory                                 by the SME when the device is
Class, and is read-only. This                                initialized for operation in a
replaces my earlier comment.                                 band defined by a Regulatory
                                                             Class."
dot11LCIDSETable is read-           Change the description to be a DISAGREE (GEN: 2010-01-20 EDITOR
only, with SME values for           status variable written by the 08:11:13Z) -- Variables written
operation in a Regulatory           SME.                           by the SME and used by the
Class that requires DSE.                                           MAC are control variables, not
                                                                   status variables. If it was
                                                                   written by the SME and only
                                                                   used by external entities, then
                                                                   it would be considered status.

"The issue might be named           Extend Annex M to document          OUT OF SCOPE (MAC: 2010- EDITOR
""gratuitous double-                and specific the details of how     03-12 17:28:55Z). This
encapsulation"". It involves        to do this in an interoperable      comment is not directed to
deliberately (and incorrectly)      fashion, since the behavior is      changed text between REVmb
placing an additional RFC1042       out there in the field. Note that   Draft 1.0 and Draft 2.0 and is
SNAP header around the              whether we want to                  out of scope for recirculation
contents of a frame that            discourage it or not is open to     LB 160.
already has such a header (in       debate.
particular, an AppleTalk Phase
II frame) to encode the length
field. The decoding rules for
the default case of 802.1H
then cause a correct
implementation to strip the
outer SNAP header and turn it
into an 802.3 length field,
leaving the interior SNAP
header alone (since the length
field in the outer SNAP header
is neither the AppleTalk nor
IPX special-case
encoding/decoding rules
value).
    There are implementations
out there that do this on
purpose, since then an
incorrect (always remove
SNAP header) and a correct
(do not remove SNAP header
if it's one of the special values
or is the BTEP header)
implementation both produce
the same 802.3 frame on (B35)
The Titlebaum reference the         Restore the Titlebaum               AGREE (GEN: 2010-01-20         EDITOR
is required as a source of the      reference (B35) and add a           06:32:54Z) - Restore the
material in clause clause 9.8.2.    corresponding link or               referene (B35) and in 9.8.2
It was present in D1.0 but has      reference to clause 9.8.2 to        (page 406 line 22) Change text
been removed from D2.0              anchor the reference.               from "please see the reference
                                                                        [B4]" to "please see the
                                                                        references [B4] and [B35]."

Also need to cite Titlebaum         Change text from "please see AGREE (GEN: 2010-01-20              EDITOR
reference (B35).                    the reference [B4]" to "please 06:30:35Z)
                                    see the references [B4] and
                                    [B35]."
In this Note, sentence             Please remove the Note.           DISAGREE (GEN: 2010-01-20 EDITOR
"Support for CCA-ED is an          Three paragraphs above this       07:39:29Z) Reject. The text is
additional requirement that        note are already clear enough     clear, note is helpful in
relates specifically to the        about this. The Note serves       understanding the rational
sensitivities described in I.2.4   only as a confusion.              behind the text
(CCA-ED threshold)" may lead
a reader to conclude that CCA-
ED requirement at -72 dBm is
for all clause 17 devices.


Fix page numbering.                As in comment.                    DISAGREE (EDITOR: 2010- EDITOR
                                                                     01-20 14:55:33Z)
                                                                     The draft sent to ballot had
                                                                     correct page numbering.
                                                                     (Note to commenter:
                                                                     Comments should not be
                                                                     based on the redline draft.)
Is it too early to specify in      Make it a more a specific         DISAGREE (EDITOR: 2010- EDITOR
definitions bit settings?          definition without explicit bit   01-27 14:50:40Z)
                                   settings.                         By definition, A group address
                                                                     is one in which the group bit is
                                                                     set to 1, because this is the
                                                                     only property of a group
                                                                     address that distinguishes it
                                                                     from an individual address.

                                                                     As this is fundamental to the
                                                                     specification of a group
                                                                     address, there is no problem
                                                                     including it in the definition
                                                                     clause.

"invoke" instead of 'invokes"      As in comment.                    AGREE (EDITOR: 2010-01-20 EDITOR
                                                                     14:23:52Z)
Can "in the clear" be better       As in comment.                    AGREE IN PRINCIPLE               EDITOR
explained?                                                           (EDITOR: 2010-01-27
                                                                     15:00:54Z)
                                                                     Add ", i.e., without protection"
                                                                     to the end of the cited
                                                                     sentence.
After "..transmitter power         As in comment.                    DISAGREE (EDITOR: 2010- EDITOR
control" include "(TPC)"                                             01-27 15:04:53Z)
                                                                     The acronym is quoted as
                                                                     "transmit power control (TPC)"
                                                                     in the immediately previous
                                                                     subclause, and there is no
                                                                     need to repeat this.

"The OFDM PHY shall use         Please delete this sentence.         DISAGREE (GEN: 2010-01-20 EDITOR
dot11CurrentFrequency to                                             07:36:56Z) Reject.
determine the operating                                              dot11CurrentFrequency is a
frequency." This sentence with                                       control variable, written by the
"shall" statement is not                                             SME. This sentence forces the
necessary here. This relates to                                      PHY to use it.
configuration attributes of the
device.
Does there need to be a        Clarify whether FCS result               DISAGREE (MAC: 2010-01-20 EDITOR
mention here of the success of needs to be mentioned here.              01:58:36Z). Frames are only
the FCS result?                                                         received after passing the FCS
                                                                        check, according to the
                                                                        conventions in 7.1.1 (7th
                                                                        paragraph). Frames which do
                                                                        not pass the FCS check are
                                                                        not processed further.
What is the difference, in the      Clarify whether the correct         DISAGREE (GEN: 2010-01-20 EDITOR
context of 802.11, of being         adjective has been used.            06:28:04Z) Correct adjective
obsolete vs deprecated?                                                 has been used in this case.
                                                                        Deprecated functions fail to
                                                                        perform the function described
                                                                        (e.g., WEP); obsolete
                                                                        functions works as described,
                                                                        but are not used in any known
                                                                        products. If a function marked
                                                                        as "obsolete" is actually used
                                                                        in an 802.11 implementation, it
                                                                        should be brought to the Task
                                                                        Group's attention and the
                                                                        marking of "obsolete" will be
                                                                        removed

You say "power management           Make the change indicated.          AGREE IN PRINCIPLE (MAC: EDITOR
state" in this sentence, but I                                          2010-01-20 02:24:02Z) -
believe that you mean to say                                            Change P622L63 from: "A non-
"power management mode"                                                 AP STA shall not change
                                                                        power management state..." to
                                                                        read "A non-AP STA shall not
                                                                        change power management
                                                                        mode..."

MA-UNITDATA-                        Change "that was used" to           AGREE IN PRINCIPLE (MAC: EDITOR
STATUS.indication is almost         "that is anticipated to be used"    2010-03-15 18:10:24Z).
cleaned up from looking like it     in the penultimate paragraph        Change 6.2.3.2 as shown in
was a guaranteed delivery           of 6.2.3.2, and "used" to "that     11-10/0308r0. This removes
service. But, there are minor       will be used" in the ultimate       any implication about the
hints of this left, like the last   paragraph of 6.2.3.2. Also,         relative timing of this primitive
two paragraphs of 6.2.3.2           start both of these paragraphs      and the related act of
which use past tense to             with, "If the transmission status   transmission.
describe the data unit transfer.    is Successful," to clarify that
MA-UNITDATA-                        these parameters may not
STATUS.indication is a local        make sense in the
indication that the MAC has         unsuccessful cases.
accepted the request, or not
(and why not), and is not
synchronized to the actual
frame/unit data delivery. The
past tense implies a
synchronization that has been
a confusion for many readers.

What "integer" is this              Change "an integer" to "a           AGREE (MAC: 2010-01-19    EDITOR
referencing?                        requested priority"                 06:16:48Z)
This paragraph still has          Change the paragraph to, "The AGREE (GEN: 2010-01-20      EDITOR
problems, as noted by the         various entities within this       06:36:16Z)
Editor.                           model interact in various ways.
                                  Certain of these interactions
                                  are defined explicitly within this
                                  standard, via a SAP across
                                  which defined primitives are
                                  exchanged. This definition
                                  includes the GET and SET
                                  operations between MLME,
                                  PLME and SME as well as
                                  other individually defined
                                  service primitives, represented
                                  as double arrows within Figure
                                  10-1. Other interactions are
                                  not defined explicitly within this
                                  standard, such as the
                                  interfaces between the MAC
                                  and MLME and between the
                                  PLME and PLCP and PMD;the
                                  specific manner in which these
                                  MAC and PHY LMEs are
                                  integrated into the overall MAC
                                  sublayer and PHY is not
                                  specified within this standard."



The STA does not "use" a          Change, "… uses a lower          AGREE (MAC: 2010-01-19   EDITOR
lower priority AC when it         priority AC for this purpose,    06:17:47Z)
downgrades traffic, rather is     the lower priority AC affects
uses the usual AC, but uses       only …" to "… uses the EDCA
the EDCA parameters of a          parameters of a lower AC for
lower AC, for that                this purpose, it affects only …"
transmission.
The MLME-EAPOL.confirm            Delete clause 10.3.20.2, and   AGREE IN PRINCIPLE (GEN: EDITOR
primitive does not seem           reference to the MLME-         2010-01-20 06:43:04Z) -
useful. Since there is no         EAPOL.confirm on page 272,     Accept in principle. Michael
guarantee that the EAPOL-Key      line 48.                       MIC failure notifications are
frame was completely                                             transmitted in EAPOL-Key
delivered to the remote peer,                                    frames. Timing of
this primitive cannot serve any                                  countermeasures is relative to
real security purpose. I don't                                   the transmission of the EAPOL-
think any such guarantee is                                      Key frame, and therefore, this
ever needed, though, as all                                      primitive is required. Change
critical such transmissions are                                  third line of five line
included within a handshake                                      rectangular box in Figure 8-12
procedure.                                                       from "Wait for send report
                                                                 frame to complete" to "Wait for
                                                                 MLME-EAPOL.confirm". Also
                                                                 change "MLME-
                                                                 MICHEALMICFAILURE.indicat
                                                                 ion" on page 272 line 44 to
                                                                 "MLME-
                                                                 MICHAELMICFAILURE.indicat
                                                                 ion"

Extra blank line in error.        Edit out blank line between    AGREE (EDITOR: 2010-01-27 EDITOR
                                  "set to" and "Pairwise".       16:08:48Z)
There are possibly more than     Change bullet item to:             DISAGREE (SECURITY: 2010- EDITOR
1 PMKID, one for every           "PMKIDs, as defined in 8.5.1.2     03-18 20:41:13Z) - The group
available BSSID on the           (Pairwise key hierarchy). Each     could not reach consensus on
authenticator.                   PMKID identifies the security      any changes that would
                                 association via a BSSID to the     address this comment.
                                 authenticator."




authentication is between a       remove the authenticator MAC      DISAGREE (SECURITY: 2010- EDITOR
(supplicant) STA and the AS       address from the PMKSA.           03-18 20:41:28Z) - The group
associated with the other                                           could not reach consensus on
STA's authenticator, even                                           any changes that would
when an external AS (e.g. a                                         address this comment.
RADIUS server) is not used.
The AS is an entity outside of
802.11 and has no knowledge
of a MAC address. A key
derived by an AS and shared
by an AS and a STA cannot,
therefore, be bound to an
identity that was not part of the
authentication and key
establishment process. There
is NO cryptographic binding
between the PMK and any
address the authenticator may
have.

the STA has to calculate the     Make the first sentence: "If a     DISAGREE (SECURITY: 2010- EDITOR
PMKID based on the BSSID of      STA in an ESS has                  03-18 20:41:37Z) - The group
the AP to which it is about to   determined it has a valid          could not reach consensus on
(re)associate.                   PMKSA with an AP to which it       any changes that would
                                 is about to (re)associate-- for    address this comment.
                                 example, through the Key
                                 Scope bit of a Neighbor Report
                                 (section 7.3.2.37)-- it
                                 calculates a PMKID using the
                                 BSSID of the AP to which it is
                                 about to (re)associate as the
                                 AA according to 8.5.1.2, it then
                                 includes the PMKID for the
                                 PMKSA in the RSN element in
                                 the (Re)Association Request."
there can be more than one    Make the period a comma and    DISAGREE (SECURITY: 2010- EDITOR
AA.                           add: "and AA is a BSSID        03-18 20:41:46Z) - The group
                              through which communication    could not reach consensus on
                              with the authenticator is      any changes that would
                              accomplished. Note: more       address this comment.
                              than one PMKID can identify
                              the same PMKSA."

The term WDS is absolutely     Delete the term WDS and all   DISAGREE (GEN: 2010-01-21 EDITOR
useless. The definition of the of its occurences.            00:50:58Z) On first
term WDS explains that is                                    investigation of this comment,
doesn't explain anything:                                    we found that figure 8-38 uses
"3.196 wireless distribution                                 "WDS" in a normative manner.
system (WDS): A mechanism                                    The removal of WDS would
for wireless communication                                   not work in this instance. A
using a four address frame                                   submission descriping the
format specified in this                                     specific changes would be
standard. This standard                                      required to make the
describes such a frame                                       suggested change.
format, but does not describe
how such a mechanism or
frame format would be used."
So why give it a name then?
The following definition
provides the same amount of
information and is as useless
as the WDS definition for
802.11 implementors: "Coffee:
A brewed drink heavily relied
on by standards developer.
802.11 members drink this
beverage but this standard
does not describe how to brew
it."

All other occurences of WDS
are either in the list of
abbreviations, Figure 8-38, or
in Annex C, which is marked
as obsolete.
The following sentence in this Remove the sentence.          DISAGREE (GEN: 2010-01-20 EDITOR
note adds confusion, leading a                               07:38:32Z) Reject. The text is
reader to possibly believe that                              clear, note is helpful in
CCA-ED level is at -72 dBm                                   understanding the rational
for all clause 17 devices. The                               behind the text
sentence is: "Support for CCA-
ED is an additional
requirement that relates
specifically to the sensitivities
described in I.2.4 (CCA-ED
threshold)."
The following sentence          Delete entire sentence.             DISAGREE (GEN: 2010-01-20 EDITOR
contains a SHALL requirement                                        07:37:35Z) Reject.
which is not needed, as this                                        dot11CurrentFrequency is a
relates to device configuration                                     control variable, written by the
attributes. The sentence is:                                        SME. This sentence forces the
"The OFDM PHY shall use                                             PHY to use it.
dot11CurrentFrequency to
determine the operating
frequency."

The change from CCMP to             Revert the changes from         AGREE IN PRINCIPLE          EDITOR
“enhanced data cryptographic        “CCMP” to “enhanced data        (SECURITY: 2010-03-12
encapsulation mechanisms”           cryptographic encapsulation     16:19:56Z)
(which includes TKIP) here          mechanisms” in 6.1.2, i.e.,     Accept the comment and
does not look reasonable            only describe the security      make the proposed changes
taken into account the flaws        services to be provided by      to clause 6.1.2.
identified in TKIP and the          CCMP. In addition, reconsider
statement in this same              introduction of the “enhanced
subclause indicating that           data cryptographic
“TKIP algorithm is unsuitable       encapsulation mechanism”
for the purposes of this            throughout the draft.
standard”. I do not think it is a
good idea to claim that TKIP
would provide data
confidentiality or authentication
and would prefer these
services to be described only
for the ciphers that are
currently believed to be
secure. In addition, including
TKIP as an “enhanced data
cryptographic encapsulation
mechanism” is questionable
with the current knowledge of
weaknesses in its
construction.


“WEP” is not a valid cipher         Replace “TKIP or WEP with     AGREE (SECURITY: 2010-03- EDITOR
suite (“WEP-40” and “WEP-           TKIP” with “TKIP, WEP-104, or 17 19:26:12Z)
104” would be).                     WEP-40 with TKIP”. Similarly,
                                    replace “TKIP or WEP” with
                                    “TKIP, WEP-104, or WEP-40”
                                    on line 61.
As an answer to the editor's     Replace “Key” with “Wrapped        AGREE IN PRINCIPLE (MAC: EDITOR
note on line 30: “yes”. To be    Key” in the rightmost field in     2010-01-19 06:19:11Z).
consistent with Figure 7-95o7,   Figure 7-95o6a (i.e., do not       Replace "Key" with "Wrapped
the “Key” field in Figure 7-     change “Key Length”. On line       Key" in the rightmost field in
95o6a should indeed be           59, replace “The Key field is      Figure 7-95o6a (i.e., do not
renamed to “Wrapped Key”.        the IGTK being distributed”        change "Key Length". On line
                                 with “The Wrapper Key field        59, replace "The Key field is
                                 contains the wrapped IGTK          the IGTK being distributed"
                                 being distributed”. On lines 59-   with "The Wrapped Key field
                                 60, replace “Key field” with       contains the wrapped IGTK
                                 “Wrapper Key field”.               being distributed". On lines 59-
                                                                    60, replace "Key field" with
                                                                    "Wrapped Key field".

                                                                    [Note to editor: this is the
                                                                    same as the commenter's
                                                                    proposed resolution, but
                                                                    changes "wrapper key" to
                                                                    "wrapped key."

Table 8-2 style change seems Add a new row to the end of            AGREE (SECURITY: 2010-01- EDITOR
to have overriden the change Table 8-2 with the following           19 01:22:30Z)
from IEEE Std 802.11w-2009 contents: BIP | 16 | 128.
that described the key length
used with BIP.

The leftover “SetProtection”     Remove “SetProtection” text AGREE (EDITOR: 2010-01-27 EDITOR
text outside the PTKINITDONE outside the PTKINITDONE box 16:07:22Z)
box should not be there. The in Figure 8-37.
spelling of this primitive was
fixed in IEEE Std 802.11w-
2009, but it looks like the old,
incorrect spelling somehow
ended up remaining on the
side..
Why would unsuccessful             Remove the transition from       AGREE IN PRINCIPLE (GEN: EDITOR
association move the state         State 4 to State 2 with          2010-03-17 21:51:11Z) Apply
from State 4 to State 2? This      condition “Unsuccessful          the changes in doc 11-
seems to break any possible        Association”. On page 638 line   10/390r0.
protection we introduce            19 in 11.3.2.0a, replace
against DoS attacks (e.g., the     “Unsuccessful association
protections added in FT) since     when not in State 1 sets the
the association would be           STA's state to State 2” with
dropped in case of such an         “Unsuccessful association
attack (e.g., fake association     does not change STA's state”.
request sent to the AP).           On page 638 line 22, replace
Furthermore, this type of state    “Unsuccessful reassociation
change is not defined for State    when not in State 1 sets the
3. Is there a difference on        STA's state to State 2” with
failed (re)association behavior    “Unsuccessful reassociation
between the States 3 and 4?        does not change STA's state”.




The text describing                Replace “Unsuccessful            AGREE IN PRINCIPLE (GEN: EDITOR
unsuccessful authentication is     authentication sets the STA's    2010-03-12 13:27:33Z)Accept
in conflict with the transitions   state to State 1” with           in principle. Replace the
shown in Figure 11-6. The text     “Unsuccessful authentication     second paragraph in 11.3.1.0a
claims a failure to result in      does not change STA's state”.    with "Successful authentication
transition to State 1 while the                                     sets the STA's state to State 2.
figure claims there is no                                           Unsuccessful authentication
transition in such a case. I                                        leaves the STA's state
believe the behavior in the                                         unchanged. The STA shall not
figure is correct since it is                                       transmit Class 3 frames unless
needed to maintain DoS                                              in State 3 or State 4.
protection provided for FT.                                         Authentication notification
                                                                    when in State 3 or 4 implies
                                                                    disassociation as well."
The introduction of the new      Replace “State 3 if RSNA           AGREE (GEN: 2010-03-16   EDITOR
State 4 did not seem to take     establishment is required” with    21:40:17Z)
into account FT protocol for     “State 3 if RSNA
reassociation cases. When FT     establishment is required and
is used, 4-way handshake         FT Protocol is not used”.
does not follow the              Similarly, on page 641 line 49
reassociation. Instead, the      in 11.3.2.4, replace “State 3 if
STA should end up in State 4     RSNA establishment is
at the successful completion of  required on the new AP” with
reassociation.                   “State 3 if RSNA
                                 establishment is required on
                                 the new AP and FT Protocol is
                                 not used”.
Regulatory class definition and Extend the regulatory class         AGREE IN PRINCIPLE (MAC: EDITOR
use in IEEE 802.11 is limited definitions or provide an             2010-03-05 16:53:53Z).
to not cover all countries       alternative mechanism to allow     Accept the changes in
where IEEE 802.11 can be         regulatory specific rules and      document 11-10/0210r6.
used due to Annex J only         channel specification to be
defining regulatory classes for used in all countries where
US, EU, and JP.                  IEEE 802.11 can be used.
                                 This comment is not explicitly
This comment relates to CID requesting Annex J to be
781 in LB 147 (802.11s/D3.0) extended to cover all
that was rejected with the       regulatory rules, i.e., some
claim that it would be out of    generic mechanism for
scope for TGs to resolve and describing channels
TGmb was suggested as the (regulatory class,channel
place for resolving the issue. number pairs) outside the
While I may not fully agree      US/EU/JP areas (that are
with the part of making          defined in Annex J) could also
P802.11s work in all countries resolve the comment.
being out of scope for TGs, I
do agree that this is a more
generic issue and review in
TGmb would be useful. I also
realize that this WG
recirculation LB may not be
procedurally the best time to
submit this comment and will
understand if this gets ruled
out of order (and will resubmit
the same comment in the
initial sponsor ballot). Anyway,
I consider this to be an
important issue that needs a
resolution as soon as possible.
The resolution adopted to CID      Move the definition of            AGREE IN PRINCIPLE             EDITOR
1597, merging Annex Q into         dot11Groups 27 through 29 to      (EDITOR: 2010-01-29
Annex D, didn't addres the         follow dot11Groups 26             15:39:20Z)
issue raised by the comment -      (moving page 1555 line 13         As specified, except move all
namely that the dot11Groups        through page 1556 line 35 to      dot11Compliances to come
are not contiguous in the MIB      page 1527 line 30). Move the      after all dot11Groups.
definition. The same problem       definition of dot11groups 52 to   This results in dot11Groups 52
also exists for the dot11smt       the end of Annex D (moving        coming before the first
definitions.                       page 1527 line 29 through         compliance statement, not
                                   page 1527 line 44 to page         at the end of the MIB as
                                   1556 line 35). Also the same      indicated in the resolution.
                                   treatment for dot11smt. Move
                                   the definitions of dot11smt 9
                                   through dot11smt 12 to follow
                                   dot11smt 8 (moving page
                                   1538 line 58 through page
                                   1554 line 55 to page 1384 line
                                   10), and move the definition of
                                   dot11smt14 to follow dot11smt
                                   13 (moving page 1445 line 41
                                   through page 1520 line 10 to
                                   page 1385 line 21).


The resolution approved for        Follow the guidance given by AGREE (GEN: 2010-03-15           EDITOR
CID 1005 is incomplete, as it      ARC (as documented in         23:23:26Z) see specific details
also needs to be applied when      09/533r1) to add MIB text     of changes in 11-10/300r1
TGn is incorporated into           regarding the variables added
REVmb                              by TGn




Regarding rejected CID 1241:       Delete Annex C                    UNRESOLVABLE (GEN: 2010- EDITOR
The proponents of Annex C,                                           01-20 07:55:40Z) Comment
claiming there is behavior                                           withdrawn by commenter in
defined in Annex C that does                                         January 2010 session
not appear elsewhere in the                                          Tuesday PM2.
standard, have had nearly a
full year to identify such gaps.
Time is up.
The resolution to CID 1517 is      Change first sentence to "DLS AGREE (EDITOR: 2010-01-20 EDITOR
certainly correct, that "In an     is a protocol that enables a   13:11:33Z)
infrastructure network, non-AP     STA in an infrastructure
STAs are not allowed to            network to transmit frames
transmit frames directly to        directly to another STA in the
other non-AP STAs, except          same infrastructure network."
when using DLS." However,          Delete the Editor's Note, as
the sentence it replaced           this sentence does not need
provided the antecedent for        modification when TGz is
"this protocol" in the following   incorporated.
sentence. The resulting text is
unclear.
CID 1558 only changes some      remove remaining              AGREE (GEN: 2010-01-20             EDITOR
of the occurrances of "and is   occurrances of "and is        07:56:49Z)
accessed big-endian"            accessed big-endian" in Annex
                                D (ten places)




Several hanging paragraphs      Fixing hanging paragraph in          AGREE IN PRINCIPLE            EDITOR
have appeared since this        5.2, 5.2.7, 5.2.8, 5.3, 5.4,         (EDITOR: 2010-01-26
problem was addressed prior     5.4.2, 5.4.3, 5.4.4, 5.8, 5.8.2,     15:18:55Z)
to D1.0                         5.8.3, 6.1.1, 6.2, 7.1.3.1,          As indicated by the
                                7.1.3.3, 7.1.3.4, 7.1.3.5,           commenter, plus the following
                                7.3.2.21, 7.3.2.22, 7.3.2.25,        in D 2.01:
                                7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.4.6,   20.1.3
                                7.4.9, 8.3.4, 8.4.1.1, 11.1.1,       20.3.9.5
                                11.9a.3, 11.10, 11.10.9,             20.3.11
                                11.10.12, 11A.9.2, 11A.9.3,          20.3.11.8
                                11A.9.4, 11A.9.5, 17.1.2, and        20.3.11.10
                                everywhere else they appear          20.3.12
                                as part of incorporating TGn.        20.3.12.2
                                                                     20.3.13
                                                                     20.3.15
                                                                     20.3.22.5
"for a reason unrelated to      delete "any" from this phrase        AGREE (EDITOR: 2010-01-28 EDITOR
every any reason code"                                               16:18:17Z)
Several MIB variables are         For each of these MIB            DISAGREE (GEN: 2010-01-21 EDITOR
identified as written by an       variables, change all            21:56:51Z) While accepting
external management entity,       occurrences in the text from     that there are multiple
but changes only take effect      dot11<NAME> to                   improvements and
on a MLME-START or MLME-          dot11Current<NAME>. Insert       clarifications that may be
JOIN. This leads to confusion     a new table in the MIB,          made in the MIB, the amount
at the external management        dot11CurrentBSSParameters,       of effort is signficant and the
entity upon reading one of        using the next dot11smt value,   benefit is limited. On balance,
these variables and not           containing all of these          we prefer to make no change.
knowing whether the value         dot11Current<NAME>
read has taken effect yet or      variables. All are MAX-
not. For reasons of backward      ACCESS read-only.
compatibility, the confusion      Description for all of these
must be retained. But a           contain "This is a status
method can be included that       variable. It is written by the
unambiguously tells the           MAC when an MLME-
external management entity        START.request or MLME-
what is currently happening. In   JOIN.request is received. This
D2.0 this affects the following   is a copy of the MIB variable
MIB variables: dot11StationID,    dot11<NAME> that is copied
dot11BeaconPeriod,                at the time of the MLME-
dot11DTIMPeriod,                  START.request or MLME-
dot11MultiDomainCapabiityAct      JOIN.request."
ivated, dot11CountryString,
dot11SpectrumManagementR
equired,
dot11RegulatoryClassesRequi
red,
dot11RadioMeasurementActiv
ated,
dot11RMLinkMeasurementActi
vated,
dot11RMParallelMeasurement
This line telling what happened   change this line to Editor's     AGREE (EDITOR: 2010-01-20 EDITOR
to Annex Q should be an           Note                             14:54:12Z)
Editor's Note, rather than text
to keep in the final document
Status of PBCC in D2.0 is      Change "deprecated" to     AGREE (GEN: 2010-01-20                  EDITOR
inconsistent. With HR/DSSS "obsolete" at page 977 line 34 07:40:42Z)
(Clause 18) it is noted as     and at page 1098 line 18.
obsolete (page 922 line 35),
but with ERP (Clause 19) it is
marked deprecated (page 977
line 34). In the PICS (Annex
A) PC17 says obsolete (page
1032 line 13) and ERP2 is
deprecated (page 1098 line
18). It is further noted (page
978 line 48) that ERP-PBCC is
an extension to DSSS-PBCC.
The comments that led to this
new text (#1053, #1178, #1187
for HR/DSSS, and #1180,
#1189 for ERP) make no claim
that the PBCC option doesn't
work, nor that it doesn't meet
the design goals, nor that
using PBCC is harmful in any
way. Therefore, the proper
change is to consistently mark
it "obsolete".


normative reference is made       change reference in 11.1.3.0a AGREE (GEN: 2010-01-20            EDITOR
here to IEEE Std 802-1990,        to IEEE Std 802-2001. Same 06:47:21Z)
but that version doesn't appear   change in 7.1.3.3.2 on page
in Clause 2.                      78 line 54.


Almost everywhere, IEEE Std       change IEEE Std 802.11-2007        AGREE IN PRINCIPLE              EDITOR
802.11 is given either without    to IEEE Std 802.11-<year>          (EDITOR: 2010-01-29
a year, or as 802.11-<year>       with the appropriate Editor's      14:16:07Z)
(with instructions to change      Note following it.                 Replace 2007 by "<year>" and
<year> to the year of                                                move the following editorial
publication). One was missed                                         note (occurs later in Annex A)
                                                                     to just after the A.1 heading:
                                                                     "<year> will be replaced with
                                                                     the year of publication during
                                                                     publication of this standard by
                                                                     the IEEE-SA editorial staff."

                                                                     (Same resolution as to CID
                                                                     2032)

It looks as though the page       Although I like it. I think most   DISAGREE (EDITOR: 2010- EDITOR
numbering has been done as        readers would prefer the           01-20 14:58:31Z) - The draft
alphabetical. (I just had to      pages of the document to be        sent to ballot had correct page
enter this comment)               numbered. :-)                      numbering.
                                                                     (Note to commenter:
                                                                     Comments should not be
                                                                     based on the redline draft.)
Calling the frames "Protected   Replace "Protected Dual of        UNRESOLVABLE (MAC: 2010- EDITOR
Dual of Public Action" frames   Public Action" with "Protected    01-19 07:03:14Z) - Comment
is unnecessary.                 Public Action" and add the        withdrawn by commenter
                                follow sentence after the first   during Monday EVE in January
                                sentence of the first paragraph   2010 meeting.
                                of section 7.4.9a.1. "Protected
                                Dual of Public Action frames
                                are used between STA's when
                                Management Frame
                                Protection has been enabled,
                                and after a security
                                association has been
                                established between them."

Figure 11-10 should be          Remove Figure 11-10               DISAGREE (GEN: 2010-01-20 EDITOR
replaced by Figure 11-11.                                         06:48:31Z) -
                                                                  No change required. The
                                                                  figure is correct in the non-
                                                                  redline version of the draft.



The second sentence of the      Replace the paragraph with        AGREE IN PRINCIPLE (GEN: EDITOR
paragraph does not provide      the following text:               2010-03-12 05:50:43Z) A
any useful information to the   "The STA shall indicate that      consistency to the cited
reader.                         reason code from Table 7-28       sentence was made. CID
                                (Reason codes) of                 2197 has the specific changes
                                7.3.1.7(Reason Code field)."      listed in this clause and
                                                                  several others.
The second sentence of the         Replace the paragraph with           AGREE IN PRINCIPLE (GEN: EDITOR
paragraph does not provide         the following text:                  2010-03-12 15:13:22Z) The
any useful information to the      "The STA shall indicate that         specific text change is noted in
reader.                            reason code from Table 7-28          CID 2197. Also for
                                   (Reason codes) of                    consistency, other places
                                   7.3.1.7(Reason Code field)."         where this text was reiterated
                                                                        was fixed as well.




Items a, b, c and d are            Use the same phrasing for all        AGREE (EDITOR: 2010-01-27 EDITOR
inconsistently worded.             4 (e.g. start all of them with “If   15:57:28Z)
                                   an RSNA is ...”)
“Hence ...” incorrectly claims     Revise d)3) to be more               AGREE IN PRINCIPLE               EDITOR
that the two authentications       consistent with c)3).                (SECURITY: 2010-01-11
are happening in parallel.                                              22:32:41Z)
While they may happen in                                                Replace "Hence two such key
parallel, they may also be                                              management algorithms are
serialized. Item c)3) correctly                                         happening in parallel between
states that they may happen                                             any two STA’s Supplicants and
simultaneously.                                                         Authenticators." with "Note that
                                                                        two peer STAs may follow
                                                                        this procedure
                                                                        simultaneously."


Items a)6) and b)5) are            Use the same phrasing for            AGREE IN PRINCIPLE           EDITOR
inconsistently worded.             both.                                (EDITOR: 2010-01-27
                                                                        15:59:11Z)
                                                                        Replace first sentence of a6
                                                                        with the contents of b5.
Items a)7) and b)6) are            Use the same phrasing for            AGREE IN PRINCIPLE           EDITOR
inconsistently worded.             both.                                (EDITOR: 2010-01-27
                                                                        16:02:17Z)
                                                                        Replace b6 with contents of
                                                                        a7.
The “STA programs the ...” is      Change to “the STA's SME             AGREE (SECURITY: 2010-01- EDITOR
vague and inconsistent with        programs the ...”                    11 22:31:38Z) - Accept.
the beginning of the
procedure.
“, bits 0 to 3 of the Priority     Change to “, the Priority            AGREE (SECURITY: 2010-01- EDITOR
field” should have been update     subfield”                            12 20:04:57Z)
to reflect the change of Prority
field to Priority subfield.
Which TK? PTK? GTK? STK? Specify which TK.                  DISAGREE (SECURITY: 2010- EDITOR
                                                            01-29 16:37:17Z)
                                                            The use of TK (temporal key)
                                                            appears to be correct. See
                                                            8.5.1.2 and 8.5.1.4
“may be concatenated” or may Change “may” to “are”, or      AGREE IN PRINCIPLE           EDITOR
be what?                     provide information on other   (SECURITY: 2010-01-12
                             possible actions.              20:15:09Z)
                                                            Change "may be" to "are"
“shall use the same TK as a Specify which TK and which      DISAGREE (SECURITY: 2010- EDITOR
Data MPDU”. Again, which TK data MPDU (e.g. “the PTK        01-29 16:38:36Z)
(or which Data MPDU)?       used for unicast addressed      The use of TK (temporal key)
                            data MPDUs”).                   appears to be correct. See
                                                            8.5.1.2 and 8.5.1.4




it should be table 7-57e      Change accordingly            DISAGREE (MAC: 2010-01-20 EDITOR
instead of table 7-57c                                      01:21:39Z). The cited text
                                                            does not appear to exist on
                                                            page 235 of REVmb-D2.0.




it should be                   Change accordingly           DISAGREE (EDITOR: 2010- EDITOR
dot11ExtendedChannelAssign                                  01-29 13:30:35Z) - There are
mentEnabled instead of                                      no occurances of
dot11Extended-                                              "dot11Extended-" in the ballot
ChannelAssignmentEnabled                                    draft.
If the                         Change accordingly           DISAGREE (SECURITY: 2010- EDITOR
dot11ExtendedChannelSwitch                                  01-14 21:42:32Z)
Enabled is false, should the                                The text clearly states that the
AP sends the Extended                                       STA can send the CSA or
Channel Switch                                              send both the CSA and ECSA.
Announcement or the
Extended Channel Switch
Announcement and the
Channel Switch
Announcement elements and
frames? What is the difference
with
dot11ExtendedChannelSwitch
Enabled is true?
If the                         Change accordingly             DISAGREE (SECURITY: 2010- EDITOR
dot11ExtendedChannelSwitch                                    01-14 21:44:27Z)
Enabled is false, should the                                  The text clearly states that the
AP sends the Extended                                         STA can send the ECSA or
Channel Switch                                                both the ECSA and the CSA.
Announcement or the
Extended Channel Switch
Announcement and the
Channel Switch
Announcement elements and
frames? What is the difference
with dot11ExtendedC

It should be               Change accordingly                 DISAGREE (EDITOR: 2010- EDITOR
dot11RRMNonOperatingChan                                      01-29 13:32:03Z) - The only
nelMaxMeasurementDuration                                     occurance of "Max-
instead of                                                    Measurement" in the balloted
dot11RRMNonOperatingChan                                      draft is in the heading of Table
nelMax-MeasurementDuration                                    11-9, where hyphenation is
                                                              necessary to avoid an over-
                                                              wide column.

                                                              Perhaps the commenter was
                                                              looking at deleted text in the
                                                              redline, or at the wrong version
                                                              of the draft as the reported
                                                              page/line numbers do not
                                                              agree with the reported clause.

The distinction between          Submission "doc.: IEEE       AGREE IN PRINCIPLE (MAC: EDITOR
NonERP_Present and               802.11-10/0010r0" suggests   2010-01-20 00:49:33Z). Insert
Use_Protection bit is not clear. resolution.                  the following text at page 437,
Looks like the statement refers                               line 18 after the first sentence:
to Use_Protection instead of                                  "In an IBSS, if a member of an
NonERP_Present                                                IBSS detects one or more
                                                              NonERP STAs that are
                                                              members of the same IBSS
                                                              NonERP_Present bit should
                                                              be set to 1."

                                                              Insert the following paragraph
                                                              at page 437, line 36:
                                                              "The Use_Protection bit may
                                                              be set to 1 when the
                                                              NonERP_Present bit is 1."
"A STA shall transmit no frame   Modify "A STA shall transmit  AGREE (MAC: 2010-01-22           EDITOR
types other than RTS, CTS,       no frame types other than     01:47:43Z)
and ACK Control frames,          RTS, CTS, and ACK Control
Beacon and ATIM                  frames, Beacon and ATIM
management frames and Null       management frames and Null
data frames during the ATIM      data frames during the ATIM
Window."                         Window." as "A STA shall
I think the above should         transmit no frame types other
include (QoS) Null frames as     than RTS, CTS, and ACK
well.                            Control frames, Beacon and
                                 ATIM management frames
                                 and (QoS) Null data frames
                                 during the ATIM Window."

The SSID length should be 0 -    Correct SSID length to 0 - 32    AGREE (GEN: 2010-01-20        EDITOR
32 octects                       octets                           06:41:11Z)
The SSID length should be 0 -    Correct SSID length to 0 - 32    AGREE (GEN: 2010-01-20        EDITOR
32 octects                       octets                           06:41:26Z)
The SSID length should be 0 -    Correct SSID length to 0 - 32    AGREE (GEN: 2010-01-20        EDITOR
32 octects                       octets                           07:17:29Z)
The value of Beacon period is    Clarify.                         DISAGREE (GEN: 2010-01-20     EDITOR
shown as >=1TU. Given that                                        06:41:52Z) - Range given is
most of the time Beacon                                           not incorrect
airtime would be more than
1TU should we increase this
lower limit of 1TU?
The definitions of "3.83         In the two definitions:          AGREE (GEN: 2010-01-20          EDITOR
individually addressed" and         1. remove the "or control     06:17:26Z) Accept Both
"3.72 group addressed" are       frame"s                          changes are to be made. In
confusing. 1) It is not clear       2. replace the "(RA)"s with   the two cited definitions: 1.
how the definition applies to    "(Address 1)"s.                  remove the "or control frame"s
MMPDUs, since these do not                                        and 2. replace the "(RA)"s with
have an RA (see section                                           "(Address 1)"s.
7.2.3). 2) Control frames are
MPDUs (see section 7.1.1), so
"(MPDU) or control frame"
sows doubt.
11.2.1.0a says that "A STA        Delete sentences which         DISAGREE (MAC: 2010-01-19 EDITOR
shall determine that an MSDU      duplicate detailed information 07:06:16Z). The proposed
or MMPDU is buffered for it by    in other sections, and replace change has insufficient detail
receiving and interpreting a      with general statement. (i.e.  to implement. The commenter
TIM." but this is not true for    remove cited sentence)         is encouraged to bring a
MSDUs on delivery-enabled                                        submission to the TG for
ACs, unless all ACs are           Change to cover all types and consideration.
delivery-enabled.                 scenarios of power
This section does not account     management, or delete
for U-APSD, e.g. if there are     sentences which duplicate
MSDUs on delivery-enabled         information in other sections,
ACs only but not all ACs are      and replace with general
delivery-enabled, then the TIM    statement. (See CID 1365)
will not signal their presence.
(See CID 1365)

Project Purpose should match A Modified PAR should be              UNRESOLVABLE (GEN: 2010- EDITOR
what is in the PAR.          crafted to adjust the PAR to          01-20 06:14:21Z) -- The
                             match the improved text in the        Modified PAR process needs
                             draft.                                to occur in parrallel with the LB
                                                                   Process. The changes to the
                                                                   PAR should be made later in
                                                                   the process to allow for other
                                                                   amendment adjustments, but
                                                                   prior to start of Sponsor Ballot.

3.83 and 3.84 are in the wrong reverse the order of 3.83 and       AGREE (EDITOR: 2010-01-27 EDITOR
order -- Individual addressed 3.84                                 14:57:31Z)
vs Individual Address

"These two variables create       Change sentence to be            AGREE (GEN: 2010-01-21       EDITOR
four local states for each        "These two variables create      01:21:48Z) in 11.3.0a Change
remote STA". This sentence        four local states for the        sentence to be "These two
should indicate that it is the    relationship between the STA     variables create four local
relationship between the STA      and the remote STA."             states for the relationship
and the remote STA not the                                         between the STA and the
STAs themselves that are in                                        remote STA."
the states described.
The diagram shows the state remove the "Unsuccessful               AGREE IN PRINCIPLE (GEN: EDITOR
of the STA with respect to a   802.11 Authentication" loops        2010-03-17 21:52:43Z)
remote STA. When in State 3 for state 3 and 4.                     remove the four unsuccessful
or 4, the STA would not                                            self loops.
execute an "802.11
Authentication" with the
remote STA. It may do so with
a new STA (AP) that it was
wanting to transition to, but
that would not be included in
this digraph because the state
of the STA with the other
Remote STA would be a
different state diagram. So
while the transition of
"Unsuccessful 802.11
Authentication" doing nothing
(looping back to the same
state) is valid (it the new
remote STA did not
authenticate with the STA,
then the relationship of the
STA and the current remote
STA would not change), it is
not correct to be on this
diagram.




Remove Editor's Note.             Remove Editor's Note -- No       AGREE (GEN: 2010-03-12        EDITOR
                                  action required.                 03:52:43Z) The editor note is
                                                                   to be removed, CID 2197
                                                                   addresses the Editor's
                                                                   concern.
This paragraph is a duplicate     Remove the cited paragraph       AGREE (EDITOR: 2010-01-28 EDITOR
of paragraph 1 -- in the          as it is redundant.              16:19:16Z)
comment resolution
instructions (see CID 1357 , it
was to be deleted.)
As noted in the Editor Note,      Remove the parenthetical         AGREE IN PRINCIPLE (GEN: EDITOR
the Parenthetical Statement is    statement. "(including the old   2010-01-20 07:28:49Z) -
not realizable, but the main      AP……)"                           Remove Editor's Note and
statement is correct.                                              parenthetical in 11.3.2.4 h).
Figure 11-11 has various         Add missing state transitions   AGREE IN PRINCIPLE (GEN: EDITOR
missing transitions, e.g.:       as cited.                       2010-03-17 21:54:03Z)
  - successful auth in State 2                                   Change the introduction to the
leaves you in State 2                                            figure to read "Figure 11-6
  - unsuccessful auth in State 2                                 shows the state transition
takes you to State 1                                             diagram for these STA states.
  - unsuccessful (re)assoc in                                    Note that only events causing
State 3 takes you to State 2                                     states changes are shown."
  - unsuccessful reassoc (not
just assoc) in State 4 takes
you to State 2
  - successful (re)assoc in
State 3 leaves you in State 3
  - successful (re)assoc in
State 4 when RSNA is
required takes you to state 3
  - successful (re)assoc in
State 4 when RSNA is not
required leaves you in state 4
 11.3.1.0a the rules about      Rewrite the paragraph using   AGREE IN PRINCIPLE (GEN: EDITOR
class errors are normative, not normative language.           2010-03-17 22:22:40Z) Delete
informative. So drop the "For                                 "For example, " and change
example," and add some                                        "discards" to "shall discard" in
"shall"s.                                                     11.3.1.0a. And add a line to
                                                              page 801(D2.04) a) 3) "ii)
                                                              Data frames between peers
                                                              using DLS"




 11.3.2.0a the rules about      Rewrite the paragraph using   AGREE (GEN: 2010-03-12          EDITOR
class errors are normative, not normative language.           05:54:16Z) in 11.3.2.0a the
informative. So drop the "For                                 6th paragraph 1st sentence:
example," and add some                                        Delete "For example, " and
"shall"s.                                                     change "discards" to "shall
                                                              discard".
In 11.3.1.1 I don't understand    Change "may" to "shall"     AGREE GEN: 2010-01-20           EDITOR
why the PTKSA and temporal                                    07:07:06Z - Accept. -Change
key deletion is a "may".                                      "may" to "shall" in 11.3.1.1.
Everywhere else it's a "shall".
shouldn't there be blurb in e.g. Make the conditional deletion   AGREE (GEN: 2010-03-12             EDITOR
11.3.1.4 and 11.3.2.6/8 in the of Keys consistent in 11.3.1.2,   03:58:24Z) Make the following
same way there is in 11.3.1.2, 11.3.14, 11.3.2.6 and 11.3.2.8.   changes
about not deleting keys if MFP                                   in 11.3.1.2:
was in force?                                                    Delete "if and only if
                                                                 Management Frame
                                                                 Protection had not been
                                                                 negotiated when the PTKSA(s)
                                                                 were created"
                                                                 Add "and if Management
                                                                 Frame Protection was not
                                                                 negotiated when the PTKSA(s)
                                                                 were created," after the first "if
                                                                 conditional phrase" at the start
                                                                 of the paragraph and correct
                                                                 capitalization.

                                                                 in 11.3.1.4:
                                                                 add "if Management Frame
                                                                 Protection was not negotiated
                                                                 when the PTKSA(s) were
                                                                 created," to the start of the
                                                                 paragraph(line 4) and correct
                                                                 capitalization.

                                                                 in 11.3.2.6:
                                                                 add "If Management Frame
                                                                 Protection was not negotiated
                                                                 when the PTKSA(s) were
                                                                 created," to the start of the
                                                                 paragraph and correct
                                                                 capitalization.
The first para of 11.3.2.6      change paragraph to use          AGREE IN PRINCIPLE (GEN: EDITOR
needs to be fixed because it    .indication.                     2010-03-15 23:27:37Z) The
talks about invoking .request                                    specific change to the first
but this is about getting a                                      para is not necessary, but we
.indication.                                                     did find that along the line of
                                                                 understanding why this is the
                                                                 case, that the 2nd paragraph
                                                                 should change from
                                                                 "oriingating STA's" to
                                                                 "originating STA's MLME" (or
                                                                 AP as the case may be.) This
                                                                 clarification would help point to
                                                                 the part of the STA that is
                                                                 logically acting on the
                                                                 information.

                                                                 Changes made to 11.3.1.1,
                                                                 11.3.1.2, 11.3.1.3, 11.3.1.4,
                                                                 11.3.2.1, 11.3.2.2, 11.3.2.3,
                                                                 11.3.2.4, 11.3.2.5, 11.2.3.6,
                                                                 11.2.3.7 and 11.3.2.8: 2nd par
                                                                 add "s MLME" to the STA, Non-
                                                                 AP STA or AP as appropriate.
11.3.1.2.d needs to say that if Add to the end of the sentence      AGREE IN PRINCIPLE (GEN: EDITOR
the auth was unsuccessful the at d) "if the authentication was      2010-03-17 21:57:49Z) make
state is set to State 1.        unsuccessful, the state for the     the change as noted in 11-
                                originating STA shall be set to     10/390r0, which insert the
                                State 1."                           recommended text in a
                                                                    different location -- at the end
                                                                    of b.




 11.3.2.1.b should not say        Change "The STA shall             AGREE (GEN: 2010-03-12          EDITOR
"STA shall transmit, if           transmit an Association           06:03:41Z) Change "The STA
contained RSN; included in        Request frame to the AP, if the   shall transmit an Association
frame." but "STA shall            MLMEASSOCIATE.request             Request frame to the AP, if the
transmit. If contained RSN,       primitive contained an RSN..."    MLMEASSOCIATE.request
included in frame." (Change       to                                primitive contained an
comma to period and make          "The STA shall transmit an        RSN..."
two sentances.                    Association Request frame to      to
                                  the AP. If the                    "The STA shall transmit an
                                  MLMEASSOCIATE.request             Association Request frame to
                                  primitive contained an RSN..."    the AP. If the
                                                                    MLMEASSOCIATE.request
                                                                    primitive contained an RSN..."


11.3.2.5 should say              add "initiation" to title cited and AGREE IN PRINCIPLE (GEN: EDITOR
"disassociation initiation" not  a followup submission to made 2010-03-12 14:56:52Z)
just "disassociation".           on consistency efforts.             Change the following titles by
                                                                     adding the quoted word:
We should make sure the                                                 11.3.2.1 Non-AP STA
wording is consistent in all the                                     association "initiation"
categories (e.g. between all                                         procedures
the "initiation" procedures and                                         11.3.2.2 AP association
between "association" and                                            "receipt" procedures
"reassociation" and between                                             11.3.2.3 Non-AP STA
"deauthentication" and                                               reassociation"initiation"
"disassociation") to avoid                                           procedures
causing Fear Uncertainty and                                            11.3.2.4 AP reassociation
Doubt.                                                               "receipt" procedures
                                                                        11.3.2.5 Non-AP STA
                                                                     disassociation "initiation"
                                                                     procedures
"STA's SME" has not always     simplify to "SME" at the           AGREE IN PRINCIPLE                 EDITOR
been simplified to "SME" (e.g. following locations:               (SECURITY: 2010-01-12
11.3.1.3).                     11.3.1.1 p636 - line 13            21:21:54Z)
                               11.3.1.2 p636 line 42              Change "STA's SME" to SME
There are 28 instances of      11.3.1.3 p637 line 17              at the following locations:
"STA's SME". Most are in       11.13 p701 line 33                 11.3.1.1 p636 - line 13
clause 8., but the ones in                                        11.3.1.2 p636 line 42
clause 11 may be simplified.                                      11.3.1.3 p637 line 17
                                                                  11.13 p701 line 33




extra "." after Public Action   remove extra "."                  AGREE (EDITOR: 2010-01-20 EDITOR
                                                                  14:49:08Z)
extra "." after (above)         remove extra "."                  AGREE (EDITOR: 2010-01-20 EDITOR
                                                                  14:49:58Z)
Sometimes there's a missing     add "primitive" after the MLME    AGREE IN PRINCIPLE              EDITOR
definite article before MLME    primitive name to the following   (EDITOR: 2010-01-28
primitive names and/or the      locations:                        12:13:29Z) - Editor is to scan
word "primitive" is missing     p619 line 53 and line 58.; p620   all uses of ".request",
after MLME primitive names.     line 2; p622 line 53 and 54;      ".confirm", ".indication" and
                                p637 line 20 and 53; p639 line    ".response" and add "primitive"
                                19; page 640 line 14;page 641     and adjust articles where
                                line 3 and 37; page 642 line 3,   necessary (i.e. where missing
                                22, and 51;page 643 line 11       in body text).
                                and 34;
                                                                  For consistency, replace
                                Missing article at                "service primitive" with
                                page 636 line 14 and 16; p637     "primitive".
                                line 20 and 53; p638 line 45      Note, in pseudo-code as part
                                and 47; p639 line 19, 25, 46,     of a condition, and followed
                                and 53; page 640 line 14, 27,     "by invoking", do not add
                                and 28; page 641 line 3, and      primitive.
                                9; page 642 line 3, 22, and
                                51;page 643 line 11 and 34;       Reword adjacent text for
                                                                  consistency, e.g. "the primitive
                                                                  yyy" -> "the yyy primitive",
                                                                  "commands" -> "primitives",
                                                                  "signal" -> "primitive",
                                                                  "message" -> "primitive"

                                                                  (There are ~418 location
                                                                  requiring correction. The
                                                                  commenter gets the editor's
                                                                  award for quantity.)
There are instances of "MLME 5 Locations where "-" is                   AGREE IN PRINCIPLE              EDITOR
SETPROTECTION" (should          missing or extra space in               (EDITOR: 2010-01-28
be "MLME-                       name: figure 8-39 lower right           15:55:16Z)
SETPROTECTION"). Do             box. (remove extra space)               Make changes in text as
search on "MLME                 missing "-": page 639 line 19;          shown. The error in Figure 8-
SETPROTECTION". 33              page 640 line 15; page 641              39 is caused by the "-" being
instances, but they include the line 2; page 642 line 2;                shifted left into the E. Adjust
correct "MLME-                                                          figure 8-39 to correct any
SETPROTECTION" as well.                                                 overlap between text strings.
Fix locations where "-" is
missing.
There are instances of "MLME- there are 5 instances that                AGREE (EDITOR: 2010-01-28 EDITOR
SAQUERY" (should be "MLME- need correcting. Page 639 line               12:10:34Z)
SAQuery").                      46 and 53; page 641 line 31
                                and 37; page 1371 line 22.

An MPDU (also known as a             A quick search can easily find     AGREE IN PRINCIPLE (GEN: EDITOR
frame) is the unit of data sent      the instances noted. It is         2010-03-05 17:26:25Z) Add
between two devices using the        understood that to fully resolve   "Syn: Frame." to the definintion
PHY. An MSDU is the unit of          this comment that a                of MPDU. Clause 7.1.1.
data which can be sent               submission with more detailed      supplies a context for the use
between two devices using the        change will be necessary.          of the word frame. The
services of the MAC, and an                                             comment is not quite correct.
MMPDU is the unit of data            However for starters, add          The terms "frame" and
which is sent between two            "Also known as a frame" as         "MPDU" are synonyms. No
devices to manage the MAC.           indicated bye the comment to       other change is warranted at
Both MSDUs and MMPDUs                3.97 (page 12 line 56).            this time.
are sent as one or more
MPDUs, but they are not
MPDUs and do not, strictly
speaking, have e.g. a MAC
header.
Therefore expressions like
"The frame body of a
management frame of subtype
Beacon contains" are dubious.
"A Beacon MMPDU contains"
might be better. Similarly
expressions like "Probe
Response frames" are dubious
-- "Probe Response MMPDUs"
or just "Probe Responses"
might be better. And the
definitions of e.g. "group
addressed" are also dubious.
As a first step, the definition of
MPDU should additionally say
"Also known as a frame."
The statement that the Power Restore the deleted normative             AGREE IN PRINCIPLE (MAC: EDITOR
Management mode (and         language.                                 2010-01-20 00:14:43Z) - Insert
hence the PM bit) shall not                                            the following paragraph into
change during a single frame                                           clause 11.2.1.0a: "A STA shall
exchange has apparently been                                           remain in its current Power
lost from 11.2.                                                        Management mode until it
                                                                       informs the AP of a Power
                                                                       Management mode change via
                                                                       a frame exchange that
                                                                       includes an acknowledgment
                                                                       from the AP. Power
                                                                       Management mode shall not
                                                                       change during any single
                                                                       frame exchange sequence, as
                                                                       described in 9.12."

                                                                       Note: Clause 9.12 may have
                                                                       moved in D2.01 after
                                                                       incorporation of 802.11n-2009
                                                                       (Annex S).


Carry-forward comment from          Please clarify which function is   DISAGREE (GEN: 2010-01-20 EDITOR
LB149.                              mandatory for a QoS STA.           06:20:34Z) - The
The definition of QoS facility is   Proposed resolution to             Requirements are stated in the
vague. Does this implies that       CID1370 in 11-09/1233r0            text, not in the definition. See,
the QoS facility means the use      (page6-7) looks reasonable.        e.g., 9.1.1 ("The DCF shall be
of EDCA as a minimum set?                                              implemented in all STAs…"),
If the STA is in IBSS, there are                                       9.1.3.0a ("The HCF shall be
no HCF and HCCA is not                                                 implemented in all QoS
used. However, if we look at                                           STAs."). While the
the PICS table in A.4.16, all                                          requirements may be more
the HCCA rules are mandatory                                           than necessary for an IBSS-
for a QoS STA. It looks like a                                         only STA, the IBSS-only STA
contradiction.                                                         is not addressed in the
                                                                       standard.




Carry-forward comment from          Please clarify. Suggest to         DISAGREE (GEN: 2010-01-20 EDITOR
LB149.                              remove the table entirely, or      07:45:33Z) -- The table in
The table in A.4.4.2 does not       complete the table.                A.4.4.2 only contains those
contain all the defined frame                                          frame types that the baseline
types. Why is that?                                                    standard and its amendments
                                                                       have seen fit to describe here,
                                                                       and the table makes no claims
                                                                       to be totally inclusive.

Placeholder for a description Add list of main technical   AGREE IN PRINCIPLE (GEN: EDITOR
of technical changes needs to changes gleaned from previou 2010-01-20 06:11:03Z) -
be filled in.                 comment resolutions.         Accept in principle. Delete
                                                           placeholder for list of
                                                           enhancements.
Editor’s Note: The changes        Resolve conflict and remove   AGREE (SECURITY: 2010-01- EDITOR
made in response to CID 1115 note.                              29 17:02:02Z) - The updated
(see 11-09/601r2) replace use                                   text has been reviewed and it
of the term “TKIP and/or                                        has been determined that the
CCMP” with “Enhanced data                                       conflict has been properly
cryptographic encapsulation                                     resolved. No changes
mechanisms”, which includes                                     necessary.
TKIP. The changes made in
response to CID 98 replace
“TKIP and/or CCMP” with
CCMP. Where these
resolutions conflict, resolved in
favor of CID 1115.

Editor’s Note: One of the    State what happens for a non-      AGREE IN PRINCIPLE              EDITOR
surrounding statements in    AP probe response and              (EDITOR: 2010-03-15
incomplete because nothing   remove note.                       20:34:42Z) - - Insert the
states what a non-AP                                            following phrase before the
STA puts in a probe response                                    closing period of the first
frame.                                                          sentence: "; STAs in an IBSS
                                                                set the short preamble subfield
                                                                to 1 in transmitted Beacon
                                                                frames when
                                                                dot11ShortPreambleOptionIm
                                                                plemented is true." Delete the
                                                                paragraph at line 10 and its
                                                                preceding editor's note.

                                                                Also replace the last sentence
                                                                of the cited para with:
                                                                "Otherwise an AP or a STA in
                                                                an IBSS sets the Short
                                                                Preamble subfield to 0."




Editor’s Note: One of the         Resolve conflict and remove   AGREE IN PRINCIPLE (MAC: EDITOR
surrounding statements is         note.                         2010-03-15 18:15:16Z). Make
incomplete because the non-                                     changes to 7.3.1.4 as shown
AP Probe Response is                                            in 11-10/0308r0, which clarify
not mentioned. Also note that                                   the IBSS case reflects the
the general rule for STAs                                       device capability, and adds the
above (in which it PBCC                                         missing probe response case.
subfield is a capability)
conflicts with the specific rules
for APs (above) and STAs in
an IBSSS (below) in which it is
a property of
the BSS.
Editor’s Note: The following     Resolve inconsistency with       AGREE IN PRINCIPLE (MAC: EDITOR
paragraph was added in           setting of subfield and remove   2010-01-20 01:06:06Z). There
response to CID 1386. The        note.                            is no conflict because the
editor instructions were                                          paragraph at line 16 calls out
inadequate. Careful review is                                     specific frame types. Remove
advised. Also note that the                                       editor's note.
general rule in the para above
(“STAs”) in                                                       Change paragraph at line 30
which the subfield is related to                                  to read: "STAs in an IBSS set
the MIB variable conflicts with                                   the DSSS-OFDM subfield to 1
the specific case of the AP                                       in transmitted Beacon and
above (in which                                                   Probe Response MMPDUs
the subfield indicates ‘is                                        when
allowed in the BSS’) and the                                      dot11DSSSOFDMOptionImple
specific case of IBSS below (in                                   mented and
which case the subfield                                           dot11DSSSOFDMOptionActiv
indicates ‘intends to use DSSS-                                   ated are true. Otherwise, STAs
OFDM’).                                                           in an IBSS set the DSSS-
                                                                  OFDM subfield to 0."

Editor’s Note: Rules of the         Reword subclause to specify   AGREE (MAC: 2010-01-19           EDITOR
form “STAs shall” or “APs           in the singular.              07:12:48Z)
shall” need to be rephrased “A
STA” or “An AP”,
because a normative
requirement cannot be
distributed across multiple
entities.
Editor’s Note: Resolution of        Resolve conflict and remove   AGREE IN PRINCIPLE (MAC: EDITOR
CID 1708 moves the note from        note.                         2010-01-19 07:13:34Z). Move
a                                                                 NOTE to the 1-1-0 row.
footer row on the (probably
incorrect) assumption that it
was
intended to apply to that row.
However the explicit “See
NOTE”
on row 3 above claims row 3 is
the intended default behavior.
The
result of this edit is to make it
ambiguous which is the default
behavior.

Editor’s Note: Should the “Key” Consider whether change           AGREE IN PRINCIPLE (MAC: EDITOR
field of 7-9506a be replaced    necessary and remove note.        2010-01-19 06:19:11Z).
with a “Wrapped Key” field, as                                    Replace "Key" with "Wrapped
done to Figure                                                    Key" in the rightmost field in
7-95o6 in response to                                             Figure 7-95o6a (i.e., do not
comment 1251?                                                     change "Key Length". On line
                                                                  59, replace "The Key field is
                                                                  the IGTK being distributed"
                                                                  with "The Wrapped Key field
                                                                  contains the wrapped IGTK
                                                                  being distributed". On lines 59-
                                                                  60, replace "Key field" with
                                                                  "Wrapped Key field".
Editor’s Note: Size of Local     Specify size of field in figure 7- AGREE (MAC: 2010-01-19       EDITOR
Power Constraint field is not    101h8                              07:15:14Z). Set field as one
specified.                                                          octet.
Editor’s Note: A normative       Move from overview or relabel AGREE (SECURITY: 2010-01- EDITOR
statement probably shouldn’t     heading to remove overview         20 04:31:41Z) - Accept.
exist in an overview                                                Merge "overview" subclause
subclause.                                                          into "General" subclause.




Clause 5 contains multiple       Move normative statements      AGREE IN PRINCIPLE (GEN: EDITOR
normative statements. It is      from clause 5 into Clause 9,   2010-01-21 23:06:54Z) The
not where most people would      11 etc… as appropriate.        editor is instructed to find the
go to look for normative                                        two "Shalls" and three
statements, so there is the                                     "Shoulds" statements. The
risk that these will get lost.                                  Shalls turn in to informative
                                                                statements and the original
                                                                statements get copied into the
                                                                corresponding normative
                                                                clause. The "Shoulds"
                                                                statements get replaced as
                                                                appropriate and put the
                                                                original statement into the
                                                                appropriate location in the
                                                                normative clauses.

Editor’s Note: What is         Remove it or explain it          AGREE IN PRINCIPLE             EDITOR
“SetProtection” doing hovering                                  (SECURITY: 2010-01-12
near bottom right of Figure 8-                                  20:59:29Z)
37?                                                             Remove the "hovering
                                                                SetProtection" from figure 8-
                                                                37. It does not appear in IEEE
                                                                802.11-2007.
Editor’s Note: This is called out Ah, an excuse to do more      DISAGREE (SECURITY: 2010- EDITOR
in resolution of CID 1115 as      work. Joy.                    01-29 16:45:34Z)
requiring extra work.                                           The committee has reviewed
                                                                the new material from IEEE
                                                                802.11w-2009 and no
                                                                adjustments are necessary.




Editor’s Note: This is called out Ah, an excuse to do more      DISAGREE (SECURITY: 2010- EDITOR
in resolution of CID 1115 as      work. Joy.                    01-29 16:46:57Z)
requiring extra work.                                           The committee has reviewed
                                                                the new material from IEEE
                                                                802.11w-2009 and no
                                                                adjustments are necessary.
Editor’s Note: The resolution of Correct this error.       AGREE (GEN: 2010-01-20             EDITOR
CID 1141 was incorrect. This                               06:40:05Z) - Same change
comment is talking about                                   requeste by CID 2094:
interactions not                                           Change the paragraph to, "The
represented by a SAP. As                                   various entities within this
such it called out the right                               model interact in various ways.
interacting pairs, but was                                 Certain of these interactions
wrong to call out the double                               are defined explicitly within this
arrows which relate to different                           standard, via a SAP across
interactions. The interactions                             which defined primitives are
between the MLME, PLME and                                 exchanged. This definition
SME                                                        includes the GET and SET
take place through well-                                   operations between MLME,
defined SAPs, contrary to the                              PLME and SME as well as
statement below (as modified                               other individually defined
by CID 1141).                                              service primitives, represented
                                                           as double arrows within Figure
                                                           10-1. Other interactions are
                                                           not defined explicitly within this
                                                           standard, such as the
                                                           interfaces between the MAC
                                                           and MLME and between the
                                                           PLME and PLCP and PMD;the
                                                           specific manner in which these
                                                           MAC and PHY LMEs are
                                                           integrated into the overall MAC
                                                           sublayer and PHY is not
                                                           specified within this standard."



Editor’s Note: The change        Reverse change made by CID AGREE (GEN: 2010-01-20         EDITOR
made by CID 1333 below (to       1333 here and remove note. 06:44:20Z)
introduce “or any valid group
MAC address”) is
incorrect. The Peer MAC
address is the entity from
which the action frame was
received, i.e., its SA, and
this cannot be a group
address.
Editor’s Note: The change        Reverse change made by CID AGREE (GEN: 2010-01-20         EDITOR
made by CID 1334 below (to       1333 here and remove note. 06:44:44Z)
introduce “or any valid group
MAC address”) is
incorrect. The Peer MAC
address is the entity from
which the action frame was
received, i.e., its SA, and
this cannot be a group
address.
Editor’s Note: Bad “if and only Replace "if and only if" with "if AGREE IN PRINCIPLE (GEN: EDITOR
if”                             <condition> and shall not         2010-03-12 12:59:18Z) The
                                <verb> otherwise"                 Cited "if and only If" was
                                                                  deleted by CID 2164 and the
                                                                  sentence was relocated and
                                                                  rewritten.
Editor’s Note: The previous      Replace "The use of             AGREE IN PRINCIPLE (GEN: EDITOR
statement makes legacy STA       Unspecified reason shall        2010-03-12 03:03:28Z)
potentially non-compliant when   indicate the indicated STA was In 11.3.1.3 b), Replace
a new reason                     deauthenticated for a reason paragraph with
code is added.                   unrelated to every any defined "The STA shall indicate the
                                 reason code defined in Table 7- appropriate reason code for
Ditto 640.05 and 641.61 and      22 (Reason codes)." with        the STA deathentication as
642.38                           "The use of Unspecified         defined in Table 7-28 (Reason
                                 reason indicates the STA was codes) of 7.3.1.7(Reason
                                 deauthenticated for a reason Code field)."
                                 unrelated to any other reason
                                 code defined in Table 7-22      Similar change to be made in
                                 (Reason codes) that is          11.3.2.2 d) Replace paragraph
                                 understood by the               with
                                 deauthenitcating STA."          "When the status code of the
                                                                 association is not Successful,
                                                                 the AP shall indicate a specific
                                                                 reason for the failure to
                                                                 associate in the status code of
                                                                 the Association Response
                                                                 frame as defined in Table 7-23
                                                                 (Status Codes) in 7.3.1.9
                                                                 (Status Code Field). The state
                                                                 for the STA shall be set to
                                                                 State 2.(#1342)"

                                                             Similar change to be made in
                                                             11.3.2.4 e) Replace paragraph
                                                             with
                                                             "When the status code of the
                                                             reassociation is not
                                                             Successful, the AP shall
                                                             indicate a specific reason for
Editor’s Note: 802.11 includes Remove the cited                 AGREE (GEN: 2010-03-16         EDITOR
no protocol that allows a new parenthetical text and editor's   21:20:33Z) - Remove Editor's
AP to talk to an old AP, so this note.                          Note and parenthetical in
shall statement                                                 11.3.2.4 h). See CID 2159
is not realizable.
"h) The SME shall inform the
DS (including the old AP, if this
is not the same as the new
AP) of any
changes in the association
state."
Editor’s Note: Note conflict       I think this can be solved      AGREE IN PRINCIPLE              EDITOR
introduced by change to last       easily by naming the role the (SECURITY: 2010-03-17
sentence of the following para     STA is performing and calling 19:23:45Z) -
(comment 1112                      it out in this role throughout  Add the following definition to
removes “non-AP”). The last        11A and the primitives in 10. I Clause 3:
sentence of the previous para      suggest we use a name like      FT Originator. A STA that
and the last sentence of the       "FT originator" for similarity  initiates the FT protocol by
following para                     with other protocols.           sending an FT Request frame
appear to conflict. This can                                       or an Authentication frame
perhaps be resolved by             Add a suitable definition to    with Authentication Algorithm
introducing a terminology to       clause 3A, replace use of the set to Fast BSS Transition..
replace “the STA” when             term previously known as non- Replace the term "STA" with
it is specific to the STA acting   AP STA in the FT primitives     "FT Originator" in Clause 11A
in the role of an RRB request      and Clause 11A with this term. where STA refers to the "FT
originator.                                                        Originator" role.
"When the RRB of the current       I think this change also wraps
AP has received a response         up the specific comment that
from the target AP, it uses the    the cited editor's note was
MLME-REMOTEREQUEST.                complaining about.
request primitive to send the
response, as an FT Action
frame, to the requesting STA.
The MAC
of the current AP transmits this
Action frame and issues a
MLME-REMOTE-
REQUEST.confirm primitive
to signal that it has been sent.
When the MAC of the STA
receives an FT Action frame,
the MAC passes the
Action frame to the SME by
use of an MLME-REMOTE- of
Editor’s Note: The resolution      Find a way to deprecate thisAGREE IN PRINCIPLE (GEN: EDITOR
CID 1062 sets the status of        table, or perhaps deprecate 2010-02-26 ) Make changes
this table to deprecated.          its entry definition.       as shown in 11-10-0216r2.
However the MIB won’t also                                     These mark the members of
compile unless the index types     Remove from                 the table, and the group that
of                                 PhyRegDomainsSupportGrou contains the table as
dot11RegDomainsSupportedE          p, perhaps by creating a    deprecated. As the group is
ntry are set to deprecated         …Group2 and deprecating the marked optional in the
status. As one of these            old one.                    compliance statement, there is
indexes is a standard type                                     no need to create any new
(ifIndex), this is not possible                                group. The issue of the
without defining a new type                                    ifIndex preventing compilation
solely to represent a                                          of the deprecated table was an
decprecated index. So this                                     issue with the tools. This
version of the MIB won’t                                       issue went away when the
compile. It’s also referenced                                  recommended tools were used
from                                                           as described in document 11-
dot11PhyRegDomainsSupport                                      10/0216. The editor’s note
Group, with status current,                                    cited in the comment is
which is probably an error.                                    removed by changes in the
                                                               cited document.
Editor’s Note: Per the          Add a description of why it's AGREE IN PRINCIPLE (GEN: EDITOR
resolution of CID 1595, MIB     deprecated if it remains so   2010-01-21 22:13:38Z) Add
variables that are shown as     (see also my comment at       the following to the description:
deprecated should carry         1432.30).                     "Superceded by
in the description a reason                                   dot11RegulatoryClassesTable.
why it is deprecated.                                         "
Editor’s Note: Per the          Add to description:           AGREE IN PRINCIPLE (GEN: EDITOR
resolution of CID 1595, MIB     Superseded by the regulatory 2010-01-21 22:19:23Z) Add to
variables that are shown as     domain and regulatory classes description "Superseded by
deprecated should carry         mechanisms.                   subband-specific supported
in the description a reason                                   regulatory classes."
why it is deprecated.
Editor’s Note: Resolution of    Throughout the MIB remove           AGREE (GEN: 2010-01-20           EDITOR
CID 1588 in LB149 removed       any "this is accessed big-          08:25:07Z)
"big-endian" language in a      endian" or similar phrase.
similar context.                There are 7 such occurances
                                in the MIB, and all should be
                                removed.
Editor’s Note: Should be in     Add NIST SP-800-38B to          DISAGREE (EDITOR: 2010- EDITOR
bibliography?                   bibliography and cite from      01-29 15:42:42Z) - 800-38B is
                                here.                           already listed as a normative
                                                                reference
an AP may set the More Data Use of normative language.          AGREE IN PRINCIPLE (MAC: EDITOR
field to 1 in ACK frames to this "may set" -> "sets" or move to 2010-01-20 00:56:50Z).
STA to indicate that the AP      clause 9.                      Change "may set" to
has a pending transmission for                                  "optionally sets"
the STA.

"The Vendor Specific Content    Describe constraints on the         AGREE (MAC: 2010-01-20         EDITOR
contains the vendor-specific    content of the vendor specific      01:46:55Z). Insert the
fields and may include          content that allow any              following text into the
elements defined in the         elements that follow the            Information column of Table 7-
standard. The length of the     vendor specific content (i.e.       19 in the row "2 - (Last-1)":
Vendor Specific Content in a    following the Action field) to be   "These elements are absent
Vendor Specific Public Action   parsed.                             when the Category subfield of
frame is limited by the                                             the Action field is Vendor-
maximum allowed MMPDU             The minimum requirement is        Specific or Vendor-Specific
size."                            that the vendor specific          Protected."
                                  content can be parsed in some
There is an inconsistency         vendor-specific way to            Insert the following paragraph
between 7.2.3.12 (which           determine its end - i.e., it      and informative note at the
implies that any action frame doesn't rely on the length of         end of 9.14.0e: "The MME of a
can be parsed to locate vendor the MPDU to determine the            Vendor-Specific Protected
specific elements and a           end of the Action field.          Action Frame is located at the
possible BIP at the tail of the                                     end of the frame body.
frame) and the cited location,
which makes no requirement                                          "NOTE: It is not necessary to
that the action field is parsable                                   be able to parse the Vendor-
as elements.                                                        Specific Content to locate the
                                                                    MME."
Why do we need a separate        Add a "protected" parameter to    AGREE IN PRINCIPLE (GEN: EDITOR
Clause 10 interface for          the public action frame           2010-01-21 22:50:54Z) Accept
primitives that generate         versions of any of the            the proposed change as cited,
protected dual public frames.?   interfaces duplicated in          AND modify references to
It is unnecessary.               10.3.40 to 10.3.43 with           public action frames in the
                                 definition: Boolean, indicates    modified primitives sections to
                                 that the exchange will be/was     relate to public action frames
                                 (as appropriate to primitive      or to protected dual public
                                 type) performed using a           action frames based on the
                                 protected dual of public Action   value of the protected
                                 frame.                            attribute.




There is a requirement that      Add vendor specific action      AGREE (GEN: 2010-01-21     EDITOR
Action frames (including         frame to table 7-57m.           22:57:26Z)
Vendor specific) be parseable Delete 10.3.44 and add a
so that the BIP can be located - "protected" parameter to the
i.e., they are inherently        primitives in 10.3.29 with
protectable by the .11w          definition: Boolean, indicates
mechanisms. The presence of that the exchange will be/was
10.3.44 also imples they are     (as appropriate to primitive
protected.                       type) performed using a
                                 protected dual of public Action
However, protected vendor        frame.
specific is not present in table
7-57m, and there is no clause
10 interface that supports the
generation of protected vendor
specific Action frames.




The use of the More Data field Change More Data = 0 to             AGREE (MAC: 2010-03-17   EDITOR
in this subclause is not        EOSP = 1 in item b).               19:20:09Z)
backwards compatible. From
a legacy STA point of view,
More Data is explicitly set to
zero. A new STA cannot
distinguis a new from a legacy
STA, but regardless of this
11.2.2.3 item b) uses the More
Data field to permit transition
into power-saving.
"a infrastructure"                 fix                         AGREE IN PRINCIPLE         EDITOR
                                                               (EDITOR: 2010-01-20
                                                               14:49:33Z) - Change to "an
                                                               infrastructure"
Review and remove               As in comment                  AGREE (EDITOR: 2010-01-20 EDITOR
unnecessary Editor's notes                                     14:54:42Z)
"c) On receipt of an ACK        Replace "on receipt of an Ack AGREE (GEN: 2010-01-21      EDITOR
frame that acknowledges the frame that acknowledges the 23:29:03Z)
DSE Enablement frame, issue DSE Enablement frame" with
an MLMEENABLEMENT.              "on receipt of a matching DSE
confirm primitive to inform the Enablement frame (i.e. the
SME of the result of the        Requester STA Address and
enablement.                     Responder STA Address
1) The primitive may contain    mach the pending request) "
information from an
enablement response             And replace start of d) "If no
message received from           acknowledgement" with "If no
the enabling STA (see           matching DSE Enablement
11.11.2.3 (Enablement           frame"
responder STA)), or it may be
issued for another
reason (see 7.4.7.3 (DSE
Enablement frame format))."

This is internally inconsistent.
Any Ack occurs before any
enablement response. As the
confirm needs to use
information from the
responding MMPDU, it can
only occur then.


Changes made in response to        On 240.34, reserve all but the AGREE (GEN: 2010-01-22   EDITOR
ballot LB149 tell us that          "Deenablement requested"       01:17:07Z)
primitives emitted on receipt of   status code.
an Ack frame are wrong. The        Delete 10.3.37.2
point is that we cannot            Change the bulleted list of
determine whether a frame          11.11.2.4 to read:
has been correctly received or
not (because it might be           "b) Create and transmit a DSE
received, but the ack is lost).    Deenablement frame to the
So any indication of transmit      deenablement responder STA.
failure may be incorrect.          1) Specific information items in
                                   the deenablement message
Any responding MMPDU               are as follows:
carries no intelligence, so a      i) Enabling STA identity
confirm primitive is               assertion (in
unnecessary. There is no           RequesterSTAAddress)
normative behaviour                ii) STA identity assertion (in
describing generation of a         ResponderSTAAddress)
response MMPDU.                    iii) Reason result code = 2
Compile the MIB and resolve     As in comment                     Agree in principle. Make the     EDITOR
any compilation errors                                            changes as shown in
                                                                  document 11-10/0216r2.




The equation 17-29 doesn't     Remove N_DBPS from the             AGREE (EDITOR: 2010-01-29 EDITOR
match the variable list that   variable list. Add variable list   14:13:13Z)
follows.                       entries for the other variables
                               (T_PREAMBLE, T_SIGNAL
                               and T_SYM) pointing to their
                               definitions.
In Clause 11, There's a lot of Review Clause 11 and correct       AGREE IN PRINCIPLE               EDITOR
variability in use of "or" and use of "and" and "or" as           (EDITOR: 2010-01-29
"and" in the phrase "MSDUs, A- described in the comment.          13:24:09Z) - As indicated and
MSDUs, or MPDUs".                                                 expand also MSDU/MPDU to
Generally it should be an "or"                                    include an "and" or an "or" as
when the singular is used                                         appropriate.
(where selection of one is
implied) and an "and" when
the plural is used (where
inclusion of all is implied).




There are two F.0a headings     Renumber second one               AGREE (EDITOR: 2010-01-20 EDITOR
                                                                  14:53:48Z)
Re CID 1704, there are             Change any such to "Radio        AGREE (EDITOR: 2010-01-27 EDITOR
occurances of "Radio               Measurement"                     15:43:08Z)
Resource Measurement" in
Tables 7-29 and 7-30.
It has been observed in            Insert the following new         AGREE IN PRINCIPLE            EDITOR
practice that the timing of the    paragraph and note at 331.20:    (SECURITY: 2010-03-17
MLME-SETKEYS.request from          The Authenticator/Supplicant     19:04:48Z)
the supplicant is critical and     should postpone the sending      Make changes as shown in 11-
subject to a race condition with   of encrypted data after          10/0314r0, which allow 2 keys
data encrypted using the new       receiving/sending Message 4      to be simultaneously be
keys.                              for a period of 20 ms.           allowed during rekeying.
If the authenticator and           NOTE--This gives the             4.7.2.
supplicant configure the           implementation time to install
temporal key at significantly      the new temporal key and
different times, data sent         avoid transmission of data
during this overlap period will    using a key that has not yet
be lost.                           been installed by the peer.
This can cause loss of
subsequent supposedly
encrypted EAPOL protocol
messages, which can result in
a damaged RSN association
state. Submission 11-
10/0018r0 describes this in
more detail.
If the 4-way handshake takes
place during rekeying, an
application that is sensitive to
MSDU loss (e.g. a video
stream) may expose the user
to temporary or permanent
loss of service.




A wildcard BSSID can also be Correct the text.                      AGREE IN PRINCIPLE (MAC: EDITOR
used in public action frames                                        2010-01-19 07:16:57Z) -
sent between BSSs. The text                                         Change "except for
does not so state.                                                  management frames of
                                                                    subtype Probe Request" to
                                                                    "except for management
                                                                    frames of subtype Probe
                                                                    Request or subtype Action".




"Add TS request" should be         Correct the text.                AGREE IN PRINCIPLE           EDITOR
"ADDTS request"                                                     (EDITOR: 2010-01-28
                                                                    12:05:55Z)
                                                                    Change end of cited sentence
                                                                    to read "...form of an ADDTS
                                                                    request frame."
I object to the changes made Revert to the text in 802.11mb-   AGREE IN PRINCIPLE (MAC: EDITOR
to this paragraph. There is no d1.0.                           2010-01-19 23:12:01Z) -
longer the means to send                                       Insert the following paragraph
unsolicited management                                         within clause 11.2.1.0a:
frames to STAs in power-save                                   "A bufferable management
state.                                                         frame is a unicast
                                                               management frame,
                                                               addressed to an associated
                                                               STA, of the following subtypes:
                                                               Action, Disassociation,
                                                               Deauthentication, or Probe
                                                               Response (when sent in
                                                               response to a unicast probe
                                                               request); or a group-
                                                               addressed management frame
                                                               of the following subtypes:
                                                               Action, Disassociation, or
                                                               Deauthentication. A bufferable
                                                               MMPDU is an MMPDU that will
                                                               be transmitted using a
                                                               bufferable management
                                                               frame."

                                                               Wherever "Action frame" is
                                                               used in clause 11.2.1, replace
                                                               with "bufferable management
                                                               frame". Wherever "MMPDU"
                                                               is used in clause 11.2.1,
                                                               replace with "bufferable
                                                               MMPDU." Make changes for
                                                               consistency or to remove and
                                                               do away with redundancy
                                                               following these changes.
I object to the changes made Revert to the text in 802.11mb-       AGREE IN PRINCIPLE (MAC: EDITOR
to this paragraph. There is no d1.0.                               2010-01-19 23:21:23Z) -
longer the means to send                                           Insert the following paragraph
unsolicited, group-addressed                                       within clause 11.2.1.0a:
management frames to STAs                                          "A bufferable management
in power-save state.                                               frame is a unicast
                                                                   management frame,
                                                                   addressed to an associated
                                                                   STA, of the following subtypes:
                                                                   Action, Disassociation,
                                                                   Deauthentication, or Probe
                                                                   Response (when sent in
                                                                   response to a unicast probe
                                                                   request); or a group-
                                                                   addressed management frame
                                                                   of the following subtypes:
                                                                   Action, Disassociation, or
                                                                   Deauthentication. A bufferable
                                                                   MMPDU is an MMPDU that will
                                                                   be transmitted using a
                                                                   bufferable management
                                                                   frame."

                                                                Wherever "Action frame" is
                                                                used in clause 11.2.1, replace
                                                                with "bufferable management
                                                                frame". Wherever "MMPDU"
                                                                is used in clause 11.2.1,
                                                                replace with "bufferable
                                                                MMPDU." Make changes for
                                                                consistency or to remove and
                                                                do away with redundancy
In the first sentence of the                                    AGREE these changes.
                                Revert to the text in 802.11mb- followingIN PRINCIPLE (MAC: EDITOR
paragrph, the text states that d1.0.                            2010-01-19 07:09:59Z).
"A QoS STA may be in PS                                         Change to "A non-AP QoS
mode before the setup of DLS                                    STA may be in PS mode..."
or Block Ack." This text is now
in error, because a QoS STA
includes an AP which can
never be in power-save mode.

The text indicates a STA uses    Provide guidance on how to        OUT OF SCOPE (MAC: 2010- EDITOR
TSPECs to change the u-apsd      set the other TSPEC fields for    01-22 01:26:14Z). This
trigger and delivery enabled     two situations:                   comment is not directed to
settings dynamically. The text   a) for an AC configured for       changed text in section
describes the bits used to       mandatory admission control--     11.2.1.4 in D2.0 or an
accomplish this, which are the   in this case, the TSPEC would     unsatisfied comment against
ASPD and Schedule subfields.     be expected to be used to         11.2.1.4 in LB149.
However, the text does not       request admission of a TS.
provide any guidance on how
to set the other TSPEC fields.   b) for an AC not configured for
                                 mandatory admission control--
                                 this this case, most of the
                                 TSPEC fields, other than
                                 TSID, UP, APSD and
                                 Schedule, would seem to be
                                 irrelevant.
The text states that "An AP   Add and align the text.               AGREE IN PRINCIPLE (MAC: EDITOR
shall, depending on the Power                                       2010-01-22 01:35:02Z).Insert
Management mode of the                                              the following paragraph within
STA, temporarily buffer                                             clause 11.2.1.0a:
MSDUs or MMPDUs that will                                           "A bufferable management
be sent in an Action frame                                          frame is a unicast
destined to the STA. An AP                                          management frame,
implementing APSD shall, if a                                       addressed to an associated
STA is using APSD and is in                                         STA, of the following subtypes:
PS mode, temporarily buffer                                         Action, Disassociation,
MSDUs or MMPDUs that will                                           Deauthentication, or Probe
be sent in an Action frame                                          Response (when sent in
destined to that STA."                                              response to a unicast probe
                                                                    request); or a group-
An AP may have the need to                                          addressed management frame
send a deauthentication or                                          of the following subtypes:
disassociation management                                           Action, Disassociation, or
frame to a non-AP STA in                                            Deauthentication. A bufferable
power-save state. The                                               MMPDU is an MMPDU that will
standard does not describe                                          be transmitted using a
how to deliver these frame                                          bufferable management
subtypes to the STA.                                                frame."

The P374L18 states                                                  Wherever "Action frame" is
"Management frames shall be                                         used in clause 11.2.1, replace
sent using the access category                                      with "bufferable management
AC_VO without being                                                 frame". Wherever "MMPDU"
restricted by admission                                             is used in clause 11.2.1,
control procedures." So if                                          replace with "bufferable
AC_VO is set for being                                              MMPDU." Make changes for
delivery enabled, then all                                          consistency or to remove and
management frames must be                                           do away with redundancy
delivered using APSD.
The text states, "The STA shall     Delete the word "Action" from   AGREE these changes.
                                                                    followingIN PRINCIPLE (MAC: EDITOR
remain awake until it receives      the cited sentence.             2010-03-16 17:43:07Z).
a QoS data frame or                                                 Change to ". . .until it receives
management Action frame                                             a QoS data frame or
addressed to it, with the EOSP                                      bufferable management frame
subfield in the QoS Control                                         addressed to it. . ." (this
field set to 1." What if the AP                                     change was effected for CID
needs to transmit another                                           2222).
management frame subtype
(e.g., Disassociation or
Deauthentication), why can't it
send it?
The text state, "The STA may        Delete the word "Action" from   AGREE IN PRINCIPLE (MAC: EDITOR
send additional trigger frames      the cited sentence.             2010-03-16 17:46:49Z).
if the More Data subfield is 1 in                                   Change to ". . .individually
downlink individually                                               addressed data or bufferable
addressed data or Action                                            management frames . . ." (this
frames that use delivery-                                           change was effected for CID
enabled ACs." What if the AP                                        2222).
needs to transmit another
management frame subtype
(e.g., Disassociation or
Deauthentication), why can't it
send it?
The text states "Unsuccessful Align the text and the figure.   AGREE IN PRINCIPLE (GEN: EDITOR
authentication sets the STA's                                  2010-03-12 14:15:23Z) See
state to State 1." However, in                                 CID 2111 for specific text
figure 11-6, if in states 3 or 4,                              changes: (from CID
the new state after                                            2111:AGREE IN PRINCIPLE
unsuccessful authentication is                                 (GEN: 2010-03-12
not state 1.                                                   13:27:33Z)Accept in principle.
                                                               Replace the second paragraph
                                                               in 11.3.1.0a with "Successful
                                                               authentication sets the STA's
                                                               state to State 2. Unsuccessful
                                                               authentication leaves the