Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

["Brian Rosen" <br at brianrosen.net>]

Thank you for your comments.  I have dealt with most of them in the -05
version of -phonebcp.  Please note that -phonebcp must be read in
conjunction with -framework, as the latter does not explain why the
requirement is in place, where framework does.  Some of your comments imply
you want more motivation for the requirement.  -framework is where you can
find that motivation.  If the motivation in -framework is not sufficient, we
can improve it there.

Brian

> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
> Gabor.Bajko at nokia.com
> Sent: Sunday, March 02, 2008 11:37 PM
> To: Hannes.Tschofenig at gmx.net; ecrit at ietf.org
> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04
> 
> Few comments below:
> 
> 1. The title of the document does not explicitely say that this document
> is about "VoIP" emergency calls.
> Suggestion: add "VoIP" to the title (... Communications Services in
> support of VoIP Emergency Calling)
My co-author answered this item.  Communications services encompasses all
forms of interactive media including voice, video and text.  Therefore, VoIP
is not an appropriate term

> 
> 2. The title of the documents says "Best Current Practice for ...",
> while the document is not a collection nor a subset of the currently
> used practices for emergency calling. And there is no 'current practice'
> for VoIP emergency calling yet, thus a 'best current practice' of yet
> nonexisting practices is confusing.
> Suggestion: change the title eg to "Requirements for Communication
> Services in support of VoIP Emergency Calling"
> (and revise the abstract section accordingly)
My co-author dealt with this issue. BCP is what the IETF uses for this kind
of document.

> 
> 3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
>    Request-URI of the INVITE."
> Marked by whom, the endpoints, the proxies or both? Clarify
Since the requirement is labeled "ED-4/SP-3" it is marked by the End Device,
with the Service Provider assuring that if the end device doesn't do it, the
SP does.
> 
> 4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5
> Home dial strings MAY be recognized."
> Recognized by whom? Clarify
See above

> 
> 5. "ED-10 Devices SHOULD NOT have one button emergency calling
>    initiation."
> While I understand that the intention is to discourage vendors to design
> devices with a button dedicated only for emergency calls, current mobile
> phones have the possibility of 'speed dial', when a preset dial string
> (including 112 or 911) can be assigned to any button. Requirement ED-10
> can be also read to ban this feature in the phone. Clarify.
> I do not have a suggestion, but as today's devices do not have such a
> dedicated red button any more, I see no value in this requirement, it
> just creates confusion.
I added some text in -framework that says that speed dials with the
emergency dial string should be prohibited.  The requirement is ED-68.
> 
> 6. "ED-11/SP-9 All emergency services specified in
> [I-D.ietf-ecrit-service-urn] MUST be recognized."
> Recognized by whom? Clarify.
See above

> 
> 7. "6.1.  Types of location information
> 
>    There are several forms of location.  In IETF protocols , civic and
> geospatial (geo) forms are both supported."
> The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all
> 'IETF protocols', but they do not support location. Be more specific.
I reworded the text to "IETF location configuration and location conveyance"

> 
> 8. section 6.1
> "Other forms of
>    location representation must be mapped into either a geo or civic for
>    use in emergency calls."
> Currently most mobile network carriers use cell-id for directing the
> call to the correct psap. That technique will not go away for yet a long
> time. While cell-id could be mapped into either civic or geo, there is
> no added value in doing so, as cell-id based routing serves the purpose
> just as well as civic or geo based routing. I would suggest relaxing the
> requirement, otherwise the draft will go against current practices.
I believe this issue was discussed and the conclusion is that cell id should
not be used as location when sent to a PSAP (or a device for that matter).
Cell ID is, and will be used within wireless networks, but they will not be
used in the places this document deals with.  No changes were made

> 
> 9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location
>    MUST have at least a coarse location capability (typically <1km
>    accuracy when not location hiding) at all times for routing of
> calls."
> I do not understand the text in the brackets. What is location hiding
> (add reference to it) and what happens when it is applied, will the req
> become n/a? clarify.
See the text in -framework for an explanation.

> Same comment for AN-9
> 
> 10. same paragraph as above. "This mechanism MAY be a service provided
> by the access network." It is not clear what 'this mechanism' refers to.
I fixed the text to say "The location determination mechanism"
> 
> 11. "AN-8 Access networks MAY provide network-measured location
>    determination.  Wireless access network which do not support network
>    measured location MUST require that all devices connected to the
>    network have end-system measured location. "
> What kind of wireless access networks are we talking about? Commercial,
> public, private, academic or all of them? I could hardly believe that a
> free public network like the google one in Mountain View (which does not
> support network measured location) would have a means to restrict my
> laptop's access (which does not have an end-system measured location).
> Suggestion: be more specific. Say 'commercial wireless access networks'
> or 'subscription based wireless access networks'. It has to be a managed
> network, otherwise nothing can be enforced.
All access networks must make sure location can be provided for emergency
calls.  There are no exceptions.  The free google network must supply
location one way or another.

> 
> 12. "ED-27/INT-20 If the device sends a DHCP INFORM message"
> The text should say 'DHCPINFORM' (no space between, rfc2131).
Fixed

> 
> 13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow
> split
>    tunneling VPNs, location configuration SHOULD be attempted before
>    such tunnels are established."
> Add reference to 'split tunneling VPNs'(if exists). If there is no
> reference, then be more explicit. Say that using an LCP while on a VPN
> may result in getting the location of the vpn gateway. Avoid using
> non-defined terms.
I reworded the text to say " To minimize the effects of VPNs that do not
allow packets to be sent via the native hardware interface
rather than via the VPN tunnel" 
> 
> 14. "ED-47 Endpoints MUST support one or more mechanisms that allow them
>    to determine their public IP address.  Examples include ICE ..."
> It should be STUN instead of ICE.
Fixed

> 
> 15. "   ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in
> Call
>    Forward numbers or speed dial lists."
> There is no such regulatory requirement in place. Vendors comply with
> regulatory requirements when it comes to emergency services. This draft
> is not an amendment to any regulatory document, thus this requirement is
> inappropriate. Remove it.
Emergency service professionals recommend such features be disabled.  See
comment above

> 
> 16. general comment: the draft seem to focus on 802.11 access networks.
> The term "access point" is used all over. Access networks other than
> wi-fi use terms like base station, rnc, node-b, etc. If the draft is
> meant to be applicable to access networks other than wi-fi, then a more
> generic term should be used instead of 'Access Point'.
I didn't make a change, but I'm willing to if we can agree on a term.

Brian

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit