Subject: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 05 May 2006 14:21:54 +0200

Hi all,

here is a review of draft-ietf-ecrit-requirements-08.txt. The document 
is getting much better. Still, I have a few comments:

* Introduction:

I would delete this paragraph since it is a bit confusing at this point:

    As used in this document, validation of location does not require
    that we ascertain as to whether or not the location actually exists.
    For example, validation might only check that the house number in a
    civic address falls within the assigned range, not whether a
    building, known by a specific building number, exists at that
    location.  However, such higher precision validation is desirable.

This might be relevant in subsequent sections.

    Identification of the caller, while not incompatible with the
    requirements for messaging outlined within this document, is
    considered to be outside the scope of the ECRIT charter.
                                          ^^^^^^^^^^^^^^^^^^

Don't mention the working group name in the document.

Write "... is outside the scope of this document."

    Despite this goal, some PSAPs
    may not immediately have IP based connectivity, and therefore it is
    imperative that the URI scheme not be fixed, in order to ensure
    support for a less preferred set of URIs such as, for example, a TEL
    URI which may be used to complete a call via the PSTN.

I am not sure about this paragraph. Where do we provide such a 
functionality?

* Terminology

I would cluster the terms. For example, you might want to keep
  - (Location-dependent) emergency dial string
  - Home emergency dial string
  - Visited emergency dial string
together to make the terminology easier to read.

There is no requirement to list the terms alphabetically.

    Emergency address: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, IM:
              ^^^^^^^ change to identifier
       URI, etc.) which represents the address of the PSAP useful for the
       completion of an emergency call.

    Emergency call routing support: An intermediary function which
       assists in the routing of an emergency call via IP.  An ESRP is an
       example of an Emergency call routing support entity.
                     ^^^^^^^^^ emergency

Delete the following paragraph:

    Codes: "caller" or "emergency caller" refers to the person placing an
    emergency call or sending an emergency instant message (IM).

AND move the text over to this term:

    Emergency caller: The user or user device entity which sends his/her
       location to another entity in the network.

As such, it would read:

    (Emergency) caller: The term "caller" or "emergency caller" refer to 
the person placing an emergency call or sending an emergency instant
message (IM).

    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
    and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
    with the qualification that unless otherwise stated these words apply
    to the design of the mapping protocol, not its implementation or
    application.
    ^^^^^^^^^^^ usage

With the suggested change from "Emergency address" to "Emergency 
identifer" we have the term 'emergency identifier' appearing twice:

    Emergency identifier: An identifier that marks a call as an emergency
       call.

I suggest to delete this definition or to merge it with the previous one.

In the text we should always use small letters for terms like 'mapping 
servers' or 'mapping clients'. For example,

    Mapping client: A mapping client interacts with the Mapping Server to
                                                        ^^^^^^^^^^^^^^
       learn one or more PSAP URIs for a given location.

    Mapping server: The Mapping Server holds information about the
                        ^^^^^^^^^^^^^^
       location-to-PSAP URI mapping.

Change from:

"
    PSAP URI: PSAP URI is a general term, used to refer to the output of
       the mapping protocol, and represents either the actual PSAP IP
       address, or the IP address of some other intermediary, e.g., an
       ESRP, which points to the actual PSAP.
"

to:

"
    PSAP URI: The term 'PSAP URI' refers to a URI that identifiers a 
PSAP. We use this term to denote the reponse of a mapping protocol query.
"

* Section 3.  Basic Actors

    In order to support emergency services covering a large physical
    area, various infrastructure elements are necessary, including:
    Internet Attachment Providers (IAPs), Application/Voice Service
    Providers (ASP/VSPs), PSAPs as endpoints for emergency calls, mapping
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete 
this part; the PSAP is only one endpoint of the communciation.

    services or other infrastructure elements that assist during the call
             ^^^ and
    routing.

       o How is location information provided to the end host?  It might
    either be known to the end host itself via manual configuration,
    provided via GPS, or obtained via a third party method.  Even if
    location information is known to the network it might be made
    available to the end host via DHCP (RFC 3825 [2]) or some other
    mechanism.  Alternatively, location information is used as part of
    call routing and inserted by intermediaries.

Change paragraph to:

     o How is location information provided to the end host?  It might
    either be known to the end host itself via manual configuration,
    provided via GPS, made
    available via DHCP (see RFC 3825 [2]) or some other
    mechanisms.  Alternatively, location information is used as part of
    call routing and inserted by intermediaries.

    (5) Location Information is used by emergency call routing entities
                 ^^^^^^^^^^^ information
    for subsequent mapping requests.

4.  High-Level Requirements

    Re1.  Application/Voice service provider existence: The initiation of
       an IP-based emergency call SHOULD NOT assume the existence of an
       Application/Voice Service Provider (ASP/VSP).

       Motivation: The caller may not have an application/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.
                     ^ add "might"

5.  Identifying the Caller's Location

    Location can either be provided directly, or by reference, and
    represents either a civic location, or as a geographic location.
                                        ^^ and geospatial location 
information.

   How
    does the location (or location reference) become associated with the
    call?

change last sentence to:

"An important question is how and when to attach location information to 
the VoIP emergency signaling."

   In general, we can distinguish three modes of operation of how
    a location is associated with an emergency call:

Change from:

    UA-inserted: The caller's user agent inserts the location information
       into the call signaling message.  The location information is
       derived from sources such as GPS, DHCP (RFC 3825 [2]) and
       I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer
       Discovery Protocol (LLDP) [see IEEE8021AB].

to:

    UA-inserted: The caller's user agent inserts the location information
       into the call signaling message.  The location information is
       derived from sources such as GPS, DHCP (see [2] for geospatial 
location information and [7] for civic location information) or 
utilizing the Link Layer
       Discovery Protocol (LLDP) (see [IEEE8021AB]).

    UA-referenced: The caller's user agent provides a pointer (i.e., a
       location reference), via a permanent or temporary identifier, to
       the location which is stored by a location service somewhere else
                                                  ^^^^^^^ server
delete the 'somewhere else' part.
       and then retrieved by the PSAP, ESRP, or other authorized service
       entity.

    Lo2.  Location object/info preservation: The mapping protocol MUST
       retain any location information which is provided to it, even
       after mapping 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
                                           ^ does
       Information so that the PSAP can still receive the caller
       ^^^^^^^^^^^ information
       location.

    Lo5.  Validation of civic location: The mapping protocol MUST support
       location validation for civic location (street addresses), prior
       to initiating an emergency call.

delete the ", prior to initiating an emergency call." part.

       Motivation: Location validation provides an opportunity to help
       assure ahead of time, whether or not successful mapping to the
                                           ^ add 'a'
       appropriate PSAP will likely occur when it is required.
       Validation may also help to avoid delays during emergency call
       setup due to invalid locations.

Isn't Lo7 similar to L10?
Isn't Lo6 similar to Lo11?

    Lo9. 3D sensitive mapping: The mapping protocol MUST implement
       support for both 2D and 3D location information, and may accept
       either a 2D or 3D mapping request as input.

       Motivation: It is expected that provisioning systems will accept
                                       ^^^^^^^^^^^^^^^^^^^^ what is that?

       both 2D and 3D data.  When a 3D request is presented to an area
       only defined by 2D data, the mapping result would be the same as
       if the height/altitude dimension was omitted in the request.

6.  Emergency Identifier

    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.

I guess this requirement should say:

"
  Emergency identifier support: The mapping protocol MUST be able to 
return one or multiple emergency identifiers in response to a query.
"

    Id2.  Emergency identifier resolution: Where multiple emergency
       identifiers exist, the mapping protocol MUST be able to
       differentiate between identifiers based on the specific type of
       emergency help requested.

       Motivation: Some jurisdictions may have multiple types of
       emergency services available, (e.g., fire, police, ambulance), in
       which case, it is important that any one could be selected
       directly.

There is a terminology confusion here:
I think you refer to 'sos Service Types' here rather than multiple 
emergency identifers. You might want to double-check with 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt 
(and in particular with Section 4.3).

This terminology issue impacts also requirement Id5.

    Id4.  Prevention of fraud: If a call is identified as an emergency
       call, the mapping protocol MUST support that call being
       successfully routed to a PSAP.

       Motivation: This prevents use of the emergency call indication to
       gain access to call features or authentication override for non-
       emergency purposes.

This requirement is covered in the security document.

Requirement Id6, Id7, Id8, Id9, Id10 start with "The mapping protocol 
MUST/SHOULD support " but I think that these requirements do not 
necessarily address the  mapping protocol. I think a "There MUST be 
support for...."

7.  Mapping Protocol

    There are two basic approaches to invoking a mapping service.  We
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                      invoke the mapping protocol.

    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
    I-D.hardie-ecrit-lost [6].

    For caller-based resolution, the caller's user agent invokes a
                                                                 ^ the
    mapping service to determine the appropriate PSAP based on the
            ^^^^^^^ protocol
    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
                             ^^^^^^^^^^^^^^^^^^^^^^^
                             an emergency call routing support entity

    (outbound) proxy or redirect server invokes the mapping service.

    Ma5.  URI alternate contact: In addition to returning a primary
       contact, the mapping protocol MUST support the return of a URI or
       contact method explicitly marked as an alternate contact.

       Motivation: In response to a mapping request, the mapping server
       may return an alternate URI.  Implementation details to be
       described within an operational document.

I am not quite sure about Ma6 and Ma8. Ma8 tells me that the mapping 
protocol provides a URL for error reporting. Isn't Ma6 similar?

    Ma6.  URL properties: The mapping protocol MUST support the ability
          ^^^ URI

       to provide ancillary information about a contact or URI that
                                                        ^^^^^^ delete
       allows the mapping client to determine relevant properties of the
       URL.
       ^^^^ URI?

       Motivation: In some cases, the same geographic area is served by
       several PSAPs, for example, a corporate campus might be served by
       both a corporate security department and the municipal PSAP.  The
       mapping protocol should then return URLs for both, with
                                           ^^^^ URIs
       information allowing the querying entity to choose one or the
       other.  This determination could be made by either an ESRP, based
       on local policy, or by direct user choice, in the case of caller-
       based methods.

    Ma7.  Traceable resolution: The mapping protocol SHOULD support the
       ability of the mapping client to be able to determine the entity
       or entities which provided the emergency address resolution
                   ^^^^^ that
       information.

       Motivation: It is important for public safety reasons, that there
       is a method to provide operational traceability in case of errors.

    Ma8.  URI for error reporting: The mapping protocol MUST support the
          ^^^^ URL

       return of a URI that can be used to report a suspected or known
       ^^^^^^^^^^^^^^^ the ability to return a URL

       error within the mapping database.

       Motivation: If an error is returned, for example, there needs to
       be a URI which points to a resource which can explain or
            ^^^^ URL

       potentially help resolve the error.

    Ma16.  Multiple PSAP URIs: The mapping protocol MUST support a method
       to receive multiple PSAP URIs which cover the same geographic
          ^^^^^^^ return
       area.

       Motivation: Two different mapping servers may cover the same
       geographic area, and therefore have the same set of coverage
       information.

Isn't this requirement very similar to Ma4?

* 8.  Security Considerations

    Security considerations are discussed in the ECRIT security document
    I-D.ietf-ecrit-security-threats [4] .

Write:

"
Threats and security requirements are discussed in a separate document, 
see [4].
"

* Add an IANA section.
"
9.  IANA Considerations

    This document does not require actions by the IANA.
"

Ciao
Hannes

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 05 May 2006 08:52:01 -0400

There is a functional distinction between something that identifies the 
call as an emergency call (and must be present even after mapping has 
been performed so that downstream elements are aware of the nature of 
the call) and something that says where the call should be directed. By 
calling them both 'identifier' you lose this distinction. I think it is 
important that we keep it.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 05 May 2006 17:07:19 +0200

Hi Tom,

I guess you refer to the distinction between 'emgerency identifier' and 
'emergency address'. We have used 'emergency identifier' for what we 
call 'emergency address' in this document. You might remember the 
extremely long discussion regarding the 'emergency identifier' vs. 
'emergency dial strings'.

Now, I agree that it is necessary to have some form of emergency call 
marking. That's also in the requirements document listed as a 
requirement. There is no need to use a separate term for it, 
particularly when it conflicts with something else. Actually, I haven't 
come accross such a emergency call marking in one of our solution 
specific documents. Shouldn't that be in Henning's Service URN document? 
I want to review the latest version (after resubmitted it).

Ciao
Hannes
Tom-PT Taylor wrote:
>>    (Emergency) caller: The term "caller" or "emergency caller" refer 
>> to the person placing an emergency call or sending an emergency instant
>> message (IM).
>>
>>
>>
>> "An important question is how and when to attach location information 
>> to the VoIP emergency signaling."
>>
>> Threats and security requirements are discussed in a separate 
>> document, see [4].
>> "
>>
>> * Add an IANA section.
>> "
>> 9.  IANA Considerations
>>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 05 May 2006 13:33:41 -0400

My security I-D uses definitions from the requirements document. These 
definitions and terms have changed. I may be forced to create 
definitions of my own as a result.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 05 May 2006 23:14:32 +0200

I took a look at my review comment regarding the emergency address and I 
  have to realize that I was a bit confused when I wrote my review. It 
is totally wrong to change the term 'emergency address' to 'emergency 
identifier'.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 May 2006 19:56:03 +0200

Another tiny issue:

The normative reference section should only contain

    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

I would move the following references to the informative reference 
section to avoid creating unnecessary dependencies.

    [2]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
         Configuration Protocol Option for Coordinate-based Location
         Configuration Information", RFC 3825, July 2004.

    [3]  Peterson, J., "A Presence-based GEOPRIV Location Object Format",
         RFC 4119, December 2005.
    [5]  Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
         draft-ietf-ecrit-service-urn-02 (work in progress), April 2006.

    [6]  Hardie, T., "LoST: A Location-to-Service Translation Protocol",
         draft-hardie-ecrit-lost-00 (work in progress), March 2006.

    [7]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
         and DHCPv6) Option for Civic  Addresses Configuration
         Information", draft-ietf-geopriv-dhcp-civil-09 (work in
         progress), January 2006.

I am not sure about the reference to the security threats document. 
Since it will hopefully be completed at the same time it does not really 
matter whether you put it into the normative or the informative part of 
the references section.

    [4]  Taylor, T., "Security Threats and Requirements for Emergency
         Call Marking and Mapping", draft-ietf-ecrit-security-threats-01
         (work in progress), April 2006.

Ciao
Hannes