Edward
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---> [1] 19/2160r2: the proposed resolution for the 89 CIDs
Thanks for these resolutions. Here are my comments on the proposed
resolutions to the 89 "review" comments in 19/2160r2:
CID 4063: I think it needs to be "NOTE 1" and "NOTE 2" not "NOTE1" and "NOTE2"
[Ed] Agree.
CID 4069: Has to be REVISED because proposed change has duplicate "54"
[Ed] Agree.
CID 4070: No, this comment should be REJECTED. The point is that the
BFee does not fragment if the CBR fits in the BFer's max MPDU len capability.
So if for example the CBR is 10k and the BFer's max MPDU len capability
is 11k, then the BFee does not fragment, even if the BFee's max MPDU
len capability on rx is 4k (which one might think might also be its
max on tx). This is the subtlety the NOTE is capturing. Indeed,
The VHT beamformee might therefore have to transmit an MPDU that is bigger than the VHT beamformer is capable of receiving.
would be plain wrong: it never does that.
[Ed] I move this CID from "Review" to "Discuss" for further discussion.
CID 4072: Actually, the spec is inconsistent as to the enum names for
the (EDMG_)BEAM_TRACKING_REQUEST parameter:
Table 20-1: Beam tracking requested or Beam tracking not requested
Table 24-1: Beam tracking requested or beam tracking not requested
and Enhanced beam tracking requested or enhanced beam tracking not requested
Table 25-1: Beam tracking requested or Beam tracking not requested
I suggest making the first letter of each word uppercase, so in
addition to the above the following need fixing:
10.42.7
BEAM_TRACKING_REQUEST to Beam Tracking Requested
BEAM_TRACKING_REQUEST parameter shall be set to Beam Tracking Not Requested
BEAM_TRACKING_REQUEST parameter in the RXVECTOR set to Beam Track Requested
BEAM_TRACKING_REQUEST parameter in the TXVECTOR to Beam Tracking Requested
BEAM_TRACKING_REQUEST to beam tracking not requested
BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to beam tracking not requested
10.42.9
ENHANCED_BEAM_TRACKING_REQUEST to enhanced beam tracking requested
ENHANCED_BEAM_TRACKING_REQUEST parameter shall be set to enhanced beam tracking not requested
ENHANCED_BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to enhanced beam tracking requested
ENHANCED_BEAM_TRACKING_REQUEST parameter in the TXVECTOR to enhanced beam tracking requested
ENHANCED_BEAM_TRACKING_REQUEST parameter in the TXVECTOR to enhanced beam tracking requested
ENHANCED_BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to enhanced beam tracking requested
Also, in 20.9.2.2.1 "Beam Tracking Request (if present) equal to 0"
should (I presume) have "field" before the parenthesis. Or maybe,
looking at the wider sentence structure, instead delete "the" in
"the PPDU Type" (also in next bullet)?
[Ed] I move this CID from "Review" to "Discuss" for further discussion.
CID 4074: I'm not sure "following" should be deleted. I think it's
referring to the immediately following PPDU, so maybe a better fix would
be to add "immediately"? Note there are 4 other "following PPDU"s:
2059.63, 2064.24/25, 4405.59.
[Ed] I move this CID from "Review" to "Discuss" for further discussion.
CID 4123: "The thickness of the line at the bottom of Aggregation is very thin
because it is not the end of the table." is a nice theory, but in practice
there are many tables split across pages where the line at the bottom of
one page is not very thin. Can't this be made some kind of global setting?
[Ed] As far as I know, the global setting will be done by the IEEE-SA Publication Editor.
CID 4241: Re the note to commenter, I think the two locations should be
fixed even if they don't match the comment string. Also 230.2 "transmissions
from the AP to itself", 1838.7 "CTS to itself", 2213.19/2214.27 "SPs allocated
to itself".
[Ed] I add these 4 locations into the updated resolution.
CID 4251: Did I really not miss any in CID 4252?
[Ed] No, you do not miss anything in CID 4252.
CID 4254:
Also "Unless another value is mandated by regulatory authorities, the default value is 256." at 3896.39,
"The default value is null." at 3941.57, 3942.44, 3951.43, 3957.23, 3962.5, 3966.45, 3979.14, 3996.61, 4002.8, 4003.48, 4010.49, 4040.28, 4043.7, 4043.25, 4044.54, 4070.27, 4079.59, 4081.19,
"The default value of this attribute is …" at 4113.3, 4113.22, 4160.64, 4174.39.
[Ed] Thanks. I add all but one locations (4160.64) into my updated resolution. It is because I've already included 4160.64 in my original resolution.
CID 4275: Did I really not miss any in CID 4276?
[Ed] CID 4276 covers "if", while CID 4275 covers "if" and "when". For the "if" part, you do not miss anything.
CID 4518 and CID 4770: Are the resolutions exactly the same (slight miracle if so!)?
[Ed] Yes, exactly the same including the reminder to change "above" to "below". It is a miracle!
CID 4627: Should it maybe be "RCPI parameter", by analogy with other locations?
15.2.3.6 PHY-RXEND.indication parameter RCPI(#2560)
The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 9.4.2.37 (RCPI element).
This parameter is a measure by the PHY of the received channel power. The performance requirements for
the measurement of RCPI are defined in 15.4.6.6 (Received Channel Power Indicator Measurement).
17.2.3.6 PHY-RXEND.indication parameter RCPI(#2560)
The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 17.3.10.7 (Received
Channel Power Indicator Measurement). This parameter is a measure by the PHY of the received channel
power. RCPI indications of 8 bits are supported. RCPI shall be measured over the entire received frame or
by other equivalent means that meet the specified accuracy.
[which leads to]
17.3.10.7 Received Channel Power Indicator Measurement
The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This
parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire
received frame or by other equivalent means that meet the specified accuracy.
The RCPI encoding is defined in 15.4.6.6 (Received Channel Power Indicator Measurement).
[which leads to]
15.4.6.6 Received Channel Power Indicator Measurement
The RCPI is a measure of the received RF power in the selected channel for a received frame. This
parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire
received frame or by other equivalent means that meet the specified accuracy.
The encoding of received power to RCPI is defined in 9.4.2.37 (RCPI element).
[Ed] I move this CID from "Review" to "Discuss" for further discussion.
CID 4645: 2061.61 also needs a "the"
[Ed] Thanks. I've added "the" in my updated resolution.
CID 4775: I find:
446 "µs" (the right micro, namely U+00B5)
269 "μs" (the wrong micro, namely U+03BC)
213 "microsecond" (of which about 50 in the MIB, where it has to be ASCII)
so I think the comment should be ACCEPTED.
[Ed] Thanks. I miss the word "unicode" in the commenter's comment. I agree it is "Accepted" but "Revised", and I've updated the resolution accordingly.
CID 4794: There are two more, broken across a line, at 2056.50 and 3469.20
[Ed] Thanks, I've included these 2 locations in the notes to the editors.
> [2] 19/2163r2: I will have an additional 15 - 20 CIDs for discussion.
I attach my comments on 19/2163r2.
> [3] 19/2160r2: a few CIDs that need discussion or assignment to volunteer(s)
Which are these? The 15 with status Discuss are addressed in 19/2163r2.
So that just leaves CID 4315 and 4784, which do indeed need a submission
(for the latter, the commenter has said he will provide a submission.)
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
> -----Original Message-----
> From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxx> On Behalf Of
> Edward Au
> Sent: 2 January 2020 06:10
> To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGM] Proposed resolution for 89 CIDs uploaded (19/2160r2)
>
> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>
> Hi Dorothy, and all
>
> Proposed resolution for 89 CIDs, which are relatively straightforward,
> are uploaded at
> https://mentor.ieee.org/802.11/dcn/19/11-19-2160-02-000m-revmd-editor2-standards-association-ballot-
>
> The ad-hoc status of these 89 CIDs in the spreadsheet is "Review" and
> these 89 CIDs are listed as follows:
>
> 4794, 4789, 4788, 4775, 4773, 4770, 4724, 4684, 4675, 4674,
> 4673, 4666, 4665, 4664, 4660, 4645, 4644, 4638, 4627, 4621,
> 4619, 4610, 4609, 4532, 4518, 4504, 4502, 4500, 4484, 4481,
> 4472, 4464, 4461, 4434, 4426, 4412, 4411, 4407, 4387, 4385,
> 4367, 4359, 4357, 4356, 4350, 4348, 4346, 4337, 4333, 4332,
> 4331, 4330, 4316, 4302, 4300, 4290, 4280, 4279, 4278, 4276,
> 4275, 4268, 4255, 4254, 4252, 4251, 4241, 4228, 4215, 4211,
> 4210, 4200, 4199, 4187, 4186, 4185, 4184, 4183, 4180, 4130,
> 4128, 4127, 4124, 4123, 4074, 4072, 4070, 4069, 4063
>
> Please review and let me know if you have any comment/question.
>
> Regards,
> Edward
>
> _______________________________________________________________________________
>
> 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: https://protect2.fireeye.com/url?k=ad318a15-f0e2d3ab-ad30015a-
> 0cc47a31ba82-a85575ba8fc22529&u=http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1