Subject: [Ecrit] Review List

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 02 Oct 2006 10:05:09 +0200

Hi all,

to make progress with our work please review the following documents:

LoST:
-----

http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-01.txt

The issue tracker is available at:
http://www.tschofenig.priv.at:8080/lost/index

DHCP-based LoST discovery:
http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-dhc-lost-discovery-01.txt

Mapping Architecture:
---------------------

http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/draft-ietf-ecrit-mapping-arch-00.txt

ECRIT Framework:
-----------------

http://tools.ietf.org/wg/ecrit/draft-rosen-ecrit-framework-00.txt

Phone BCP:
----------

http://www.ietf.org/internet-drafts/draft-rosen-sos-phonebcp-01.txt

Ciao
Hannes & Marc

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Oct 2006 18:10:40 -0400

In response to Hannes' suggested review list, I took a look at the
ecrit-framework draft.  My comments are below.  I'd be glad to help with 
revisions, especially to the security considerations; just let me know.
--Richard

Comments about Security Considerations:
-- There should be an introductory paragraph setting out the general 
security context for ECRIT, roughly as it is laid out in 16.1: There are 
a variety of security services that can be employed, but any security 
policies need to be balanced against the need for all legitimate 
emergency calls to be completed.

-- I'd like to suggest a restructuring of the Security Considerations 
section.  There are two core concerns when it comes to security of 
emergency calling: Location information and call routing.  It seems like 
we could split the security considerations into these two parts, and 
treat each along its lifecycle.

-- Section 16.2 needs a more systematic list of points in the call flow 
where location data might be compromised, and a corresponding list of 
countermeasures.

-- It's misleading for section 16.2 to reference RFC 3118, which only 
deals with authentication (not confidentiality).  Perhaps there's a 
separate section here for "Location Integrity" to cover impersonation of 
location providers, etc.?

-- Section 16.4 says that "sips:" forces TLS on each hop, which is false.

Other substantive comments:
-- Is this intended to be INFORMATIONAL or BCP?  It seems like the 
former, but there are places where it makes recommendations.

-- (Page 4) Is there a better example than GPS to differentiate between 
Acquisition and Determination?  AGPS, perhaps, or LLDP-MED?

-- (Page 5) I'm not clear on what the bullet about 
"separation/interleaving of signaling and media packets" means.  Can you 
clarify?

-- (Page 6) With respect to the following block:
 >   To ensure that at least one common means of
 >   communications, this document recommends certain minimal capabilities
 >   in [I-D.rosen-sos-phonebcp] that call taker user agents and PSAP-
 >   operated proxies should possess.
Do you mean that this document makes recommendations, or that the 
phonebcp does?

-- (Page 8) It seems like this section wanders a little; it should be 
more structured either by making more thorough use of the numbers in 
Figure 2 or by referencing the numbers in Figure 1.

-- (Page 10) What's the point of messages [M5, M6] (or, equivalently, 
[M8-9])?  It seems like if the UA already had a PSAP URI, it would just 
go directly there, rather than to the sos URN, and the secondary LoST 
lookup would be unnecessary.

-- (Page 12) Should section 5.1 contain some mention about the usage of 
the transmitted location for directing first responders?

-- (Page 13) In the paragraph starting "All location objects...":  This 
first sentence seems at odds with the guidance of the previous paragraph 
(pointing to phonebcp).  In the second sentence, it's not clear which 
"such policy decisions" you're referring to.  Perhaps this whole 
paragraph should be struck in deference to the phonebcp?

-- (Page 15) "It also requires all devices to be equipped with the 
appropriate GPS capability."  This seemed a little non-sensical to me -- 
GPS requires devices to be equipped with GPS?  How about: "Only devices 
equipped with the capability to receive GPS signals can use GPS to 
determine their location"

-- (Page 15) Section 5.4: I would remove the hyphens from "by-value" and 
"by-reference", and the "as" before "by-value".

Editorial comments:
-- (Page 4) Missing closing paren after "National Emergency Number 
Association"
-- (Page 5) Missing period after "... EV-DO as an uplink"
-- (Page 5) Missing comma after "... 9-1-1 or 1-1-2"
-- (Page 7) In the first paragraph of section 3, there's a lot of weird 
parens.
-- (Page 8) Numbers in Figure 1 are never referenced
-- (Page 8) Reference to Figure 2 should be to Figure 1.
-- (Page 9) Missing period after "...may not pass through one"
-- (Page 13) Delete "Handling multiple locations ... XRef??."  This is 
already handled at the end of the paragraph.
-- (Page 11) "... common emergency call URIs ..."  should be "... common 
emergency call URNs ..."
-- (Page 25), "emergency calls are to handled" should be "emergency 
calls are to be handled