Subject: [Ecrit] ECRIT -06 editing change log for new requirements draft version - all sections

From: "Roger Marshall" <[email-masked]>
Date: Mon, 6 Mar 2006 02:31:30 -0800

ECRIT WG:
Change log to accompany latest version of ECRIT requirements draft,
<draft-ietf-ecrit-requirements-06.txt>, once it gets posted by the RFC
editor.

Editing based on Henning's redlined observations, ECRIT list-server
email, and the editor's own reading:

An assortment of important, yet minor changes in grammar and wording -
these were not all documented in this change log, but will show up
within a diff report against -05.

The following log does seek to document noteable changes, based on
issues/comments and based on general readability/consistency of the
information.

Changes:

2. Re5:[Ed. Broke apart Re5 into two separate requirements as below
(Re5X will get renumbered as well in the next draft version)]

Re5.  Alternate Mapping Sources: The mapping protocol 
MUST implement a mechanism that allows for the retrieval of mapping 
information from different sources.

Motivation: This provides the possibility of having available 
alternative sources of mapping information when the normal source  is 
unavailable or unreachable.

Re5X.  Differences of Currency in Mapping Sources: 
For alternate mapping, differences in currency between mapping data 
contained within mapping sources SHOULD be minimized.

Motivation: Alternative sources of mapping data may not have been 
created or updated with the same set of information within the same 
timeframe.

3. Re6: Reworded.

[CHANGE FROM:
Re6.  Incremental Deployment: The ECRIT mapping 
protocol MUST return URIs that are usable by a standard signaling 
protocol (i.e., without special emergency extensions) unless an error is

returned.

Motivation: The format of the output returned by the mapping protocol 
is in a standard format for communication protocol.  For example, it
should 
return something SIP specific (e.g. URI), that any SIP capable phone 
would be able to use if used in a SIP context.  Special purpose URIs 
would not be understood by "legacy" SIP devices since they do not 
have knowledge about the mapping protocol, and therefore are not to be 
used.
]

[CHANGE TO:
Re6.  Mapping Result Usability: The ECRIT mapping 
protocol MUST return a URI (or URIs) that are usable within a standard 
signaling protocol (i.e., without special emergency extensions).

Motivation:  For example, a SIP specific URI returned by the mapping 
protocol, needs to be usable within any SIP capable phone in a SIP 
initiated emergency call.  This is in contrast to a "special purpose"
URI, 
which may not be recognizable within a legacy SIP device.

4. Re7.  [Ed. Relocated requirement Re7 to end of mapping section.]

5. Lo1-Lo4, Lo7 moved to end of Mapping Protocol section, (relabeled all
sections)

6. Id2., Emergency Identifier section:

[Change FROM:
Id2.  Universal Identifier Resolution: Where multiple 
emergency service types exist, the mapping protocol MUST support 
(i.e. implement, though not necessarily use) the individual treatment of

each emergency identifier used, based on the specific type of 
emergency help requested.
]
[Change TO:
Id2.  Emergency identifier resolution: Where 
multiple emergency service identifiers exist, there MUST be a mechanism
to 
differentiate each emergency identifier used, based on the 
specific type of emergency help requested.
]

7. Id4. Removed the following requirement, since it isn't a protocol
requirement, renumber section.

[Removed following text:
Id4.  Emergency Identifier-based Marking: User 
agents, proxies, and other network elements that process signaling 
associated with emergency calls SHOULD be configured to recognize a 
reasonable selection of logical emergency identifiers as a means to 
initiate emergency marking.

Motivation:  Since user devices roam, emergency identifiers may vary 
from region to region.  It is therefore important that a network entity
be 
able to perform mapping and/or call routing within the context of its
own 
point of origin rather than relying on non-local logical emergency 
identifiers as the only basis for emergency marking of calls.
]

8. Id12. 

[Removed requirement, duplicate requirement with Id8. 
   Id12.  Translation of emergency dial-strings: The SIP UA SHOULD
      translate both home and visited emergency dial-strings into a
      universal emergency identifier.
]

9. Section 7, Mapping Protocol, removed the following paragraph, since
this was not mapping  protocol specific.

[Removed following text:
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.
]

10. Section 7, Mapping Protocol, removed the following paragraph, since
it is not required to specify the mapping protocol.

[Removed following text:
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.)
]

11. Ma2., Mapping Protocol requirements, (section 7, con't).

[Removed following text, since it is stated more clearly already in
Ma4.:
Ma2.  Mapping redirection: The mapping protocol MUST 
support (i.e. implement for use) redirection functionality, since in
some 
cases, an initial mapping may provide a single URL for a large
geographic 
area.  Redirection is needed to then re-invokes the mapping protocol on 
a different database to obtain another URL for a more resolute ESRP or 
PSAP, which covers a smaller area.

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

12. Ma5.

[Removed following Motivation text, since it added no new information.
Motivation: In response to a mapping request, a server will
normally provide a URI or set of URIs for contacting the
appropriate PSAP.
]

13. Ma13. 

[Removed requirement and motivation text, since location updates are not
supplied by the mapping protocol:
Ma13.  Location Updates: The mapping protocol MUST 
support (i.e. implement, though not necessarily use) the ability to
provide 
location updates.  Mapping services should implement the mechanisms to 
provide updated location.

Motivation: Updated location information may have an impact on PSAP 
routing.  In some cases it may be possible to redirect that call to a
more 
appropriate PSAP (some device measurement techniques provide quick 
(i.e. early), but imprecise "first fix" location).
]

14. Ma17.

[Change FROM:
Ma17.  Pervasive Mapping: The mapping protocol MUST support (i.e. 
implement for use) the ability of the mapping function to be 
invoked at any time, including while an emergency call is in 
process.
]

[Change TO:
Ma17.  Any time mapping: The mapping protocol MUST 
support (i.e. implement for use) the ability of the 
mapping function to be invoked at any time, including 
while an emergency call is in process and before an 
emergency call.
]

15. Ma19.

[Change FROM:
Ma19.  Single URI Scheme: The mapping protocol MAY return multiple 
URIs, though it SHOULD return only one URI per scheme, so that 
clients are not required to select among different targets for the 
same contact protocol.
]

[Change TO:
Ma19.  Single URI per contact protocol: Though the mapping protocol 
supports the return of multiple URIs, it SHOULD return only one URI per 
contact protocol, so that clients are not required to select among
different targets 
for the same contact protocol.
]

16. Ma23. 

[Removed requirement, since it's purpose is not sufficiently explained,
through examples, etc.:
Ma23. Support for location alias: The mapping protocol 
MUST support (i.e. implement, though not necessarily use) one or more 
aliases for a specific location entry.

Motivation:  It should be possible to relate one entry to another and be

able to determine which is the "primary" entry and which is the alias.  
The result of aliasing is always that mapping from the primary or any of

the aliases is the same.
]

17. Ma24.

[Removed requirement, since it is addressed in the now reworded Ma17
"Any time mapping".
Ma24. Pre-call mapping for fallback: The mapping 
protocol MUST support (i.e. implement, though not necessarily use) 
LCMS queries prior to making an emergency call.
]

[Appended the below motivation text onto Ma17, the "Any time mapping"
requirement.
Motivation: Used as a fallback mechanism only, if a LCMS query fails 
at emergency call time, it may be advantageous to have prior knowledge 
of the PSAP URI.  This prior knowledge would be obtained by performing 
an LCMS query at any time prior to an emergency call.
]

18. Reworded the following original paragraph to make it fit the mapping
protocol section:

[Change FROM:
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.
]

[Change TO:
There are two basic approaches to invoking a mapping service.  We 
refer to these as caller-based and mediated.  In each case, the mapping 
client initiates a request to a mapping server via a mapping protocol.  
A proposed mapping protocol is outlined in the document 
<xref target="I-D.hardie-ecrit-lost">I-D.hardie-ecrit-lost</xref>.
]

19.  Some cleanup of the use of "Universal emergency identifier" vs.
"dial string", etc.

20.  Incorporate Gunnar Hellstrom's recommended text changes ("text
messaging" to "text communication", etc.)

21.  Modify definition for term, "Emergency Identifier" as follows (per
Taylor comment, plus an added sentence to contrast to a universal
emergency identifier):

[Change FROM:
Emergency identifier: The numerical and/or text identifier which is
supplied by a user or a user device, which identifies the call as
an emergency call and is translated into an emergency address,
useful for call routing and completion of the emergency call.
]

[Change TO:
Emergency identifier: The numerical and/or text 
identifier which is supplied by a user or a user device, which 
identifies the call as an emergency call.  A universal emergency 
identifier is an example of an emergency identifier.
]

[end]

-Roger Marshall

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