March 2007doc.: IEEE 802.11-07/0364r0
IEEE P802.11
Wireless LANs
Wireless Network Management
Ad-Hoc Meeting Minutes
March 2007
Date: 2007-03-11
Author(s):
Name / Company / Address / Phone / email
Pat R. Calhoun / Cisco Systems, Inc. / 170 W. Tasman Dr.
San Jose, CA95134 / +1 408 853-5269 /
Submissionpage 1Pat R. Calhoun, Cisco Systems, Inc.
March 2007doc.: IEEE 802.11-07/0364r0
Monday March 12 TGv adhoc session
Attendees: Allan Thomson, Dave Stephenson, Robert Miller, Dongee Shim, Jiyoung Huh, Jae Young Lee, Dorothy Stanley, Mark Hamilton, Yongho Seck, Frans Hermodsson, Ivan Reede, Charles Cook, Richard Payne,Lan wang, Xudong Wang, Lucian Sucui, Macian Sudiu, Seji Yoshida, Qi Wang, Dennis Volpano, Jari Jokela, Walter Buca, Alex Ashley, Joe Epstein
8:09am. The meeting comes to order
11-07/0285r0. Allan Thomson. This presentation addresses comment 251, which stated that Annex D was incomplete. Allan had sent Ganesh this document, which attempts to add some MIB elements we may need. Ganesh is not in the adhoc, so we cannot confirm live, but he did agree in e-mail. The first table is a wireless management table. It defines the set of TGv options that are either configurable, or implemented. There are certain TGv options that are optional, and there are certain options that are mandatory. For the latter, there is no MIB attribute stating whether it is implemented, but there is a knob to state whether support is enabled or disabled. For optional features, there is a MIB element on whether the feature was implemented.
For instance, Presence Enabled, Diagnostics Enabled, etc. We may need to add one for Jari's multi-interference detection, as this is not in the current list. This is a tabled that is indexed off the interface, which is common in MIBs. They are all boolean values, configurable are read-write, while the status ones are read-only. This would be added at the end of the SMT MIB.
Before addressing this comment, Allan asked around to determine what needed to be in the MIB (functionality in the protocol vs. what is in the proposal). The general consensus was that keepin gthe MIB as flexible as possible, but lightweight is ideal. The general consensus was this was a reasonable start.
11-07/0234r0. Dorothy Stanley. This presentation addresses comment 96, which stated that table 26 needed to be consistent with table 26 in MA. The element ID column needed a reference to the section where the element was defined. There was an additional length column added, which includes the valid length. Dorothy plans to post an r1 of the document, but wants to solicit feedback. She wants people to look at the valid length values before posting r1. This was discussed during an adhoc conference call, at which time some changes were found. Figure v80 needs to be changed from a length of 5 to a length of 16, which is only in r1. There will be additional text that will need to be changed. In r1, the changes to the length of the wireless management capablities field was removed. Please take a look at r1, and let Dorothy know if you find any errors.
Issue 348. The changes are not complete, and some of these were voted in January. Dorothy still owes text to address this comment. The document will be 11-07/0123r3.
11-07/0310r0. Dorothy Stanley. This is a spreadsheet that Emily put together with additional comments on the draft. There were many deferred technical issues. Some you could argue are trivial changes (e.g., language consistency). NOTE: A change occured in line item 42, requiring an r1 of this spreadsheet
Line item 6,page 6, is inconsistent terminology in 7.2.3.1, on page 6. This is the definition of the fields in the beacon frame. There are six new information elements, and they all have a similar language (e.g., where something is present if...). The line for multiple BSSID element, the language was different from the rest, so the suggestion is to make it consistent with the rest of the information elements.
Line item 12, page 9. This is the table that shows the elements added to the probe response. This once again changes the language to be consistent in the Multiple BSSID information element.
Line item 19. page 20. The field names do not match. The title of the first colum in table v1 doesn't match the name in figure v11. Suggest Multicast Reporting Reason
Line item 21, page 22. This is text talking about the meaning of different values of the preference field. Some of the text is also in clause 11. The suggestion is to move the text to clause 11.
Line item 42, page 68. This is where the EDCA is defined, which is also included in TGn. We need to define whether we still want them in TGv. Allan Thomson has been saying that until TGn becomes a standard, we should keep it. TGy also has it, and it will most likely get ratified before TGn. So TGn should also remove it. We should not have it in three places. The recommendation is to leave it in place until either TGy or TGn becomes a standard. The changes of either one of them NOT being ratified is small, so Dorothy would prefer to just remove it from the draft and rely on one of the other documents. Could we add a sentence to the fact that this will be removed once it is ratified in the actual TGv draft? The group agreed to add an editorial note in the draft that the text will be removed once EDCA is published in either one of the standards goes to sponsor ballot.
Line item 63, page 88. In 10.3.6.1.2, the list of MLME associate request service primitives, which lists all of the fields that can be included inthe message. The presence parameters is not included in the list, but it is included in 7.2.3.4, the definition of the associate request. The MLME is the one that is incorrect.
Line item 64, page 89. in 10.3.6.2.2, the FBMS response, the traffic generation is included, but table v11, which is the list of association response elements, the information element is missing. The recommendation is to add the missing field to table v11. The same field is also missing in table v13.
Line item 79, page 154. in 11.15.3, the last paragraph of the section is incorrect. The text does not state what the proper reason code that should be set when this error occurs. Section 7.3.2.52.5.18. has the reason code, but it's not clear which one. Allan Thomson believes that reason code 2 is the right one. Dorothy and Allan do not like the term operator for reason code 2, they will change the description from "cancelled by operator" to "cancelled"
Line item 83, page 158. In 11.15.4.3, In the presence configuration procedures, there is a sentence on page 158, line 34 that says until a sufficient time has passed since the original request. This is not well defined. If we want an interval, then let's define it, otherwise remove/change the text. What is "sufficient time", and can this be an implementation issue, hence the text could be removed? Dorothy proposes to delete the sentence. Allan believes the intent was that if an AP or STA sends a reqest for something, but for some reason the other end cannot service the request, do you want the STA to keep sending the request repeatedly, or just the STA wait a certain amount of time before trying again. It would have no way of knowing how much time has passed, and when it the proper time to request again. This is an anti-DoS mechanism. Dorothy agrees it is good implementation practice, but does it belong in the document. Allan believes it would be useful to define minimum time instead. We need to look at whether other measurement mechanisms have something similar in place, and we should try to leverage from those mechanisms - possible something in TGk. Richard Payne will look at it and get back to the group this week. If TGk has not defined anything, then we don't need to. Richard will provide the info to Dorothy. If they have a timer, then let's use it. If there is nothing, then we need to discuss this further.
Line item 89, line 164. In A.4.16, Proxy ARP is missing in PICS. We list an RRM for each capability level/function, but not Proxy ARP. Qi stated that since there is a capabilities advertisement, it implies it is optional, which will be reflected in the PICS entry. This would be an independent capability from FBMS, it will be RME 9, and the rest will be renumbered.
The remaining items, 93-95 belong to Emily Qi, and will be reviewed at a later time.
Submissionpage 1Pat R. Calhoun, Cisco Systems, Inc.