--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Dear TGmc-inclined folks,
I have uploaded
https://mentor.ieee.org/802.11/dcn/15/11-15-0532-08-000m-revmc-sponsor-ballot-comments.xls, which
contains resolutions as approved at the F2F in sunny Hillsboro last week.
By now you’ve come to expect the ritual slaying of the statistics, and it would be churlish to disappoint.
The tables below show current status, editor’s comments for review, needs submission and assigned comments.
|
Owning Ad-hoc
|
Unassigned
|
Submission Required
|
Assigned
|
Discuss
|
Review
|
Resolution Drafted
|
Ready for Motion
|
Approved
|
Duplicate
|
Defer
|
Grand Total
|
|
EDITOR
|
|
27
|
16
|
9
|
5
|
538
|
5
|
106
|
28
|
1
|
735
|
|
ANA
|
|
|
|
|
|
2
|
|
|
|
|
2
|
|
Editorials
|
|
22
|
7
|
3
|
|
1
|
|
|
|
1
|
34
|
|
Style - value of
|
|
|
|
|
|
18
|
|
|
|
|
18
|
|
Style - value for
|
|
|
|
|
|
14
|
|
|
|
|
14
|
|
Style - for a
|
|
|
|
|
|
52
|
1
|
|
|
|
53
|
|
Style - 1.4
|
|
|
|
|
|
1
|
|
|
|
|
1
|
|
Style - contents of
|
|
|
|
|
|
2
|
|
|
|
|
2
|
|
Style - WNM-Notification
|
|
|
4
|
|
|
|
|
|
|
|
4
|
|
Style - Extensibility
|
|
|
4
|
|
|
|
|
|
|
|
4
|
|
Similar to CID 5308
|
|
|
|
|
|
119
|
|
|
|
|
119
|
|
Style - IEEE Std
|
|
|
|
|
|
3
|
|
|
|
|
3
|
|
Similar to CID 5837
|
|
|
|
|
|
3
|
|
|
|
|
3
|
|
Editorials - objected, submission-required
|
|
3
|
|
|
|
|
|
|
|
|
3
|
|
Editorials - rework
|
|
|
|
|
|
3
|
|
|
|
|
3
|
|
201505 approved
|
|
|
|
|
|
|
|
48
|
|
|
48
|
|
General
|
|
2
|
1
|
|
|
8
|
|
|
|
|
11
|
|
Editorials - for Ed_Q review
|
|
|
|
|
1
|
38
|
|
|
1
|
|
40
|
|
Editorials - for Ed_A review
|
|
|
|
|
|
1
|
|
|
|
|
1
|
|
Editorials - for Ed review
|
|
|
|
6
|
4
|
273
|
1
|
6
|
27
|
|
317
|
|
201506 approved
|
|
|
|
|
|
|
|
52
|
|
|
52
|
|
Motion Ed Hillsboro C
|
|
|
|
|
|
|
3
|
|
|
|
3
|
|
EDITOR_A
|
|
1
|
|
|
1
|
164
|
|
2
|
|
|
168
|
|
Editorials - rework
|
|
|
|
|
|
1
|
|
|
|
|
1
|
|
Editorials - for Ed_A review
|
|
1
|
|
|
1
|
163
|
|
2
|
|
|
167
|
|
EDITOR_Q
|
|
|
|
|
|
264
|
|
1
|
|
|
265
|
|
Editorials - for Ed_Q review
|
|
|
|
|
|
264
|
|
1
|
|
|
265
|
|
GEN
|
153
|
2
|
9
|
5
|
|
2
|
4
|
|
|
1
|
176
|
|
Definitions
|
16
|
|
|
|
|
|
|
|
|
|
16
|
|
Editorials
|
1
|
|
|
|
|
|
|
|
|
|
1
|
|
MIB
|
17
|
1
|
|
|
|
|
|
|
|
|
18
|
|
PICS
|
4
|
|
1
|
|
|
|
|
|
|
|
5
|
|
Terminology
|
15
|
|
2
|
|
|
|
|
|
|
|
17
|
|
Frame formats 8.4
|
1
|
|
|
|
|
|
|
|
|
|
1
|
|
Style
|
2
|
|
|
|
|
|
|
|
|
|
2
|
|
VHT PHY
|
34
|
|
|
|
|
|
|
|
|
|
34
|
|
PHY
|
38
|
|
|
1
|
|
|
|
|
|
|
39
|
|
PHY Service
|
2
|
|
|
|
|
|
|
|
|
|
2
|
|
Conventions
|
2
|
|
|
|
|
|
|
|
|
|
2
|
|
Insufficient Detail
|
5
|
1
|
3
|
|
|
|
|
|
|
|
9
|
|
DMG PHY
|
13
|
|
1
|
|
|
|
|
|
|
|
14
|
|
Annex E
|
|
|
1
|
|
|
|
|
|
|
1
|
2
|
|
RAC
|
2
|
|
|
1
|
|
1
|
|
|
|
|
4
|
|
TVHT PHY
|
1
|
|
|
|
|
|
|
|
|
|
1
|
|
GEN Discuss
|
|
|
|
3
|
|
1
|
|
|
|
|
4
|
|
Hillsboro-B
|
|
|
|
|
|
|
4
|
|
|
|
4
|
|
Assigned to Mark RISON
|
|
|
1
|
|
|
|
|
|
|
|
1
|
|
MAC
|
330
|
1
|
136
|
6
|
25
|
|
57
|
|
|
|
555
|
|
Editorials
|
6
|
|
11
|
2
|
|
|
|
|
|
|
19
|
|
Frame formats
|
26
|
|
2
|
2
|
|
|
|
|
|
|
30
|
|
Location
|
1
|
|
6
|
|
|
|
|
|
|
|
7
|
|
MAC operation
|
51
|
|
4
|
|
|
|
|
|
|
|
55
|
|
Power Saving
|
27
|
|
|
|
|
|
|
|
|
|
27
|
|
Security
|
1
|
|
28
|
|
3
|
|
|
|
|
|
32
|
|
Terminology
|
7
|
|
|
1
|
|
|
|
|
|
|
8
|
|
(blank)
|
50
|
|
4
|
|
|
|
|
|
|
|
54
|
|
MAC state machine
|
9
|
|
|
|
|
|
|
|
|
|
9
|
|
HCF
|
1
|
|
4
|
|
3
|
|
|
|
|
|
8
|
|
Layer management
|
13
|
|
1
|
|
|
|
|
|
|
|
14
|
|
Frame formats 8.4
|
48
|
|
4
|
|
|
|
|
|
|
|
52
|
|
MAC management
|
31
|
|
2
|
|
|
|
|
|
|
|
33
|
|
Synchronization
|
19
|
|
|
|
|
|
|
|
|
|
19
|
|
Mesh
|
6
|
|
|
|
|
|
|
|
|
|
6
|
|
Action Frames
|
|
|
20
|
|
1
|
|
|
|
|
|
21
|
|
Frame Control field
|
12
|
|
|
|
|
|
|
|
|
|
12
|
|
DCF & HCF
|
|
|
10
|
|
7
|
|
|
|
|
|
17
|
|
Interworking
|
3
|
|
1
|
|
5
|
|
|
|
|
|
9
|
|
General description
|
|
|
1
|
1
|
3
|
|
|
|
|
|
5
|
|
DMG operation
|
|
|
4
|
|
|
|
1
|
|
|
|
5
|
|
MAC Service
|
9
|
|
|
|
|
|
|
|
|
|
9
|
|
A-MPDU operation
|
|
|
1
|
|
3
|
|
|
|
|
|
4
|
|
DFS
|
1
|
|
15
|
|
|
|
|
|
|
|
16
|
|
TPC
|
9
|
|
1
|
|
|
|
|
|
|
|
10
|
|
VHT MAC
|
|
|
16
|
|
|
|
|
|
|
|
16
|
|
GCR
|
|
|
1
|
|
|
|
|
|
|
|
1
|
|
Editorials - objected, submission-required
|
|
1
|
|
|
|
|
|
|
|
|
1
|
|
Motion MAC-AP
|
|
|
|
|
|
|
56
|
|
|
|
56
|
|
Grand Total
|
483
|
31
|
161
|
20
|
31
|
968
|
66
|
109
|
28
|
2
|
1899
|
The editors have been hard at work reviewing the implementation of the non-contentious editorials.
|
Count of CID
|
Column Labels
|
|
|
|
Owning Ad-hoc
|
Not edited
|
Edited
|
Grand Total
|
|
EDITOR
|
309
|
322
|
631
|
|
ANA
|
2
|
|
2
|
|
Style - value of
|
11
|
|
11
|
|
Style - value for
|
14
|
|
14
|
|
Style - for a
|
52
|
|
52
|
|
Style - 1.4
|
1
|
|
1
|
|
Style - contents of
|
1
|
|
1
|
|
Similar to CID 5308
|
119
|
|
119
|
|
Style - IEEE Std
|
3
|
|
3
|
|
Similar to CID 5837
|
3
|
|
3
|
|
Editorials - rework
|
2
|
|
2
|
|
201505 approved
|
44
|
|
44
|
|
General
|
4
|
|
4
|
|
Editorials - for Ed_Q review
|
|
39
|
39
|
|
Editorials - for Ed review
|
2
|
283
|
285
|
|
201506 approved
|
48
|
|
48
|
|
Motion Ed Hillsboro C
|
3
|
|
3
|
|
EDITOR_A
|
4
|
78
|
82
|
|
Editorials - rework
|
1
|
|
1
|
|
Editorials - for Ed_A review
|
3
|
78
|
81
|
|
EDITOR_Q
|
|
265
|
265
|
|
Editorials - for Ed_Q review
|
|
265
|
265
|
|
Grand Total
|
313
|
665
|
978
|
We can discuss today, but I think it’s reasonable to post a D4.1 containing these edits prior to
Waikoloa.
The following Editorial comments need to be discussed in TGmc
|
comments editor discuss or review
|
|
CID
|
Owning Ad-hoc
|
Ad-hoc Status
|
Page
|
Clause
|
Comment
|
Proposed Change
|
Resolution
|
Ad-hoc Notes
|
Edit Status
|
Edit Notes
|
|
5235
|
EDITOR
|
Review
|
1709.21
|
10.21
|
page 1709 of body. Unclear. Apparently conflicting shalls on lines 21 and 24.
|
Change 1st sentence to: "When a STA joins a BSS, if Dot11OBCactivated is present, it shall set it to false."
|
REVISED (EDITOR_A: 2015-05-04 10:30:47Z) Change the cited sentence to "When a STA joins a BSS, it shall set dot11OCBActivated to false if it is present".
|
EDITOR: 2015-06-25 10:02:25Z -
Review requested as this is modifying a normative statement.
EDITOR_A: 2015-05-04 10:30:56Z
|
I
|
EDITOR: 2015-06-25 10:01:19Z- Reviewed.
Tag corrected. Comment set to review, as it is modifying a normative statement.
EDITOR_A: 2015-05-04 10:30:58Z
|
|
5308
|
EDITOR
|
Review
|
738.11
|
8.4.2.20.6
|
"The Channel Number field indicates": fields don't indicate things, but their values do.
|
Replace "The Channel" with "The value of the Channel". On line 17 replace "the Operating" with "the fields of the Operating". On line 22 replace "Randomization" with "The value of the
Randomization".
|
REVISED (EDITOR: 2015-05-26 13:46:41Z) - Replace para at 2.53 starting "When “field is” is used ..."
with the following:
' If represents a scalar field, scalar subfield, scalar parameter or scalar MIB attribute:
-- if " is" is used in a context that relates to the testing or setting the value of "" this usage should be interpreted as though written "the value of is"
-- " indicate(s)" should be interpreted as though written "the value of indicate(s)"
-- "indicated by " should be interpreted as though written "indicated by the value of "
-- " that indicate" should be interpreted as though written " whose values indicate"
If represents a frame, element, subelement, structured field, structured subfield, structured parameter or structured MIB attribute:
-- " indicate(s)" should be interpreted as though written "the contents of indicate".
-- "indicated by " should be interpreted as though written "indicated by the contents of "
-- " that indicate" should be interpreted as though written " whose contents indicate"
'
|
EDITOR: 2015-05-26 12:15:27Z - Resolution updated, based on Graham Smith's email.
EDITOR: 2015-05-01 15:17:05Z -
Is there objection to proceeding with extending 1.4 to cover the cases indicated by the comment?
No objection.
Also needs to be considered in the context of other comments on other structures. parameters, subfields. Elements / subelements might need separate treatment.
EDITOR: 2015-04-28 08:56:15Z - There are ~100 comments requesting insertion of "value of". We have previously inserted a convention in 1.4 to avoid the necessity of adding these words. If we still believe they are unnecessary, the comments should be rejected.
However the words in 1.4 might not cover all types of object cited in these comments, in which case 1.4 should be extended.
|
|
|
|
5357
|
EDITOR
|
Review
|
801.6
|
8.4.2.21.13
|
The values of the Civic Location Type field are 0, 1, etc., not "IETF RFC 4776-2006". Also, "-2006" is redundant, as that is the only version of RFC 4776 listed in Clause 2.
|
Replace "When the Civic Location Type is IETF RFC 4776-2006:" with "When the value of the Civic Location Type field is 0 (for 'IETF RFC 4776'):"
|
REJECTED (EDITOR: 2015-05-26 13:44:17Z) - The Civic Location Type field encoding does include the year number. So it is appropriate to quote it here.
The replacement of a "named value" by a numeric value, plus the name in parentheses, goes against the principle that the TG prefers of only defining the encoding in one place.
|
|
|
|
|
5536
|
EDITOR
|
Discuss
|
1637.23
|
10.8.4
|
The 10-line long sentence that makes up this paragraph is painful, if not worse. At least attempt to break it up into separate thoughts.
|
Replace:
"If the Beacon or Probe Response frame most recently received from an AP by a STA that is extended spectrum management capable and that has dot11SpectrumManagementRequired or
dot11RadioMeasurementActivated equal to true includes one or more Transmit Power Envelope elements, then the units"
with:
"Assume a STA is extended spectrum management capable and the value of its dot11SpectrumManagementRequired or its
dot11RadioMeasurementActivated attribute is true. If the Beacon or Probe Response frame most recently received by that STA from an AP includes one or more Transmit Power Envelope elements, then the units".
This same change is needed in the following long paragraph (starting on line 36) about mesh STAs.
|
|
EDITOR: 2015-05-28 15:01:28Z - I don’t like the "Assume". But I spent some time staring at this and got nowhere. Request a group discussion to come up with some ideas.
|
|
|
|
5994
|
EDITOR
|
Review
|
1970.29
|
11.6.2
|
In Figure 11-43, the number of reserved bits should be 14 instead of 6.
|
As suggested.
|
ACCEPTED (EDITOR_A: 2015-05-03 04:22:44Z)
|
EDITOR: 2015-06-23 12:56:47Z -
Review requested as this is making a technical change.
EDITOR_A: 2015-05-03 04:22:46Z
|
I
|
EDITOR: 2015-06-23 12:56:35Z- Reviewed. EDITOR_A: 2015-05-03 04:22:48Z
|
|
6160
|
EDITOR
|
Discuss
|
1344.44
|
9.22.4.2.3
|
From Guido Hiertz:The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations".
Accordingly, this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters
[...] are set in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols
for quantities, mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "admitted_time = admitted_time - dot11EDCAAveragingPeriod times (medium time of TSPEC)" contains variables that are neither abbreviations, constants, or functions. These variables
need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:48:29Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR_A: 2015-05-02 04:09:28Z
|
N
|
EDITOR: 2015-06-23 10:49:05Z- Reviewed. Rewrote resolution to a rejected.
|
|
6161
|
EDITOR
|
Discuss
|
1344.53
|
9.22.4.2.3
|
From Guido Hiertz:The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations".
Accordingly, this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters
[...] are set in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols
for quantities, mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "used_time = max((used_time - admitted_time), 0)" contains variables that are neither abbreviations, constants, or functions. These variables need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:50:42Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR_A: 2015-05-02 04:13:02Z
|
N
|
EDITOR: 2015-06-23 10:50:52Z- Reviewed. Rewrote as a rejected. EDITOR_A: 2015-05-02 04:12:51Z Implemented for CID 6851.
|
|
6193
|
EDITOR
|
Review
|
1157.34
|
8.6.13.4
|
It says "the TDLS Setup Response Action field contained an HT Capabilities element"
|
Change "Action field" to "frame" in the cited text
|
ACCEPTED (EDITOR_A: 2015-05-24 14:19:25Z)
|
EDITOR: 2015-06-23 10:10:34Z - Review requested. The change is technical.
|
I
|
EDITOR: 2015-06-23 10:10:00Z- Reviewed. This is a technical change. Needs review. EDITOR_A: 2015-06-05 10:52:37Z
|
|
6197
|
EDITOR
|
Review
|
1155.11
|
8.6.13.3
|
Some of the fields in Table 8-328---Information for TDLS Setup Response Action field are missing "and the Status Code is SUCCESS and is not present otherwise" (e.g. VHT Capabilities)
|
Add the cited text where missing
|
REVISED (EDITOR: 2015-06-23 10:07:18Z) - For "Link Identifier", "Multi-band", "AID" and "VHT Capabilities" rows append "and the Status Code is SUCCESS and not present otherwise" to their
Notes.
|
EDITOR: 2015-06-23 10:07:58Z -
Please review as proposed change contains technical changes.
EDITOR_A: 2015-05-26 15:04:34Z
|
I
|
EDITOR: 2015-06-23 10:07:31Z- Reviewed.
Setting ad-hoc status to "review" as this is a technical change.
EDITOR_A: 2015-06-05 10:52:32Z
|
|
6248
|
EDITOR_A
|
Review
|
105.06
|
|
4.5.4.9 "Action frames specified with "No" in the "Robust" column of Table 8-46 (Category values) are not robust Management frames and are not protected."; 11.1.7 "Action frames specified
with "No" in the "Robust" column of Table 8-46 (Category values) are not robust Management frames and shall not be protected."; 11.5.19 "Action frames with "No" in the "Robust" column in Table 8-46 (Category values) shall not be protected." -- duplication
is at best wasteful
|
Delete all but one of these instances (I suggest not keeping the one in Clause 4)
|
REVISED (EDITOR: 2015-06-10 13:18:56Z) - At 105.06, delete: "Action frames specified with “No” in the “Robust” column of Table 8-46 (Category values) are not robust Management frames
and are not protected."
At 1947.16, delete: "Action frames with “No” in the “Robust” column in
Table 8-46 (Category values) shall not be protected."
|
|
I
|
EDITOR: 2015-06-12 10:26:21Z- Review requested because the proposed resolution deletes a "shall not".
|
|
6282
|
EDITOR
|
Discuss
|
3378
|
L
|
It says "CRC32" (4 instances)
|
Change all 4 instances to "FCS", changing any preceding "a" to "an"; also delete "CRC 32" at 3407.40 and add "ITU-T" before "CRC-32" at 3493.37 and 3494.16
|
ACCEPTED (EDITOR_A: 2015-04-30 10:08:05Z)
|
EDITOR: 2015-06-24 12:45:13Z - For discussion.
The proposed changes have been edited. However, I question that we can reference ITU-T (implicitly V42) CRC-32 as added by the proposed change, but in 8.2.1 describe the FCS as an "IEEE 32-bit CRC", and define it in 8.2.4.8 without reference to anything else.
We should either be definitive ourselves (and not reference anybody), or normatively reference something else.
EDITOR_A: 2015-04-30 10:08:09Z
|
I
|
EDITOR: 2015-06-24 12:48:12Z- Reviewed.
Changes made as stated, but raised the comment to discuss status. See ad-hoc notes for rationale.
EDITOR_A: 2015-04-30 10:08:11Z
|
|
6348
|
EDITOR
|
Review
|
1330.3
|
9.22.2.7
|
It says "The bandwidth of a PS-Poll frame does not constrain the bandwidth of an immediate data response to that PS-Poll frame." -- it doesn't constrain the bw of a mgmt frame either
|
Change "data response" to "Management or Data frame response" in the cited text
|
ACCEPTED (EDITOR_A: 2015-05-02 00:52:30Z)
|
EDITOR: 2015-06-23 10:31:20Z -
While this is arguably editorial, because it is a change to a note, it does make a technical interpretation. Requesting review.
EDITOR_A: 2015-05-02 00:52:29Z
|
I
|
EDITOR: 2015-06-23 10:31:14Z- Reviewed. EDITOR_A: 2015-05-02 00:52:25Z
|
|
6584
|
EDITOR
|
Discuss
|
|
|
Is it really necessary to say "The Optional Subelements field format contains zero or more subelements, each consisting of a 1-octet
Subelement ID field, a 1-octet Length field, and a variable-length Data field, as shown in Figure 8-402. The
optional subelements are ordered by nondecreasing subelement ID.
The Subelement ID field values for the defined optional subelements are shown in Table 8-xxx. A Yes in the
Extensible column of a subelement listed in Table 8-xxx indicates that the Length of the subelement might be
extended in future revisions or amendments of this standard. When the Extensible column of an element is
equal to Subelements, then the subelement might be extended in future revisions or amendments of this
standard by defining additional subelements within the subelement. See 9.24.9." a million times? Won't someone *please* think of the children?
|
Say it once in some common place
|
REVISED (EDITOR: 2015-04-30 13:06:20Z) - Globally replace all paragraphs of the form: "The Optional Subelements field [format] contains zero or more subelements, each consisting of a
1-octet Subelement ID field, a 1-octet Length field, and a variable-length Data field, as shown in Figure 8-578 (Subelement format). Any optional subelements are ordered by nondecreasing subelement ID." with
"The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 8.4.3."
|
EDITOR: 2015-06-22 11:04:58Z - The identical statements have been identified (and edited). The two similar statements about TFS at 944.62 and 946.32 might be semantically different because
there is no statement about ordering by non-decreasing subelement ID. Was this likely to be be an omission, or an intentional difference?
|
I
|
EDITOR: 2015-06-22 11:02:26Z-
Reviewed OK.
EDITOR_A: 2015-06-22 04:32:56Z
|
|
6651
|
EDITOR
|
Discuss
|
880.27
|
8.4.2.55.2
|
It says "shall be"
|
Change to "is"
|
ACCEPTED (EDITOR_A: 2015-05-25 17:50:49Z)
|
EDITOR: 2015-06-22 15:48:11Z - Discuss, because this is turning a "shall be" into an "is", and
the result: "Reserved and is(#6651)set to 0 or 3 otherwise." makes no sense to me.
EDITOR_A: 2015-05-25 17:51:02Z
|
I
|
EDITOR_A: 2015-05-25 17:50:53Z
|
|
6696
|
EDITOR
|
Review
|
1042
|
8.4.2.157.3
|
It says "for transmission to a user" -- this is not clear
|
Add "given" before "user"
|
REVISED (EDITOR: 2015-06-23 09:30:15Z) - Delete "to a user" at cited location.
In reply to the comment, "given user" would be potentially misleading as this structure is about the device capabilities, and is independent of the capabilities of other devices.
|
EDITOR: 2015-06-23 09:34:22Z - Requesting review. It might be better to state "transmission to a single user" if "user" is felt to be necessary.
|
I
|
EDITOR: 2015-06-23 09:28:53Z- Reviewed. Rewrote resolution, as there is no "given" user. EDITOR_A: 2015-06-05 10:51:54Z
|
|
6843
|
EDITOR
|
Discuss
|
598.03
|
8.3.1.6
|
The equation "Duration = (i - 1) x (TXTIME(CF-End) + SIFS)" uses upright (roman) font. Equation X-32 on page 3600 in X.2.6, however, uses italic font. This is inconsistent. Clause 4.2
(Alphabets and typography) on page 3 of IEEE 260 explains that "The type families that are used for text in modern book and journal publishing all include sloping (italic) type faces and related upright (roman) type faces. The former are used for quantity
symbols; the latter, for unit symbols."
|
Comply with the rules set out in IEEE 260 and change the equation in 8.3.1.6 to use italic font for quantity symbols (i, Duration, TXTIME, SIFS).
|
REJECTED (EDITOR: 2015-06-22 14:34:32Z) - According to the IEEE Style guide, only the "i" is required to be italics.
|
EDITOR: 2015-06-18 12:08:43Z - I prefer we don't create inconsistencies with our own usage. I suspect the same issue obtain with many equations.
|
N
|
EDITOR: 2015-06-22 14:35:05Z- Reviewed. Rewrote resolution as a reject. EDITOR_A: 2015-05-25 17:16:40Z
|
|
6844
|
EDITOR
|
Discuss
|
3.01
|
1.5
|
This clause uses upright font for quantity symbols. This seems to comply with IEEE 260. Other equations in 802.11REVmc/D4.0 use upright font for quantity symbols. This is inconsistent.
|
I propose that no changes are applied to this clause. However, this clause should refer to IEEE Std 260.1-2004 to explain basic principles of mathematical notations.
|
|
Same as CID #6154
|
|
|
|
6848
|
EDITOR_A
|
Discuss
|
534.33
|
6.5.4.2
|
aTxPHYDelay, aRxTxSwitchTime, and aTxRampOnTime can assume different values. Following style guidelines this might be treated as an equation.
|
Replace upright font with italic font.
|
ACCEPTED (EDITOR_Q: 2015-05-31 22:30:35Z)
|
EDITOR: 2015-06-18 12:07:17Z - This is the thin end of the wedge. Do we also change all MIB variables in the text?
|
I
|
EDITOR_Q: 2015-05-31 22:30:38Z: Same as CID #6158
|
|
6849
|
EDITOR
|
Discuss
|
1344.35
|
9.22.4.2.3
|
The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations". Accordingly,
this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters [...] are set
in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols for quantities,
mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "admitted_time = admitted_time + dot11EDCAAveragingPeriod x (medium time of TSPEC)" contains variables that are neither abbreviations, constants, or functions. These variables
need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:46:07Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR_A: 2015-05-02 04:11:16Z
|
I
|
EDITOR: 2015-06-23 10:46:16Z- Reviewed. Rewrote resolution as a reject and undid edit. EDITOR_A: 2015-05-02 04:11:18Z
|
|
6850
|
EDITOR
|
Discuss
|
1344.44
|
9.22.4.2.3
|
The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations". Accordingly,
this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters [...] are set
in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols for quantities,
mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "admitted_time = admitted_time - dot11EDCAAveragingPeriod x (medium time of TSPEC)" contains variables that are neither abbreviations, constants, or functions. These variables
need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:48:29Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR: 2015-06-23 10:49:46Z - Copied from CID 6160
|
N
|
EDITOR: 2015-06-23 10:49:58Z- Reviewed. EDITOR_A: 2015-05-02 04:09:12Z
|
|
6851
|
EDITOR
|
Discuss
|
1344.53
|
9.22.4.2.3
|
The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations". Accordingly,
this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters [...] are set
in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols for quantities,
mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "used_time = max((used_time - admitted_time), 0)" contains variables that are neither abbreviations, constants, or functions. These variables need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:50:42Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR: 2015-06-23 10:52:47Z - Copied from CID 6161
|
N
|
EDITOR: 2015-06-23 10:53:03Z- Reviewed. Identified as duplicate. EDITOR_A: 2015-05-02 04:12:42Z
|
|
6852
|
EDITOR
|
Discuss
|
1344.53
|
9.22.4.2.3
|
The current 802.11 Style Guide in 802.11-09/1034r11 outlines in Clause 4.1 that the IEEE-SA Style Guide introduced "New material describing use of italics in equations". Accordingly,
this material can be found in the "2014 IEEE - SA Standards Style Manual" (https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf). Clause 12.4 in the IEEE - SA Standards Style Manual explains that "quantity letters [...] are set
in italic letters" and 15.3 (Presentation of equations) states "Some simple general rules apply. All variables are italic. [...] Quantity symbols (including the symbols for physical constants), subscripts or superscripts representing symbols for quantities,
mathematical variables, and indexes are set in italic text. Unit symbols, mathematical constants, mathematical functions, abbreviations, and numerals are set in upright (Roman) text." 802.11REVmc/D4.0 is inconsistent with these rules.
|
The formula "used_time = used_time + MPDUExchangeTime" contains variables that are neither abbreviations, constants, or functions. These variables need to be set in italics.
|
REJECTED (EDITOR: 2015-06-23 10:50:42Z) - IEEE-SA style guide 15.3 includes "Function names and abbreviations are Roman (sin, cos, sinc, sinh), as
are units or unit abbreviations (e.g., deg, Hz,) complete words (e.g., in, out), and abbreviations of words (e.g., max, min), or acronyms (e.g., SNR)."
All the terms in this equation are arguably "words", so no change is warranted.
|
EDITOR: 2015-06-23 10:53:32Z - Copied from CID 6162
|
N
|
EDITOR: 2015-06-23 10:53:37Z- Reviewed. Identified as duplicate. EDITOR_A: 2015-05-02 04:14:01Z
|
|
6853
|
EDITOR
|
Discuss
|
598.03
|
8.3.1.6
|
Compare the formating of "Duration = (i - 1) x (TXTIME(CF-End) + SIFS)" with G(x) in 8.2.4.8. In G(x) all variables are written in italics. In the present formula only i is written in
italics. However, Duration is variable too and thus should be written in italics too.
|
Use italic font for "Duration"
|
REJECTED (EDITOR: 2015-06-22 14:32:27Z) - According to the IEEE Style guide, only the "i" is required to be italics.
|
|
N
|
EDITOR: 2015-06-22 14:31:18Z- Reviewed. Rewrite resolution to a reject and undid editing. EDITOR_A: 2015-06-05 10:49:03Z
|
|
6854
|
EDITOR
|
Discuss
|
3436.44
|
L.5.2.3
|
Incorrect equation. The units in "88 + 168 = 256 bits" do not match.
|
Replace "88 + 168 = 256 bits" with "88 b + 168 b = 256 b"
|
REVISED (EDITOR_A: 2015-05-03 09:38:44Z) Revise the whole sentence as "The number of bits produced by the first codeword after zero stripping is 88 + 168 = 256,".
|
EDITOR_A: 2015-05-03 09:39:17Z
|
I
|
EDITOR: 2015-06-24 12:54:32Z- Reviewed. EDITOR_A: 2015-05-03 09:39:13Z
|
|
6855
|
EDITOR
|
Discuss
|
3436.44
|
L.5.2.3
|
Incorrect equation. The units in "152 + 168 = 320 bits" do not match.
|
Replace " 152 + 168 = 320 bits" with "152 b + 168 b = 320 b"
|
REVISED (EDITOR_A: 2015-05-03 09:41:46Z) Revise the sentence as "and the number of bits produced by each of the remaining 6 codewords is 152 + 168 = 320."
|
EDITOR_A: 2015-05-03 09:42:00Z
|
I
|
EDITOR: 2015-06-24 12:54:27Z- Reviewed. EDITOR_A: 2015-05-03 09:41:58Z
|
|
6856
|
EDITOR
|
Discuss
|
3436.45
|
L.5.2.3
|
Incorrect equation. The units in "256 + 6 x 320 = 2176 bits" do not match.
|
Replace "256 + 6 x 320 = 2176 bits" with "256 b + 6 x 320 b = 2176 b"
|
REVISED (EDITOR_A: 2015-05-03 09:44:38Z) Revise the sentence as "The total number of bits after LDPC encoding is 256 + 6 x 320 = 2176".
|
EDITOR_A: 2015-05-03 09:44:52Z
|
I
|
EDITOR: 2015-06-24 12:54:56Z- Reviewed. EDITOR_A: 2015-05-03 09:44:54Z
|
|
6857
|
EDITOR
|
Discuss
|
3435.29
|
L.5.2
|
Figure L-2. Incorrect equation. The units in "(5 + 6) x 8 = 88 bits" do not match.
|
Replace "(5 + 6) x 8 = 88 bits" with "(5 + 6) x 8 b = 88 b"
|
|
EDITOR: 2015-06-18 12:01:59Z - For discussion. We have plenty of "bits:" in figures, but I accept the correct text for "88 bits" is "88 b".
However, we do not require our equations to show units for their component parts. Otherwise the correct equation would be (5 B + 6 B) x 8 b/B = 88 b. I am not willing to create a style that implies any equation without full decoration of units is wrong in some
sense.
EDITOR_A: 2015-05-04 13:01:54Z
|
|
EDITOR: 2015-06-18 11:48:50Z - Rework required.
Original resolution: Change it as " = 88 bits ( (5 + 6) octets x 8 bits )
EDITOR_A: 2015-05-04 13:01:52Z
|
|
6858
|
EDITOR
|
Discuss
|
3445.12
|
L.6.3.2.3
|
Incorrect equation. The units in "10 080 + 224 = 10 304 bits" do not match.
|
Replace "10 080 + 224 = 10 304 bits" with "10 080 b + 224 b = 10 304 b"
|
REVISED (EDITOR_A: 2015-05-03 09:53:02Z) Revise the sentence as "the total number of bits is 10 080 + 224 = 10 304".
|
EDITOR_A: 2015-05-03 09:53:04Z
|
I
|
EDITOR: 2015-06-24 12:55:34Z- Reviewed. EDITOR_A: 2015-05-03 09:53:07Z
|
|
6859
|
EDITOR
|
Discuss
|
3463.29
|
L.8.3
|
Inconsistent formatting. The formulas on line 17 and 24 follow normal convention and use italic font. The equation on line 29, however, uses upright font.
|
Use italic font for the equation on line 29.
|
ACCEPTED (EDITOR_A: 2015-05-03 04:29:15Z)
|
EDITOR_A: 2015-05-03 04:29:51Z
|
I
|
EDITOR: 2015-06-24 13:07:45Z- Reviewed. EDITOR_A: 2015-05-03 04:29:27Z
|
|
6862
|
EDITOR
|
Discuss
|
3520.58
|
N.2.2
|
The preceding text announces a formula. However, the formula itself does not follow the formatting convention for equations.
|
Make equation consistent with formatting rules in IEEE 260. Use italic fonts e.g.
|
REJECTED (EDITOR: 2015-06-24 13:12:08Z) - The IEEE-SA Style guide states that words are set in Roman type.
|
EDITOR: 2015-06-24 13:12:33Z -
The change as proposed runs counter to the IEEE-SA style guide. However the use of "phrases as variable names" is also poor style. A "proper" treatment would be to define single-char + subscript variables and a where clause holding the explanatory phrases.
This should be done consistently through Annex N.
EDITOR_A: 2015-04-30 08:15:22Z
|
I
|
EDITOR: 2015-06-24 13:12:09Z- Reviewed.
Re-written as a reject, and edits unmade.
EDITOR_A: 2015-04-30 08:15:25Z
|
|
6863
|
EDITOR
|
Discuss
|
3521.02
|
N.2.2
|
Incorrect formatting and missing units.
|
Replace "8" with "8 b / 1 B" to account for the fact that the "Nominal MSDU Size" is measured in B (byte). Also follow conventions regarding formatting of equations.
|
REJECTED (EDITOR: 2015-06-24 13:17:02Z) - The IEEE-SA Style guide states that words are set in Roman type. It is not necessary to embed units in equations as proposed.
|
EDITOR: 2015-06-18 12:23:52Z - The proposed resolution is inadequate describing exactly what changes are necessary.
Also there lots of equations on this page, which are not given the same treatment.
So either we should fix them all, or fix none of them. And the fix should be described.
One such fix is to replace "multi word variable" with Single-character plus subscript abbreviation,
and then define in a where clause the expansion. This produces short equations that can unambiguouly meeting IEEE Style requirements.
EDITOR_A: 2015-04-30 08:02:41Z
|
N
|
EDITOR: 2015-06-24 13:17:38Z- Reviewed.
Rewrite resolution as a reject and undid edits.
EDITOR_A: 2015-04-30 08:02:39Z
|
|
6867
|
EDITOR
|
Discuss
|
1084.34
|
8.5.3
|
Is "SNR" in "4x(SNR-19)" a variable or an abbreviation? If "SNR" is treated as a variable, it should be put in italics
|
If SNR is treated as a variable set it in italics.
|
REJECTED (EDITOR: 2015-06-23 09:55:31Z) - SNR is an abbreviation and should therefore be upright. (The IEEE-SA style guide uses "SNR" as an example of an acronym that should be "Roman"
text.)
|
EDITOR: 2015-06-18 12:11:50Z - Resolution previously was "accepted", which is incorrect because commenter offers a choice.
|
N
|
EDITOR: 2015-06-23 09:55:36Z- Reviewed. Rewrote to reject and removed edit. EDITOR_A: 2015-05-24 14:28:34Z
|
|
6868
|
EDITOR
|
Discuss
|
1086.36
|
8.5.5
|
Does "RXSS Length" in "(RXSS Length+1)x2" denote a variable or an abbreviation? If "RXSS Length" denotes a variable, it should be set in italics.
|
Set "RXSS Length" in italics in case it is a variable.
|
REJECTED (EDITOR: 2015-06-23 09:58:22Z) - The IEEE-SA style guide states that whole words and abbreviations are upright.
|
EDITOR: 2015-06-18 12:12:45Z - Previous resolution was "accepted", which is incorrect because proposed change is conditional.
|
N
|
EDITOR: 2015-06-23 09:57:56Z- Reviewed. Missing resolution written as a reject. Edit undone. EDITOR_A: 2015-05-24 14:27:29Z
|
The following editorials need a volunteer to write a submission, or I will propose a reject:
|
comments editor discuss or review
|
|
CID
|
Owning Ad-hoc
|
Page
|
Clause
|
Comment
|
Proposed Change
|
Resolution
|
Ad-hoc Notes
|
Edit Status
|
Edit Notes
|
|
5038
|
EDITOR
|
|
|
The "Action field format" tables are inconsistent in their interpretation as to the meaning of the "Information" field. Either it names "a field" which might contain a field, an element,
or multiple of them. (e.g. the "Relay Status Code" field contains a Status Code); or the name of the field is absent, and it identifies the information that goes into it (e.g. "one or more elements").
|
Recommend that this be discussed and see if a simple fix to create a single interpretation is possible.
For example, to make the Information hold "[Name: ][field|element]".
This would entail adding missing when the information holds the definition of a new name, and adding field or element to every entry that does not have it.
Furthermore, many of these tables are followed by a list of "the xyz field is defined in ".
These could be combined into the table by moving the xref into the information column, e.g. in parens after field or element. So "Category" becomes "Category (8.4.1.11)". Or we could add a new column for that purpose. So, in 8.6.20.15, "Destination Status Code"
would become "Destination Status Code: Status Code field (optional)"
|
|
|
|
|
|
5160
|
EDITOR
|
|
General
|
In previous cycles we went to much effort to ensure every "802.11" was prefixed by IEEE Std.
From memory, I think we adopted this approach because it was the quickest, and time was of the essence.
In my opinion, such a prefix is unnecessary and unwieldy.
In D4 there are 90 instances of 802.11 without such prefixing, and 676 instances of 802.11 regardless of prefix.
This is inconsistent.
|
Either add the missing IEEE Stds, or change our policy and use IEEE Std 802.11 only when a reference to a document is being explicitly made.
(I prefer the latter).
|
REVISED (EDITOR: 2015-05-28 13:58:33Z) - Editor to review all occurances of "802", and enforce the following rules:
1. A reference to a standard has the prefix "IEEE Std"
2. Other occurrences have the prefix "IEEE"
Check that the first occurrence of IEEE 802.11 and IEEE Std 802.11 have a ™ in both the front-matter and the body.
Note to the editor, this is the same resolution as CID 6566.
|
EDITOR: 2015-05-28 11:39:03Z - Resolve with CID 6566
|
|
|
|
6120
|
EDITOR_A
|
8.49
|
3.1
|
This definition implies that BSS transition occurs because the STA changes location, which is not an actual requirement, as the transition could result from changes to the RF environment
or operational policy (e.g. load balancing).
|
Change the definition to "Transfer of association by a station (STA) from one BSS to another BSS in the same extended service set (ESS)."
|
|
EDITOR: 2015-06-17 22:55:53Z - previous resolution
REVISED (EDITOR: 2015-06-11 10:23:34Z) - At 8.48 replace "movement" with "transition".
EDITOR: 2015-06-11 10:22:44Z - I am not sure associations are transferred. A new instance of an association exists after the transfer. Propose using a "neutral" word - transition.
EDITOR_A: - I am not clear about the proposed change on "Transfer of association by a station". Need a discussion.
|
|
EDITOR: 2015-06-17 22:56:39Z -
rework required.
EDITOR: 2015-06-12 10:08:47Z
|
|
6127
|
EDITOR_A
|
11.41
|
3.1
|
This definition implies that ESS transition occurs because the STA changes location, which is not an actual requirement, as the transition could result from changes to the RF environment
or operational policy.
|
Change the definition to "Transfer of association by a station (STA) from one basic service set (BSS) in one ESS to another BSS in a different ESS."
|
|
EDITOR: 2015-06-17 22:58:11Z -
Previous resolution: REVISED (EDITOR: 2015-06-11 10:28:19Z) - At 11.49, replace "movement" with "transition"
DITOR: 2015-06-11 10:28:26Z - Similar to #6120.
|
|
EDITOR: 2015-06-17 22:57:53Z -
rework required
EDITOR: 2015-06-12 10:11:11Z
|
|
6128
|
EDITOR_A
|
11.53
|
3.1
|
This definition implies that fast BSS transition occurs because the STA changes location, which is not an actual requirement, as the transition could result from changes to the RF environment
or operational policy.
|
Change the definition to "Transfer of association by a station (STA) that is from one BSS in one extended service set (ESS) to another BSS in the same ESS and that minimizes the amount
of time that the data connectivity is lost between the STA and the distribution system (DS)."
|
|
EDITOR: 2015-06-17 22:58:56Z -
Previous resolution: REVISED (EDITOR: 2015-06-11 10:29:29Z) - At 11.53, replace "movement" with "transition"
EDITOR: 2015-06-11 10:29:33Z - Similar to #6120
|
|
EDITOR: 2015-06-17 22:58:41Z -
rework required
EDITOR: 2015-06-12 10:11:24Z
|
|
6198
|
EDITOR
|
|
|
It is not always stated explicitly in various locations that conditional things are not present if the condition is not met, i.e. some "and is not present otherwise" is missing
|
Add the cited text where missing
|
|
EDITOR: 2015-05-28 14:19:02Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
|
|
|
|
6215
|
EDITOR_A
|
|
|
Use "CS" rather than "carrier sense" except when defined etc.
|
Use "CS" rather than "carrier sense" at 74.14, 833.8, 1239.15, 1664.39, 1664.40, 3187.59 (2x), 860.43, 864.52, 1378.5, 1679.57, 2184.52, 2437.59
|
REJECTED (EDITOR: 2015-05-28 12:45:39Z) - The comment does not indicate a problem to be addressed. The use of this term does not create a problem.
|
|
N
|
2015-05-28
|
|
6216
|
EDITOR_A
|
|
|
The terms PHYCS and PHYED are defined but barely used
|
Delete them from subclause 3.4 and replace them in the other locations with their full-fat equivalents, i.e. physical CS and physical ED (4 instances each)
|
REJECTED (EDITOR: 2015-05-28 12:44:40Z) - These terms are useful in providing clarity to the discussion in 16.3.7.
|
|
N
|
2015-05-28
|
|
6237
|
EDITOR
|
|
|
The SAP primitive parameter names are inconsistent as to whether they have spaces or not
|
Be consistent (I suggest not having spaces, for contrast with frame contents)
|
|
|
|
|
|
6366
|
EDITOR
|
1884.56
|
11.3.5.4
|
"KCK || KEK" is not the way it's done anywhere else, and the inconsistency leads to unnecessary doubt
|
Change all other instances of extraction of subfields from a KDF to use the || formulation (I can provide a list of such instances)
|
|
EDITOR_A: 2015-05-03 09:48:52Z
|
|
|
|
6527
|
EDITOR_A
|
|
|
It sometimes says "STA in an ESS" and sometimes "STA in an infrastructure network" or "... BSS"
|
Be consistent. Reserve "STA in an ESS" to the cases which require a multi-BSS STA. Use "STA in an infrastructure BSS" (or "... network" -- see other comment) for other cases
|
REJECTED (EDITOR: 2015-04-30 13:46:21Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6529
|
EDITOR_A
|
|
|
It says "AP in an infrastructure BSS" or "... network" or "... ESS"
|
Delete "in an infrastructure *" in all cases
|
REJECTED (EDITOR: 2015-04-30 14:11:20Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6537
|
EDITOR
|
|
|
Use minuses not hyphens for subtraction and negative numbers
|
As it says in the comment
|
|
EDITOR: 2015-06-10 13:22:09Z - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined.
|
|
|
|
6539
|
EDITOR
|
|
|
There are still a bunch of desires (nearly 100), under the "desir" stem (desirable, desiring)
|
Change them in the same way as the CID 2051 resolution
|
|
EDITOR: 2015-06-10 13:22:26Z - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined.
|
|
|
|
6546
|
EDITOR
|
|
|
"the value $n", where "$n" is a number, can be compressed
|
Change all instances to "$n"
|
The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter
can be determined.
Furthermore the cited usage is not incorrect.
|
EDITOR: 2015-04-30 13:45:11Z - The global change as proposed results in many ungrammatical constructions.
|
|
|
|
6549
|
EDITOR_A
|
|
|
It says "_SAP" (about 33 instances)
|
Replace the underscore with a space in all of them
|
REJECTED (EDITOR: 2015-04-30 14:16:57Z) - X_SAP and X SAP are both valid and do not create any ambiguity. The former is used as a label for the SAP (usually on a figure showing an architecture).
The lattter names the SAP.
|
|
N
|
2015-05-28
|
|
6551
|
EDITOR
|
|
|
The subclause headings for xXVECTOR parameters are sometimes missing the "xXVECTOR" or "field" or have a spurious "PHY", e.g. in 16.2.3.5, 18.2.2.6, 18.2.3.4, 18.2.3.5, 18.3.4.3, 16.3.3.3,
16.3.4, 17.2.3.3, 17.2.3.7, 17.2.3.14, 17.2.4 ,18.3.5.5
|
Add the missing "xXVECTOR"s and "field"s, delete the spurious "PHY"s
|
REJECTED (EDITOR: 2015-04-30 13:56:23Z) - The cited locations are unambiuous.
|
EDITOR: 2015-04-30 13:56:47Z
The trouble here is different PHYs adopt different conventions, so the question is whether to go for local consistency or global consistency (e.g. inclusion of "PHY" and "field").
|
|
|
|
6552
|
EDITOR_A
|
|
|
We should not give length information both in text and in figures
|
Delete the length info in text and make the figures the sole source of info
|
REJECTED (EDITOR: 2015-04-30 13:27:29Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6553
|
EDITOR_A
|
|
|
Sexless double quotes
|
Make all sexless double quotes sexy, except those in code and in the MIB
|
REJECTED (EDITOR: 2015-04-30 13:23:21Z) - There
is no requirement in IEEE-SA style for quotes to follow any specific format.
|
|
N
|
2015-05-28
|
|
6567
|
EDITOR_A
|
|
|
Should the word "format" appear in IE figure captions? E.g. "Figure 8-85--DSSS Parameter Set element format" v. "Figure 8-94--ERP element"
|
Be consistent. Look at the list of figures and fix other inconsistencies (e.g. "fixed": "Timestamp field" v. "Dialog Token fixed field"). See ad-hoc notes for CID 135 for examples
|
REJECTED (EDITOR: 2015-04-30 13:14:45Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6573
|
EDITOR
|
2647
|
B.4
|
The PICS abbreviations are not helpful
|
Come up with some more useful abbreviations for the fundamental stuff, e.g. use "CF-IBSS" instead of "CF2.2" and "CF-HT" instead of "CF16"
|
|
EDITOR_A: 2015-05-11 22:00:27Z -
|
|
|
|
6579
|
EDITOR_A
|
|
|
"frame body" or "Frame Body" or "payload" or what?
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:09:09Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6580
|
EDITOR_A
|
|
|
The "ack policy" case is all over the place (ack/ACK/Ack all used, as are policy and Policy)
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:09:04Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6581
|
EDITOR
|
|
|
There should be a space before units
|
Make sure there is a (non-break) space between a number and its unit, except in identifiers, variables, etc. (I can provide a list of locations)
|
REJECTED (EDITOR: 2015-04-30 13:08:22Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
EDITOR: 2015-04-30 13:43:07Z - A submission is required. There is no obvious regex that identifes these with useful accuracy.
|
|
|
|
6582
|
EDITOR_A
|
|
|
The spec uses e.g. >= and the corresponding single glyph, with various degrees of popularity
|
Replace all uses with a single glyph, or (where impossible, e.g. in ASCII text) settle on one set, e.g. !=, >=, etc.
|
REJECTED (EDITOR: 2015-04-30 13:08:12Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6590
|
EDITOR_A
|
|
|
Some cross-references (to clauses, subclauses, figures, tables, etc.) are plain text, not real linked cross-references, which not only means they aren't "clickable" but means they do
not move or alert correctly as other things move or are deleted
|
Make sure all cross-references are real linked cross-references, not just plain text
|
REJECTED (EDITOR: 2015-04-30 12:55:46Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
Furthermore, comments on the metadata of the .pdf are out of scope.
|
|
N
|
2015-05-28
|
|
6597
|
EDITOR_A
|
|
|
Should a one-bit field be a Foo bit or a Foo (sub)*field?
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:09:17Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6598
|
EDITOR_A
|
|
|
Why is it sometimes Capabilities (Extended Capabilities IE, RM Enabled Capabilities IE, HT Capabilities IE, Capabilities field/subfield, HT Capabilities Info field, HT Extended Capabilities
field, TxBF Capabilities field, Timing Capabilities field, RSN Capabilities field) and sometimes Capability (Capability Information FF, Power Capability IE, QoS Capability IE, Nontransmitted BSSID Capability IE, QoS Traffic Capability IE, Capability-List AE,
TDLS Capability AE, QoS Traffic Capability Update frame)?
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:09:17Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6601
|
EDITOR_A
|
|
|
Sexless single quotes
|
Make all sexless double quotes sexy, except those in code and in the MIB and those introducing a non-decimal number
|
REJECTED (EDITOR: 2015-04-30 13:13:46Z) - There
is no requirement in IEEE-SA style for quotes to follow any specific format.
|
|
N
|
2015-05-28
|
|
6605
|
EDITOR_A
|
|
|
The space between a number and its unit should be a non-breakable one
|
Make them all NBSPs
|
REJECTED (EDITOR: 2015-04-30 13:38:41Z) - While the IEEE-SA style guide indicates this might be helpful, it does not make it a requirement.
|
|
N
|
2015-05-28
|
|
6608
|
EDITOR_A
|
|
|
There are lots of "Note that"s. Some appear to be normative (they are followed by a modal like "should") and some appear to be purely informative
|
Delete "Note that" before the normative ones and change "Note that" to "NOTE---" before the informative ones
|
REJECTED (EDITOR: 2015-04-30 13:37:05Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6620
|
EDITOR_A
|
|
|
Either always use dedicated glyphs (Unicode codepoints) for 1/2 etc. or never do so
|
As it says in the comment
|
REJECTED (EDITOR: 2015-04-30 13:47:52Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6621
|
EDITOR_A
|
|
|
Sometimes element/frame figures have "(optional)", sometimes not
|
Be consistent -- either always (when the field in question is indeed optional) or never
|
REJECTED (EDITOR: 2015-04-30 13:47:34Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6622
|
EDITOR_A
|
|
|
Don't use exp, use e
|
As it says in the comment
|
REJECTED (EDITOR: 2015-04-30 13:47:27Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6627
|
EDITOR_A
|
|
|
Instances of "multicast" in normal text (i.e. not field names etc.) should be "group addressed"
|
As it says in the comment
|
REJECTED (EDITOR: 2015-04-30 13:58:20Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6633
|
EDITOR_A
|
|
|
There is inconsistency as to the capitalisation and hyphenation of "self protected", "vendor specific", "vendor specific protected", "spectrum management", "fast session transfer", "radio
measurement"
|
Make the capitalisation and hyphenation consistent
|
REJECTED (EDITOR: 2015-05-01 10:53:19Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6659
|
EDITOR_A
|
|
|
Change "local policy" to "implementation-defined". Change "implementation-defined" to "outside the scope of this standard too"? Canonicalise "out of scope"/"out of the scope"/"beyond
the scope"/"outside the scope" and "scope for"/"of" etc.
|
As it says in the comment
|
REJECTED (EDITOR: 2015-05-01 11:01:58Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6661
|
EDITOR_A
|
|
|
"attribute values" in the context of PHY characteristics should be "characteristics".
|
As it says in the comment
|
REJECTED (EDITOR: 2015-04-30 14:30:48Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6673
|
EDITOR_A
|
|
|
Be consistent for "xXVECTOR XXX parameter" and "xXVECTOR parameter XXX" (latter seems more common).
|
As it says in the comment
|
REJECTED (EDITOR: 2015-04-30 14:26:48Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6686
|
EDITOR_A
|
|
|
"that the transmitter of this frame is providing to the destination of the frame" is a bit odd.
|
Make it sound less odd
|
REJECTED (EDITOR: 2015-04-30 14:19:03Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6693
|
EDITOR
|
560
|
8
|
"The X element/subelement/field/subfield is present in the Y frame/element/subelement/field/subfield" should be deleted. If it is not duplicated in the description of Y, then it should
be added to Y.
|
As it says in the comment
|
|
EDITOR: 2015-05-28 14:29:54Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
|
|
|
|
6694
|
EDITOR
|
560
|
8
|
Be consistent on whether to say "element" for rows in tables showing Action field formats
|
As it says in the comment
|
|
EDITOR: 2015-05-28 14:29:33Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
|
|
|
|
6715
|
EDITOR
|
|
|
The capitalisation of "operating class" is haphazard
|
Make it all-lowercase, except in field names etc.
|
|
EDITOR: 2015-05-01 10:55:42Z - There are 848 instances. Submission Required.
|
|
|
|
6716
|
EDITOR_A
|
|
|
Use Chinese characters or translation, not transliteration (see CID 3302)
|
As it says in the comment
|
REJECTED (EDITOR: 2015-05-01 11:09:08Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6718
|
EDITOR_A
|
|
|
Binary order in tables -- is the order clear enough? Also Tables 8-1, 8-2, 8-143, 9-17, 10-18, 16-8, 17-8, 17-9, 17-10, 17-11, 18-14, 18-15, 18-16, 23-4, 23-13 (references might be to
D3.0). Also some instances of "(binary)" but maybe not all?
|
As it says in the comment
|
|
|
N
|
2015-05-28
|
|
6723
|
EDITOR
|
|
|
Terms like "HT format PPDU" (including NON_HT, non-HT etc.) don't need the "format"
|
Delete the spurious "format"s throughout
|
|
|
|
|
|
6730
|
EDITOR
|
|
|
"VHT Capabilities element (optional). The VHT Capabilities element is present if the dot11VHTOptionImplemented is true" (multiple instances). Probably other spurious "Blah element (optionals)"
and also many spurious "the dot11"s (possibly acceptable for *Entry and maybe also *Table?). Also case of "the status code is SUCCESS" (should be Status Code).
|
Delete "VHT Capabilities element (optional)" in the cited text, and similarly in other places. Delete "the" before "dot11" and similarly in other places.
|
|
|
|
|
|
6731
|
EDITOR
|
|
|
It says "the status code is SUCCESS"
|
Change "status code" to "Status Code" throughout
|
|
EDITOR: 2015-05-01 11:18:30Z - The change does not address the issue that "Status Code" needs to be followed by field or parameter to indicate where it comes from. A consistent change
is necessary to all references to "status code" regardless of caps to highlight whether is a reference to the field contents or SAP parameter.
|
|
|
|
6741
|
EDITOR
|
|
|
Fix the case of "TIM Broadcast" (as for WNM-Sleep Mode under CID 3369).
|
As it says in the comment
|
|
EDITOR: 2015-05-28 11:52:57Z - Comment fails to identifty the locations to be changed.
|
|
|
|
6742
|
EDITOR
|
560
|
8
|
Behavioural stuff should not be in clause 8, it should be in a later clause.
|
As it says in the comment
|
|
EDITOR: 2015-05-28 14:29:13Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
|
|
|
|
6754
|
EDITOR
|
|
|
Table 9-17 should be moved to clause 8, somewhere near Table 8-34 [these might be D3.0 references]
|
As it says in the comment
|
|
EDITOR: 2015-05-28 12:29:33Z - The commenter is inexact about what should be moved, where it should be moved to, and doesn't indicate a reason.
|
|
|
|
6758
|
EDITOR_A
|
|
|
Add non-break space after , except for the pilot subcarriers and unitless contexts.
|
As it says in the comment
|
REJECTED (EDITOR: 2015-05-28 13:08:33Z) - There is no requirement by IEEE-SA style that this space exist.
|
|
N
|
2015-05-28
|
|
6766
|
EDITOR
|
1549.54
|
|
"A non-AP STA shall be in Active mode upon Association or Reassociation." appears before active mode has been introduced.
|
Add a forward reference
|
|
EDITOR: 2015-06-08 12:38:32Z -
Although the commenter has now indicated the location (1549.54) and reference (to 10.3), I don't see what benefit is gained from this. Leaving as "submission required" so somebody can argue this case.
EDITOR: 2015-05-28 13:12:12Z - Needs identification of an appropriate reference.
|
|
|
|
6771
|
EDITOR
|
|
|
A few "retry bit"s
|
Change all of them to "Retry bit"s
|
|
EDITOR: 2015-06-11 09:43:25Z - Needs submission. Some of these references are informal, some formal. The formal references should be changed to "Retry subfield", except where its location
as a bit is significant (in AAD construction).
|
|
|
|
6772
|
EDITOR_A
|
|
|
There is confusion between "Deny" and "Denied" status/result/reason codes
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:09:17Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
|
6773
|
EDITOR
|
|
|
"properly" (formatted, received, etc.) -- the spec should be written with the implicit understanding that things are done properly!
|
Delete "properly" throughout
|
|
EDITOR: 2015-06-11 09:43:36Z - A number of uses of "properly" are, indeed, proper. Needs submission.
|
|
|
|
6788
|
EDITOR
|
|
|
"bufferable" v. "buffered" -- there is confusion in these terms. Probably move to "buffered" for most cases
|
As it says in the comment
|
|
EDITOR: 2015-05-28 14:22:24Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
As far as I can tell there is a necessary difference between these terms, and I don't see obvious confustion.
|
|
|
|
6793
|
EDITOR
|
|
|
"FST" is an action, so what's an "FST session"?
|
Clarify
|
|
EDITOR: 2015-05-28 14:21:57Z - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined.
|
|
|
|
6795
|
EDITOR_A
|
|
|
Per the rejection of CID 3372, add "network" after all instances of "BSS" which do not already have it
|
As it says in the comment
|
REJECTED (EDITOR: 2015-05-28 14:20:29Z) - "network" is not necessary in this context. The resolution of the comment in the working group ballot established that "network" did no harm
after BSS, but not that it was necessary.
|
|
N
|
2015-05-28
|
|
6800
|
EDITOR
|
143
|
6
|
The type for parameters should not be "As defined in Foo element", just "Foo element".
|
As it says in the comment
|
|
EDITOR: 2015-06-11 10:50:52Z - Needs specific changes. Submission Required.
|
|
|
|
6807
|
EDITOR_A
|
560
|
8
|
"Table 8-162--RM Enabled Capabilities definition" has (a) lowercase "enabled"s in the Field name column and (b) missing articles in the Notes column and (c) inconsistency for "field"
v. "bit" v. nothing.
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:26:41Z) - The comment fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be
determined.
|
|
N
|
2015-05-28
|
|
6810
|
EDITOR
|
|
|
Identifiers don't really "name a" $something, they, well, identify them.
|
Change "name" to "identify"
|
|
EDITOR: 2015-06-11 09:44:09Z - Comment doesn't identify what is wrong, or what to change (there are 624 instances of "name").
|
|
|
|
6812
|
EDITOR
|
|
|
"OFDM"/"SC" "packets" should be "modulations".
|
As it says in the comment
|
|
EDITOR: 2015-05-28 14:04:58Z - The comment doesn't adequately identify what is wrong or provide a rationale.
|
|
|
|
6820
|
EDITOR_A
|
|
|
Why was "Gaussian" lowercased?
|
Restore the uppercase G throughout
|
REJECTED (EDITOR: 2015-05-28 13:15:40Z) - It was lower-cased because "Gaussian" is not a proper name, notwithstanding that it is derived from one.
|
|
N
|
2015-05-28
|
|
6832
|
EDITOR_A
|
143
|
6
|
Type is sometimes "MAC Address" and sometimes "MAC address".
|
Be consistent
|
REJECTED (EDITOR: 2015-04-30 13:26:03Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
|
|
N
|
2015-05-28
|
The following editor comments have an assignee:
|
comments editor assigned
|
|
CID
|
Owning Ad-hoc
|
Assignee
|
Page
|
Clause
|
Comment
|
Proposed Change
|
Resolution
|
Ad-hoc Notes
|
Edit Status
|
Edit Notes
|
|
5069
|
EDITOR
|
Adrian Stephens
|
652.08
|
8.4.1.7
|
The reason codes have been updated with a short name. This is not reflected in the ANA database.
|
Request the ANA to update the database to match the "Name" column values.
|
REVISED (EDITOR: 2015-06-09 12:36:33Z)
Editor to request 802.11 ANA to update database to reflect reason code names in the draft.
|
EDITOR_A: 2015-05-25 17:28:21Z
|
|
|
|
5077
|
EDITOR
|
Adrian Stephens
|
832.29
|
8.4.2.26
|
Request the ANA to allocate anything flagged with
|
As in comment
|
REVISED (EDITOR: 2015-06-09 12:51:29Z)
Editor to request allocations from the 802.11 ANA for any items flagged "" and replace such flags and delete related editorial notices once the allocations have been provided. Such action is to take place before the next ballot of this project.
|
|
|
|
|
5159
|
EDITOR
|
Adrian Stephens
|
|
General
|
The use of "binary" encoding is to be treated with suspicion because:
1. Bitstrings and binary representations are often confused - and their representations are very different
2. Quoting magic numbers in the body text should be minimized
|
Review all use of "binary". When used to define the encoding of an integer field, replace with decimal.
When used to either insert or test a value in an integer field, replace with either the decimal value, or (where possible) the name of the value, and introduce names for enumeration values if none exist.
|
|
|
|
|
|
5183
|
EDITOR
|
Carlos Aldana
|
1738.22
|
10.24.6.4
|
Replace "Burst Timeout" with "Burst Duration" in the Figure, as Burst Period is no longer defined. Do this for Figures 10-35 and 10-36 as well.
|
As in comment
|
REVISED (EDITOR: 2015-06-19 17:06:06Z) - Incorporate the changes in doc https://mentor.ieee.org/802.11/dcn/15/11-15-0687-01-000m-cids-5183-6778-resolution.docx
|
EDITOR_A: 2015-05-03 02:50:56Z
|
|
|
|
5249
|
EDITOR
|
Edward Au
|
80.37
|
4.3.16.1
|
WNM-Notification is a capability, not a frame, field, element, etc., so its name does not require initial caps. In addition, similarly to "U-APSD coexistence", this name does not need
a hyphen.
|
When "WNM-Notification" is part of the name of a frame, field, element, etc. replace it with "WNM Notification" throughout the draft. Otherwise (such as line 37), replace it with "WNM
notification" throughout the draft.
|
|
EDITOR: 2015-04-28 07:14:04Z - "etc." is not sufficient instruction to the editor. Needs submission. I agree the name does not need a hyphen.
|
|
|
|
5250
|
EDITOR_Q
|
Edward Au
|
80.37
|
4.3.16.1
|
Similarly to the name "U-APSD coexistence", "WNM-sleep mode" does not need a hyphen.
|
Replace "WNM-sleep mode" with "WNM sleep mode" throughout the draft.
|
REVISED (EDITOR_A: 2015-06-05 10:55:24Z) Replace "WNM-Sleep" with "WNM sleep" throughout the draft except when it is part of the nsame of a frame, field, etc., that replace "WNM-Sleep"
with "WNM Sleep".
|
EDITOR: 2015-04-28 07:16:47Z - This term forms part of the name of a frame and element. Global lower-casing is not appropriate.
|
I
|
EDITOR_Q: 2015-06-25 01:33:09Z - Reviewed
EDITOR_A: 2015-06-05 10:55:30Z Implemented for CID 5381.
|
|
5310
|
EDITOR
|
Edward Au
|
738.35
|
8.4.2.20.6
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
See cid 5311.
|
EDITOR: 2015-05-01 15:23:09Z - TGmc telecon. No objection to making change to all 37.
EDITOR: 2015-04-28 08:58:50Z - There are 37 instances of "Yes in the Extensible" column, of which the commenter cites two in comments. Either change them all or change none.
|
|
|
|
5311
|
EDITOR
|
Edward Au
|
738.37
|
8.4.2.20.6
|
What could it possibly mean to say: "When the Extensible column of an element is equal to Subelements, then the subelement might be extended ..."? What element has a column in it? When
is a column equal to one or more subelements? One might guess that the reference is to a column that has a "Subelement" entry in it; however, a search doesn't turn up any "Subelement" entry in a cell in a column named "Extensible" of any table in clause 7.
|
If the intent is to say that the subelement whose name is in the row that contains "Yes" in the column headed "Extensible" is itself extensible, then say that more clearly. Otherwise
delete this sentence.
|
Globally Replace text that is similar to this "A Yes in the Extensible column of a subelement listed in Table 8- indicates that the subelement might be extended infuture revisions or
amendments of this standard. When the Extensible column of an element is equal to Subelements, then the subelement might be extended in future revisions or amendments of this standard by defining additional subelements within the subelement. See 9.27.9 (Extensible
subelement parsing)."
TODO: make precise & find other comments related.
with
"The interpretation of the "Extensible" column is defined in 9.27.9."
|
EDITOR: 2015-05-01 15:32:41Z - No objection to:
Globally Replace text that is similar to this "A Yes in the Extensible column of a subelement listed in Table 8- indicates that the subelement might be extended infuture revisions or amendments of this standard. When the Extensible column of an element is equal
to Subelements, then the subelement might be extended in future revisions or amendments of this standard by defining additional subelements within the subelement. See 9.27.9 (Extensible subelement parsing)."
TODO: make precise & find other comments related.
with
"The interpretation of the "Extensible" column is defined in 9.27.9."
EDITOR: 2015-05-01 15:32:31Z - Another comment says we shouldn't be repeating this thing over and over. There are ~37 instances of this text, and the commenter cites a couple.
For discussion: move the definition of "extensibility" to a subclause where the structure of a subelement is described. We can then put some effort into cleaning the text up.
|
|
|
|
5318
|
EDITOR
|
Edward Au
|
741.39
|
8.4.2.20.7
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
|
Resolve with CID 5311.
|
|
|
|
5319
|
EDITOR
|
Edward Au
|
741.41
|
8.4.2.20.7
|
What could it possibly mean to say: "When the Extensible column of an element is equal to Subelements, then the subelement might be extended ..."? What element has a column in it? When
is a column equal to one or more subelements? One might guess that the reference is to a column that has a "Subelement" entry in it; however, a search doesn't turn up any "Subelement" entry in a cell in a column named "Extensible" of any table in clause 7.
|
If the intent is to say that the subelement whose name is in the row that contains "Yes" in the column headed "Extensible" is itself extensible, then say that more clearly. Otherwise
delete this sentence.
|
|
EDITOR: 2015-05-28 11:43:46Z - Resolve with CID 5311.
|
|
|
|
5693
|
EDITOR
|
Edward Au
|
1767.51
|
10.24.17
|
What is the difference between "WNM-Notification and WNM notification? If there is no difference in function, then replace the name "WNM-Notification" with "WNM notification".
|
Replace: "WNM-Notification" with "WNM notification" throughout the text, except when it is part of the name of a frame, field, etc. and it uses initial caps: "WNM Notification".
|
|
The hyphen can be removed without issue. There are about 15 instances of WNM-Notification that should become WNM notification. And some capitalization that needs to be adjusted after
WNM-Notification. There is at least one other editorial comment on this topic.
|
|
|
|
5694
|
EDITOR
|
Edward Au
|
1767.57
|
10.24.17
|
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the
WNM-Notification Enabled field of the Extended Capabilities element to 1.": see the comments on 1536.37; the same problems dominate here (including using initial caps on the capability's name).
|
Replace:
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the WNM-Notification Enabled field of the Extended Capabilities element to
1."
With:
"A STA whose dot11WNMNotificationActivated value is true shall support WNM notification and shall set to 1 the WNM-Notification field of the Extended Capabilities elements that it transmits."
|
REVISED (EDITOR: 2015-04-28 12:46:05Z) - Replace:
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the WNM-Notification Enabled field of the Extended Capabilities element to
1."
With:
"A STA whose dot11WNMNotificationActivated is true shall support WNM notification and shall set to 1 the WNM-Notification field of the Extended Capabilities elements that it transmits."
|
EDITOR: 2015-06-08 13:21:28Z - Making Assignee Edward, to handle with global changes to the terminology.
|
|
|
|
5695
|
EDITOR
|
Edward Au
|
1768.08
|
10.24.17
|
"WNM-Notification capability": this is not the name of a frame, field, element, etc., so it does not need initial caps.
|
On line 8 replace "WNM-Notification" with "WNM notification".
|
REVISED (EDITOR: 2015-05-28 14:38:59Z) - Editor to review all uses of "WNM-Notification" and change to "WNM notification" except when followed by "Request frame" or "Response frame".
|
EDITOR: 2015-06-08 13:21:28Z - Making Assignee Edward, to handle with global changes to the terminology.
|
|
|
|
5773
|
EDITOR
|
Edward Au
|
2212.14
|
17.3.1
|
"PHY_CCA", "PHY_RXEND", "PHY_DATA" and "PHY_RXSTART": there are no such primitives.
|
Throughout the draft, including all of the related figures, replace "PHY_CCA" with "PHY-CCA", replace "PHY_RXEND" with "PHY-RXEND", replace "PHY_DATA" with "PHY-DATA", and replace "PHY_RXSTART"
with "PHY-RXSTART". It might be possible to search and replace "PHY_" with "PHY-" univarsally (but that still requires manual labor with the figures).
|
|
EDITOR: 2015-04-29 13:20:16Z
The following are instances of the misspelled primitives not in figures:
A.indication PHY_RXEND.indication (No_Error) PHY_CCA.indication (IDLE) Decremen
ble Receive the SIGNAL RX IDLE State CS/CCA or PHY_CCA Parity Fail PHY_CCA and PHY-CCA.indication(IDL
or supported mode Setup PSDU RX Set Length Set PHY_RXSTART .indication (RXVECTOR) RX Symbol Decode Symbo
for Signal Extension RX IDLE state CS/CCA Set PHY_CCA.indication(BUSY) HT_SIG (GF preamble) L-SIG (MF or non-HT pream
-SIG: Refer to 17.3.12 or 19.3.6 CRC Fail: Set PHY_RXEND .indication (FormatViolation) CRC OK Carrier
nal Length >0 Length=0 Time=0 End of Wait Set PHY_CCA. indication(IDLE) when receive level drops belo
ow threshold (missed preamble) End of Wait Set PHY_CCA .indication(IDLE) when receive level drops bel
e type Supported Preamble Unsupported mode: Set PHY_RXSTART .indication (RXVECTOR) then set PHY_RXEND .i
et PHY_RXEND .indication(Unsuppor tedRate) Set PHY_RXEND .indication(CarrierLost) Carrier Lost Set PHY_
RXEND .indication(CarrierLost) Carrier Lost Set PHY_RXEND .indication (CarrierLost) For unsupported mod
End of Wait For Reserved HT-SIG Indication: set PHY_CCA .indication(IDLE) when receive level drops bel
XEND .indication (RxEndStatus) End of Wait Set PHY_CCA .indication(IDLE). Set PHY_RXEND .indication
58 59 61 Figure 21-19—PHY transmit procedure PHY_TXSTART.request(TXVECTOR) MPDU Scrambling + encoding PHY_TXSTART.confirm
ted mode Setup PSDU RX Set N_symbols = NSYM Set PHY_RXSTART.indication (RXVECTOR) RX Symbol Decode Symbol Decode and
CCA.indication (IDLE) RX IDLE state CS/CCA Set PHY_CCA.indication(BUSY,primary) HT_SIG (HT GF preamble): Refer to 20.3.23 L-SI
Not VHT-SIG-A: Refer to 18.3.12 CRC Fail: Set PHY_RXEND.indication (FormatViolation) CRC OK Carrier lost Valid Si
d VHT-SIG-A Indication and Invalid L-LENGTH: Set PHY_RXEND.indication (FormatViolation) NOTE—This state machine does
as LDPC, STBC or partial AID. Carrier Lost: Set PHY_RXEND.indication (CarrierLost) Carrier Lost: Set PHY_RXEND.indi
XEND.indication (CarrierLost) Carrier Lost: Set PHY_RXEND.indication (CarrierLost) For unsupported modes, Reserved
TIME has elapsed. End of Wait Parity Fail: Set PHY_RXEND.indication (FormatViolation) RX VHT-SIG-B RX Supported m
fer to 20.3.23 Not HT-SIG Unsupported mode: Set PHY_RXSTART.indication (RXVECTOR) then set PHY_RXEND.indication (Unsu
Set PHY_RXSTART.indication (RXVECTOR) then set PHY_RXEND.indication (UnsupportedRate) Determine if PPDU is filtere
|
|
|
|
6154
|
EDITOR
|
Guido Hertz
|
3.01
|
1.5
|
From Guido Hiertz:This clause uses upright font for quantity symbols. This seems to comply with IEEE 260. Other equations in 802.11REVmc/D4.0 use upright font for quantity symbols. This
is inconsistent.
|
I propose that no changes are applied to this clause. However, this clause should refer to IEEE Std 260.1-2004 to explain basic principles of mathematical notations.
|
REJECTED (EDITOR: 2015-06-16 12:28:16Z) - The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording
of the changes that will satisfy the commenter can be determined.
Note that another of the commenters comments, introduces a normative resference to IEEE Std 260.1-2004 in Clause 2.
|
EDITOR: 2015-06-16 12:29:47Z - Nothing to do for this comment. The reference is introduced by CID 6845.
|
|
|
|
6313
|
EDITOR
|
Carlos Aldana
|
|
|
The editorial improvements made to FTM should where appropriate be made to TM
|
As it says in the comment
|
|
|
|
|
|
6319
|
EDITOR
|
Peter Ecclesine
|
|
|
The behavior limits sets identified in Annex E are no longer so identified by number, just by name, so using the numbers elsewhere is just needlessly confusing
|
Change from numbers to words on p. 666 (4x), 890 (2x), 891 (4x), 1649 (2x), 1694 (4x), 3352. Delete the Encoding column in Table D-2
|
|
EDITOR: 2015-05-28 12:12:33Z - Do we want to do this? If so, will require a submission.
|
|
|
|
6376
|
EDITOR
|
Mark Rison
|
1593
|
10.3.5
|
There are numerous editorial and consistency issues with the description of the AP/PCP (re)assoc receipt procedures
|
I will propose text (not possible to give here)
|
|
EDITOR_A: 2015-05-02 01:11:09Z Need submission from Mark Rison.
|
|
|
|
6707
|
EDITOR
|
Adrian Stephens
|
|
|
Stop constantly repeating the stuff about "Extendable" "Yes" and "Subelements"!
|
As it says in the comment
|
REVISED (EDITOR: 2015-06-19 21:35:14Z) - Incorporate changes in https://mentor.ieee.org/802.11/dcn/15/11-15-0758-01-000m-sb0-stephens-resolutions-part-1.doc
|
EDITOR: 2015-05-28 10:52:04Z - I agree with the sentiment of the comment.
|
|
|
|
6713
|
EDITOR
|
Adrian Stephens
|
|
|
There are instances of "Probe Response" without a following "frame"
|
Append "frame" or make all-lowercase, throughout
|
|
|
|
|
|
6728
|
EDITOR
|
Edward Au
|
|
|
"the Sleep Mode element" needs "WNM-" added (and s lowercased). Sometimes "elements", which is suspect. Also follow-ons, e.g. references to "Sleep Mode Request" frames.
|
As it says in the comment
|
|
|
|
|
|
6733
|
EDITOR
|
Mark Rison
|
|
|
Ref. to "8.4.2.21.10" in new BSSID stuff -- caption does not say "LCI report" nor "Location configuration information" nor "field" etc.
|
I will propose text once I've worked out what I was going on about
|
|
|
|
|
|
6778
|
EDITOR
|
Carlos Aldana
|
1734
|
10.24.6
|
Fix the FTM figures to follow normal style (no colours, nice fonts, etc.)
|
As it says in the comment
|
REVISED (EDITOR: 2015-06-19 17:06:32Z) - Incorporate the changes in doc https://mentor.ieee.org/802.11/dcn/15/11-15-0687-01-000m-cids-5183-6778-resolution.docx
|
EDITOR_A: 2015-05-03 02:52:10Z
|
|
|
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile)
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
|