July 2014 doc.: Ieee 802. 11-14/780r2 ieee p802. 11


Trivial Technical comments (owned by EDITOR)



Yüklə 288,8 Kb.
səhifə3/5
tarix04.05.2017
ölçüsü288,8 Kb.
1   2   3   4   5

Trivial Technical comments (owned by EDITOR)





CID

Page

Clause

Comment

Proposed Change

3361







Mostly the spec says "the defined optional subelements" but in a couple of places it omits "optional" (4 instances)

Is the point that at least one of the subelements is required? If so, some of the subelements (e.g. VSSEs) are still optional, so the wording is still inconsistent -- just add "optional"

Discussion:

It is unnecessary to indicate that subelements are optional more than once, which the phrase “the defined optional subelements” does.

I checked, and in every case, this phrase relates to a subfield called “Optional subelements” and follows: “The Optional Subelements field contains zero or more subelements,”


Proposed resolution:

Revised. Globally change “the defined optional subelements” to “the defined subelements”.

At 1170.31 change “field format contains” to “field contains”.



3341







Still some "may not"s (3 instances)

Change to "shall not" or "might not" as appropriate

Discussion:

“may not” is deprecated because most, but not all, will interpret it to mean “shall not”. There’s one “may not” in the boilerplate, which we can’t touch. But we can fix the others.
At 1721.51:

The initial Fine Timing Measurement frame may might or may might not have captured timestamps.

At 1757.04:



the external network and the Advertisement Server, a query response from the Advertisement Server mightmay or mightmay not be dependent on the BSSID used in the GAS frame exchange sequence

At 1849.07:



WEP implementations shall discard the MSDU and generate an MA-UNITDATA-STATUS.indication primitive with transmission status indicating that a frame may shall not be encapsulated with a null key in response to any request to encapsulate an MPDU with a null key.

Proposed resolution:

Revised. Make changes in under CID 3361.



3399

2.59

1.5

What if y is negative?

Add "this operator is not used in this Standard if y is negative" (assuming that's true, otherwise explain exactly how it works)

Proposed Resolution:

Revised. At 2.60 after “equal to x” insert “; this form is defined only for y > 0.”



3398

2.59

1.5

There should be an example for Ceil(x,y). Oh, and a space before the opening paren

Give examples (including negative x) and add space

Proposed Resolution:

Revised.


Insert space as indicated.

Insert at end of cited para: “For example, Ceil (2.3, 2) is 4 and Ceil (-2.3, 24) is -2.”




3104

559.26

8.2.4.4.2

"Each MSDU, A-MSDU, or MMPDU transmitted by a STA is assigned a sequence number. See 9.3.2.12
(Duplicate detection and recovery)."

Every thing that is transmitted in 802.11 is transmitted by a STA. So the qualification "transmitted by a STA" is unnecessary.



Delete "transmitted by a STA".
Review all "transmitted by a STA" and remove any unnecessary occurences.

Proposed Changes:

At cited location delete “transmitted by a STA”.
At 1074.04 change:

The Measurement Report frame uses the Action frame body format and is transmitted by a STA in response to a Measurement Request frame or by a STA transmitted autonomously providing measurement information.

At 1074.62:



The TPC Report frame uses the Action frame body format and is transmitted by a STA in response to a TPC Request frame.

Similar change at 1092.18, 1093.34, 1095.20, 1150.20, 1151.43, 1155.39
At 1099.19:

The DSE Enablement frame is an Action frame. It is transmitted by a STA as part of enablement. The format of the DSE Enablement frame Action field is shown in Figure 8-633 (DSE Enablement frame Action field format).

At 1102.26:



The DSE Measurement Request frame is a Public Action frame requesting a DSE measurement report. It is transmitted by a STA using the procedures defined in10.12 (DSE procedures).

Similar change at 1103.07, 1117.45, 1118.11,
At 1149.18:

The Event Report frame uses the Action frame body format and is transmitted by a STA in response to an

Event Request frame, or autonomously


At 1157.51:



The Collocated Interference Request frame uses the Action frame body format and is transmitted by a STA to request collocated interference reports, sent using Collocated Interference Report frames.

At 1259.09:



A STA that transmits Any a group addressed MPDUs in which the To DS field is 1 transmitted by a STA shall, in addition to conforming to the basic access procedure of CSMA/CA, obey the rules for RTS/CTS exchange and the Ack procedure because the MPDU is directed to the AP.

At 1328.19:



An STA shall transmit an ADDTS Request frame shall be transmitted by a STA to the HC in order to request admission of traffic in any direction (i.e., uplink, downlink, direct, or bidirectional) employing an AC that requires admission control.

At 2348.45:



The receiver shall be able to decode a packet that was transmitted by a STA with a RIFS separation from the previous packet.


Proposed resolution:

Revised. Make changes in under CID 3104.




3066

583.10

8.2.6

The insertion from .11af could find a better home.

Move 8.2.6 to 8.4.x

Discussion.

The TLV encodings are a new type of variable-content management field. As such, I think they are similar to elements. Moving them to 8.4.4 positions them before application-specific structures. (It is arguable whether they are a generic mechanism, or intended to be specific to TVHT).
Proposed resolution:

Revised. Move 8.2.6 to become 8.4.4 and renumber 8.4.4 to become 8.4.5 etc….





3070

699.14

8.4.1.55

"The Length field" -- struggle as I might, I fail to locate cited field in the structure.

Remove cited sentence.

Proposed Resolution:

Revised.


Delete paragraph at 699.14.
Note to editor, this text is also deleted in response to CID 3069.



3354

718.59

8.4.2.10

Ref should be to 10.1.4.3.5

As it says

Discussion:

After the reorganization in Draft 3, 10.1.4.3.5 now contains the text that indicates how to respond to a Request element.


Proposed Resolution:

Accepted




3073

758.15

8.4.2.20.19

Subelement IDs are separate namespaces for each element, and in the case of measurement reports, report type. The reference is to a table in a different report is wrong.

Replace with reference to Table 8-114.

Context:



Proposed resolution:

Accepted.





3075

760.27

8.4.2.21.1

Is the Fine Timing Measurement Range report used for "Radio measurement, spectrum management"?

Remove at least ", spectrum management"


Proposed Resolution:

Revised. At cited location remove ", spectrum management".





3425

782.36

8.4.2.21.10

The description of the RegLoc Agreement field has been lost

Put it back in

Discussion:

This was lost as an unintended side effect of recent edits.
Proposed resolution:

At 782.36 insert:

“The RegLoc Agreement field is set to 1 to report that the STA is operating within a national policy area or an international agreement area near a national border (see 10.12.3 (Registered STA operation)); otherwise, it is 0”



3201

805.46

8.4.2.21.18

In P805, L7, the length of Range Entry field format in Figure 8-245 is 15 octets but Range entry in Figure 8-244 is 16 octets. They should be consistent (removing reserved octet in Figure 8-245, and change Range Entry length to 14?).

Removing reserved octet in Figure 8-245, and change Range Entry length to 14.

I agree with the proposed change, however, it is not “trivial technical” as it makes a change in OTA signalling.


Status: Propose this be assigned to Brian Hart and be classified as “Location”.


3130

839.51

8.4.2.30

PCP means "PBSS Control Point" in 802.11.

Expand "PCP" to ""Priority Code Point".


Proposed resolution:

Revised. At 839.33, delete “PCP;”. At 839.41 and 839.51 change “PCP” to “Priority Code Point”.

Also insert “802.1Q” in front of PCP, CFI and VID at 839.51-839.56.



3343

849.25

8.4.2.36

"TSF counter" (also at 3023.11)

"TSF value" for consistency with everywhere else


Proposed resolution:

Revised. Replace “TSF counter” with “TSF timer” at cited locations (2 locations).




3495

986.04

8.4.2.121

Table 8-229 (SCS Request Type definitions) has a column labeled Usage mode, which isn't a term connected to anything. This appears to just be a list of the values that appear in the Request type field.

Change "Usage mode" to "Value"

Proposed resolution:

Accepted.





3106

999.46

8.4.2.129

Field names that include an embedded abbreviation of themselves are plain weird.
They are also confusing when the text refers to the field using only some of that field name, giving rise to the confusion as to whether the reference is to an internal working variable, or is a reference to the value of a field in some received frame.

Remove (Ntaps) and (Nmeas) from the field names. Change any references to the value of these fields from the abbreviated form to the full field name.


Proposed resolution:

Revised.


At 999.46, delete “(Ntaps)”

At 999.52, delete “(Nmeas)”

At 1489.38, add “—Nmeas: the value of the Number of Measurements subfield of the FBCK-TYPE field”


3010

1045.46

8.4.2.169

"TBTT Offset in TUs" -- It is odd to encode the encoding of a field into its name.

Replace with "TBTT Offset" globally, or perhaps "Neighbor AP TBTT Offset" if the name collision with the DMG BSS Parameter Change element is considered significant.


Proposed Resolution:

Revised. Globally replace “TBTT Offset in TUs” with “Neighbor AP TBTT Offset”.





3509

1159.01

9.20.2.1

Add labels to Figure 9-21 "Reference implementation model when dot11AlternateEDCAActivated is
false or not present."

Add labels to Figure 9-21 to look like Figure 9-22.

Note: the correct location is 1307.081265.40. And the corrected reference is Figure 9-23.
Proposed Resolution:

Revised.

Add labels “VO, VI, BE, BK” (going left to right) to the head of the transmit queues for ACs boxes, in figure 9-23, following the visual style of Figure 9-24.

Add labels “VO, VI, BE, BK” (going left to right) to the head of the “Per-queue EDCA

functions with internal collision resolution” boxes, in figure 9-23, following the visual style of Figure 9-24.


3090

1174.28

8.6.16.2.2

The so-called "Action field format" tables for mesh are not the formats of the Action field. The Action field does not include Category and Action fields.

Remove Category and Action fields from 8.6.16 to 8.6.18.

Discussion:

See 651.15:



As opposed to the commenter’s assertion, the Action field does include the Category field and everything that follows it, but excludes the Vendor Specific, MME and AMPE elements.
Proposed Resolution:

Rejected. According to Figure 8-73, the Action field does include the Category (and subsequent) fields.





3091

1188.20

8.6.19.3

The "Action field formats" in 8.6.19 include Category and Robust Action fields. They should not.

Remove any "Category" and "Robust Action" from figures claiming to be "Action field format"s in 8.6.19.

Proposed Resolution:

Rejected. According to Figure 8-73, the Action field does include the Category (and subsequent) fields.





3092

1191.06

8.6.20.2

The "Action field formats" in 8.6.20 include Category and DMG Action fields. They should not.

Remove any "Category" and "DMG Action" from figures claiming to be "Action field format"s in 8.6.20.

Proposed Resolution:

Rejected. According to Figure 8-73, the Action field does include the Category (and subsequent) fields.




3016

1216.53

8.7.1

The numbering of bits within a structure should start at 0, not 2.

Change the bit number labelling to start at 0, i.e., subtract 2 from each of the four bit position labels in Figure 8-721.

Discussion:

See 8.2.2 “In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k+ 1 bits.”
Proposed Resolution:

Accepted.





3149

1259.13

9.3.6

The 6th to last sentences of the 1st paragraph of 9.3.6 (P1259L13 to P1259L24) specify the forwarding procedure of the group addressed frames. As it is not the media access procedure, the subclause of the clause 9.3 (DCF) is not the adequate place to specify it.

Move the contents of the 6th to last sentences of the 1st paragraph of 9.3.6 (P1259L13 to P1259L24) to the subclause 9.2.8 (MAC data service) as the 4th paragraph.

Yüklə 288,8 Kb.

Dostları ilə paylaş:
1   2   3   4   5




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azkurs.org 2020
rəhbərliyinə müraciət

    Ana səhifə