| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
As I don't expect to make it to any phone conference or face to face meeting in the near future, I thought I would use email to stick my oar in.
_______________________________________________________________________________
CID1020: "The name "group membership" is (IMHO) overly general. There are lots of different types of groups. e.g. .11ac Has MU-MIMO group membership." "Replace all unadorned use of this term by .11aa with "GCR Group Membership". The proposed change does not work because the group membership management feature is used to learn the contents of the dot11GroupAddressesTable of associated STAs. This table existed prior to 11aa and its use is independent from the use of GCR. I agree that the term "group membership" is overly general and we need a new term, but "GCR group membership" ain't it. Looking at the description of dot11GroupAddressesTable it says "A conceptual table containing a set of MAC addresses identifying the multicast-group addresses for which this STA receives frames.". Would something like "Group addressed reception management" work as a replacement for "Group membership management" ? CID1025: <about the more data bit in group addressed frames> Maybe I am misreading the comment, but they don't seem to be in conflict. One says "the bit is one when there is more to send" and the other says "the bit is zero when there is no more data to send". CID1042: "The addition by .11aa of the DELBA GCR Group Address does not indicate whether the field is optional or not. Either way creates a problem. Either it is not optional, in which case legacy devices are now non-compliant, or it is optional, in which case there is no straightforward way to parse the frame - given that the action field is followed by vendor specific elements of unknown length. i.e. the lengthof the frame cannot be used to determine the presence of this field." I think it should be the "GCR Group Address element" (8.4.2.125) which is an optional element, rather than a naked MAC address. This matches the changes made by 11aa to the other block ack frame formats. CID1044: ""The Public Key field contains the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39 (Scalar field)". I beg to differ. The cited location does not contain the definition of a Public Key field." Yes, it really does contain the definition of the _format_ of the key. The public key is made up of the group ID and the scalar value. Suggest changing "The Public Key field contains the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39" to "The Public Key field contains the scalar value of the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39" CID1052: <bad grammar around 11aa addition> Suggest changing "In the absence of a PCF or use of the group addressed transmission service (GATS), when group addressed MPDUs in which the To DS field is 0 are transferred from a STA, only the basic access procedure shall be used." to "When group addressed MPDUs in which the To DS field is 0 are transferred from a STA only the basic access procedure shall be used, unless these MPDUs are delivered using PCF or the group addressed transmission service (GATS)." CID1053: <GCR-SP delivery> I think the 11aa additions can be removed. For legacy reasons, the group addressed frames are still buffered when PS mode is active. A STA using GCR-SP will get concealed versions of the group addressed MSDUs on a different schedule to DTIM. Therefore there is no need to put in the wriggle text "except when using GCR-SP" because the PS schedule still applies. CID1060: "is responsible for" in a note sounds like a requirement. It is not a requirement, it is a warning to AP implementers to watch out for an ambiguity in the block ack bitmap. It's not perfect, but how about changing "The originator is responsible for recognizing that these bit positions apply to MPDUs irrelevant to the STA and for not spuriously retrying MPDUs." to "These bit positions apply to MPDUs irrelevant to the originating STA and it is recommended that the STA avoid spuriously these retrying MPDUs." CID1065: "There is no such beast as an "ADDTS Reserve Request action frames"" Yes there is. It is defined in 8.5.3.7 CID1074: "Need to define the notation <0>32 here, or reference where it is defined" Agree with proposed resolution. It is supposed to indicate 32 octets, where each octet contains the value zero. CID1075: "Need to define Max and Min for addresses, perhaps by reference to where this function is defined." Min and max are already used in the spec for addresses. For example in 11.3.4.2.2. We need to make sure they use the same rules. Alex Date: Mon, 11 Mar 2013 13:00:20 +0000 From: Adrian.P.Stephens@xxxxxxxxx Subject: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/13/11-13-0233-01-000m-revmc-wg-ballot-comments.xls uploaded To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- R1 contains additional categorization and some comment resolution of the editorial comments: (plus some transfers to MAC/GEN) (pre-ballot roll-over comments are included in below…)
Best Regards,
Adrian P STEPHENS Tel: +44 (1793) 404 825 Tel: +44 (7920) 084 900 Tel: +1 (408) 239 7485
----------------------------------------------
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 _______________________________________________________________________________ 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 _______________________________________________________________________________ |