Subject: [Ecrit] Comments on ecrit-requirements-00 section 7

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 08 Oct 2005 12:37:05 -0400

1. Introduction
--------------
The first paragraph is repeated in the third, hence can be deleted.  The 
second paragraph isn't totally accurate and not really useful, so should 
be deleted too.

Third paragraph, first sentence: "appears" should be "appear".

Fourth para should be moved down, since the final para relates to 
mediated resolution only.  The fourth para should also be split, with 
the part beginning "Since servers may be used ..." going to a new para. 
  This new para is fairly closely related to the final one.

Fifth para (which moves up) should begin: "Caller-based resolution ..." 
since that is what it relates to.

Final para, part beginning with "In addition, the caller probably does 
not care..." doesn't seem helpful.  If it were really true, why are we 
taking the trouble to map to precisely the right PSAP?  Delete from here 
to the end of the existing paragraph.

I1 motivation.
-------------
The motivation as stated is really an elaboration of the requirement and 
could be merged into that requirement.  The actual motivation is probably:

"Motivation: Routing to the wrong PSAP will result in delays in handling 
emergencies as calls are redirected, and result in inefficient use of 
PSAP resources at the initial point of contact."

D5 motivation
-------------
The existing text is not a motivation, but a statement of a solution. 
The motivation (if we even bother to state something so obvious) is that 
the faster emergency services can be invoked, the more favourable the 
likely outcome.

I7
-------------
Is the phrase "emergency address resolution information" clear?  If I 
understand correctly, the intent is that the entity requesting mapping 
should be able to determine the source of the data in the mapping 
database that was used to generate the returned mapping.  Could someone 
confirm that this is the intended requirement?

I assume the motivation for this requirement is to provide operational 
traceability in case of errors.  This might be stated.

Gotta go.  More in another E-mail.

Tom Taylor

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

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 12 Oct 2005 21:10:56 -0700

Tom:
Thanks for your comments.  Please see my responses in-line within
"[brackets]").  I have also included the entire intro to sect 7, as it's
currently rewritten (inserted in middle), based on comments (some Tom's,
some my own, and some unresolved still).

Baseline document is
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt

Thanks.

Roger Marshall. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tom-PT Taylor
>Sent: Saturday, October 08, 2005 9:37 AM
>To: [email-masked]
>Subject: [Ecrit] Comments on ecrit-requirements-00 section 7
>
>1. Introduction
>--------------
>The first paragraph is repeated in the third, hence can be 
>deleted.  The second paragraph isn't totally accurate and not 
>really useful, so should be deleted too.

[rsm - Paragraph 1 merged into paragraph 3.  Paragraph 2 has been
rewritten as shown below:

Given the requirement from the previous section, that of a single 
(or small number of) emergency identifier(s) which are independent of 
the caller's location, and since PSAPs only serve a limited geographic 
region, and for reasons of jurisdictional and local knowledge, having
the 
call reach the appropriate PSAP based on a mapping protocol, is 
crucial.</t>
]

>Third paragraph, first sentence: "appears" should be "appear".

[rsm - I've changed Section 7, paragraph 3 from:

"There appears to be two basic architectures..." 
to 
"There are two basic architectures described..."
]

>
>Fourth para should be moved down, since the final para relates 
>to mediated resolution only.  The fourth para should also be 
>split, with the part beginning "Since servers may be used ..." 
>going to a new para. 

[rsm - Split the original paragraph into two parts, moving them both
down, second and third from the end, respectively.]

>since that is what it relates to.

[rsm - rewording of section includes this change (see at end).]

>
>Final para, part beginning with "In addition, the caller 
>probably does not care..." doesn't seem helpful.  If it were 
>really true, why are we taking the trouble to map to precisely 
>the right PSAP?  Delete from here to the end of the existing paragraph.

[rsm - above paragraph rewritten for clarity, see complete Section 7
intro text (proposed, below), along with some additional comments
w/requests for input):

Section 7 - Mapping Protocol

Given the requirement from the previous section, that of a single 
(or small number of) emergency identifier(s) which are independent of 
the caller's location, and since PSAPs only serve a limited geographic 
region, and for reasons of jurisdictional and local knowledge, having
the 
call reach the appropriate PSAP based on a mapping protocol, is 
crucial.

There are two basic architectures described for translating an
emergency identifier into the appropriate PSAP emergency address.
We refer to these as caller-based and mediated.

For caller-based resolution, the caller's user agent consults a mapping 
service to determine the appropriate PSAP based on the location
provided.  
The resolution may take place well before the actual emergency call is 
placed, or at the time of the call.

For mediated resolution, a call signaling server, such as a SIP
(outbound) proxy or redirect server performs this function (a request
for 
mapping) by invoking the mapping protocol.

Note that this case relies on an architecture where the call is 
effectively routed to a copy of the database, rather than having some 
non-SIP protocol query the database.

[rsm - This phrase, "a copy of the database" is confusing... which 
database?  Also, if the database is essentially the "mapping server", 
aren't the protocols, LUMP, DNS-SOS, IRIS all "non-SIP" protocols?  
Not sure the average reader will know what is meant here. Comments
requested.]

Since servers may be used as outbound proxy servers by 
clients that are not in the same geographic area as the proxy server,
any 
proxy server has to be able to translate any caller location to the 
appropriate PSAP.  (A traveler may, for example, accidentally or 
intentionally configure its home proxy server as its outbound proxy 
server, even while far away from home.)

[rsm - The above paragraph seems confusing, based on the liberal use 
of terms like "servers" and "proxy servers" as opposed to "mapping 
servers", etc.  Can this be reworded to make it clearer?  Comments
requested.]

The problem at hand is more difficult to resolve than that for
traditional 
web or email services.  In this case, the emergency caller only dialed
an 
emergency identifier, and depending on the location, any one of several 
thousand PSAPs around the world could be appropriate PSAP.  In 
addition, there may be a finer resolution of routing (which the caller
isn't 
aware of), which results in a particular "accredited" PSAP (i.e. one run

by local authorities) answering to call.   (Many PSAPs are run by
private 
entities.  For example, universities and corporations with large
campuses 
often have their own emergency response centers.)
]

[rsm - now for Tom's comments to the requirements in section 7.]

>
>I1 motivation.
>-------------
>The motivation as stated is really an elaboration of the 
>requirement and could be merged into that requirement.  The 
>actual motivation is probably:
>
>"Motivation: Routing to the wrong PSAP will result in delays 
>in handling emergencies as calls are redirected, and result in 
>inefficient use of PSAP resources at the initial point of contact."

[rsm - done as proposed.]

>The motivation (if we even bother to state something so 
>obvious) is that the faster emergency services can be invoked, 
>the more favourable the likely outcome.

[rsm - I'm willing to have the obvious stated, though I've applied a
slight twist to this supplied motivation, and have also merged the
original text into the requirement.  Here's the new motivation:

Motivation: The more local the mapping output is, the more favourable 
(in most cases) the likely outcome will be for the emergency caller.
]

>
>I7
>-------------
>Is the phrase "emergency address resolution information" 
>clear?  If I understand correctly, the intent is that the 
>entity requesting mapping should be able to determine the 
>source of the data in the mapping database that was used to 
>generate the returned mapping.  Could someone confirm that 
>this is the intended requirement?

[rsm - Do we have an issue as to what is meant by "provided"?  Is it the
server of the data? or the creator of the data?  Should these two
suppliers 
of data be rooted in separated requirements?  Comments requested.]

>
>I assume the motivation for this requirement is to provide 
>operational traceability in case of errors.  This might be stated.

[rsm - good idea. Done.]