Subject: [Ecrit] Phonebcp-02 comments (mostly substantive)

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 9 Oct 2007 10:56:33 -0400

Here are my mostly substantive comments on phonebcp-02. I'll send other
comments separately. First, I'd like to say that Brian did an
outstanding job on this document. It's really good.
Barbara

----------
   ED-11/SP-9 All emergency services specified in
   [I-D.ietf-ecrit-service-urn] MUST be recognized.  Devices/Service
   Providers MUST be capable of recognizing all of the associated dial
   strings.

Comment: Service Providers may only be able to recognize home strings.
Nowhere is it required/recommended for end devices to provide SPs with
their current location outside of an emergency call. It is also not
required/recommended that SPs attempt to locate devices prior to an
emergency call. This means that SPs that operate as core applications in
the open Internet will have no ability to know the local dialstrings.

Perhaps the last sentence of this requirement could read: "...all of the
associated dial strings that known to them."
---------
6.5 End system location configuration

I'd like to see an additional requirement along the lines of:
ED-XX Endpoints using HELD to configure location for use with emergency
services MUST set protocol parameters as follows: 
 - responseTime = emergencyRouting (when requesting a location for
routing an emergency call) or
 - responseTime = emergencyDispatch (when requesting a location for
emergency dispatch)
----------
   ED-22 Endpoints SHOULD try all LCPs supported by the device in any
   order or in parallel.  The first one that succeeds in supplying
   location can be used.

Comment: Does this mean it is or isn't ok to stop after the first
successful attempt? I think it should be ok to not do others if one
succeeds.
-----------
   AN-14 Network administrators MUST take care in assigning IP addresses
   such that VPN address assignments can be distinguished from local
   devices (by subnet choice, for example), and LISs should not attempt
   to provide location to addresses that arrive via VPN connections.

Comment: Would it be reasonable to have a similar requirement for that
LISs should not provide location for enterprise gateways, or connections
from other service providers?
-----------
   ED-26 For devices which are not expected to roam, refreshing on the
   order of once per day is RECOMMENDED.

   ED-27 For devices which roam, refresh of location SHOULD be more
   frequent, with the frequency related to the mobility of the device
   and the ability of the access network to support the refresh
   operation.  There can be instances in which a device is aware of when
   it moves, for example when it changes access points.  When this type
   of event occurs, the device SHOULD refresh its location.

Comment: I think an additional requirement is needed along the lines of:
If location is configured as a PIDF-LO, the device MUST refresh location
prior to the retention-expires value. If this value is not present, RFC
4119 says it must be assumed to be 24 hours.
------------
   AN-21 Location validation of civic locations via LoST SHOULD be
   performed by the LIS before entering a location in its database.

Comment: Why does it have to be via LoST? We have existing validation
mechanisms that should continue to be valid. I'd like to strike "via
LoST", or provide it as an example mechanism. Also we validate long
before it gets to the LIS, so we wouldn't expect the LIS to do this. How
about "Location validation of civic locations entered into a LIS
database MUST be performed (e.g. via LoST)." I think this is a MUST and
not a SHOULD.
-------------
6.10.  Location validation
I'd like to see an additional requirement along the lines of:
ED-XX Endpoints MUST validate user-entered locations (Section 6.2.1) via
LoST. Validation SHOULD be performed in conjunction with the LoST route
query. 
-------------
   ED-39 If the LCP does not return location in the form of a PIDF-LO
   [RFC4119], the endpoint MUST map the location information it receives
   from the configuration protocol to a PIDF-LO.

Comment: Have we decided whether we need more guidance on geo format
conversion? Can we reference that guidance for converting civic format
is in RFC 4776 for DHCP and in the LLDP-MED spec?
--------------
   ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of
   placing an emergency call unless local regulations require it.

Comment: I'd like to see better definition of what you mean by
"uninitialized device". I'd like to see this term in framework
terminology section (and I'll make that comment against framework). From
framework, I gather that uninitialized devices are "not registered, or
that don't have valid call back identifiers". Does this mean that a
device that registers against an Asterisk server in my basement is
"initialized"? Should the "or" in the definition be "and" (i.e., valid
call back is required to be considered initialized)? I'll put this whole
comment in framework, but may need to revisit these requirements based
on what's decided there. Probably not, though.
---------------
   ED-47/SP-26 Uninitialized devices MUST include identifiers in the
   signaling that can be used by the service provider to identify the
   device and to allow filtering of calls from the device by the PSAP/
   ESRP.

Comment: Since this is a must, is there any recommendation as to what
sort of ID needs to be included?
---------------
   SP-27 All proxies in the outbound path SHOULD recognize emergency
   calls with a Request URI of the service URN in the "sos" tree.  An
   endpoint places a service URN in the Request URI to indicate that the
   endpoint understood the call was an emergency call.  A proxy that
   processes such a call looks for the presence of a Route header with a
   URI of a PSAP.  Absence of such a Route header indicates the UAC was
   unable to invoke LoST and the proxy MUST perform the LoST mapping and
   insert a Route header with the URI obtained.

Comment: What does a PSAP URI look like (since the proxy is expected to
look for the presence of such a thing)? Or is the proxy really only
expected to look for a non-null and routable URI in the Route header?
---------------
   ED-55/SP-32 sips: MUST be specified when attempting to signal an
   emergency call with SIP.

Comment: If the device is configured to do SIP over IPsec, is TLS still
needed? I'm also concerned as to whether this is really practical -- I'd
prefer for the device to make all calls (including emergency calls) the
way it's been configured to make calls. 
---------------
   ED-60 The initial SIP signaling Method is an INVITE: 
  5.   A Route: header SHOULD be present with a PSAP URI obtained from
        LoST (see Section 8) and the loose route parameter.  A sips URI
        [RFC3261] SHOULD be specified, unless the operation must be
        retried due to a failure to establish a TLS connection.  If the
        device does not do dial plan interpretation, no Route: header
        will be present.

Comment: A Route header would also not be present if LoST failed, even
if it did do dial plan interpretation?
----------------
   11.  If a device understands the SIP Location Conveyance extension
        and supports LoST [I-D.ietf-ecrit-lost] then whichever location
        is used for routing the message towards the PSAP or ESRP, even
        if there is only one, the Geolocation "message-routed-on- this-
        uri" header parameter SHOULD be added to the corresponding URI
        in the Geolocation header.

Comment: Why isn't this a MUST?
----------------
   SP-35 SIP Proxy servers processing emergency calls:
   1.  If the proxy does dial plan interpretation on behalf of user
       agents, the proxy MUST look for the local emergency dialstring at
       the location of the end device and MAY look for the home
       dialstring.  

Comment: Same as my first comment about SPs not knowing local
dialstrings. Since the device probably didn't include location in the
SIP INVITE, these means the SP will  likely use the default location on
record, and will only recognize dialstrings associated with that
location.
------------------
   SP-35 SIP Proxy servers processing emergency calls:
   1.  If the proxy does dial plan interpretation on behalf of user
       agents, the proxy MUST look for the local emergency dialstring at
       the location of the end device and MAY look for the home
       dialstring.  If it finds it, the proxy MUST:
       *  Add a Route header with the service URN appropriate for the
          emergency dialstring.
       *  Replace the Request-URI (which was the dialstring) with the
          PSAP URI obtained from LoST.

Comment: Are these backwards? Should the Request-URI be the service URN
and the Route header be the PSAP URI?
-------------------
13.  Disabling of features

Comment: I'm really not comfortable with disabling features without
properly thinking through scenarios where they might be useful, and then
proving they aren't needed or can be worked around. I want to avoid the
Law of Unintended Consequences. I think this is probably the only big
issue that remains in this document (for me). I'll start a discussion on
the list.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

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