1. Comments on 802.23 PAR and 5C Date: 2010-03-11 Authors: March 2010
doc.: IEEE /0281r0
March 2010
Comments on PAR and 5C
Date:
Authors:
Peter Ecclesine, Cisco Systems
Peter Ecclesine, Cisco Systems

2. Abstract Comments on 802.23 PAR and 5C March 2010 March 2010
doc.: IEEE /0281r0
March 2010
Abstract
Comments on PAR and 5C
Peter Ecclesine, Cisco Systems
Peter Ecclesine, Cisco Systems

3. March 2010
PAR request form
Peter Ecclesine, Cisco Systems

4. 1.2 Type of Document Situation: Standard
March 2010
1.2 Type of Document
Situation: Standard
Complication: Noone can name the IP communications tools all the authorities are using for citizen-to-authority emergency services communications.
Question: What should be done: compile a taxonomy and architecture of emergency services data packet communications?
Answer: PAR should be for a Reference Guide, not a Standard.
Peter Ecclesine, Cisco Systems

5. March 2010
5.2 Scope
Situation: This standard defines a mechanism that supports compliance within IEEE 802 to applicable civil authority requirements for citizen-to-authority emergency services packet data communications. Specifically, it supports the need for consistent data that is required for citizen-to-authority emergency services packet data encoded session initiation requests.
A new MAC or PHY is outside the scope of this effort.
Complication: There is no evidence of the current lack of support for "civil authority requirements".
Question: What should be done: Provide references of particular requirements not being met.
Answer: Research exact requirements and include them (or references to) in the PAR.
Peter Ecclesine, Cisco Systems

6. March 2010
5.2 Scope (2)
Situation: This standard defines a mechanism that supports compliance within IEEE 802 to applicable civil authority requirements for citizen-to-authority emergency services packet data communications. Specifically, it supports the need for consistent data that is required for citizen-to-authority emergency services packet data encoded session initiation requests.
A new MAC or PHY is outside the scope of this effort.
Complication: We have kept IEEE 802 standards independent of telecommunications regulations of 185 countries. Those regulations change continually.
Question: What should be done: Should the IEEE 802 Architecture be changed to include mechanisms that support compliance with civil authority requirements?
Answer: Research exact requirements and include them (or references to) in a Reference Guide.
Peter Ecclesine, Cisco Systems

7. March 2010
5.2 Scope (3)
Situation: This standard defines a mechanism that supports compliance within IEEE 802 to applicable civil authority requirements for citizen-to-authority emergency services packet data communications. Specifically, it supports the need for consistent data that is required for citizen-to-authority emergency services packet data encoded session initiation requests.
A new MAC or PHY is outside the scope of this effort.
Complication: We have kept IEEE 802 standards independent of telecommunications regulations of 185 countries. Those regulations change continually.
Question: What should be done: Is there consistent data that is required for citizen-to-authority emergency services packet data requirements?
Answer: Research exact requirements and include them (or references to) in a Reference Guide.
Peter Ecclesine, Cisco Systems

8. March 2010
5.4 Purpose
Situation: The purpose of this standard is to support compliance to civil authority requirements complementary to IETF ECRIT specifications for citizen to authority emergency services functionality. This standard intends to encompass voice, data and multi-media requests across IEEE 802 using a new Layer 2 entity and associated behaviors and provide a uniform Structure of Management Information (SMI) for transferring required data for emergency services requests.
Complication: There is no evidence of what civil authority requirements are.
Question: What should be done: Provide references of particular requirements not being met.
Answer: Research exact requirements and include them in the PAR, or change PAR to be for Reference Guide.
Peter Ecclesine, Cisco Systems

9. March 2010
5.5 Need for the project
Situation: VoIP emergency calls are currently less effective than those provided by traditional wireline and cellular networks. Emergency calls across IEEE 802 technologies need to support regulatory requirements to assure successful completion (and all associated requirements) of these calls to the correct Public Service Access Point (PSAP), and to do so utilizing the existing set of IEEE 802 PHYs and MACs.
Complication: Today, VoIP Service Providers are meeting the regulatory requirements. There is no evidence of what regulatory requirements are not being met.
Question: What should be done: Provide references of particular requirements not being met.
Answer: Research exact regulatory requirements and include them in the PAR, or change PAR to be for Reference Guide.
Peter Ecclesine, Cisco Systems

10. 8.1 Additional Explanatory Notes
March 2010
8.1 Additional Explanatory Notes
Situation: There are increasingly uniform regulatory requirements that are being imposed on telephone systems across the world on the handling of calls to Emergency Services (911 calls in the US, for example). These requirements have been extended to cellular telephony and are being further extended to cover all cases of packet based telephony services. Voice over Internet Protocol (VoIP) is the most common of these. VoIP calls can easily originate on an 802 network. There is a need for such calls to be handled uniformly at the interface between the 802 Layer 2 network and the Internet. IETF-ECRIT is the group tasked with developing the Internet standards to meet these requirements for the upper layers of the protocol stack. This 802 effort will work with ECRIT to develop a complete solution.
Complication: Packet based telephony services are operated at the application layer does not develop packet based telephony service standards.
Question: What is the involvement of 802 with packet based telephony service?
Answer: Research exact requirements of 802 for packet based telephony service and include them in the PAR , or change PAR to be for Reference Guide.
Peter Ecclesine, Cisco Systems

11. Separating Regulation from Standards
March 2010
Separating Regulation from Standards
Situation: We have kept IEEE 802 standards independent of regulations
Complication: Regulations continually change in 185 countries
Question: How closely coupled should IEEE 802 Architecture be with packet data emergency services communications?
Answer: A Reference Guide is the way IEEE-SA collects information about alternative ways for good practice. The IEEE 802 Architecture can be informed by such a Reference Guide.
Peter Ecclesine, Cisco Systems

12. References IEEE-SA PAR Training Materials
March 2010
References
IEEE-SA PAR Training Materials
802 Overview & Architecture
This document serves as the foundation for the family of IEEE 802 Standards published by IEEE for Local Area Networks (LANs) and Metropolitan Area Networks (MANs). It contains descriptions of the networks considered as well as a reference model for protocol standards. Compliance with the family of IEEE 802 Standards is defined, and a standard for the identification of public, private and standard protocols is included.
Peter Ecclesine, Cisco Systems