Subject: [Ecrit] ECRIT changes between -06/-07 draft requirements document - all sections

From: "Roger Marshall" <[email-masked]>
Date: Thu, 13 Apr 2006 17:12:57 -0700

All:
I have attempted to rewrite the first few ECRIT requirements in order
that they conform to the insightful advice given by Steve Kent at IETF65
- specifically, as to how a protocol requirement should be worded.

(ref. following jabber log entries:

[...
[10:17:23] <[email-masked]> Steve Kent says there are only two
cases here: you are writing requirements for a protocol which will later
design
[10:17:29] <[email-masked]> or you are writing a protocol
[10:17:44] <[email-masked]> The IETF uses an "implementation
compliance" model for the latter.
...]

Per the notes, I think were dealing with the first case, i.e., we're
trying to write requirements which we will later design a protocol to.
As a result of this more constrained approach, there is some significant
impact to some of the original requirement(s) as  written in -06.  This
is not necessarily a bad thing, but demands re-vetting with the wg.
I've attempted to rewrite all these below from a protocol view, rather
than proposing to throw out any which seem to be out of scope of a
protocol design.  Overall, I think the end product is more trackable,
and results in less ambiguity.  

The task is not complete, as I want to get some feedback on the
direction I'm taking.  Generally, Again, I think Steve's advice is
essential for addressing the scope of creating a mapping protocol.  

Each of the below changes have been listed separately in the
issue-tracker (http://www.ietf-ecrit.org:8080/ecrit-req/).  The
following is a concatenated list made with RFC 2119 guidance in mind.

[Section 4.  High-Level Requirements]

Issue 42.  Re1. Proposed changed to text, to provide clarity to the
protocol requirement and to provide context (e.g. during an emergency
call):

CHANGE FROM:
"Re1.  Application/Voice service provider: The existence of 
an Application/Voice Service Provider (ASP/VSP) 
SHOULD NOT be assumed.

CHANGE TO:
Re1.  Application/Voice service provider existence: The 
mapping protocol SHOULD NOT assume the existence of an 
Application/Voice Service Provider (ASP/VSP) during an emergency 
call.

Issue 43.  Re2. Proposed changed to text, to provide clarity to the
protocol requirement:

CHANGE FROM:
Re2.  International: Regional, political and organizational 
aspects MUST be considered during the design of protocols and 
protocol extensions.

CHANGE TO:
Re2.  International applicability: The mapping protocol 
and its extensiions MUST consider and incorporate regional, political 
and organizational aspects during its design and development.

Issue 44.  Re3. Proposed changed to text, to avoid a protocol deployment
requirement within a protocol design requirements document:

CHANGE FROM:
Re3.  Distributed administration: Deployment of 
emergency services MUST NOT depend on a sole central administration 
authority.

Motivation: Once common standards are established, 
it must be possible to deploy and administer emergency calling 
features on a regional or national basis without requiring coordination 
with other regions or nations.  The system cannot assume, for example, 
that there is a single global entity issuing certificates for PSAPs,
ASP/VSPs, 
IAPs or other participants.

CHANGE TO:
Re3.  Distributed administration: The mapping protocol design MUST NOT 
be dependent on a sole central administration authority.

Motivation: The design mapping protocol must make it possible to 
deploy and administer emergency calling features on a regional 
or national basis without requiring coordination with other regions 
or nations.  The system cannot assume, for example, that there is a 
single global entity issuing certificates for PSAPs, ASP/VSPs, 
IAPs or other participants.

Issue 45.  Re4. Proposed changed to text, to clarify protocol design
requirements:

CHANGE FROM:
Re4.  Multiple modes: Multiple communication modes, 
such as audio, video and text MUST be supported (i.e., 
implemented in the protocol, though not necessarily used in all 
calls).

Motivation: In PSTN, voice and text telephony (often called TTY or 
textphone in North America) are the only commonly supported media.  
Emergency calling must support a variety of media. Such media should 
include voice, conversational text 
(<xref target="RFC4103">RFC 4103</xref>), instant messaging and 
video.

CHANGE TO:
Re4.  Multi-mode communication: The mapping protocol MUST support 
multiple communication modes, including, for example, audio, video and
text.

Motivation: In PSTN, voice and text telephony (often called TTY or 
textphone in North America) are the only commonly supported media.  
Emergency calling must support a variety of media. Such media should 
include voice, conversational text 
(<xref target="RFC4103">RFC 4103</xref>), instant messaging and 
video.

Issue 46.  Re6. Proposed changed to text, to reword title, clarify
protocol design requirement language:

CHANGE FROM:
Re6.  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.

CHANGE TO:
Re6.  Currency indication: The mapping protocol SHOULD 
support an indicator describing how current the information provided by
the 
mapping source is.

Motivation: This is especially useful when an alternate mapping is 
requested, and alternative sources of mapping data may not have 
been created or updated with the same set of information or within 
the same timeframe.  Differences in currency between mapping data 
contained within mapping sources should be minimized.

Issue 47.  Re7. Proposed changed to text for minor rewording:

CHANGE FROM:
Re7.  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 by a legacy SIP device.

CHANGE TO:
Re7.  Mapping result usability: The mapping protocol 
MUST return one or more URIs that are usable within a standard 
signaling protocol (i.e., without special emergency extensions).

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

Issue 48.  Re8. Propose to change this requirement to make it specific
to the mapping protocol, and because a general requirement for mapping
information at the server is out of scope for the mapping protocol
itself.

CHANGE FROM:
Re8.  PSAP accessibility: The mapping information 
MUST be available without having to enroll with a service provider.

Motivation: The mapping server may well be operated by a service 
provider, but access to the server offering the mapping must not 
require use of a specific ISP or ASP/VSP.

CHANGE TO:
Re8.  PSAP URI accessibility:"> The mapping protocol 
MUST support interaction between the client and server where no 
enrollment to a mapping service exists or is required.

Motivation: The mapping server may well be operated by a service 
provider, but access to the server offering the mapping must not 
require use of a specific ISP or ASP/VSP.

Issue 49.  Re9. Propose to change this requirement to make it specific
to the mapping protocol, and because a requirement for mapping server
and it's internal database is out of scope for the mapping protocol
itself.

CHANGE FROM:
<t hangText="Re9.  No modification of location databases:"> 
The mapping protocol SHOULD NOT require that data within 
location databases be transformed or modified in any unusual or 
unreasonable way in order for the mapping protocol to use the data.</t>

<t>Motivation: Databases which contain civic addresses used within 
location servers, may be used for multiple purposes and applications 
beyond emergency service mapping.</t>

CHANGE TO:
<t hangText="Re9.  Common data structures and formats:"> 
The mapping protocol SHOULD support common data structures and 
formats from the mapping server.</t>

<t>Motivation:  Location databases should not need to be transformed or 
modified in any unusual or unreasonable way in order for the mapping 
protocol to use the data.  For example, a database which contains civic 
addresses used by location servers, may be used for multiple 
purposes and applications beyond emergency service location-to-PSAP 
URI mapping.</t>

[Section 5.  Identifying the Caller's Location]

Issue 50.  Lo1. Propose to change text to make it specific to the
mapping protocol, and because a requirement for mapping server is out of
scope.

CHANGE FROM:
Lo1.  Reference datum: The mapping server MUST 
implement support for the WGS-84 coordinate reference system and 
MAY support other coordinate reference systems.

CHANGE TO:
Lo1.  Reference datum: The mapping protocol MUST 
support the WGS-84 coordinate reference system and 
MAY support other coordinate reference systems.

Issue 51.  Lo2. Propose to change text to make it specific to the
mapping protocol, and because a requirement for an ESRP is out of scope.

CHANGE FROM:
Lo2.  Location provided: An Emergency Services 
Routing Proxy (ESRP) MUST NOT remove location information after 
performing location based routing.

Motivation:  The ESRP and the PSAP use the same location 
information object, but for a different purpose.  Therefore, the PSAP 
still needs to receive the caller's location.

CHANGE TO:
Lo2.  Location retained: The mapping protocol MUST 
retain any location information which is provided to it, 
even after a location based action is performed.

Motivation:  The ESRP and the PSAP use the same location 
information object, but for a different purpose.  Therefore, 
It is imperative that the mapping protocol not remove location 
Information so that the PSAP can still receive the caller 
location.

[Section 6.  Emergency Identifier]

Issue 52.  Id1. Propose to change the intent of the requirement, from a
phone/UA requirement to a mapping protocol requirement.  The mapping
protocol doesn't care what identifier is used to invoke an emergency
call, except if it is slated to provide that identifier/dialstring as a
response based on location.

CHANGE FROM:
Id1.  Emergency identifier setup: One or more 
emergency identifiers MUST be recognized by any device or 
network element for call setup purposes.

Motivation: There must be some way for any device or element to 
recognize an emergency call throughout the call setup.  This is 
regardless of the device location, the application/voice service 
provider used.  An example of this might be "urn:service:sos".

CHANGE TO:
Id1.  Emergency identifier support: The mapping 
protocol MUST support one or more emergency identifiers for delivery 
back to mapping clients to be used for call setup purposes.

Motivation: Since there is a need for any device or network 
element to recognize an emergency call throughout the call setup, there 
is also a need to have the mapping protocol provide support for such an 
identifier.  This is regardless of the device location or the ASP/VSP
used.  
An example of this kind of identifier might be "urn:service:sos".

[to be continued...]
/end

-Roger Marshall.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Apr 2006 21:52:30 +0200

Hi Roger,

I also agree that some rewording is necessary.
However, I wonder what the best approach is to make the best progress on 
the document.

I would like to suggest the following approach based on your suggested 
rewording. I don't think that the wording changes the meaning of the 
individual requirements.

Can you compile a new draft version to allow working group members to 
review the entire document?

A question regarding the comments we received during the WGLC: Issue#31 
to Issue#39
Do you think that the require a discussion on the mailing list (one by 
one)?  If they are not resolved yet then the chairs are going to trigger 
a discussion on each of them in order to finalize the document.

Ciao
Hannes