Subject: [Ecrit] comments on ECRIT requirements

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Aug 2005 11:12:12 -0400

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

---

From: "James Winterbottom" <[email-masked]>
Date: Sat, 6 Aug 2005 19:36:32 +1000

Hi Nadine,

This is another of the requirements that I think bridges the boundary
between GeoPriv and ECRIT, and is, in my opinion anyway, in the same ilk as
location dependability. It seems that the are charter for ECRIT is strictly
routing, probably reasonable if a conclusion is to be reached, but I think
that the Geopriv charter needs to be revised to include location
dependability, and location validation.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Abbott, Nadine B
Sent: Saturday, 6 August 2005 3: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

-andy

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 12 Aug 2005 08:57:14 -0700

All:
In reference to comments received on requirement A6
"Backward-Compatible", I will considering deleting this from the draft
if there is no champion for it.  It is problematic to me for the
following reasons:

Definition of the term to everyone's satisfaction may be difficult,
since the term's use has a wide breadth of use.

Lack of clarity as to the essential meaning of the term, as James points
out.  Is it backward-compatible message routing? Signaling protocol, or
addressing?

Roger Marshall

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Thursday, August 11, 2005 8:54 PM
To: Andrew Newton; Roger Marshall
Cc: ECRIT
Subject: Re: [Ecrit] comments on ECRIT requirements

At 03:34 AM 8/6/2005 -0400, Andrew Newton wrote:
>Roger,
>
>Thanks for doing the hard work.
>
>My comments are in-line:
>
>On Aug 6, 2005, at 3:05 AM, Roger Marshall wrote:
>>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.
>
>I still do not understand this requirement.

I also do not understand this requirement (now).

>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".

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.