Subject: [Ecrit] Phonebcp comments

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 17 Apr 2007 15:51:21 -0400

Here are my phonebcp comments.
Barbara

1. Section 2, numbered and bullet lists
" 1. Device connects to access network, and obtains initial location
  2. User dials visited location's emergency number  "

It would be nice if the steps in the bullet list of event could more
closely map back to the steps in the numbered list. The LoST steps
aren't currently reflected in the numbered list. I recommend the
following changes to items 1 and 2 in the numbered list:
1.	Device connects to access network and obtains initial location,
emergency dialstring(s), and emergency urns with their associated PSAP
URIs.
2.	User dials an emergency dialstring.

2. Section 4.4 
"It is essential for the location to be determined BEFORE any VPN
tunnels are established. It is equally essential that this location
information is *not* overwritten by any process engaged from
establishing a VPN connection. In other words, the established VPN to
Chicago from the device in Dallas MUST NOT overwrite the Dallas location
for any reason especially an emergency call."

I would prefer to see "MUST" verbiage, instead of "essential". I also
think the MUST NOT verbiage needs to be applied to the more generic
statement and not the example. I recommend rewording to:
"Devices MUST determine location BEFORE establishing any VPN tunnels.
This location information MUST NOT be overwritten by any process engaged
over the VPN connection. In other words, the established VPN to Chicago
from the device in Dallas must not overwrite the Dallas location for any
reason, especially when there is an emergency call."

3. Section 4.5
Converting to PIDF-LO - Isn't there an IETF reference for how to do this
for a DHCP-delivered location?

4. Section 5
In 2nd paragraph "Note:": "PSAPs prefer devices to use their local
emergency call dialstring."

I'd like to see this sentence deleted, since it seems out of context
here, and this topic is described much better in the 8th paragraph of
this section.

5. Section 6.1
Items 1 and 2, requirement to use sips
There's a large movement to use IPsec instead of TLS, in many VSP
arrangements. I'd like to see this be something like "The device MUST
either specify a sips URI [RFC32361] or establish an IPsec [reference]
session to use for SIP transport, unless neither a TLS nor an IPsec
session can be established."

6. Section 6.5
Paragraph after the numbered list, "...the device should ring..." -
would this be better as "...the device SHOULD "ring"..." [given that
some devices vibrate or flash lights]

7. Section 6.5
Last paragraph - where did "5 minutes" come from? Is this a recommended
default, or is it exactly the right number? If it's a default, what
would be a reasonable range for configuration?

8. Section 6.6 Disabling of features
I would prefer to see the first sentence reworded to be more explicit,
like "When a calling device and/or service determines an emergency call
is being made or is in progress, it SHOULD disable outgoing call
features such as:"

9. Section 6.6 Disabling of features
I'm not sure we should disable 3-way calling (which may require use of
flash hook). I think there could be a case where someone has called
their best friend to ask for help, instead of 9-1-1, and the friend then
calls 9-1-1 and bridges the two legs together. If the first leg is lost,
then the friend may need to try to re-establish the first leg, because
the PSAP may not have the necessary info.

10. Section 6.6 Disabling of features
Call waiting - what's the difference between "Call Waiting" in the first
bullet list and "Call Waiting (all kinds)" in the second list? That is,
why is "all kinds" specified for one and not the other?

11. Section 6.6
The disabling of VAD is easy t o overlook in section 8. I think that
this is really important to do. Could we call out disabling of VAD
specifically in section 6.6?

12. Section 9.1 Testing Mechanism
2nd paragraph, "For the latter, the PSAP SHOULD return location-by-value
even if the original location delivered with the test was by-reference."
I completely disagree. I believe the appropriate requirement is "For the
latter, the PSAP MUST NOT return location-by-value when the original
location delivered with the test was by-reference."

13. Section 9.1
4th paragraph.
I'm not comfortable with the potential frequency of testing that these
requirements would cause. Is there some way a PSAP can specifically tell
an end device to not query this same PSAP uri in a given (in the SIP
response) amount of time?
To make the exception in the 5th paragraph work with the requirements in
the 4th paragraph, I'd prefer words in the 4th paragraph like "...after
a disconnect and subsequent change in IP address, unless this is due to
a reboot."

14. Section 10.1
1st paragraph, last sentence, "The [L7 LCP] is not limited and TLS
SHOULD be used to protect location privacy."
It's possible to implement theL7 LCP in an environment and manner so
that it is limited. I would prefer for this to read "The [L7 LCP] may
not be limited and TLS SHOULD be used to protect location privacy."

15. Section 10.1
2nd paragraph, last sentence, "[L7 LCP] SHOULD use DIGEST authentication
(or better) to identify the LIS." I don't understand this statement
completely. What information does the LIS use to authenticate itself
with the device?

16. Section 10.1
Last paragraph - what if IPsec is being used between the end device and
its VSP?
 
---------------------------------------------------------------
Items I haven't been able to fully research yet (which means I may have
comments on these):
1.	Section 4.5 and 10.1, implications of using RFC 3118 to prevent
against spoofing by the DHCP server.
2.	Section 8, implications of requiring support for RFC 3428 and
3920 for instant messaging.
3.	Section 10.2, implications of requiring use of
P-Asserted-Identity or SIP Identity by calling networks.

----------------------------------------------------------------
Editorial Comments
1.	Section 5, 3rd paragraph, "(i.e. 911 in North America)" - should
this be an "e.g."?
2.	Section 5, 4th paragraph, "responder specific" - hyphenate this
to be "responder-specific"
3.	Section 5, 6th paragraph, "This mapping be SHOULD performed..."
-> "This mapping SHOULD be performed..."
4.	Section 5, 7th paragraph, needs period "." At end of paragraph.
5.	Section 5, 9th paragraph, "If that devices roam..." -> "If that
device roams..."
6.	Section 6.1, item 3, NOTE, "unintialized" -> "uninitialized"
7.	Section 6.1, item 4, needs a period "." at the end.
8.	Section 6.1, item 8, needs a period "." at the end.
9.	Section 6.1, item 11, capitalize first word "If"
10.	Section 6.2, item 1, "If it finds it it MUST" -> "If it finds
this dialstring, it MUST"
11.	Section 6.2, item 3, "...and the message is routing is now to be
done..." -- delete the first "is"
12.	Section 6.3, 1st paragraph, "...the previous mapping may no
longer valid." -> ...the previous mapping may no longer be valid."
13.	Section 6.3, 3rd paragraph, "geo reported" -> "geo-reported"
14.	Section 7, 3rd paragraph, I recommend "...MAY reINVITE the
endpoint and the 200 OK..." -> "MAY reINVITE the endpoint; in this case,
the 200OK..."
15.	Section 7, 3rd paragraph, "For calls send..." - > "For calls
sent..."
16.	Section 8, 2nd paragraph, need period after "...wideband codecs
in the offer"
17.	Section 10.2, last paragraph, "...endpoint SHOULD..." ->
"...endpoints SHOULD..."

*****

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