Subject: RE: [Ecrit] comments on ECRIT requirements

From: "Roger Marshall" <[email-masked]>
Date: Sat, 6 Aug 2005 00:05:13 -0700

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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Sat, 6 Aug 2005 03:34:21 -0400

Roger,

Thanks for doing the hard work.

My comments are in-line:

> reliance on external entities, other than for the transport of

This works for me.  Thanks.

> MUST be backward-compatible for use with existing devices.

I still do not understand this requirement.  If this working group  
creates a method for emergency call routing that does not already  
exist, which is the purpose of this group, then by definition it will  
not be backwards compatible with existing devices.  When I read this  
requirement, to me it indicates that we either are not producing a  
new standards track document or we should close down the working group.

Perhaps there needs to be more definition with regard to the meaning  
of "backward-compatible".

> the context in which the call is initiated.

I'm fine with this too.

Again, thanks Roger for doing the hard work.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Aug 2005 22:54:03 -0500

At 03:34 AM 8/6/2005 -0400, Andrew Newton wrote:
>I still do not understand this requirement.

I also do not understand this requirement (now).

>If this working group

I agree here - maybe we need to define first exactly what this phrase means 
to everyone.

Is it backwards-compatible message routing?

Is it backwards-compatible signaling protocol and which extensions?
meaning: for SIP, is it only 3261 elements, or 3261 plus the 34 PS-RFCs 
since 3261?

Is it backwards-compatible addressing?

Which, or all 3?

>-andy

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.