Doc.: IEEE 802.11-08/0843r0
IEEE P802.11
Wireless LANs
|Task Group U Meeting Minutes for |
|March 2007 Plenary Session (Denver, Colorado, USA) |
|Date: 2008-07-14 |
|Author(s): |
|Name |Affiliation |Address |Phone |email |
|Matthew Gast |Trapeze Networks |5753 W. Las Positas Blvd |+1 925 474 2273 |msg@ |
| | |Pleasanton, CA 94588 USA | | |
| | | | | |
Monday, July 14, 2008
Chair: Stephen McCann
Recording secretary: Matthew Gast
Call to order and agenda
Meeting called to order on Monday, July 14, 2008 by Stephen McCann at 4:01 pm Mountain Daylight Time (MDT). The chair then reviewed the following topics from the agenda:
• The agenda is document number 11-08/0721r1
• The chair displayed the IEEE patent policy
o The membership had no questions on the policy
o The chair requested information on essential patents, patent claims, and pending patent applications and called for letters of assurance. No response was made to the call
• The chair also noted the affiliation FAQ, anti-trust FAQ, ethics code, IEEE 802.11 policies and procedures, and IEEE 802 policies and procedures
• The chair reminded attendees to record attendance
• After discussion, the agenda accepted by unanimous consent
Approval of previous meeting minutes
• May 2008 interim meeting, Jacksonville, Florida USA (11-08/0596r1)
o The chair asked for corrections; none were required
o The chair requested approval by unanimous consent
o There was no objection from the task group, so the minutes are approved
• June 2008 ad hoc, Southampton, United Kingdom (11-08/0719r0)
o The chair asked for corrections; none were required
o The chair requested approval by unanimous consent
o There was no objection from the task group, so the minutes are approved
Presentation: 11-08/0839r0, Locational Protocol info ID, Gabor Bajko
• Kapil Sood: What is the purpose of providing the location information to the client?
o Gabor Bajko: To get the location and show its position on a map.
• Necati Canpolat: Does this function need to use native query?
o Gabor Bajko: With native query, you can get info from the AP. I assume location is one thing that would be native to the AP.
• Kapil Sood: How is this a use case? The airport already has location information. How does this enhance the client?
o Gabor Bajko: You can have the airport floor plan on the mobile device.
• Stephen McCann: Has this been proposed in TGv or discussed with TGv participants?
o Gabor Bajko: There is no overlap with the work done in TGv.
Straw poll (4:50 pm): Are you interested in this presention and would you like see normative text?
• Vote: 7 – 0 in favor of seeing more developed text.
The task group recessed into ad hoc mode for comment resolution at 5:08 pm.
Tuesday, July 15, 2008
Chair: Stephen McCann
Recording secretary: Matthew Gast
Call to order and agenda
Meeting called to order on Monday, July 14, 2008 by Stephen McCann at 10:33 am Mountain Daylight Time (MDT). The chair called for presentations and then reviewed the agenda:
The task group began working on comment resolutions in document 11-08/0722r2, and began discussing comments marked for more detailed discussion in that version.
• CID 643
o Necati Canpolat: This comment should be rejected the comment because it is wrong.
o Dave Stephenson: The "interworking service" only refers to permissions over the SSPN interface and enforcement of those permissions. It can't mean GAS, because STAs need do to GAS.
o Dave Stephenson: Perhaps we should name the function "SSPN interface management"?
o Necati Canpolat: The note refers only to the box in Figure 5-10.
o Dave Stephenson: We also do not describe mobility management, so we should remove that block.
o Stephen McCann: I made the proposal in WNG for the mobility management because we have the block in the TGu draft.
o Dave Stephenson: MSGCF doesn't provide mobility management, so we should not have it.
o Dave Stephenson: Propose deleting mobility management and renaing interworking service management to "SSPN Interface Management"
o Necati Canpolat: If we do that, we need to remove clause 21.4.
o Matthew Gast: The "imminent transition" and predictive link failure indications are required for the convergence function.
o Necati Canpolat: What is the harm of including this box?
▪ Stephen McCann: This has no implementation effect.
o Gabor Bajko: Much more information is required to have mobility management
o Stephen McCann: Could we call the box "ESS management"?
▪ Matthew Gast: ESS Link management to be consistent with the spec.
o Dave Stephenson: The main change is the convergence function. Leave it, but remove everything else.
o Straw poll (11:17 am): Should this comment be resolved by changing Figure 5-10 to remove the "Mobility Management" and "Interworking Service Management" boxes, and correct clause 21 appropriately?
▪ Result: 9 for – 0 against
• Comment bucket 438
o The technical editor needs to work with the working group editor to ensure conformance with diagrammatic conventions
• CID 613
o Dick Roy: This is a circular definition, and the use of "native" is a bad word.
o Dave Stephenson: Alternate proposals should be circulated on the reflector to gain consensus.
o Necati Canpolat volunteered to produce a new name.
• CID 86
o Dick Roy: Why is this function even in the 802.11 scope? We define OTA functionality, but we should not define the type tags. Defined classes for this function are irrelevant to the rest of the world, e.g. 802.21.
o Stephen McCann: If we do not, who will define these tag values? The task group tried to find an external source for a list of tags, but could not. As far as we could tell, there is no external definition of these ideas.
o Dick Roy: Other groups must be doing this work. 802.21 is a start. If the first comment on this list is that there is not enough number space, that shows that there is a problem already.
o Dave Stephenson: This group's charter is to work with external networks. We need to provide information about what we're connecting to.
o Dick Roy: This question is who provides the detail on the networks. In 11p, we went to the SAE because that was the right place to go.
o Dave Stephenson: 802.11 is the only body that can provide things in the contents of Beacons and Probes.
o Dick Roy: Has 802.21 identified this as a need?
▪ David Cypher: 802.21 has a vendor-specific type, but it is not very flexible.
o Dave Stephenson: The concept of this feature was to separate broadly into buckets. These are supposed to be for a very coarse sort.
▪ Gabor Bajko: This may not be specific enough
▪ Matthew Gast: If these are not specific enough, then a station can do a .21 query.
o Dave Stephenson: If some SDO wants to define lots of network types, that is fine. We can add that into MAC any time we want.
o Necati Canpolat: We need to cut down on sponsor ballot comments
o Dave Stephenson: We could create an informative annex that describes example implementations
o Dick Roy: Is the T-Mobile network an ES net?
▪ Matthew Gast: No, because it is a general-purpose network.
▪ Dick Roy: Most chargeable public networks are required to be ES networks.
o Dick Roy: You might want to have a classification that allows for emergency services in addition to the underlying network type.
▪ Gabor Bajko: That is not feasible. You need a VoIP provider plus network access. This function cannot indicate application-layer presence.
The task group rececessed at 12:31 pm.
Tuesday, July 15, 2008
Chair: Stephen McCann
Recording secretary: Matthew Gast
Call to order and agenda
Meeting called to order on Monday, July 14, 2008 by Stephen McCann at 4:05 pm Mountain Daylight Time (MDT). The chair called for presentations. Hearing none, the group continued with comment resolution.
Comment Resolution
• Continuing discussion of CID 86
o Gabor Bajko: We can call the "network type" to be "IEEE 802.11 network type"
▪ Dave Stephenson: How about "IEEE 802.11 network category"
o Stephen McCann: What about venue type?
▪ Necati Canpolat: They are from a building code document.
▪ Dave Stephenson: Venue type is a property of the building, but network type depends on the type of network.
o Dave Stephenson: How many bits is it?
▪ Gabor Bajko: I am happy with 4.
▪ Dave Stephenson: This is in Probe Request/Response, you need to have bigger probes.
▪ After discussion, the task group decided to leave as 4.
o Two submissions are required to resolve this comment
▪ One submission will change the name and make it consistent, to be produced by Gabor Bajko.
▪ A second submission will add an informative annex on implementation, to be produced by Stephen McCann and Dave Stephenson.
• CID 914
o Dave Stephenson: The NASR definition should refer to 7.3.3.5.
• CID 916
o Description is required in the CID 86 informative annex
• CID 87
o Commenter to produce submission
• CID 23
o Gabor Bajko: There is a contradiction. Many of these network type codes have no meaning if Internet bit is zero.
o Dave Stephenson: D2.02 had a statement that the Internet/Intranet bit applied only to free public networks.
o Matthew Gast: The internet bit applies only to free and chargeable networks
• CID 66
o Text to address this comment will be added to the CID 86 informative annex.
o Dave Stephenson: Where does this text go?
▪ Necati Canpolat: This should be added to Annex T with a new subclause for network selection
• CID 447
o Necati Canpolat: All this information should be put in a native query. You can get ESO from scanning, but you would need to send native query to learn about other networks
o Outline of submission
▪ Use a reserved bit to indicate support for ES. ES access may be provided through a network that only supports ES, or a network that can support ES in addition to other traffic
▪ If Probe Request has a class of emergency, APs respond if they are ESO or if they support ES.
▪ Revise 11.1.3.2.1 and add a MIB variable
• CID 863
o Stephen McCann: L3 access is required to interface with the LoST database
▪ Dave Stephenson: That can be provided through GAS
▪ Gabor Bajko: If you put the number in the AP, there is liability
▪ Matthew Gast: If the network breaks with the LoST server, there is liability
▪ Dave Stephenson: AP can fetch number from LoST server and then provide locally
The meeting recessed at 6:01 pm.
Wednesday, July 16, 2008
Chair: Stephen McCann
Recording secretary: Matthew Gast
Call to order and agenda
Meeting called to order on Wednesday, July 16, 2008 by Stephen McCann at 1:31 pm Mountain Daylight Time (MDT). The chair then reviewed the following topics from the agenda:
• The new agenda is 08/721r2.
o The chair called for presentations, and the following presentations were added to the agenda:
▪ State 1 location query (11-08/887r0)
▪ QoS Map in Reassociation Response (11-08/894r0)
▪ SSP domain name query (11-08/0890r0)
o The revised agenda was approved by unanimous consent
Approval of minutes from past meetings
• Monday, July 14, 2008 ad hoc meeting, Denver, Colorado USA (11-08/0829r0)
o The chair asked for corrections; none were required
o The chair requested approval by unanimous consent
o There was no objection from the task group, so the minutes are approved
September ad hoc meeting planning
• The chair requested permission from the group to show a slide not in the standard format. No objection was heard
• Donald Eastlake is organizing an ad hoc on Lihu'e, Kauai from September 3-5
o 5 task group participants indicated interest
Liaisons
• WFA Public Safety
o Necati Canpolat was not present to report
• 802.1af
o Comments received have been placed in an IEEE 802.11 document as 11-08/885r0
• NENA
o Comments received have been placed in an IEEE 802.11 document as 11-08/884r0
o Gabor Bajko: We have met requirements without specifying HELD or DHCP.
o Gabor Bajko: I put a comment in the LB that terminals should use LoST to use database to download the emergency number. That would address comment #3 from NENA.
▪ Dave Stephenson: APs should retrieve data from LoST, which would be more scalable. We should use the same format as LoST.
▪ Gabor Bajko: This is not more scalable, because LoST data has a TTL. When the TTL expires, there is a need to retrieve from the LoST database. The cache is up to 256 seconds. LoST is like DNS, but for PSAPs.
▪ Dave Stephenson: How often do emergency dialing digits ever change?
• Gabor Bajko: NENA doesn't allow that kind of assumption.
▪ Gabor Bajko: This is like caching DNS.
▪ Gabor Bajko: Explain this problem to Mark Linsner. We need to allow unauthenticated stations to download data from LoST server
o Comment #4
▪ Gabor Bajko: If client can access ES URI from LoST, then you need to connect to network.
• ATIS
o After reviewing their comments, it was decided to coordinate the TGu response with TGv due to overlap with location
• 3GPP
o Update from George Bumiller
▪ CT1 is finishing R8
▪ The next meeting is in Budapest, from August 18-22
▪ Draft needs to be published to get discussion going with 3GPP
• It may also be useful to have a description of the current draft that explains functions of GAS
o Gabor Bajko: That is a good step 2, but we first need to identify the work item and attach a requirement to it
o George Bumiller: TS 24-234 has interworking attributes.
o Stephen McCann: Karen Kenny, associate director of IEEE, said it was OK to send draft. However, 3G will not post it to their server because it is IEEE copyright.
o Gabor Bajko: TS 24-234 has zero requirements. TS 23-234 has requirements, and it states that legacy devices are required to be supported. You need to get SA2 to revise the requirements.
▪ George Bumiller: SA2 said that CT1 is the correct group.
▪ Gabor Bajko: Withotu requirements, this is useless.
o George Bumiller: If we can publish our draft, that meets their policy requirements.
Motion (2:47 pm): "Move that IEEE 802.11u requests the IEEE 802.11 WG chairman to request that IEEE-SA publishes IEEE 802.11u Draft D3.0 as soon as is practical, knowing that it has passed the 75% approval threshold."
• Moved by George Bumiller, seconded by Dave Stephenson
• No debate on the motion
• Vote: 4 in favor – 0 against – 0 abstention
• Motion passes
• Emergency Services workshop #5, Vienna, 21 Oct 2008
o Agenda expected September 2008
• Liaison strategy
o Gabor Bajko: This group needs relationshisps with 802.21 and 3G. Due to the efforts of 802.21 within 3G, these are linked. It is wrong to treat them in parallel.
o Stephen McCann: The task group previously decided to use the liaison format to these relationships, but we are not being invited to participate in 3G activities.
o Gabor Bajko: We should work with 802.21, possibly sending joint liaisons. TGu has not tried to have experiences with 802.21.
At 3:08 pm, the group decided to move the afternoon break from 3:30 to 3:10 by unanimous consent. The meeting recessed early, and returned to order at 3:46 pm. When the meeting returned to order, network connectivity was poor and several members were prevented from logging attendance.
Comment Resolution, 11-08/722r5
• CID 863
o Stephen McCann: Should we harmonize encoding of formats of dial strings with LoST?
o Dave Stephenson: LoST is an internet draft.
o Gabor Bajko: LoST is in the RFC Editor Queue (see Internet-Draft page), and therefore is stable.
o Matthew Gast: The format is XML, and native query responses do not fragment. Will the LoST response always be small enough to fit in a single response?
The meeting recessed at 6:01 pm
Thursday, July 17, 2008
Chair: Stephen McCann
Recording secretary: Matthew Gast
Call to order and agenda
Meeting called to order on Thursday, July 17, 2008 by Stephen McCann at 10:31 am Mountain Daylight Time (MDT). The chair then reviewed the following topics from the agenda:
• Attendance reminder
• Agenda is 11-08/0721r2.
o In response to a call for presentations, the chair added a presentation by Gabor Bajko
• Motions are stored in 11-08/0723
• The secretary announced that his employer, Trapeze Networks, has been acquired by Belden. However, Trapeze Networks will continue to operate as a wholly-owend independent subsidiary, so no affiliation change is necessary.
Presentation: 11-08/0887r0: Proposal for Native GAS Query for AP Location, Dave Stephenson & Gabor Bajko
• Stephen McCann: This uses a recognized format for location.
• Mike Montemurro: This is a good thing to add.
Motion (10:46 am): "Move that IEEE 802.11u approves document 11-08-0887-00-000u-state-1-location-query.doc, and request the technical editor to incorporate it into the IEEE 802.11u draft document."
• Moved by Dave, seconded by Gabor
• No debate on the motion
• Vote: 7 in favor – 0 opposed – 1 abstention
• Motion passes
Presentation: 11-08/0894r0: QoS Map in (Re)Association Response, Dave Stephenson
• Comment: This addresses CIDs 729, 790, 802, 821, and 880
• Dave Stephenson: It is necessary to change variables in 7.2.3.5 & 7.2.3.7 to replace "dot11InterworkingServiceEnabled" with dot11QoSMapEnabled"
Motion (10:54 am): "Move that IEEE 802.11u approves document 11-08-0894-00-000u-lb132-qosmap-in-re-association-response.doc, with editorial updates to table 7-11 and 7-13 changing dot11InterworkingServiceEnabled to dot11QoSMapEnabled, and requests the technical editor to incorporate it into the IEEE 802.11u draft document."
• Moved by Dave Stephenson, seconded by Mike Montemurro
• No debate on the motion
• Vote: 4 in favor – 0 opposed – 1 abstention
• Motion passes
Presentation: 11-08/0890r0: SSP Domain Name Query, Dave Stephenson, Michael Montemurro, Stephen McCann, Matthew Gast, & Necati Canpolat
• Gabor Bajko: Is domain name the right thing to include in this query response? The right thing is the realm. The domain name is not something you should be authenticated against. I think we are talking about the realm.
o Answer: The abstract says that the domain is the AAA realm.
• Gabor Bajko: How does this work? If you want to find out if an AP can access , how do you use this?
o Answer: The name identifies the service that the AP will provide, via higher layers.
• Matthew Gast: The top-level DNS name is equivalent to a realm. The non-AP STA will submit the realm of its user credentials to an AP to see if it works.
o Gabor Bajko: This is a question of terminology.
o Dave Stephenson: The non-AP STA can use this as a realm. See the abstract of the presentation.
• Necati Canpolat: This may introduce a security issue. The domain name could be used for phishing. Have you thought about the ramification of domain name and potential exposure to security issues?
o Answer: This is not introducing security issues because it only works as a pre-association hint.
o Mike Montemurro: Identity is generally sent unprotected anyway, which removes security issue.
• Gabor Bajko: RFC 4284 addresses this issue. It also defines hints to provide to STAs and it uses NAI realm. That is what we should use here. NAI realm may be more than domain name. We should align terminology because this RFC was written to assist 802.11.
• Mike Montemurro: By leaving this as a domain, there might be other use cases that this can address. Realm is the case right now.
o Gabor Bajko: Regarding additional use cases, it is bad to leave it open ended.
• Necati Canpolat: Need confidence I am connecting to the right web site, especially in the case of open authentication.
• Gabor Bajko: RFC 4284 discusses security threats of such a hint, and deployment advice on mitigating against these threats.
• Mike Montemurro: To address security, you must balance usability with security. This is a usability enhancement that does not significantly change security properties because many networks are open.
o Dave Stephenson: I agree. Security is provided by authentication, not the secrecy of this information.
• Dave Stephenson: Domain and realm follow similar formats. Using a domain name can also be used as a realm. This depends on how the non-AP STA uses this information.
• Gabor Bajko: The security topic has been discussed for years. People have come to the conclusion that you must keep security in mind. I encourage everybody to read the RFC. The domain and realm are different. Realms include resources.
Straw poll (11:25 am): "Should the query response provide the domain name (per RFC 1034) as opposed to the AAA realm (per RFC 4282)"
• Vote: 9 for – 0 against
Motion (11:30 am): "Move that IEEE 802.11u approves document 11-08-0890-00-000u-ssp-domain-name-query.doc and requests the technical editor to incorporate it into the IEEE 802.11u draft document."
• Moved by dave, seconded by mike montemurro
• Debate on the motion
o Gabor Bajko: Does this go with the domain name, or realm?
▪ Answer: yes, the straw poll indicated that
• Vote: 7 in favor – 0 opposed – 1 abstention
• Motion passes
Presentation: 11-08/0915, Solution for comment 32, Gabor Bajko
• Normative text is in 11-08/0916
• Dave Stephenson: TGv has also defined a time format, and we should use the same thing between groups
• Dick Roy: How often is this going to be updated? Does the AP need to maintain UTC time?
• Stephen McCann: If this function is not regularly used, it is just a waste of bandwidth
• Dave Stephenson: We should sync with TGv's time format
o Gabor Bajko: What is the procedure for doing so?
o Dave Stephenson: We can either adopt theirs, or propose our own.
Ad hoc
• Chair: good position to do recirc after September by holding this ad hoc
Motion (12:24 pm): "Move to approve an IEEE 802.11u ad hoc in Kauai, Hawaii, on September 3-5 2008, hosted by Donald Eastlake"
• Moved by Dave Stephenson, seconded by Necati
• No debate on the motion
• Vote: 4 in favor – 0 opposed – 3 abstentions
• Motion passes
The meeting recessed at 12:29 pm, and returned to order at 1:32 pm.
Teleconferences
• The chair proposed the following teleconferences, all at 10 am Eastern time:
o 8/8 – GAS
o 8/15 – SSPN
o 8/22 – MIH & ES
o 8/29 – Others
• After discussion, the group decided on a slightly modified schedule:
• New proposal, all 10 ET
o 8/8 – Others, Editorial - 1 hr
o 8/12 – SSPN, QoS – 1 hr
o 8/19 – ES & MIH – 1 hr
o 8/26 – GAS – 2 hr
o Note: Comments on the MIB will be resolved in the September ad hoc
• Dave Stephenson volunteered Cisco teleconference facilities
Motion (1:50 pm): Move to approve the following IEEE 802.11u teleconferences
August 8 2008 : 10:00 ET [1 hr]
August 12 2008 : 10:00 ET [1 hr]
August 19 2008 : 10:00 ET [1 hr]
August 26 2008 : 10:00 ET [2 hr]
• Moved by Necati Canpolat, seconded by George Bumiller
• Discussion on the motion
o Motion (1:52 pm): Move to divide the question with two votes: one for the first two teleconferences, and a second vote for the last two teleconferences
▪ Moved by Gabor Bajko
▪ Motion fails due to lack of a second.
o No further discussion on the motion
• Vote: 3 in favor – 1 opposed – 1 abstention
• Motion passes (75%)
• Gabor Bajko: How is that vote 75% approval
o Stephen McCann: Abstention votes are neutral. Three of the four votes cast were in favor of the motion.
Timeline
• The chair proposes moving dates by one meeting cycle to meet expected recirculation by September 2008
• The group accepted the chair's proposal
Comment Resolution
• CID 25
o Gabor Bajko: ES is not only voice services. ES may also use text services or other types of payload. It also requires QoS, but QoS is not widely deployed
o Matthew Gast: QoS is widespread on air links, and is useful. Most enterprise products are WMM certified.
• Dave Stephenson concurred with the assertion.
• Gabor Bajko: Is QoS actually turned on?
• Matthew Gast: Yes. Most products enable WMM by default. QoS-enabled applications are widely used. Ask any hospital using 802.11.
o Gabor Bajko: We should forward these questions to NENA.
• Stephen McCann proposed having a straw poll to close the comment, and starting a list of comments to send to NENA for further guidance.
o Dave Stephenson proposed the following straw poll:
Straw poll (2:18): "Should the text leave dot11QosOptionImplemented is TRUE" as opposed to "dot11QoSOptionImplemented is Optional" in clause 7.3.2.59 (referenced by CID 25)"
• Result 5 in favor – 1 opposed
• CID 26
o Gabor Bajko: This text is out of scope
o Matthew Gast: You can get QoS through many mechanisms
Straw poll (2:38): Should the following text: "—Network supports end-to-end QoS from non-AP STA to all APs in ESS to PSAP. It is outside the scope of Interworking Services how this information is known to the AP" in clause 7.3.2.59 (referenced by CID 26) be:
A) left as is
B) removed
C) modified to remove "to PSAP"
• Vote: 1 for option A, 2 for option B, 1 for option C
After further discussion, the comment spreadsheet was uploaded with new comment resolutions as 11-08/0722r7.
The meeting adjourned at 3:26 pm.
-----------------------
Abstract
Minutes of the 802.11 Task Group U meeting held during the IEEE 802 Plenary Session in July 2008 in Denver, Colorado, USA from July 14th – 18th, 2008.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.