Subject: [Ecrit] Review of draft-ietf-ecrit-framework-03

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Oct 2007 00:38:47 +0200

Hi Brian, James, Andy, Henning,

I went through the framework draft
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt
and have a few comments.

The document is getting better and better. Thank you Brian for the 
substantial update.

Technical Comments:
-------------------

* Section 3 gives the impression that the emergency services variant 
that requires the end host to
 -- recognize the emergency call,
 -- obtain location information, and to
 -- determine the PSAP URI
is the only variant. That's, however, not true as the later text in the 
document reveals.

Hence, I suggest that this section is labeled as an example. 
Additionally, I would highlight the other
variants as well.

* Section 4 reads a bit like text of a regulator. While it seems that 
this is the current direction of regulators I wonder whether we should 
really say better delete the section.

Furthermore, one paragraph is repeated, namely "Certainly, any device 
.... should work.".

*

" Such translation is best done by the endpoint,
   because emergency calls convey location in the signaling, but non
   emergency calls do not normally do that.  
"

That's not the only reason. In general one could say that the end host 
would not execute the emergency service related procedures. 
Additionally, the proxy might not be able to uniquely detect the visited 
emergency dial string as an emergency call.

This statement also applies to the subsequent sentence:

"
   Dial string recognition
   could be performed in a signaling intermediary (proxy server) if for
   some reason, the endpoint does not recognize it.
"

* "
   Note: It is undesirable to have a single "button" emergency call user
   interface element.  These mechanisms tend to result in a very high
   rate of false or accidental emergency calls.  In order to minimize
   this rate, devices SHOULD only initiate emergency calls based on
   entry of specific emergency call dial strings.
"

I am not sure we need to put this into the draft. First, we don't 
provide a reference that supports our statement.
Second, this is not really our area of expertise.

Finally, the "SHOULD" is not appropriate here.

* Section 5

"
For end systems, on the other hand, it is
   desirable to have a universal identifier, independent of location, to
   allow the automated inclusion of location information and to allow
   the device and other entities in the call path to perform appropriate
   processing within the signaling protocol in an emergency call set-up.
"

The benefit is not really for the end system as such. I see the benefit 
more as a mechanism for emergency services call marking; hence for the 
entities that are along the signaling path.

* Section 6.1:

"
In IETF
         location protocols, there is a element (Postal Community Name)
         that can be included in a location to provide the post office
         name as well as the actual jurisdictional community name.
         There is no other accommodation for postal addresses in these
         protocols.
"

In which protocols is an element for postal community name?

* Section 6.2.2:

"
   The threshold for when interior location is needed is approximately
   650 m2 (that is derived from fire brigade recommendations of spacing
   of alarm pull stations) should have, but interior space layout,
   construction materials and other factors should be considered.  The
   ultimate goal is to be able to find the person in need quickly if
   responders arrive at the location given.
"

Do we have a reference that supports this statement?

* Section 6.3

"
However NATs and other middleboxes often make it
   impossible to determine a reference identifier the access network
   could use to determine the location.
"

As we discussed in GEOPRIV this is not really a problem.

Section 6.6:

"
The presence of NAT and VPN
   tunnels (that assign new IP addresses to communications) can obscure
   identifiers used by LCPs to determine location, especially using
   HELD.
"

The same is true for DHCP.

"
 In mobile handsets, routing is often accomplished with the cell
   site and sector of the tower serving the call, because it can take
   many seconds to start up the location determination mechanism and
   obtain an accurate location.
"

This functionality is not provided by LoST.

"
   NENA recommends IP based systems complete calls in two seconds (last
   dial press to ring at PSAP).
"

I suggest to add a reference.

* Section 6.8:

"
 In a
   subscription environment, the PSAP could update the parameters in the
   filter (immediate response required).
"

I suggest to add a bit more text regarding the meaning of the 
"subscription environment".

"
In a HELD dereference, there
   is no way to cancel and the PSAP will have to choose a ResponseTime
   that it will wait for even if it wants to dispatch sooner than that.
"

Not sure what that means.

* Section 6.9:

"
Guidelines for dealing with
   multiple locations are also given in [I-D.ietf-ecrit-lost].
"

The guidelines in LoST regarding multiple location refer to something 
entirely different.
I would delete this sentence.

* Section 6.10:

"
Validation in this context means both that there is a
   mapping from the address to a PSAP and that the PSAP understands how
   to direct responders to the location.
"
We use a different description of the term validation. See ECRIT 
terminology draft.
The same is true for the following text as well:

"
 Validation is normally a concern
   for civic addresses, although there could be a concern that a given
   geo is within at least one PSAP service boundary; that is, a "valid"
   geo is one where there is a mapping.
"

* Section 6.11

"
Default locations must be marked as such so that the
   PSAP knows that the location is not accurate.
"

How is this done?

* Section 6.12

"
   To prevent against spoofing of the DHCP server, devices implementing
   DHCP for location configuration should use DHCP security mechanisms
   [RFC3118].
"

That's true for all protocols, including HELD. For most protocols, such 
as DHCP, this is, however, not practical to assume that DHCP security is 
used.

* Section 7: Delete this section since we have a separate document on 
this topic.

* Section 14:

"
   Media should be kept secure, preferably by use of Secure RTP
   [RFC3711].
"

You should indicate what mechanisms are required for establishing the 
keying material for SRTP.

* Acknowledgements

I suggest to be more accurate. People volunteer todo reviews and spend a 
lot of time providing feedback. We should acknowledge their work at 
least by saying what type of feedback they provided.

Editorial Comments:
-------------------

* Search for "Section Section" in the .txt file.

* Introduction:

"
 Tunnels can
   obscure the identity of the actual access network that knows the
   location.
"

I guess what you want to say is the following:

"When IP addresses are used to determine the location information of an 
end host then different results are accomplished
depending on whether the inner or the outer tunnel address are used for 
the lookup."

* FROM:

"There will be PSAPs
   that require new systems to terminate to existing mechanisms for some
   time.
"

TO:

"There will be PSAPs
   that require new systems to terminate existing mechanisms for some
   time."

* FROM:

"
   o  The call is routed to the most appropriate PSAP, selected
      principally by the location of the caller.
"

TO:

"
   o  The call is routed to the most appropriate PSAP, selected
      principally by the location of the caller and the service URN.
"

" Section 3:

FROM:

"
An emergency call can be distinguished (Section 5) from any other
   call by a unique Service URN [I-D.ietf-ecrit-service-urn], that is
   placed in the call set-up signaling when a home or visited emergency
   dial string is detected.
"

TO:

"
When a home or visited emergency dial string is detected then the call 
is marked with
a Service URN [I-D.ietf-ecrit-service-urn]. Thereby, an emergency call 
can be distinguished (Section 5)
from non-emergency calls by other SIP signaling entities.
"

* FROM:

"
The call is routed
   (Section 8) based on location using the LoST protocol
   [I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs.
"

TO:

"
The call is routed
   (Section 8) based on location and the service URN using the LoST protocol
   [I-D.ietf-ecrit-lost] that maps the input to a set of PSAP URIs.
"

FROM:

"
   At some time after her device has booted, Alice initiates an
   emergency call.  She may do this by dialing an emergency dial string
   valid for her current ("local") location, or for her "home" location.
"

TO:

"
   At some time, Alice initiates an
   emergency call.  She may do this by dialing an emergency dial string
   valid for her current ("local") location, or for her "home" location.
"

* FROM:

"
If the endpoint
   does not support the translation of dial strings to telephone
   numbers, the dialing sequence would be represented as a dial string
   [RFC4967] and the outgoing proxy would recognize the dial string and
   translate to the service URN.
"

TO:

"
If the endpoint
   does not support the translation of dial strings to service URNs,
   the dialing sequence would be represented as a tel URI
   [RFC4967]. The outgoing proxy would have to recognize the dial string
   and translate to the service URN. In some cases the proxy might
   have difficulties to detect the emergency call.
"

* Section 5

I suggest to move the following paragraph

"
   While in some countries there is a single 3 digit dial string that is
   used for all emergency calls (i.e. 9-1-1 in North America), in some
   countries there are several 3 digit numbers used for different types
   of calls.  For example, in Switzerland, 1-1-7 is used to call police,
   1-1-8 is used to call the fire brigade, and 1-4-4 is used for
   emergency medical assistance.  In other countries, there are no
   "short codes" or "service codes" for 3 digit dialing of emergency
   services and local (PSTN) numbers are used.
"

after the first paragraph:

"
   Using the PSTN, emergency help can often be summoned by dialing a
   nationally designated, widely known number, regardless of where the
   telephone was purchased.  The appropriate number is determined by the
   infrastructure the telephone is connected to.  However, this number
   differs between localities, even though it is often the same for a
   country or region, as it is in many countries in the European Union.
   In some countries, there is a single digit sequence that is used for
   all types of emergencies.  In others, there are several sequences
   that are specific to the type of responder needed, e.g., one for
   police, another for fire.

"

* Section 6.1:

"Geospatial (geo)" --> geodetic.

* "
In IETF protocols, civic and geospatial forms are both supported.
"

I would add references here.

* Terminology Section
I would be add references to all the terms.

The term "access network" or "access network provider" is defined 
differently in
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt
The same is true for LIS.

The confidence and uncertainty require a reference. You might, for 
example, want to look at
http://cobweb.ecn.purdue.edu/~ee650/downloads/uncertainty-in-measurement-uk.pdf

With respect to the mobility related terminology you might also refer to 
http://www.ietf.org/rfc/rfc3753.txt.

* There are far too many normative references in the document.
I would at least move the following refs to the informative section:
 - [I-D.barnes-geopriv-lo-sec]
 - [I-D.ietf-sipping-config-framework]
 - [RFC2401]
 - [RFC3118]
 - [RFC3920]
 - [RFC4033]
 - [RFC4190]

idnits says:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  
----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See 
Section
     2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the case
     when there are no actions for IANA.)

  Miscellaneous warnings:
  
----------------------------------------------------------------------------

  == Line 56 has weird spacing: '...support  emerg...'

  == Line 476 has weird spacing: '...support  emerg...'

Ciao
Hannes

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