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

From: "Roger Marshall" <[email-masked]>
Date: Fri, 12 May 2006 17:24:53 -0700

Hannes:
Thanks very much for your comments to the -08 draft.  A new version,
w/the changes incorporated, will be published soon.

See changes/responses in-line:

-roger.

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: Friday, May 05, 2006 5:22 AM
>To: [email-masked]; Henning Schulzrinne; Roger Marshall
>Subject: Review of draft-ietf-ecrit-requirements-08.txt
>
>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.

Agreed, deleted above paragraph.  Concept is already referred to in the
term defn, "Location validation".

>
>
>
>    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.

The reference to ECRIT has been removed throughout document.

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

Agreed.  Done.

>
>
>    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?

Agree that there is no existing requirement to which this paragraph
refers to, so I've reworded the paragraph, and have added a NEW
requirement as written below:

CHANGE FROM:
Ideally, the mapping protocol would yield a URI from a preferred set of 
URIs (e.g., SIP:URI, SIPS:URI) which would allow an emergency call to be

completed using IP end-to-end.  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.

CHANGE TO:
The intent of the mapping protocol is to produce a PSAP URI (from a 
preferred set of URIs, e.g., SIP:URI, SIPS:URI) based on a location
input, 
to facilitate the IP end-to-end completion of an emergency call.  Since
not 
every PSAP will immediately support IP, it may be necessary to also 
support less preferred URI schemes, such as a TEL URI in order to 
complete an emergency call via the PSTN.

ADDED:
Ma18.  Non-preferred URI schemes: The mapping 
protocol MAY support the return of a less preferred URI scheme, 
(e.g., TEL URI).

Motivation:   In order to provide incremental support to non-IP 
PSAPs it may be necessary to be able to complete an emergency 
call via the PSTN.

>
>* 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.

Agreed.  Terms have been reordered and clumped together.

>
>
>    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
>

Conflated the two terms, "Emergency address" and "PSAP URI", into one
entry under PSAP URI.

>
>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).

Agreed.  Changes made to draft.

>
>
>
>    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

Modification made.

>
>
>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.

No changes made here, subject to list discussions/clarfications.  We end
up with two terms, having different usage, "emergency identifier", and
"PSAP URI".

>
>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.

Agreed. Low-case changes made.

>
>
>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.

Change NOT made, since we have renamed emergency address to PSAP URI,
and so have the result:

PSAP URI: The URI (e.g., SIP:URI, SIPS:URI, XMPP:URI, 
etc.) at which the PSAP may be contacted with an emergency call.  This 
contact could be done directly, or via an intermediary, (e.g., ESRP).

>"
>
>* 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.

Changed text to read:
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), Emergency Call Routing Support (ECRS) providers, 
mapping service providers, and PSAPs.

>
>
>       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.

Changed text as suggested.

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

Corrected text to low-case.

>
>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"

Inserted word "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.

Changed text as suggested.

>
>   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."

Changed text as suggested.

>
>   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]).

Changed text as suggested.

>
>
>    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.

Changed "service" to "server".

>
>    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.

Changed text to:
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 does not remove the  
location information from the messaging, so that it can be provided 
to the PSAP.

>
>
>    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.

Removed text per suggestion.

>
>       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.

Inserted "a" per suggestion.

>
>
>Isn't Lo7 similar to L10?

Agree that the two are similar in intent, therefore have removed Lo10.

>Isn't Lo6 similar to Lo11?

Not sure, but I do think that Lo11 is not general enough, so have
removed 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.

Reworded motivation paragraph to read as follows:
Motivation:  It is expected that end devices or location servers will 
provide either 2D or 3D data. When a 3D request is presented within an 
area only defined by 2D data within the mapping server, 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.

Changed text to:
Id1.  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-ur
>n-02.txt 
>(and in particular with Section 4.3).
>
>This terminology issue impacts also requirement Id5.

Pending.  Not sure.  Seeking clarification from Hannes on above items.

>
>    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.

Deleted Id4 as per suggestion.

>
>
>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...."

Changed requirements Id6, Id7, Id8, Id9, Id10, to now read "There MUST
be support for...". 

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

Changed wording.

>
>    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.

Changes made to draft.

>
>
>    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?

Modified text as per suggestion.

>
>
>       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.

Changed per suggestion.

>
>
>    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?

Agreed that Ma4 & Ma16 are same.  Deleted 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].

Changed text as per suggestion.

>"
>
>* Add an IANA section.
>"
>9.  IANA Considerations
>
>    This document does not require actions by the IANA.
>"

Added new section as per suggestion.

>Ciao
>Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 May 2006 01:34:43 +0200

Hi Roger,

thanks for the quick response. You suggested changes look good.

Ciao
Hannes