[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ecrit] comments on ECRIT requirements
Comments to R1: I see the point that Andy is making. Based on the
input, I've attempted a rewrite of the motivation section to R1, yet
with some questions still of how this (autonomous case) would actually
work. We should explore the boundaries of this case.
R1. Application Service Provider: The existence of a
Application Service Provider (ASP) MUST NOT be assumed.
Motivation: The caller may not have a voice service
Provider in the traditional sense, i.e., a corporate entity that
provides voice services as a Business, or may not have any separable
voice service provider at all. Examples of these include, a residence
having its own DNS domain and running its own SIP proxy server for that
domain, a large University which may provide voice services to its
students and staff,
(yet still not be known as a telecommunication provider), or a
individual device may operate autonomously, without any additioanl
reliance on external entities, other than for the transport of
individual data packets.
Comments to A6: I think we all have a sense of what
backward-compatibility means, which (at least to me) would equate to the
idea that whatever protocol that ecrit comes up with for emergency
routing, that it'll work for legacy (pre-ecrit) handsets.
Perhaps a simpler, alternate wording is in order, such as:
A6. Backward-compatible:"> Emergency routing protocols and functions
MUST be backward-compatible for use with existing devices.
Comments to L6: I agree with the idea that there should be no
pre-ordered requirement that a "valid address" should be required, since
we're talking about more than just North America, and more than just
civic addresses. I would propose adding a separate requirement for this
one.
LX. Validation of civic addresses MUST NOT be required to enable any
feature that is part of the emergency call process.
Motivation: Emergency routing protocols must take into account location
based on a variety of forms and formats, (e.g. civic address, MSAG,
USPS, lat/lon, etc.) and be able to perform adequate PSAP routing for
the context in which the call is initiated.
Roger Marshall
-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of Abbott, Nadine B
Sent: Friday, August 05, 2005 10:09 AM
To: ECRIT
Subject: RE: [Ecrit] comments on ECRIT requirements
Andy,
I'm not sure of the purpose for your addition to requirement L6?
The purpose of location validation of civic addresses before they are
used in a call origination is to ensure that the address will result in
successful routing/mapping if used during an emergency call, and to
avoid the necessity for default routing and associated delays, if at all
possible.
This would seem to me to be a "required feature that is part of the
emergency call process" (although I think there is agreement that it
should precede any actual emergency call processing)?
Thanks,
Nadine
-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of Andrew Newton
Sent: Friday, August 05, 2005 11:12 AM
To: ECRIT
Subject: [Ecrit] comments on ECRIT requirements
Here are some comments on the ECRIT requirements document:
R1. This requirement seems to be saying that an ASP is not required,
but the motivation goes on to explain that ASP is just not a
traditional ASP, not that they do not run the application.
A6. What is the purpose of this requirement?
L6. I think the following should be added: Validation of civic
addresses MUST NOT be required to enable any feature that is part of
the emergency call process.
-andy
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit