doc.: IEEE 802.11-10/1416r2 · Web viewTGmb Teleconference Minutes Dec 2010 –Jan 2011 Date:...

January 2011 doc.: IEEE 802.11-10/1416r2

IEEE P802.11Wireless LANs

TGmb Teleconference Minutes Dec 2010 –Jan 2011

Date: 2010-12-03

Author(s):Name Affiliation Address Phone email

Dorothy Stanley Aruba Networks 1332 Crossman AveSunnyvale, CA 94089 +1-630-363-1389 [email protected]

Jon Rosdahl CSR 10871 N 5750 WHighland, UT 84003 +1-801-492-4023 [email protected]

Minutes page 1 Jon Rosdahl (CSR)

AbstractThis document contains the meeting notes from the TGmb teleconferences held December 3, and 17, 2010 as well as the January 7, 2011.


December 3, 2010 Teleconference

Agenda:

1. Call to Order, Patent Notification2. TG Status3. Comment resolution – GEN category comments4. Adjourn

Please review the documents at the following links prior to the call:

- IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt- Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html- Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf - Ethics - http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf

Notes – Friday, December 3, 2010

Attendees: Mark Hamilton (Polycom), Bill Marshall (AT&T), Mike Montemurro (RIM), Dorothy Stanley (Aruba Networks).

1. Chair called meeting to order: 10:05 Eastern

Chair called attention to the patent policy slides. Are there any questions on the slides?None

Chair asked: Are there any patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard? None brought forward

Are there any additions to the proposed agenda? No changes proposed.

2. TG Status

We are resolving comments from the initial Sponsor Ballot, see https://mentor.ieee.org/802.11/dcn/10/11-10-1284-00-000m-revmb-sponsor-ballot-comments.xls .

3. Discussion of proposed comment resolutions to GEN category comments. We reviewed proposed resolutions that Bill Marshall had prepared in https://mentor.ieee.org/802.11/dcn/10/11-10-1329-01-000m-misc-resolutions.xls .

a. CID 10001 – Accept in Principle, “TGp is incorporated in D7.0.”b. CID 10085 – Accept in Principle, “TGp and TGz are incorporated in D7.0.”c. CID10015 – Accept in Principle, insert a new acronym in 3.3 P34 “URL” and “Universal

Resource Locator”

d. CID 10182 – Accept in Principle, “Resolutions in the referenced comment file are present in 11-10-1284 (add link to most recent version) as individual entries.”

e. CID 10057 – Unresolvable, “The comment is not on P802.11mb D6.0.”f. CID 10058 – Unresolvable, “The comment is not on P802.11mb D6.0.”

g. CID10005 – Accept in Principle, “Incorporate all changes indicated by the commenter except on P935L1 (comment on IR PHY, as that clause in no longer maintained).


http://standards.ieee.org/board/pat/pat-slideset.ppt

https://mentor.ieee.org/802.11/dcn/10/11-10-1329-01-000m-misc-resolutions.xls


https://mentor.ieee.org/802.11/dcn/10/11-10-1284-00-000m-revmb-sponsor-ballot-comments.xls


http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf

http://standards.ieee.org/resources/antitrust-guidelines.pdf

http://standards.ieee.org/faqs/affiliationFAQ.html


h. CID 10029 – Accept, “See comments to resolutions in 11-10-1284 (add link to most recent version) in the “terminology-may” comment group.

i. CID 10200 – Accept in Principle, “At any given instant, a STA is associated with no more than one AP.”

j. CID 10181 – Disagree, “The proposed changes are not specified in sufficient detail to be implemented.”

k. CID 10036 – Disagree, “As stated in the comment, adoption of parameters that are not understood is harmless; regarding dissimilar beacons, parameters that are not understood are not transmitted and are ignored upon receipt, see 9.23.6 and P263L34.

l. CID 10237 – Accept

m. CID 10046 – Acceptn. CID 10053 – Accept in Principle, change “dot11QBSSLoadOptionImplemented” to

“dot11QBSSLoadImplemented” throughout the drafto. CID 10019 - Accept in Principle, Change from:

“2) when the BSS Load element is present and theAvailable Capacity Bitmask equals 256 (Available AdmissionCapacity List contains only the AC_VO entry).”to“2) when the BSS Load element is present and theAvailable Admission Capacity Bitmask states that only AC_VO is present in the Available Admission Capacity List field.”

p. CID 10007 - Accept in Principle, change "Length (in octets)" in heading of Table 8-50 to "Length of Indicated Element (in octets)"

q. CID 10292 – Acceptr. CID 10300 – Accept

s. CID 10303 – Acceptt. CID 10141 - Accept in Principle, change from

“In an IBSS, a STA that transmitted a Beacon frame since the last TBTT shall respond toprobe requests.”to"In an IBSS, a STA that transmitted a Beacon frame since the last TBTT shall respond to group addressed Probe Request frames. A STA in an IBSS shall respond to Probe Request frames sent to the individual address of the STA.

Remaining GEN category comments in 1329 are 10080 and 10125.

4. Next callsThe next calls are Dec 17th and Jan 7th:

Bridge info: 1-719-457-6209Code: 712-821-86412 hours

5. Adjourned at 1200 Eastern.




Agenda:3 Call to Order, Patent Notification

2. Editor Report3. Comment resolutionDec 17 - review 11p integration, others as agreed4. Adjourn

Attendees: Mike Montemurro (RIM) (Starting 11:30), Dorothy Stanley (Aruba Networks), Jon Rosdahl (CSR), Adrian Stephens (Intel), Peter Es (Cisco), John Kenney (Toyota Infotecnology Center).

1. Chair called meeting to order: 10:02 Eastern

Chair called attention to the patent policy slides. Are there any questions on the slides?None

Chair asked: Are there any patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard? None brought forward

Are there any additions to the proposed agenda? No changes proposed.

2. TG Status Report from Editor on 6.01 roll-up

Comments were posted in file: There are 16 that need more discussion6.02 includes TGz roll-up and it is available on the server.6.03 is expected prior to January F2F meeting with more editorial changes and terminology issues.

6.04 will contain approved technical changes.3. Comment Resolution:

11p roll-in and https://mentor.ieee.org/802.11/dcn/10/11-10-1455-00-000m-revmb-sponsor-ballot-editor-comments.xls

look at 6.01 Roll-in tab There are 16 comments that need discussion, and the rest have some proposed resolution, and it is doubtful that there will be much debate on those.

a. CID 10528: This is an open ended comment. There is no specific issue identified. Mark as unresolvable. The specific comment suggests that TGp will provide comments, but as that Task Group is no longer viable, it is not reasonable to expect more feedback from them as a group. The TGm and 802.11 reflector are the only reflectors for discussion left as the TGp reflector no longer exists. It is expected that TGp experts would participate in TGm to help with the roll-in resolutions.

a. Proposed Resolution: UNRESOLVABLE, The commenter does not describe a specific problem or a specific change.

b. CID 10501: There is an issue a. The PICS is not definitive as to mandatory/optional features. So we have two

separate issues here:


https://mentor.ieee.org/802.11/dcn/10/11-10-1455-00-000m-revmb-sponsor-ballot-editor-comments.xls



1. The accuracy of the edit - I accept I didn't make the edit, although .11p was at fault for not showing change marking.

2. The accuracy of the statement.b. The last sentence is from the baseline text, and so there is really no change in TGp on

this last sentence. The sentence was removed in the recent past, but we do not need to reput it in to just remove it later.

c. The PICs provides a single location for finding description of mandatory and optional is stated.

d. Discussion on what we should propose: CID 1415 removed this sentence originally. The WG members can make comments on the final draft proposals. There is a concern that changes by TGmb, may effect roll-in for amendments being rolled-in.

e. The concern is that the comment does not reflect a conflict with the roll-in and TGmb change before.

f. Proposed Resolution: DISAGREE - This sentence was not modified by .11p. The cited sentence was removed by CID 1415. The BRC believes this change is not inconsistent with the .11p roll-in.

c. CID 10534a. Review the comment:b. EDITOR notes: I think the second option makes more sense. It is, however, the

manufacturers obligation to meet regulation, not 802.11's. How about adding something like:

"Std IEEE 802.11-<year> provides no support for meeting regulatory DFS requirements when dot11OCBEnabled is true."

c. There are not going to be radar (at least not defined today) in the 5.7 or above band.d. We should not try to list “we don’t dos” in the general description clause.e. This would be better to be a general comment in sponsor ballot process.f. Propsosed Resolution: DISAGREE: This comment is not related to the accuracy of

the roll-in and needs to be brought as a sponsor ballot comment.d. CID 10503

a. Review the comment:b. It is a clear and obvious mistake - i.e. the TA cannot be a group-address, and it is the

TA that maps onto this parameter.c. We are not obligated to have TGp members review the proposed changes.d. The Chair will note separately to the former TGp folks to have them check on these

changes that we are making in the roll-up.e. Proposed Resolution: AGREE IN PRINCIPLE - remove "or group" and "or group

of". The TA cannot be a group address, and it is the TA that maps onto this parameter. This change will be incorporated in the next draft and posted to the .11 website and all .11 working group members, including former .11p members can review this change and all other changes related to the incorporation of .11p.

e. CID 10505a. Review the comment.b. Clause 8 is the new Frame Formats clause. The change from "shall" to "is" was done

to provide compliance to the WG11 style guide. There is a single "shall" in Clause 8 that makes any subsequent shalls unnecessary.

c. There are no more “shalls” in the clause 8 to allow structure vs behaviour be separated. Previously it was mixed in this clause.

d. Proposed Resolution: AGREE - The change from "shall" to "is" was done to provide compliance to the WG11 style guide. There is a single "shall" in Clause 8 that makes any subsequent shalls unnecessary.

f. CID 10540a. Review the commentb. This is not an inconsistency, but rather a real issue that would need to come up in

ballot commenting.



c. There is a change in the revision that has caused the inconsistency with the roll-up, and so it should be in scope of the comment.

d. There was a comment on Draft 1 that caused this change to occur in July 2009 originally. But we need to address the condition when dotOCBEnabled is false, then we should include this to fix the sentence.

e. Proposed Resolution: AGREE IN PRINCIPLE: When dotOCBEnabled is false and the BSSID field contains the wildcard value, the Address 1 (DA) field is also set to all 1s to indicate the broadcast address.

g. CID 10536a. Review commentb. CID 2220 change the types of frames that can use wildcard can be used.c. So there is a conflict on what TGp and REVmb has done. By removing the note, we

would be using the TGp version of the conflict.d. Proposed Resolution: Agree

h. CID 10513a. Review commentb. We should refer to resolution in 10547.c. Propsoed Resolution: Agree in Principle – See resolution in 10547.

i. CID 10514a. Review Commentb. The labels have changed, so to keep the same requirments, the way that they are

stated is different that removes the need for the “or not”.c. Propossed Resolution: DISAGREE - CF2.1 implies "not CF2.3", so the change (after

remapping CF2.1 (11p) to CF2.3 (D6.01)) is not needed.j. CID 10538

a. Review commentb. Confusion of how to represent when something was “activated”, “enabled” or some

other set of terms. This was a way to choose a common term that was hopefully less confusing.

c. Proposed Resolution: AGREE (EDITOR: 2010-12-17 10:30:04Z) - Globally change dot11OCBEnabled to dot11OCBActivated.

k. CID 10585a. Review Commentb. The variables listed have a cross-reference become like the IEEE-stlye guide rules.

We need to change the enumeration to allow for better naming.c. Proposed Resolution: Agree.

l. CID 10525a. Review Commentb. Editor Notes: There's another comment resolution (CID 10585) that proposes a

change.Additional information: the enumeration variable "Table 17-13" creates an ASN.1 syntax error when compiling the MIB: 1) embedded space; 2) hyphen in name. So if we attempt to continue making this look like a reference, we have to convert it into something that is a valid enumeration name. A better alternative would be to put the references into the description.

c. The chair will add CID 10525 as a special comment that will be sent to the emeritus TGp members.

d. Proposed Resolution: AGREE IN PRINCIPLE (EDITOR: 2010-12-17 16:25:42Z) – See comment resolution (CID 10585) that proposes a change. Additional information: the enumeration variable "Table 17-13" creates an ASN.1 syntax error when compiling the MIB: 1) embedded space; 2) hyphen in name. So if we attempt to continue making this look like a reference, we have to convert it into something that is a valid enumeration name. A better alternative would be to put the references into the description.

m. CID 10527



a. Review commentb. The removal of the table I.1, is now in table D.1 and it was redundant, and where the

behaviour that is controlled by regulation is done, we suggest that the law is read rather than restating it here.

c. In Annex D, there is a table that has these regulations listed.d. Proposed Resolution: UNRESOLVABLE - The commenter does not identify a

specific problem or provide a specific change.n. CID 10529

a. Review commentb. Can we remove the table or not? We need to either determine that the table is

redundant (i.e., determined by regulation) or make the changes Lee wants.c. This table is redundant with regulations. Peter and Carl were to check to see if we

were specifiying something different from regulation, and as it was in the Law, it did not need to be included in the standard.

d. We should be able to remove table D3e. Proposed Resoltuion: AGREE IN PRINCIPLE - Remove Table D-3. This is a

restatement of the cited regulations.o. CID 10553

a. Review the commentb. Where there is a law, this restates it, where there is no law, then this gives the mask

values. Doc 11-10/1327r0 clearifies the changes here.c. Proposed Resolution: DISAGREE - These changes were made in to make the mask

description non-country specific. They were discussed with former.11p members as noted in document 11-10/1327r0.

p. CID 10552a. Review the commentb. EDITOR Notes: REVmb has removed statements of power output. This resulted in

the removal of the old Table I-4. REVmb was attempting to determine whether the additions made by .11p were already determined by regulation, or where new in .11p. It determined this of the USA, EIRP entry (which it then removed), but not of the other two.

c. We have now also removed Table D3 in its entirety.d. Proposed Resolution: DISAGREE - REVmb has removed statements of regulatory-

defined power outputs and has removed Table D-3 in its entirety.q. There are 70 odd other comments, and these should be reviewed and we should make a

motion during the January Conference call to accept them as well as the 16 that we just did.4. Next Call will be in January 7th.

a. Status on 11z roll-in and comment statusi. This was less formal, and have had some input to the roll-in,but none that were

significant to this point. We can discuss them in January if needed. There is a comment on Buffered Power-saving frames, but it is covered by Sponsor Ballot comment that will be discussed separately.

b. Will 6.03 be available prior to Jan 7th?i. These would not be included by the concall time

ii. The resolutions are in 1455, not in a draft when we vote on the resolutions.c. Proposed Agenda

i. Final 11p commentsii. Finalize 11z comments

iii. Work on leftover on GEN comments.5. Adjourn – 11:55am




Proposed Agenda:1. Call to Order, Patent Notification2. Draft Status - D 6.03 posted3. Discuss “Comments on 6.01 roll-in Tab” possible Motion: "Adopt resolutions in https://mentor.ieee.org/802.11/dcn/10/11-10-1455-01-000m-revmb-sponsor-ballot-editor-comments.xls "Comments on 6.01 roll-in" tab, and incorporate indicated changes into the TGmb draft."4. GEN category comment resolution5. Plans for Jan meeting - goal to complete comment resolution of initial SB comments6. Adjourn

Attendees: Mike Montemurro (RIM), Dorothy Stanley (Aruba Networks), Jon Rosdahl (CSR), Adrian Stephens (Intel) (starting at 10:35), Peter Es (Cisco), John Kenney (Toyota Infotecnology Center). Lee Armstrong (ARINC), Bill Marshall (AT&T), Carl Kain, Peter Ecclstine, Mark Hamilton

1.0 Call to Order, Patent Notification by Dorothy at 10:051.1 Chair asked: Are there any patent claim(s)/patent application claim(s) and/or the holder of

patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard?

1.1.1 None brought forward1.2 Review Proposed Agenda

1.2.1 Note that many can only attend for one hour, so meeting is expected to be only one hour

1.3 Agenda approved without objection.2.0 Draft Status - D 6.03 posted

2.1 Has editorial resolutions from original 6.0 ballot2.2 D6.04 has been posted as well.

2.2.1 Has the technical changes approved from Nov included.2.2.2 Note that the website has the details.

2.2.2.1 http://www.ieee802.org/11/private/Draft_Standards/11mb/index.html

3.0 Comments on the 6.01 11p roll-in 3.1 Is there any comments necessary on this tab.

3.1.1 Yes, CID 10560 – this may need a bit more discussion3.1.2 Yes, CID 10529 will need discussion:

3.2 CID 10529 discussion:3.2.1 In Draft 6.04, there is a table D3 emmissions table in that is still there that some

comments had indicated it would be removed. Instructions and comments in 1455 has not been applied as of yet. This table is quoting regulations. Only table D-1 should have regulations.

3.2.2 There is a problem with a possible circular reference between the FCC part 90 and Part 95 that refer to ASTM 2220(?) and that is expected to be replaced with the 11p, so if it is, then that would be a circular reference.3.2.2.1 The proposal would be to stop the sentence after the power level is

stated, and not have the reference included. E.g. in the Europe column, “33 dBm (2W).” and delete the rest “Additional limitations apply per Clause 5 of ETSI ES 202 663”

3.2.3 D-3 does not add to the US entry in table D-4.3.2.4 The Europe or Australia regulations are not set like the ones in US, and the

allocations are so new that we don’t have them yet.3.2.5 So D-3 could be removed in its entirety. 3.2.6 What about a request to have a European equivalent for D-4?

3.2.6.1 That would have to be discussed later.3.2.6.2 Having D-3 with the proposal may be better?3.2.6.3 What about removing the “US” from the title of D-4?


http://www.ieee802.org/11/private/Draft_Standards/11mb/index.html




3.2.6.3.1 No, that would not be a good idea for this round of review, but a comment later may ask for this, but that would have to take into account what is going on in other regulatory bodies.

3.2.6.3.2 We needed to be able to require Mask D, and that is what is required by the standard, but there is no place that the PHY indicates the mask out in a MIB. These entries are “holders” to make the LAW work.

3.2.6.3.3 Annex D is almost Country independent.3.2.6.3.4 There was no objection to remove the table D-3.

3.3 CID 10560 discussion:3.3.1 John Kenny wanted Adrian to be part of this discussion, and it so happens, Adrian joined

the call3.3.2 Review of e-mail thread on adding/removing the Vendor Specific Info is useful and the

removal of “.confirm”.3.3.2.1 (Email thread added after the reference section.)

3.3.3 Is there value for the MLME to indicate to the SME that the request to transmit was successful or not?

3.3.4 Discussion on when an indication is really needed, and when it is of value. Does the higher layer handle this indication or is the lower layers (MLME/SME) supposed to be providing the completion of the service. A “confirm” that a broadcast has been done is not very useful. It does not tell you if it was received or not. If you need to know what the effect on the peer entity, then you need a higher layer protocol to handle that feedback, otherwise there is no value in the “.confirm” at this layer.

3.3.5 How to differentiate the local vs remote way? When is it necessary in the local case?3.3.6 DeEnablement: 10.12.2.4 and 10.12.2.5 there was text that does not have full handshake

and get into the details on the SME.3.3.7 There are examples where we have questionable 3.3.8 If we wanted to drop all the “.confirm” primitives then that would make more sense

rather than just droping this one.3.3.9 It is not a question of local action or not, but rather is the action relevant to the behaviour

of the standard and the interoperability of peers.(direct or indirect). There are many implementation details and things that are purely local and not necessary to have in the standard. As a general rule, we cannot through out all the “.confirms” in order to make sure that the states are properly addressed. So having the “.confirm” or the invalid Parameters may not be needed, and on a case by case basis we would need to review.

3.3.10 The Chair asked if there was any objection to the current resolution on this CID?3.3.10.1 Question, what happens if we pull this from the motion or if we don’t.3.3.10.2 It would be discussed further at the F2F if needed, whether it is pulled or not.3.3.10.3 no disagreement to leave it included.

3.4 Motion 105: Motion: "Adopt resolutions in https://mentor.ieee.org/802.11/dcn/10/11-10-1455-01-000m-revmb-sponsor-ballot-editor-comments.xls "Comments on 6.01 roll-in" tab, and incorporate indicated changes into the TGmb draft."

3.4.1 Moved by Adrian Stephens, 2nd Mark Hamilton3.4.2 9-0-0 motion passes.

4.0 GEN category comment resolution4.1 No time

5.0 Plans for Jan meeting - goal to complete comment resolution of initial SB comments5.1 We have 7 sessions scheduled for the LA session.5.2 The goal is to complete comment resolutions from the ballot.5.3 We need a list/count of the final comments to prepare for the Interim session,and allocate to

the different topics.5.4 PHY changes will be one of the topics that will be assigned to a time block.5.5 MAC Adhoc – mostly in Clause 10.35.6 Gen AdHoc still has 75 comments, need topics to be posted to reflector by Monday.

6.0 Adjourn at 11:02am.





References:

Minutes for Dec 3, 2010:https://mentor.ieee.org/802.11/dcn/10/11-10-1416-00-000m-con-call-notes-dec-2010-jan-2011.doc

General Comments discussed on Dec 3:https://mentor.ieee.org/802.11/dcn/10/11-10-1329-01-000m-misc-resolutions.xls

Minutes and document for Dec 17:

Full Comments from Sponsor Ballot:https://mentor.ieee.org/802.11/dcn/10/11-10-1284-01-000m-revmb-sponsor-ballot-comments.xls

Editor Comment resolutions:https://mentor.ieee.org/802.11/dcn/10/11-10-1455-00-000m-revmb-sponsor-ballot-editor-comments.xls

Document referenced in comment resolutions:https://mentor.ieee.org/802.11/dcn/10/11-10-1327-00-000m-11p-mask-m-specification.doc

GEN Adhoc Comments from Sponsor Ballot:https://mentor.ieee.org/802.11/dcn/10/11-10-1434-00-000m-gen-adhoc-sponsor-ballot-comment-resolutions.xls

Minutes and documents for Jan 7th:

Document referenced in Motion:https://mentor.ieee.org/802.11/dcn/10/11-10-1455-01-000m-revmb-sponsor-ballot-editor-comments.xls

Discussion included E-mail thread which follows on the subsequent page 11-25 of this document.



https://mentor.ieee.org/802.11/dcn/10/11-10-1434-00-000m-gen-adhoc-sponsor-ballot-comment-resolutions.xls

https://mentor.ieee.org/802.11/dcn/10/11-10-1434-00-000m-gen-adhoc-sponsor-ballot-comment-resolutions.xls

https://mentor.ieee.org/802.11/dcn/10/11-10-1327-00-000m-11p-mask-m-specification.doc





https://mentor.ieee.org/802.11/dcn/10/11-10-1416-00-000m-con-call-notes-dec-2010-jan-2011.doc


E-mail thread from with John Kenny, Lee Armstrong, Alastair Malarky and Adrian Stephens regarding 11p roll up (D6.01) comment resolutions.

This e-mail was discussed during the Jan 7th, 2011 teleconference. I have removed e-mail addresses and phone numbers of the respective parties, but left the names or usernames that were used in the exchange whether in the address or were in the signatures of the e-mail..

From: John Kenney Sent: Friday, January 07, 2011 9:39 AMTo: Stephens, Adrian PCc: Alastair Malarky; George VLANTIS; Lee Armstrong; Roy, Richard; Landt, Jerry; McNew Justin; FSIMON; ckain; dkavner; rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Dorothy Stanley; Jon Rosdahl; GPRUITT; John Moring; tkstds; mark.hamiltonSubject: Re: 11p roll up (D6.01) comment resolutions

This is addressed to everyone on the thread. A quick update on the just-completed REVmb conference call (others feel free to chime in if you want to add anything) We discussed two of the 11p roll up comments:

10529 regarding Table D-3

10560 regarding the VSPECIFIC.confirm primitive

After the discussion we approved the proposed resolutions in 11-10-1455/r1. This caused Table D-3 to be deleted. This caused the VSPECIFIC.confirm primitive to be absent from the REVmb draft (it was absent prior to the 11p roll up and will remain absent). Table D-3:This table has two power limits for operation in the 5.850-5.925 GHz band, one for the US and one for Europe. We decided that the US limit in Table D-3 is redundant with limits in Table D-4. From a US perspective, there was no reason to keep Table D-3. We decided that the 802.11 standard does not need to define a European power limit (regulatory bodies in Europe do not point to 802.11), so there is no reason to keep Table D-3 from a European perspective either. Therefore, we agreed to delete the table. VSPECIFIC.confirm:We summarized the information in this thread and continued the discussion about this primitive. We discussed the fact that IEEE 1609.3 does not specifically refer to this primitive (this is my understanding). My position has been that there is value in a capability for the MLME to inform the SME if it has been successful or unsuccessful in transmitting a requested VS action frame. Adrian and others pointed out that there is no prohibition on an implementation providing that capability, but that there is no reason it needs to be in the standard. I took that as a valid point and did not object to the comment resolution, which has the effect of leaving the primitive out of 802.11 REVmb. My only remaining degree of discomfort is a lingering feeling that we may be applying this principle piecemeal and creating internal 802.11 inconsistencies. For those MLME primitives of



type .confirm that convey information about a purely local action, I have a concern that we do not yet have a uniform criterion for whether each deserves to remain in 802.11. Mark suggested that one such criterion might be whether interoperability is affected by the success or failure that the .confirm will indicate. He also suggested that conveying "failure due to invalid parameters" would not generally be considered to affect interoperability. There has been a suggestion in this thread that at least one additional subclause 6.3 .confirm primitive should be removed, via a future sponsor ballot comment. I hope we can do a thorough review of the others and determine if all of the remaining ones are ok. Thanks to Adrian, Alastair and others for contributing to this discussion. I learned quite a bit. Cheers,John

On Fri, Jan 7, 2011 at 1:55 AM, Stephens, Adrian P wrote:

Hello John,

Thank you for your continuing commentary. The WAVE community requirements are slowly becoming clearer to me.

I’m afraid you have to thank my ISP for defeating your intention. I spent all day yesterday with no internet connection, and I wasn’t going to attempt to answer this thread on my cell phone :0).

Another way of looking at asynchronous and synchronous is that in one case you reliably know about the effect it has on the receiver and in the other case you do not.

I’d completely missed the fact you might be using broadcast addresses for your vspecific transmissions. If that is the case, clearly (from a protocol point of view) you are talking about the asynchronous case, because there is meaning in X.210 in attempting to get synchronous responses from multiple peers.

From a practical sense, knowing that you have transmitted a broadcast frame tells you nothing with confidence. Broadcasts are inherently unreliable due to interference, MCS/rate selection errors, range limits...

So knowing with confidence you have transmitted a frame does not tell you with confidence it was received.

I claim that in this case, trying to provide a “pseudo-confirm” provides no practical benefit.

Let’s now look at the possible result codes (from STD-2007) in the broadcast case:

SUCCESS. It tells you that the frame was transmitted, but not that it was received.

INVALID_PARAMETERS. The only parameters to the .request are PeerMACAddress, OUI, and VendorSpecificContent. In what sense can the MLME know the validity of these parameters that the SME does not? - i.e. what value can it add in determining that validity of these parameters? Note, the MLME-SAP interface is not an implementation interface, it is a protocol one. The SME knows everything the MLME knows about valid MAC addresses and VendorSpecificContent. So I claim this adds no benefit.



TIMEOUT. OK, somebody tell me what’s the timeout for transmission of a broadcast frame? I don’t know the answer to this, as I don’t see anything that describes what value should be given to a timeout in the protocol.

TRANSMISSION_FAILURE. I don’t see that it’s possible for a broadcast transmission, given that you don’t have a channel access timeout to generate a transmission failure.

UNSPECIFIED_FAILURE. This really has no place in a protocol description. Under what circumstances can a protocol cause an unspecified failure?

I really don’t see that any of these tell you anything useful in the broadcast case.

Also please see below...

Best Regards,

Adrian P STEPHENS From: John Kenney Sent: Thursday, January 06, 2011 6:05 PMTo: Stephens, Adrian PCc: Alastair Malarky; George VLANTIS; Lee Armstrong; Roy, Richard; Landt, Jerry; McNew Justin; FSIMON; ckain; dkavner; rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Dorothy Stanley; Jon Rosdahl; GPRUITT; John Moring; tkstds; mark.hamiltonSubject: Re: 11p roll up (D6.01) comment resolutions

Hi Again!

At the risk of not fully digesting your good response, I'm going to send something fairly quickly in hopes of defeating the 8-hour timezone difference and getting a reply to you during your work day.

Thanks again for the details in your message. I understand your perspective better with each exchange. Thanks also for pointing out that the UNITDATA.confirm that was in 802.11-2007 has been removed in 802.11REVmb 6.0. I missed that.

You have made a good attempt to capture in words what some of us want. I wouldn't have used the synchronous and asynchronous terms, but I'm not sure if that represents a gap in our understanding or just a terminology difference. Let me speak to a specific use case that we have, though I believe the VS action frame is a very flexible tool that could be used in other ways.

One way we want to use it is to allow a roadside device to advertise to passing vehicles a set of services it is prepared to offer (what we call a WAVE Service Advertisement - WSA). This is in the form of a "for your information" message, meaning it is broadcast for any who can hear it, and the broadcasting STA expects nothing in return. In that case, the SME at the broadcasting STA uses the VSPECIFIC.request to ask the MLME to formulate the VS action frame containing the WSA within the vendor specific information. It seems useful to us that the MLME have a way of indicating to the SME whether it successfully fulfilled the broadcast request. Without this, if there is some defect in the request that prevents the MLME from fulfilling it, the SME will happily continue issuing non-actionable broadcast requests to no purpose.

Adrian: I’m not sure what a “non-actionable” broadcast request is. But if there was some such, what protocol problem would be caused by continuing to issue them?



So, this has nothing to do with expected actions at a receiving STA, and I would put it in your first category of MLME action, i.e. purely local. Therefore, I don't think it reflects bad protocol design.

If it would be better to use the STATUS.indication method then the VSPECIFIC.confirm, I would accept that. I believe some sort of MLME-to-SME indication is desirable.

Adrian: while I can almost believe there’s some value in VSPECIFIC-STATUS.indication for the unicast case, I’m afraid I can’t convince myself there’s any value in the broadcast case. The point is that, in the unicast case, there’s a reasonable likelihood that something that a WAVE STA receives at its lower MAC will eventually hit the SME. Most processes for discarding acknowledged management frames (e.g. Class filtering, protected management frame filtering) don’t exist in the WAVE case. But for the broadcast case, knowing you transmitted a frame tells you nothing with any degree of certainty about whether it was received.

If I'm still missing something due to my effort to get this out, I apologize.

Cheers,

John

On Wed, Jan 5, 2011 at 11:51 PM, Stephens, Adrian P wrote:Hello John, Please see below. You are certainly right that there are .confirms in 802.11 for purely local MLME actions.I distinguish two types here:1. The local MLME performs some purely local action and responds2. The remote MLME delivers some indication to the remote SME, the remote SME responds.The local SME needs to understand that response before it can continue with its own protocol. In one case the response comes from the local MLME indicating how it performed the servicerequested. On the other case, the response comes from the peer SME indicating, by way ofboth MLME entities. A .confirm at one end should always be paired with a .response at the other end. UNITDATA is not a counter-example. There is no UNITDATA.confirm in REVmb D6.0. Please also see below. Best Regards, Adrian P STEPHENS

From: John Kenney Sent: Wednesday, January 05, 2011 6:10 PM To: Stephens, Adrian PCc: Alastair Malarky; George VLANTIS; Lee Armstrong; Roy, Richard; Landt, Jerry; McNew Justin; FSIMON; ckain; dkavner; rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Dorothy Stanley; Jon Rosdahl; GPRUITT; John Moring; tkstds Subject: Re: 11p roll up (D6.01) comment resolutions



Hi Adrian,

Thanks for this extra detail. It helps quite a lot.

However, I am still confused. You write:

"In discussing CID 1157, the group educated itself in the meaning of the .request/confirm primitives. Specifically the .confirm is not a confirmation of delivery, but a response of the remote MLME operating a defined MLME protocol. e.g. the local MLME says “please do X” and the remote MLME says “yes, I did X, and here’s the result”. "

Adrian: I confused the issue. It is not the remote service provider, but the remote peer you are talking to, using the MLME service.

I agree that the .confirm is not a confirmation of delivery. But, I dont' follow the rest of the statement. It does not match my understanding of how the .confirm is used for VSPECIFIC in 802.11-2007 (or for any of the subclause 6.3 primitives in 802.11REVmb). The .request primitive is not a local MLME saying to a remote MLME "please do X". Rather, it is a local SME saying to the local MLME "please do X". (in this case X is "send a VS action frame"). As 6.3.1 states, "the services provided by the MLME to the SME are specified in this subclause." The VSPECIFIC.confirm is meant to convey to the SME whether the MLME successfully executed the request to transmit the VS action frame, not whether some other STA received it.

Adrian: Yes, I understand the point. You are trying to create a “half-way” between an asynchronous action and a synchronous one.

For an asynchronous action, there is no protocol that tells when whether and when the action has any effect. Typically you might have a higher layer protocol in operation (e.g. TCP Ack over unreliable 802.11 UNITDATA).

For a synchronous action, the SAP at the receiving end has both .indication and .confirm primitives. The remote peer is informed by the remote service provider that you want to do X, it scratches its head, and says, “yes, I did X”.

For example, a local SME wants to set up a TSPEC. It uses the Add Tspec service of the MLME to ask the remote SME if it will accept a new TSPEC. The remote SME scratches its head, consults its schedule of allocated TSPECs and decides whether to admit the request. It is only when the remote SME completes this action that the .confirm is generated, which appears eventually at the local MLME-SAP as a .confirm. The semantics of the .confirm indicate that the remote SAP has taken some action, not that the request for some action has been delivered to the SME.

You want a half-way house, where the .confirm does not have a matching .response, and where it indicates only that the request frame reached the lower layers of the MAC, without guarantee that the frame ever made it to the SME, or that the SME could do anything with it, or that the SME has completed processing of any request it contains.

IMHO this is bad protocol design. You should follow a fully synchronous or a fully asynchronous model.



I see value, in general, in having the local MLME confirm to the local SME the success or failure of its ability to execute the requested operation. I again use the analogy of the MA-UNITDATA request/confirm pair of primitives. The .request is for the transmission of a data frame. The .confirm indicates whether the transmit operation requested was successfully executed, not whether the transmitted data frame was successfully received by another STA.

Adrian: This is a poor example, because 802.11REVmb does not have a UNIDATA.confirm.

Perhaps a better analogy is the MREPORT.request/.confirm pair of primitives defined in 6.3.16, since these are also SME:MLME, not data plane. Again, the .confirm "reports the result of a request to send a Measurement Report frame" (not to report the success or failure of reception of said frame).

Aridan: You are right to call attention to this as supporting your case.

See Figure 6-4 in REVmb D6.0

This nicely highlights what I believe to be an incorrect use of these primitives (and you can be sure that there will be a sponsor ballot comment to address this in the next round).

The substantive point is the lack of synchrony between the measurement request completed box in bottom left and the mreport.confirm. What protocol can the .confirm event meaningfully drive in the right hand SME? It knows nothing of the effect of the .request on the peer SME.

That this section is inconsistent is highlighted by the .confirm parameters:



Where does VendorSpecificInfo come from?

So, I fear we may be talking past each other. I may be missing something in your explanation.

Adrian: I believe I understand your point. You want a “semi-synchronous” service, where delivery from one MLME entity to the bottom of the peer MAC is synchronously indicated by the .confirm, but any effect higher than that in the stack is asynchronous.

I believe such a design is unwise. What does P1904 depend on this confirm for? What impacts does removal of this confirm have?

My guess is that either P1904 cares about subsequent effects within its own stack (in which case it will have a higher layer acknowledgement, embedded in an independent VSPECIFIC.request), or it doesn’t care (in which case the .confirm has no effect).

In both cases the .confirm can be ignored.

Thanks,

John

On Tue, Jan 4, 2011 at 11:39 PM, Stephens, Adrian P wrote:

Hello all, Please see below... Best Regards, Adrian P STEPHENS

From: John Kenney Sent: Tuesday, January 04, 2011 11:19 PM To: Alastair Malarky



Cc: George VLANTIS; Lee Armstrong; Roy, Richard; Landt, Jerry; McNew Justin; FSIMON; ckain; dkavner rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Stephens, Adrian P; Dorothy Stanley; Jon Rosdahl; GPRUITT; John Moring; tkstdsSubject: Re: 11p roll up (D6.01) comment resolutions

Hi Alastair,There are two things I don't understand about the editor's action.

First, I don't understand if he undertook this on his own advice, or if it was deemed necessary by him to resolve an inconsistency between 11p and prior REVmb comments. This "confirm" primitive was defined by 802.11-2007, not by 11p. It was removed from REVmb prior to the 11p roll up. So, this probably has little to do with 11p; our changes were minor. I assume there was a REVmb comment that caused it to be removed, but the editor does not cite it. I'd like to know what the comment was.

Adrian: The comment was:

comments

Selected CID Page Clause Resn Status Comment Proposed Change Resolution Owning

Ad-hoc

0 1157 538.21 10.3.29.2.2 P The procedure for Vendor Specific Action frames is not particularly clear, but there does not appear to be any response from the peer entity expected, beyond the MAC layer ACK. So, this should follow the X.210 model for connectionless service, which has no .confirm primitive, perhaps (in which case, delete the .confirm completely). But, at the very least, there is no concept of a TIMEOUT or TRANSMISSION_FAILURE response to the request.

Delete TIMEOUT and TRANSMISSION_FAILURE as valid values for the ResultCode. (Or, delete MLME-VSPECIFIC.confirm completely.)

AGREE IN PRINCIPLE (ARCHITECTURE: 2009-11-18 20:10:17Z) Delete MLME-VSPECIFIC.confirm completely.

EDITOR

Adrian: As .11p were making minor changes to material that had already been removed, I had to resolve a conflict. The only way I could reasonably resolve the conflict was to ignore the changes made by .11p.

Second, I don't understand the reasoning itself. I view the request-confirm pair of primitives here to be analogous to that of the MA-UNITDATA primitives, except that this is in the management plane. The SME issues a frame transmission request. The MLME replies with a confirm that provides the result of the transmission request. The editor's resolution implies that a confirm is only useful if there is an exchange of MMPDUs. I don't agree. The purpose of the confirm primitive is limited to reporting the result of the transmission request. I also don't understand



why the editor's reasoning would not apply equally to the MLME-Timing_Advertisement.confirm.

Adrian: In discussing CID 1157, the group educated itself in the meaning of the .request/confirm primitives.

Specifically the .confirm is not a confirmation of delivery, but a response of the remote MLME operating a defined MLME protocol. e.g. the local MLME says “please do X” and the remote MLME says “yes, I did X, and here’s the result”.

For the VSPECIFIC case, there is no MLME protocol associated with it. I suppose you might define a protocol with a new vendor specific confirm action frame, which is sent in response to a vendor specific action frame. But as of today, no such protocol exists, so there is no arrival of an MMPDU (i.e. event visible to the MLME) on which to hang the VSPECIFIC.confirm event.

OK, I accept we’re not that purist regarding events that drive the MLME. We do have occurances of arrival of an ack frame triggering state changes in the MLME. (in the new 10.3). If 1609 really need to know this, we also need to debate whether the use of this event is safe, i.e. whether it is possible for the local MLME to receive the Ack, but the remote MLME not to generate the .indication.

I'm obviously confused by this rejection. Perhaps there is indeed a good reason for it, but I don't get that reason from the editor's resolution. I'd be inclined to ask for a more specific resolution, including a citation of a REVmb comment, or to change the resolution to Agree and reinsert the primitive.

Adrian: As Editor I would argue that re-instating primitive (i.e. one not currently existing in the REVmb draft) cannot happen as a side-effect of an indicated minor change to that primitive shown in the .11p draft. That’s why I resolve the roll-in conflict the way I did.

However, we are now having that technical debate, and if the group decides now it should re-instate the primitives, it can change the resolutions of comments 10560 and 10006. As Editor, clearly, I’ll do whatever the group tells me to.

If I was present, as technical contributor, I would oppose because the logic behind the resolution of CID 1157 still stands.

If the group decides that the use of the ACK is safe, then it could follow the model of the MAC data service and define an MLME-VSPECIFIC-STATUS.indication

to carry this event. If the use of the ACK is not safe (i.e. it is misleading because some protocol between generation of the Ack at the receiver and generation of the VSPECIC.indication allows the event to get “swallowed”), we will have to define a new action frame to carry the response, or P1609 will have to define a higher layer Ack based on the use of the MLME-VSPECIFIC.request.

I am also glad you pointed out that the removal of the primitive has implications for the 1609 standards.



Thanks,John

On Tue, Jan 4, 2011 at 10:47 AM, Alastair Malarky wrote:

Agree with George's view of comments.

With respect to comment 10560 (MLME-VSPECIFIC.confirm), the editor's reasoning for rejecting the inclusion of this primitive is that:

The purpose of .confirm primitives is to present the result of an MLME protocol that involves the exchange of MMPDUs. As there is no MLME protocol associated with VSPECIFIC, i.e. the requester has no way of knowing if a "higher layer management" response is required, and no way of associating any received Vendor Specific action frame as a response to one it transmitted, this is not possible.

Within the 802.11 defined MLME this statement may be true but since it is a Vendor Specific Action frame, the "vendor" (who could be a protocol standard body such as 1609) can define a protocol that involves the exchange of MMPDUs using the vendor specific action frames and include any required association within the VendorSpecificContent. Thus I don’t necessarily agree with the rejection, however I don't know if deleting the .confirm from 802.11 is a significant concern either - does anyone else have thoughts on this?

I believe we based 1609.4 on the basis there is a MLME-VSPECIFIC.confirm primitive - so there will be a change to 1609.4 if it is eliminated.

Note we will already have to make change(s) to 1609 due to the proposed change from dot11OCBEnabled to dot11OCBActivate

Alastair Malarky

-----Original Message----- From: George VLANTISSent: Monday, January 03, 2011 6:35 PMTo: Lee Armstrong; John Kenney; Roy, Richard; Alastair Malarky; Landt, Jerry; McNew Justin; FSIMON; ckain; dkavner; rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Stephens, Adrian P; Dorothy Stanley; Jon Rosdahl; GPRUITTSubject: RE: 11p roll up (D6.01) comment resolutions

Hi Lee,

I reviewed the three bullets in the "Issues needing discussion and/or resolution approval" section of your attached document, and we knew at the time that we were working on 802.11p in Working Group Letter ballots and Sponsor ballots, that these changes were either coming or had completed in 802.11mb, so most of these I didn't comment on (possibly with the exception of the "emissions behavior set", but I'm in agreement with the spirit that the references are good enough). Of the comments that I did submit, the ones that were rejected were my error, and the others ("accepted" or "accepted in principle") I'm OK with.



I read the resolutions in the comment resolution spreadsheet at the tail of your attached document. The treatment by the 802.11mb CRC appears to be OK, with the obvious exception of the last row, which remains unaddressed. If true, the commenter's requests seems reasonable to me. The 802.11mb CRC's treatment of this one remains to be seen.

Thanks for pulling everything together. I hope everything has worked out well from your personal issues last month. I wish you (all on copy) good health in 2011.

Cheers.

-----Original Message-----From: Lee Armstrong Sent: Monday, January 03, 2011 6:03 AMTo: John Kenney; Roy, Richard; amalarky; Landt, Jerry; George VLANTIS; McNew Justin; FSIMON; ckain; dkavner; rdroebuck; dale.sumida; Vinuth Rai; daniel.jiang; fan.bai; Stephens, Adrian P; Dorothy Stanley; Jon Rosdahl; GPRUITTSubject: 11p roll up (D6.01) comment resolutions

To all, First, I wish you all a happy new year. I apologize for being very late with this; I had some personal problems that took me totally out of action last month, including missing the TGmb teleconference that discussed the D6.01 comment resolutions.

As part of my D6.01 comments, there were several things that I thought were OK in D6.01 but differed from the 11p amendment and needed to be approved by the core TGp members (verify that these changes are acceptable).

This doesn't require any sort of formal vote; just let me know if D6.01 is OK in these areas. In addition, a few of the comments were rejected during the teleconference, some of which I want to identify not because I disagree with the resolution, but I want to make sure that those (most) of you who missed the teleconference are aware of the results and have a chance to speak out (to me, not necessarily to TGmb) if you disagree with the resolution. The attached document {added into the end of this document by TGmb Secretary} summarizes the items that I want you to consider. As far as I am aware, all of the TGmb comment resolutions are good, no further changes need to be made, but since I submitted most of these comments, and was attempting to speak as much for TGp as for myself, I would appreciate it if each of you would verify that these conclusions are correct. Some of my comments are unresolvable, such as by stating that TGp members need to review an item. For these and a few others, a lack of feedback from any of you will result in these comments being accepted or retracted by me. This is not a time to produce new comments; we are simply addressing the resolution of existing comments. The next TGmb teleconference on 7 January will conclude this comment resolution process and prepare them to move on with the rollup of other amendments prior to the official sponsor ballot. I thus need any feedback you can give me before 7 January. Regards,



Lee ArmstrongArmstrong Consulting, Inc.



The document that was attached to Lee’s Email follows:

11p roll-up issues to be agreed upon before January 7.

Background: TGmb is attempting to accelerate the roll-up process to better manage the number of

amendments that are currently ready, or will be ready shortly. 802.11 D6.01 contains the 11p roll-up and WG members were asked to provide comments. The comments received, and the proposed resolution to each, are provided in 11-10-1455-01-

000m-revmb-sponsor-ballot-editor-comments The D6.01 comments were discussed during a December 17 TGmb teleconference. Final approval of these comment resolutions is expected during a January 7 teleconference. This comment and resolution process does not replace the normal balloting, but is intended to

make the balloted document more error free and simplify the balloted comment resolution process.

TGp is in never-never land, it is not officially active but not totally eliminated either. In other words, if we decide we need some meeting time, either face-to-face or via teleconference, we can do it. Considering the logistics of doing this however, it would probably be simpler to just have an informal ad-hoc talk amongst ourselves.

Issues needing discussion and/or resolution approvalOther than specific comments to be described below, Annex D has been significantly modified due to the impact of other amendments. Most of the material relative to 11p has been removed or significantly altered resulting in the specific issues described below (Note that Annex, Table, and subclause numbers are changed from 11p).

Former Table I-2 (Emissions limits sets) was removed. To accommodate 11p, the new Table D-1 (Regulatory requirements) was modified to include the appropriate FCC references. Is everyone OK with the change as it now is? Not what was in 11p but it should be good.

Table I-3 (Behavior limits sets) went through a major change, no longer looking like the old one. The editor tried to include the 11p limit sets within the new structure (the FCC references are now included in Table D.1). Is everyone OK with the way that the new structure supports at least the intent of the 11p changes?

Annex D.2.2 (Transmit power levels) has been modified again, between the drastic changes in D6.0, to something close to what 11p was requesting. Adding the actual power levels back solves a major problem we would have had with respect to the FCC rules referencing a standard rather than including power levels in the ruling. Make sure that the current content satisfies all concerns. We need to watch the results of sponsor ballot on this as the same comments that removed the tables could demand that they be removed again.

Comments from review of D6.01 that require consideration by us are in the following table. These are probably OK as agreed upon during the TGmb telecom, but now is the time to speak up if you disagree.



Page Line No.

Comment / Explanation

Recommended Change

56 In REVmb last sentence of the 2nd paragraph, a statement of 802.11p amendment is missing

After “…from the core QoS facilities.”, 802.11p amendment specifies the following text: “A comprehensive statement on mandatory and optional functionalities is available in Annex B; ….”

DISAGREE (EDITOR: 2010-12-17 15:24:38Z) - This sentence was not modified by .11p. The cited sentence was removed by CID 1415. The BRC believes this change is not inconsistent with the .11p roll-in.

EDITOR: 2010-12-17 15:26:59Z -

Discussed in telecon and resolution rewritten.

EDITOR: 2010-12-17 07:30:44Z

The PICS is not definitive as to mandatory/optional features. So we have two separate issues here:

1. The accuracy of the edit - I accept I didn't make the edit, although .11p was at fault for not showing change marking.

2. The accuracy of the statement.39 Editor note re

changes to table for"peerMACAddress" row.

We need to verify with all TGp members that we made an error here and that it is OK to remove the group address references.

AGREE IN PRINCIPLE (EDITOR: 2010-12-17 15:48:08Z) - remove "or group" and "or group of". The TA cannot be a group address, and it is the TA that maps onto this parameter. This change will be incorporated in the next draft and posted to the .11 website and all .11 working group members, including former .11p members can review this change and all other changes related to the incorporation of .11p.

EDITOR: 2010-12-17 15:51:01Z -

Request TGp members to review edited draft containing this change.

EDITOR: 2010-12-17 09:07:06Z

I don't believe that the confirmation of TGp members is necessary. It is a clear and obvious mistake - i.e. the TA cannot be a group-address, and it is the TA that maps onto this parameter.

54 Text is not exactly like that of 11p, could or could not be important depending upon how others percieve it. The word "is" is used in place of "shall".

Just need to verify that this change is acceptable with all.

AGREE (EDITOR: 2010-12-17 15:54:02Z) -

The change from "shall" to "is" was done to provide compliance to the WG11 style guide. There is a single "shall" in Clause 8 that makes any subsequent shalls unnecessary.

EDITOR: 2010-12-17 09:15:05Z

Change from "shall" to "is" made to be consistent with WG11 style.

8 In REVmb last sentence of the 2nd paragraph, a

Add DISAGREE (EDITOR: 2010-12-17 09:47:53Z)



statement of 802.11p amendment is missing

The convention I'm using is that the entire subclause is tagged 11p by tagging the heading.

1631 30 Editor's Note valid, but reference was specifically added to satisfy members desires

Can delete reference but would request that such changes be specifically identified for future review/balloting considerations (is this reasonable?)

AGREE IN PRINCIPLE (EDITOR: 2010-12-17 16:25:42Z) - See resolution of CID 10585.

Additional information: the enumeration variable "Table 17-13" creates an ASN.1 syntax error when compiling the MIB: 1) embedded space; 2) hyphen in name. So if we attempt to continue making this look like a reference, we have to convert it into something that is a valid enumeration name. A better alternative would be to put the references into the description.

EDITOR: 2010-12-17 16:25:56Z -

TGmb chair will draw attention of former .11p members to this resolution.

EDITOR: 2010-12-17 10:32:37Z

There's another comment resolution (CID 10585) that proposes a change.

Additional information: the enumeration variable "Table 17-13" creates an ASN.1 syntax error when compiling the MIB: 1) embedded space; 2) hyphen in name. So if we attempt to continue making this look like a reference, we have to convert it into something that is a valid enumeration name. A better alternative would be to put the references into the description.

1680 Removal of previous Table I.2 causes some problems

Allow TGp to create a recommended solution

UNRESOLVABLE (EDITOR: 2010-12-17 16:33:00Z) -

The commenter does not identify a specific problem or provide a specific change.

EDITOR: 2010-12-17 10:36:28Z

Discuss how we should respond to this.

1683 8 In REVmb, Table D-3 is out of context with no reference. The “2007” Table included the 5.xx GHz spectrum. “11p” added “5.85 – 5.925”. The 4 first items were removed in REVmb leaving only the 11p amendment.

At the minimum the suggested text of D.2.2, 2nd paragraph is as follow: “The transmit power level for regulatory domain is shown in Table D-3 and the maximum allowable STA transmit power for ITS non-mobile in the U.S 5.85-5.925 GHZ band are shown in Table D-4.”


doc.: IEEE 802.11-10/1416r2 · Web viewTGmb Teleconference Minutes Dec 2010 –Jan 2011 Date:...

Documents

Transcript of doc.: IEEE 802.11-10/1416r2 · Web viewTGmb Teleconference Minutes Dec 2010 –Jan 2011 Date:...