Re: [Ecrit] comments on ECRIT requirements

[Andrew Newton <andy at hxr.us>]

Roger,

Thanks for doing the hard work.

My comments are in-line:

On Aug 6, 2005, at 3:05 AM, Roger Marshall wrote:
> 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.

This works for me.  Thanks.

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

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

I'm fine with this too.

Again, thanks Roger for doing the hard work.

-andy

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit