[802SEC] P802.21.1 Par Review, Review input from 802.3 ad hoc
*At its opening plenary on Monday, July 13, 2009, 802.3 chartered an ad
hoc to provide the critique of the proposed P802.21.1 PAR (Standard for
Support of Emergency Services in IEEE 802 Local and Metropolitan Area
Networks). The following is the output of that ad hoc. It is being
provided to 802.21 as the input from 802.3 as their input as due Tuesday
by 5:00 PM.
*
*Geoff Thompson, Ad Hoc Chair
*
*
5.2 Scope of Proposed Standard:*
This standard will define mechanisms that support compliance within IEEE
802 to civil authority requirements for local and national emergency
services such as citizen-to-authority (e.g. packet data encoded 911/112
calls), authority-to-citizen (e.g. emergency alert broadcasts for
weather or tsunami) and authority-to-authority (e.g. priority override).
This project does not propose a new MAC and PHY.
Scope criticisms
* The proposed scope statement does not sufficiently define the term
"civil authority requirements..."
Such requirements should be defined and available for reference
before the PAR is presented for approval.
* The proposed scope statement does not discuss what interfaces it
will work to with respect to higher layers
* The proposed scope statement does not state that it will confine
its work to the layers that are within the scope of 802.
* The proposed scope statement does not state whether or not it will
require changes to existing MACs or MAC service interfaces.
* The proposed scope statement does not state whether or not it will
work with the existing installed base of hardware.
* 802.1 is not listed as a stakeholder. In many implementations the
higher layers have no access to the MAC without going through an
802.1 layer.
Each of these points must be addressed and resolved before such a PAR
(which is attempting to stake out a new scope area) is acceptable for
consideration.
*5.3 Is the completion of this standard is dependent upon the completion
of another standard:* No *
If yes, please explain:*
5.3 criticisms
We can't imagine that this is true given the breadth of the scope as
currently presented, unless it is the intention to go all the way to the
user interface. That would be a violation of 802 scope.
This proposed standard has to do one of three things:
1. Work to existing interfaces. Ifso then they should be specified.
2. Depend on new interfaces currently being specified. Ifso then the
answer to this question is yes and that work needs to be cited
3. The work will specify new interfaces that the rest of industry
will have to accept. That needs to be stated
*5.4 Purpose of Proposed Standard: *
The purpose of this standard is to define and specify across IEEE 802
technologies: emergency calling transport functions to support
compliance to civil authority requirements, including support of the
'Next Generation E911' emergency services functionality; to support
compliance to Emergency Alert Broadcast; and to support Authority to
Authority requirements.
5.4 criticisms
We believe that the words "transport functions" refers to the
standardized reference "Transport Layer".
That layer is outside the 802 scope and expertise.
*5.5 Need for the Project: *
The emergence and rapid growth in the use of packet based voice calling
has reduced the effectiveness of emergency calling functionality
compared to that typically achieved by the traditional wireline and
cellular telecom networks. This standard will provide the underlying
transport (PHY and MAC) layer functionality to achieve parity with
traditional emergency service transport functions. This project will
also satisfy regulatory requirements for support of data encoded
emergency calls (e.g. VoIP sessions) for IEEE 802 technologies. In
addition, Emergency Alert Broadcasts have become increasingly important
and the growth in usage of 802 based services as either a primary or
only network access for users provides a need to develop a consistent
means of distributing Emergency Alerts on 802 technologies.
5.5 criticisms
It is clear that government and emergency services agencies have
expressed a need for a coordinated set of standards to address this area
of concern. It is obvious that 802 can not do the entire job. This PAR
does not describe what piece it is appropriate for 802 to do and how
that piece will fit into the overall picture.
*5.6 Stakeholders for the Standard:** *
Emergency Service authorities and government agencies (e.g. NENA, and
the equivalent bodies in ROW); IETF; other telecom, cellular and
emergency services standards development organizations (e.g. IETF,
3GPP). Within IEEE 802, the expected stake holders will be 802.3,
802.11, 802.16, 802.20 and 802.22 as potential transport alternatives
and 802.21 for related handover development.
5.6 criticisms
The term "transport alternative" is probably a bad choice of words, see
above.
We can not imagine that 802.1 is not a stakeholder in this proposed
standard. They are not shown as such.
The responses to question *7.1* are inconsistent and unsatisfactory.
This question needs to be addressed correctly.
*8.1 *Given the vast new areas that this project intends to address, we
strongly believe that substantial further explanation is appropriate.
We have not reviewed the submitted *5 Criteria* at this point but we
strongly feel that the 5 Criteria need to be reviewed and approved in
detail across all 802.
*We do not feel that this effort is ready to commence a standards
project at this time.
A more appropriate effort would be an EC Study Group to define:
*
* The interfaces that an 802 project would work to
* The precise services that an 802 project would provide in order to
make E911 services possible via 802
* What specific (non conflicting) set of requirements the project
would work to
* What changes would be required to existing 802 standards to
satisfy the new project
* Whether the 802 project would be a standard, guide or recommended
practice.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.