[Ecrit] High-Level Requirements section (<draft-schulzrinne-ecrit-requirements-01.txt>)

["Tschofenig, Hannes" <hannes.tschofenig at siemens.com>]

hi all, 

please find my comments below (#). 

just a few minor fixes. 

3.  High-Level Requirements

   Below, we summarize high-level architectural requirements that guide
   some of the component requirements detailed later in the document.

   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,
      i.e., a corporate entity that provides voice services as a
      business. 

# i suggest to shorten the sentence since we already defined the term
voice service provider. 
# hence, the complete sentence would read: 
"
The caller may not have a voice service provider.
"

 For example, a residence may have its own DNS domain
      and run its own SIP proxy server for that domain.  On a larger
      scale, a university might provide voice services to its students
      and staff, but not be a telecommunication provider.

   R2.  International:  The protocols and protocol extensions developed
      MUST support regional, political and organizational differences.

      Motivation: It MUST be possible for a device or software developed
                    ^^^^^^
# the motivation paragraph should not contain capitalized must, may or
shoulds. 

      or purchased in one country to place emergency calls in another
      country.  System components should not be biased towards a
      particular set of emergency numbers or languages.  Also, different
      countries have evolved different ways of organizing emergency
      services, e.g. either centralizing them or having smaller regional
      subdivisions such as United States counties or municipalities
      handle emergency calls.

   R3.  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, ASPs, AIPs or other participants.

   R4.  Multiple Modes:  Multiple communication modes, including
      Multimedia data and services MUST be supported.


# rephrase the sentence to: 

"
Multiple communication modes, such as audio, video and text messaging
MUST be supported.

"

      Motivation: Emergency calling must support a variety of media, not
      just voice and TDD (telecommunication device for the deaf) beyond
      the capabilities of  current limitations.  Such additional media
      should include conversational text, instant messaging and video.

# what is the difference between 'conversational text' and 'instant
messaging' in this context?  

      In addition, it should be possible to convey telemetry data, such
      as data from automobile crash sensors.

# i think that this would be a separate requirement. 





Schulzrinne & Marshall    Expires November 2, 2005              [Page 9]

Internet-Draft             ECRIT requirements                   May 2005


   R5.  Minimum Connectivity:  An emergency call should succeed as long
      as there is a working network path between the caller and the
      PSAP.  In particular, reliance during call set-up and calls on
      entities and network paths that are located elsewhere should be
      minimized.

      Example: A caller in New York who needs to contact a PSAP in the
      same city shouldn't have to get information from some entity in
      Texas to make that call, as the call would then fail if the New
      York to Texas path is unavailable.  (To avoid this, the caller
      could, for example, have cached mapping information, use a local
      server that has the necessary information, or use other mechanisms
      to avoid such off-path dependencies.)

      [Ed.  No resolution yet agreed to for the above requirement.]

   R6.  Incremental Deployment The output of the ECRIT mapping protocol
      will be one or more URIs that can be used as the target of an
      emergency communication.  These must be usable by an appropriately
      capable device even if that device has no knowledge of the mapping
      protocol.  As an example, if the mapping protocol returns a SIP
      URI any SIP-capable phone should be able to use it as a target of
      the call; no special extension to SIP should be required.


# R6 does not seem to be a requirement or it is, at the moment, not
phrased as one. 


ciao
hannes

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