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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 6 May 2006 18:26:38 +0200

>I've merged the two defn's (Emergency Address & PSAP URI) together, and
>given XMPP, removed IM reference:, (Andy's comment). 

Fine, in catching up on the list I just wanted to propose to drop emergency address
and only use PSAP URI (if even Hannes gets confused ;-)

>See if you can live with the result.

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

>CHANGE TO:
>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).
OK

>The
>URI contains information about the protocol used (encoded in the
>scheme),
>so that a focus on the IP address that it may resolve to is not
>appropriate.
 
I am not sure we need this tutorial

>There are even cases where the SIP:URI and the XMPP:URI for the same
>PSAP might not point to the same box.
 
This should be a note (without the "even"
 
Just a question for clicification: the URI may also be a TEL:URI. if it is pointing to
a PSAP only on the PSTN. Shouldn't this be included also?
 
Richard

-roger.

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]]
>Sent: Friday, May 05, 2006 2:25 PM
>To: Ted Hardie
>Cc: Roger Marshall; [email-masked]
>Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
>
>I like your definition, Ted. Now, we just need to make sure
>that it is used at the right places in the draft.
>
>Btw, I think that it might be good to add the term 'sos
>service type' to draft-ietf-ecrit-requirements-08.txt as used
>in draft-ietf-ecrit-service-urn-02.txt.
>
>draft-ietf-ecrit-service-urn-02.txt denotes each of the
>following strings as sos service types (at least I think so):
>
>urn:service:sos
>urn:service:sos.ambulance
>urn:service:sos.animal-control
>....
>urn:service:sos.mental-health
>
>To have a generic term for all these identifiers the term
>'emergency identifier' seems to be appropriate.
>
>Ciao
>Hannes
>
>PS: Let me know if I got totally confused.
>
>
>Ted Hardie wrote:
>> At 10:31 PM +0200 5/5/06, Hannes Tschofenig wrote:
>>
>>>>CHANGE FROM:
>>>>Emergency address: The URI (e.g., SIP:URI, SIPS:URI,
>XMPP:URI, IM:URI, etc.) which represents the address of the
>PSAP useful for the completion of an emergency call.
>>>>
>>>>CHANGE TO:
>>>>Emergency address: The PSAP URI (e.g., SIP:URI, SIPS:URI,
>XMPP:URI, IM:URI, etc.) which represents the IP address of the
>PSAP useful for the completion of an emergency call.
>>>
>>>A URI cannot represent an IP address. A URI can be resolved
>to an IP address.
>>>
>>>Ciao
>>>Hannes
>>
>>
>> I believe we may mean:
>>
>> "Emergency address:  The URI (e.g. , SIP:URI, SIPS:URI, XMPP:URI,
>> IM:URI, etc.) at which the PSAP may be contacted with an
>emergency call."
>>
>> The URI contains information about the protocol used (encoded in the
>> scheme), so a focus on the IP address is not appropriate. There are
>> even cases where the SIP:URI and the IM:URI might not point
>to the same box.
>>                              regards,
>>                                      Ted Hardie
>>
>>
>
>

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

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 6 May 2006 18:51:29 +0200

Folks,
 
I am a bit confused with:
 
Id3.  Emergency identifier marking: The mapping protocol MUST include
      an emergency identifier with the signaling, if one does not exist,
      for the purpose of marking the call as an emergency call.
 
I have some questions here:
 
the mapping protocol cannot include by itself something in signalling.
 
so is the intention the following (derived from motivation)?: (wording to be improved)
the mapping protocol MUST return an emergency identifier that MUST be 
included by the (downstream) signalling protocol for the purpose of
marking the call as an emergency call.

      Motivation: Marking ensures proper handling as an emergency call
      by downstream elements that may not recognize, for example, a
      local variant of a logical emergency address, etc.  This marking
      mechanism is assumed to be different than a QoS marking mechanism.
 
Richard

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 6 May 2006 18:53:50 +0200

For a better understanding of this issue it may also be
helpful to place Id3 after Id8
 
Richard

________________________________

Von: Stastny Richard [mailto:[email-masked]]
Gesendet: Sa 06.05.2006 18:51
An: Hannes Tschofenig; [email-masked]; Henning Schulzrinne; Roger Marshall
Betreff: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

Folks,

Richard

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 6 May 2006 21:54:30 +0200

>To make that clear, I suggest
>we move Ma17 up to be before Ma4, and we change "URI alternate
>contact" to say "explicitly marked as an alternate contact for use when
>a fallback contact is needed".

Yes, thank you for the clarification, this would clarify the issue
 
Richard

Von: Ted Hardie [mailto:[email-masked]]
Gesendet: Sa 06.05.2006 21:14
An: Stastny Richard; Hannes Tschofenig; [email-masked]; Henning Schulzrinne; Roger Marshall
Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

At 7:09 PM +0200 5/6/06, Stastny Richard wrote:
>IMHO there is a contradiction, (espeially between Ma6 and  Ma17) or at least
>this is very confusing. I do not know now if multiple URIs for the same contact
>protocol are allowed or not)
>
>In one requirement  the client needs to the select among differnt protocols, in the other not
>
>Richard

I agree that this is a bit confusing, largely because Ma17 occurs after the
others.  I think if we moved it forward, it would make more sense, as it
would then imply that the multiple URIs  in Ma4 were each from a different
scheme.

The reason we did not want to return multiple contact URIs for a single scheme
in a standard response was that we didn't want the client to have to worry
about which of the returned URIs to pick (e.g., if I gave you six SIP URIs,
which one should be selected?).

The alternate contact field allowed you to handle the need for explicit
indication of a fallback, but with the understanding that the client didn't
need to determine an ordering in the response--the fallback was there only
when the first contact was not available.

That's my memory of how we got there.   To make that clear, I suggest
we move Ma17 up to be before Ma4, and we change "URI alternate
contact" to say "explicitly marked as an alternate contact for use when
a fallback contact is needed".
                        regards,
                                Ted

>
>Ma4.  Multiple response URIs: The mapping protocol MUST support the
>      possible inclusion of multiple URIs in a mapping response.
>      Motivation: Multiple URIs may be available from the mapping
>      server.
>
>   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.
>
>   Ma6.  URL properties: The mapping protocol MUST support the ability
>      to provide ancillary information about a contact or URI that
>      allows the mapping client to determine relevant properties of the
>      URL.
>      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
>      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.
>
>   Ma17.  Single URI per contact protocol: Though the mapping protocol
>      supports the return of multiple URIs, it SHOULD return only one
>      URI per contact protocol, so that clients are not required to
>      select among different targets for the same contact protocol.
>      Motivation: There may be two or more URIs returned when multiple
>      contact protocols are available (e.g., SIP and SMS).  The client
>      may select among multiple contact protocols based on its
>      capabilities, preference settings, or availability.
>

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 8 May 2006 16:29:36 -0700

Ok, based on the points Richard made, and Ted's suggestions, and other
than some slight ordering changes (Ma4 still first, then Ma17, since the
latter has a referenced qualification pointing to the former), and some
minor rewording for read-ability, here's the resulting clump of
requirements which we were talking about:

...

Ma4.  Multiple response URIs: The mapping protocol 
MUST allow multiple URIs to be inclued in a mapping response.

Motivation: Multiple URIs may be available from the mapping server.

Ma17.  Single URI per contact protocol: Though there is 
support for multiple URIs being returned, the mapping protocol SHOULD 
return only one URI per contact protocol used, so that clients are not 
required to select among different targets for the same contact
protocol.

Motivation:  There may be two or more URIs returned when multiple 
contact protocols are available (e.g., SIP and SMS).  The client may 
select among multiple contact protocols based on its capabilities, 
preference settings, or availability.

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 for use when

a fallback contact is needed.

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

Ma6.  URL properties:"> The mapping protocol MUST 
support the ability to provide ancillary information about a contact or
URI 
that allows the mapping client to determine relevant properties of the 
URL.

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

...

Out-of-order numbering left for reference.  These will be renumbered in
next draft vers.

-roger.

>From: Stastny Richard [mailto:[email-masked]] 
>Sent: Saturday, May 06, 2006 12:55 PM
>To: Ted Hardie; Hannes Tschofenig; [email-masked]; Henning 
>Schulzrinne; Roger Marshall
>>we move Ma17 up to be before Ma4, and we change "URI 
>alternate contact" 
>>to say "explicitly marked as an alternate contact for use when a 
>>fallback contact is needed".
>
>>IMHO there is a contradiction, (espeially between Ma6 and  
>Ma17) or at 
>>least this is very confusing. I do not know now if multiple URIs for 
>>the same contact protocol are allowed or not)
>>
>I agree that this is a bit confusing, largely because Ma17 
>occurs after the others.  I think if we moved it forward, it 
>would make more sense, as it would then imply that the 
>multiple URIs  in Ma4 were each from a different scheme.
>
>The reason we did not want to return multiple contact URIs for 
>a single scheme in a standard response was that we didn't want 
>the client to have to worry about which of the returned URIs 
>to pick (e.g., if I gave you six SIP URIs, which one should be 
>selected?).
>
>The alternate contact field allowed you to handle the need for 
>explicit indication of a fallback, but with the understanding 
>that the client didn't need to determine an ordering in the 
>response--the fallback was there only when the first contact 
>was not available.
>
>contact" to say "explicitly marked as an alternate contact for 
>use when a fallback contact is needed".
>                        regards,
>                                Ted
>
>
>>

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 8 May 2006 16:32:30 -0700

Ok, references relocated as suggested.  Pushed security draft into Info
section as well.

-roger.

>Sent: Saturday, May 06, 2006 10:56 AM
>To: Hannes Tschofenig
>Cc: [email-masked]; Henning Schulzrinne; Roger Marshall
>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
>
>
>
>Hannes Tschofenig wrote:
>> 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:
>> 
>> "
>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
>> "
>> 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.tx
>> t
>> (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.
>> 
>> 
>> 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?
>> 
>> 
>>          ^^^ URI
>>                                                        ^^^^^^ delete
>>       ^^^^ URI?
>>                                           ^^^^ URIs
>>    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
>>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 9 May 2006 09:12:20 +0200

Roger,
 
this is much better now.
 
IMHO the issue could still be slightly improved:
 
In Ma5 we are talking about an alternate contact and a primary contact
 
It should be clearly stated in Ma17 that we talk here about the primary contact:
 
Sugestion: Change Ma17 from:

to:
 
Ma17.  Single primary URI per contact protocol: Though there is
support for multiple URIs being returned, the mapping protocol SHOULD
return only one explicitely marked primary URI per contact protocol used, 
so that clients are not
required to select among different targets for the same contact
protocol
 
regards
Richard

Von: Roger Marshall [mailto:[email-masked]]
Gesendet: Di 09.05.2006 01:29
An: Stastny Richard; Ted Hardie; Hannes Tschofenig; [email-masked]; Henning Schulzrinne
Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

...

...

-roger.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 9 May 2006 12:02:12 -0400

Ted,

I am just telling you that I read the words and they appeared
self-contradictory to me.

Mike

> From: Ted Hardie [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 11:30 AM
> To: Michael Hammer (mhammer); Stastny Richard; Roger 
> Marshall; Hannes Tschofenig; [email-masked]; Henning Schulzrinne
> Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
> 
> At 10:03 AM -0400 5/9/06, Michael Hammer \(mhammer\) wrote:
> > >From the peanut gallery:
> >
> >Ma17 and Ma5 still seem to be in conflict.  If my contact 
> protocol is 
> >SIP, how many SIP contacts will be provided overall?  Ma17 
> says 1.  Ma5 
> >says there can be primary and alternate, that is 2.  So, is 
> it 1 or 2, 
> >or perhaps more if there are multiple overlapping police forces?
> 
> I think you're making this harder than you need to.  If I 
> send a query requesting the contact URIs for a specific 
> service based on my location, I get back one URI per scheme.  
> I may also get back a URI explicitly marked as a fallback, 
> for use only if I cannot use the usual contact URIs received 
> (or if I try them and they fail).
> So you might get one geographically appropriate SIP URI, one 
> geographically appropriate SMS URI, and one geographically 
> appropriate XMPP URI.
> The fallback SIP URI (if present) is not necessarily as 
> geographically appropriate; it might point to something like 
> a state-wide response center.
> 
> Frankly, I think we've wordsmithed this enough.  Much more 
> effort will not produce better instructions to the protocol designers.
> 			regards,
> 				Ted Hardie
> 
>

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 17 May 2006 16:27:28 -0700

Michael:
I've done some minor rewording and some additional reordering, which may
make this more clear.  You'll see it in the next published version in
the next couple days.

The use of "contact" and "contact method" are not representative of the
SIP Contact header.

Thx.

Roger Marshall.

>From: Michael Hammer (mhammer) [mailto:[email-masked]] 
>Sent: Tuesday, May 09, 2006 9:02 AM
>To: Ted Hardie; Stastny Richard; Roger Marshall; Hannes 
>Tschofenig; [email-masked]; Henning Schulzrinne
>Marshall; Hannes 
>> Tschofenig; [email-masked]; Henning Schulzrinne
>send a query 
>> requesting the contact URIs for a specific service based on my 
>> location, I get back one URI per scheme.
>> I may also get back a URI explicitly marked as a fallback, for use 
>> only if I cannot use the usual contact URIs received (or if 
>I try them 
>> and they fail).
>appropriate 
>> XMPP URI.
>geographically 
>> appropriate; it might point to something like a state-wide response 
>> center.
>> 
>effort will 
>> not produce better instructions to the protocol designers.
>> 			regards,
>> 				Ted Hardie
>> 
>> 
>