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

From: "Roger Marshall" <[email-masked]>
Date: Mon, 17 Apr 2006 09:21:17 -0700

Hannes:
I will compile a completed draft soon, based on the 2119 rewrites.  Yes,
my goal is to have each requirement say something close to the same
thing, but this is sometimes challenging when going from a statement
about the mapping server to the mapping protocol, for example.

Though I think that Issues 35, 38, and 39 may need special attention
(i.e. a champion), I will attempt to clarify each, and so will include
in the next version to get published.

Regards,

Roger Marshall. 

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: Friday, April 14, 2006 12:53 PM
>To: Roger Marshall
>Cc: [email-masked]; Marc Linser
>Subject: Re: ECRIT changes between -06/-07 draft requirements 
>document - all sections
>
>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
>
>
>
>Roger Marshall wrote:
>> 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