Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt

["Dawes, Peter, VF-Group" <[e-mail]>]

Hi Brian,
Copied below is an e-mail I sent in April with comments and questions on
draft-ietf-ecrit-framework-09.txt. 

Peter


Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 -
distordedreference

------------------------------------------------------------------------
--------

To: "Gunnar Hellstrom" <gunnar.hellstrom at omnitor.se>, <ecrit at
ietf.org>, "Brian Rosen" <br at brianrosen.net> 
Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 -
distordedreference 
From: "Dawes, Peter, VF-Group" <Peter.Dawes at vodafone.com> 
Date: Thu, 2 Apr 2009 15:28:11 +0200 
Delivered-to: ecrit at core3.amsl.com 
In-reply-to: <003001c9afba$44702d70$211ea8c0 at GunnarH> 
List-archive: <http://www.ietf.org/mail-archive/web/ecrit> 
List-help: <mailto:[e-mail]?subject=help> 
List-id: <ecrit.ietf.org> 
List-post: <mailto:[e-mail]> 
List-subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:[e-mail]?subject=subscribe> 
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:[e-mail]?subject=unsubscribe> 
Thread-index: AcmvLd81tlepZceYSYeGbih7J01RLgAhEWXwAPjl8JA= 
Thread-topic: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 -
distordedreference 

------------------------------------------------------------------------
--------

Hello Brian,
I have been reading
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt to
understand how it works, and I have some questions and comments about
the draft text. I also spotted some editorial corrections, so I have put
them at the bottom of this e-mail.

Thanks for the very readable draft.

Best Regards,
Peter

QUESTIONS/COMMENTS
------------------
[Page 2]/1. Terminology/"Location conveyance:  Location conveyance
delivers location information to another element."

Is this 'location information' physical location or some other kind of
location information? Also, maybe "to another element" should be
deleted. 


[Page 3]/2.  Introduction
"Such citizen/
   visitor-to-authority calls can be distinguished from those that are
   created by responders (authority-to-authority) using public
   communications infrastructure often involving some kind of priority
   access as defined in Emergency Telecommunications Service (ETS) in IP
   Telephony [RFC4190].  They also can be distinguished from emergency
   warning systems that are authority-to-citizen."

Does "can be distinguished" mean that by looking at the signalling you
can tell whether the call is visitor-to-authority etc., or does it mean
that the draft  only applies to visitor-to-authority calls?


[Page 6]/3.  Overview of how emergency calls are placed
" o  The phone gets location via a Location Configuration Protocol
      (LCP), for example from the DHCP server in civic [RFC4776] and/or
      geo [RFC3825] forms, a HELD server"

Should the ", a HELD server" be removed, or is a DHCP server also a HELD
server?


[Page 7]/3.  Overview of how emergency calls are placed

"o  The phone obtains the local emergency dial string(s) from the LoST
      [RFC5222] server for its current location.  It also receives and
      caches the PSAP URI obtained from the LoST server.
.
.
.
"o  It refreshes its location via DHCP and updates the PSAP's URI by
      querying the LoST mapping server with its location."

Does this mean that the dial strings and PSAP URI are initially pushed
in some way from the LoST server, or does the phone query the LoST
server in both  cases?


[Page 7]/3.  Overview of how emergency calls are placed
"o  The proxy recognizes the call as an emergency call and routes the
      call using normal SIP routing mechanisms to the URI specified."

Maybe this bullet should give a hint why the proxy needs to recognize
the call as an emergency one. It could say "The proxy recognizes the
call as an  emergency call, e.g., to allow it to take remedial action if
the phone location had not been included by the phone, and routes the
call using normal SIP  routing mechanisms to the URI specified."


[Page 10]/3.  Overview of how emergency calls are placed

"A proxy in the PSAP chooses an available call taker and extends the
   call to its UA."

Isn't this a function of a registrar and not a proxy?


[Page 12]/5.  Identifying an emergency call


"For devices that are mobile or nomadic, an issue arises of whether
   the home or visited dial strings should be used.  Many users would
   prefer that their home dialing sequences work no matter where they
   are.  However, local laws and regulations may require that the
   visited dialing sequence(s) work.  Therefore, the visited dial string
   must work.  Devices may have a way to be configured or learn home
   dial strings."

The last sentence doesn't seem to fit in with the rest of the paragraph.
Is this paragraph making the point that a mobile or nomadic device must
always query  for the correct dial strings for its current location
before making an emergency call?


[Page 18]/6.3 Who adds location, endpoint or proxy

"Proxy insertion of location complicates dial string recognition."

I don't understand how Proxy insertion of location relates to dial
string recognition. Should the sentence above be deleted? 


[Page 26][Page 27]/8.  Routing the call to the PSAP

"There is no mechanism provided in [I-D.ietf-sip-location-conveyance]
for a proxy
   to request the endpoint supply its location, because that would open
   the endpoint to an attack by any proxy on the path to get it to
   reveal location.  The proxy can attempt to redirect a call to the
   service URN which, if the device recognizes the significance, would
   include location in the redirected call from the device."

The paragraph above indicates that a proxy cannot request location from
an endpoint, and then seems to describe a way to do it by redirecting
the call to a  service URN. Is this contradictory?


[Page 27]/8.  Routing the call to the PSAP

"In order for the ESRP to route on media choice, the initial
   INVITE request has to supply an SDP offer."

[Page 28]/9.2.  SIP signaling requirements for User Agents

"To enable media sensitive routing,
   the call should include an SDP offer."

Enabling the ESRP to route on SDP seems to differ from normal SIP
practice. I would have thought that using caller prefs only (e.g.,
audio, video) is normal.  Also, since the ESRP doesn't know what the
terminating end of the call will answer in terms of SDP, I would have
thought that routing on the SDP in the offer  might choose the wrong
destination.


[Page 28]/9.3.  SIP signaling requirements for proxy servers

"They should recognize
   emergency dial strings, inserting the Route header with the
   appropriate service URN."

"They should query LoST with
   the location and put the resulting URI in the Request URI."

I think that 9.3 has URN and URI the wrong way around. The PSAP URI goes
in the Route header field and the service URN goes in the request URI. 






GENERAL
-------

The draft uses "end system" and  "endpoint" in various locations, would
it be better to use endpoint throughout?

RFC3261 always says "header field" (e.g., "Via header field") and not
just "header". 



 
EDITORIALS
----------
[Page 2]/1. Terminology/"Nomadic device (user):  A nomadic user agent is
connected to the
      network temporarily, for relatively short durations, but does not
      move significantly during the during the emergency call.  Examples
      include a laptop using an IEEE 802.11 hotspot or a desk IP phone
      that is moved occasionally from one cubicle to another."

"during the" is repeated.


[Page 3]/1. Terminology/"RoutinglLocation:  The routing location of a
device is used for
      routing an emergency call and may not be as precise as the
      Dispatch Location."

Space needed in "RoutinglLocation":


[Page 3]/2.  Introduction/"This document discusses how end device and
applications create emergency calls,"

"device" should be "devices"


[Page 14]/6.1.  Types of location information

"Jurisdictional  refers to a civic location using actual political
         subdivisions, especially for the community name.
      Postal  refers to a civic location for mail delivery."

Needs colon after Jurisdictional and Postal.


[Page 19]/6.4.  Location and references to location

"When location is transmitted by value, the location information is
   available to entity in the call path."

"entity" should be "entities"


[Page 20]/6.5 End system location configuration

"Normally, mobile devices will
   acquire its location at call time for use in an emergency call
   routing.  See Section 6.8 for a further discussion on location
   updates for dispatch location."

"mobile devices" should be "a mobile device"


[page 29]/11.  Mid-call behavior

"Therefore a PSAP may need to a REFER request [RFC3515] a call to a
   bridge for conferencing."

should say "Therefore a PSAP may need to send a REFER request [RFC3515]
to redirect a call to a
   bridge for conferencing."

Also,
"Requiring UI manipulation..." should say "Requiring URI
manipulation..."



[Page 30]/12.  Call termination

"i.e with a BYE request." should be "i.e., with a BYE request."


[Page 31]/15.  Testing

"<> includes a description of an automated test procedure that
   validates routing, signaling and media path continuity."

Is something missing from inside the "<>"? 


-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On
Behalf
Of Gunnar Hellstrom
Sent: 28 March 2009 15:31
To: ecrit at ietf.org; Brian Rosen
Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 -
distordedreference

Brian,
A minor editorial:
I noticed that the reference to RFC 4103 in section 9.1 was distorded in
editing.

It looks like this now: 
xref target="RFC4103"/>

It should look like this:
[RFC4103]

/Gunnar

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On
Behalf
Of Internet-Drafts at ietf.org
Sent: Friday, March 27, 2009 11:45 PM
To: i-d-announce at ietf.org
Cc: ecrit at ietf.org
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Emergency Context Resolution with
Internet Technologies Working Group of the IETF.


	Title           : Framework for Emergency Calling using Internet
Multimedia
	Author(s)       : B. Rosen, et al.
	Filename        : draft-ietf-ecrit-framework-09.txt
	Pages           : 37
	Date            : 2009-03-27

The IETF has standardized various aspects of placing emergency calls.
This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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


------------------------------------------------------------------------
--------

References: 
Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distorded
reference 
From: Gunnar Hellstrom
Prev by Date: Re: [Ecrit] Use of SIPPING config framework for
configuring location 
Next by Date: Re: [Ecrit] Use of SIPPING config framework for
configuring location 
Previous by thread: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09
- distorded reference 
Next by thread: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-09.txt 
Index(es): 
Date 
Thread  


 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Brian Rosen
Sent: 27 July 2009 21:33
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt

This update fixes idnits, and that is it.

Brian

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf

> Of [e-mail]
> Sent: Monday, July 27, 2009 12:45 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Emergency Context Resolution with 
> Internet Technologies Working Group of the IETF.
> 
> 
> 	Title           : Framework for Emergency Calling using Internet
> Multimedia
> 	Author(s)       : B. Rosen, et al.
> 	Filename        : draft-ietf-ecrit-framework-10.txt
> 	Pages           : 37
> 	Date            : 2009-07-27
> 
> The IETF has standardized various aspects of placing emergency calls.
> This document describes how all of those component parts are used to 
> support emergency calls from citizens and visitors to authorities.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-10.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit