Subject: [Ecrit] Comments on: draft-ietf-ecrit-phonebcp-01

From: Matt Lepinski <[email-masked]>
Date: Fri, 01 Jun 2007 00:48:59 -0400

Brian and James:

First, two very high level questions.

A) [Is this document supposed to be SIP-Centric?] It is unclear to me 
whether the document is intended as a BCP for SIP User Agents and SIP 
proxies, or whether it is more generally a BCP for end points and 
signaling-path devices which may or may not use SIP. For instance, 
Section 6.4 is written as though SIP signaling were a special case, and 
yet paragraph four of Section 5 indicates that all emergency calls on 
the wire should contain a Route header (which is a SIP-specific 
signaling component). Personally, I don't care whether or not the 
document is SIP centric, or whether SIP is a special case, as long as 
the document is consistent.

B) [Is there consensus on how to mark emergency calls?] The current 
version of phonebcp indicates that (in the normal case when end-points 
perform the LoST mapping) emergency calls are marked by putting the URN 
in a Route header (with a "loose" parameter that I'm not familiar with 
... can someone provide me with a reference) and that the URN is placed 
in the Request-URI when the end-point is unable to perform the LoST 
mapping). Personally, I don't understand the current mechanism because 
I'm not sure what an "ordinary" (RFC3261-compliant) proxy does when it 
sees a service URN in the top Route header. However, given the long 
discussion that occured on call marking in January (See: 
http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), 
perhaps the more important question is "Has consensus been reached that 
(something like) the current mechanism is an appropriate way to mark 
messages?"

---------------------------------
More detailed comments:

Section 2: (paragraph 3 - number 2)
Is it clear what the "visited location's emergency number" means in this 
context?
Consider changing to "the local emergency number for its current 
location" or providing a forward reference to the discussion of 
dial-strings in Section 5.

Section 2: (paragraph 4)
I agree with Barbara that if this is intended to an overview of call 
setup for the special case of an Ethernet connected phone then the 
bullets should match up more clearly with the numbered items in the 
previous paragraph.

Section 2: (last paragraph)
It is unclear whether the antecedent of "it" in the last paragraph is 
[RFC4103] or [RFC4504].

Section 3:
Consider changing "should support" to "SHOULD support"

Section 3: (paragraph 2)
It seems that the point of this paragraph is to say that a certain class 
of devices that communicates over IP networks should support emergency 
calls. However, I find the phrase "using current (evolving) standards" 
to be unclear and in particular I'm not sure what the phrase modifies. 
(E.g. Do you mean "Devices that create media sessions using current 
(evolving) standards and exchange audio ...")

Section 4: (first paragraph)
Consider replacing "the norm" with "required" (or a similar word). I 
think the point is not that automatic location is common/normal but that 
it is necessary since most users are unable to provide accurate location.

Section 4.1: (first paragraph)
I think "cellular" (or "traditional wireless")  is more precise than 
"mobile".

Section 4.2: (first paragraph ... also, the last paragraph)
Consider changing the phrase "the desired result" to something like "an 
equivalent result", or perhaps something even more explicit.

Section 4.2: (first paragraph)
Consider addition a phrase to the last sentence indicating why it is 
recommended that the network support a standardized LCP. (This may not 
be obvious to the reader). Also, consider changing "recommended" to 
"RECOMMENDED".

Section 4.2: (paragraph 2)
Given that the paragraph covers what both devices and access networks 
MUST support, consider changing "For all other devices" to "In all other 
scenarios".

Section 4.3: (paragraph 3)
The term "geo-location" is not used in RFC 3825 to describe a 
lat/lon/alt - style location. (Instead it uses terms like a 
"coordinate-based geolocation"). Also, given that the "geolocation" 
header allows for civic locations, I think using geo-location here is 
potentially confusing.
Note: This comment also applies to the use of "geo reported" in the 
third paragraph of Section 6.3

Section 4.4:  (last paragraph)
Consider re-writing the second-to-the-last sentence as: "Certain 
commonly-used techniques for measuring location create a conflict 
between the time it takes to generate a precise location and the desire 
to route the call quickly." (Also, in the following sentence I think 
"precise" is a better word than "accurate")

Section 5: (paragraphs 5 and 6)
Paragraph 5 says that devices MUST mark calls using a service:sos URN. 
However, paragraph 6 says that mapping from dialstring to URN SHOULD be 
done by the endpoint. Either both paragraphs should use "MUST" or else 
they should both use "SHOULD".

Section 5: (paragraph 8)
I don't understand what it means to be "roaming" or "nomadic" in a 
system where there is no "visited network"

Section 5: (last paragraph)
The last sentence of this paragraph seems to be redundent. Consider 
deleting it.

Section 6.1:
I agree with Barbara that the use of IPSec should not be prohibited by 
this BCP.

Section 6.1: (number 6)
These instructions are for the User Agent,  P-Asserted-Identity headers 
and Identity headers should not be inserted by the UA

Section 6.1: (number 10)
This item is unclear to me. Is the author's intention that this item 
handles the case where a UA does not know its own location? If so, I 
guess that updating this item should be deferred until consensus is 
reached on location-hiding.

Section 6.1:
Consider Re-ordering the items as:
11, 10, 12, 14, 15, 13
Also, consider deleting 12, I believe it is redundent given 9, 10 and 11.

Section 6.2: (number 1)
Consider adding an example after "... URN appropriate for the emergency 
dialstring." That is, consider adding (e.g., ...)

Section 6.2: (number 3)
I'm afraid that I don't understand the meaning of this sentence.

Section 6.3: (paragraph 3)
The sentence that begins "This can be an enclosing ..." is unclear to 
me. Are you suggesting that when a PSAP coverage region is complex, that 
a LoST server SHOULD return a simple polygon that (a) contains the 
location of the device; and (b) is entirely contained within the PSAP 
coverage region?

Section 6.5: (number 3)
This seems to imply that proxies should expect to SUBSCRIBE to Presence. 
Do you mean that proxies should expect the PSAP to SUBSCRIBE to Presence?

Section 6.5: (number 4)
I'm not very familiar with Session Timers, can you provide a reference.

Section 6.6:
I'm afraid I don't understand the parenthetical remark after the "Call 
Forward" bullet. (Consider removing the remark or re-wording it if it is 
important).

Section 7:
Given the text in Section 4.4 it seems to me that the first paragraph of 
Section 7 is redundent and should be deleted.

Section 10.2:
Given the difficulty of implementing location signing in a useful 
manner, I think that that either paragraph 2 should either be removed or 
else it should reference some other document that explains location 
signing in more detail. (That is, one paragraph does not do location 
signing justice and it seems irresponsible to strongly recommend 
location signing without providing additionaly guidence to the implementor).

-------------------------------------------------------------------
Minor Nits: (That don't change the meaning of the text)

Section 2: (last paragraph)
Put a space between [RFC4103] and "media"

Section 3: (paragraph 1)
Add commas to second sentence "Future PSAPs will, however, support ..." 
and remove the extra period at the end of the sentence

Section 4.1: (paragraph 2)
Change "... where it is the access network that knows the location ..." 
to "... when only the access network knows the location ..."

Section 4.4: (paragraph 1)
Change "... process engaged from establishing a VPN ... " to "... 
process engaged by establishing a VPN ..."

Section 4.4: (paragraph 2)
Change "... related to the mobility of the device and ..." to "... 
related to the degree of device mobility and ..."

Section 4.4: (paragraph 2)
Combine the final 2 sentances as follows:
"When a device is aware that it has moved, for instance when it changes 
access points, the device SHOULD refresh its location."

Section 4.4: (last paragraph)
Change "... getting more recent location ..." to "... getting updated 
location ..." or "... obtaining a fresh location"

Section 5: (first paragraph)
Consider re-writing as:
"A device (or a downstream signaling element) identifies an emergency 
call by an "address", which in most cases is a dialstring, although 
other user interfaces may be used."

Section 5: (paragraph 2)
First sentence has too many words modifying the word "element". Consider:
"Note: It is undesirable for a user-interface to enable a user to place 
an emergency call by pressing a single button."

Section 5: (paragraph 3)
Consider changing the first sentence:
"... in other countries there are several 3 digit numbers used for 
different types of emergency calls."

Section 5: (paragraph 6)
Change "... some entity needs to ..." to "... some entity on the 
signaling path must ..."

Section 5: (paragraph 9)
Change "... from North America, the home ..." to "... from North 
America, then while in North America the home ..."

Section 5: (last paragraph)
Add a close parenthesis ")" after "dialstrings."

Section 6:
Change "... is expected be supported ..." to "... is expected to be 
supported ..."

Section 6.1:
Change "signaling Method" to "signaling method" (lower case).

Section 6.1: (number 1)
Change "To: SHOULD" to "Request-URI: SHOULD"

Section 6.1: (number 2)
Add a space between [I-D.rosen-iptel-dialstring] and "with"
Also change "sips MUST be ..." to "a sips URI MUST be ..."

Section 6.2: (number 1)
Change "If it finds it it MUST:" to "If it finds the dialstring it MUST:"
Also, change "... for the endpoint" to "... of the end device." (note 
that period was missing)

Section 6.3: (paragraph 3)
Non-parallel sentence structure. Consider re-writing the last sentence as:
"In the case of civic location, the LoST server SHOULD report that the 
same mapping is good within a community name or even a street, as this 
is helpful for WiFi connected devices that roam and obtain civic 
location from the AP to which they connect."
(Or perhaps "Despite the fact that civic location is uncommon for mobile 
devices, the LoST server SHOULD ...")

Section 6.3: (paragraph 4)
Change "... URI of the service URN ..." to "... URI of a service URN ..."

Section 6.3: (last paragraph)
Re-write the last sentence as: "The proxy then replaces the Request-URI 
with the resulting PSAP URI."
Or perhaps "The resulting PSAP URI then replaces the Request-URI"

Section 6.4: (first paragraph)
Consider adding the phrase "Once the mapping to a PSAP URI has been 
performed," to the begining of the paragraph (to improve the flow of the 
document).

Section 6.6:
Change "The emergency dialstrings ..." to "Emergency dialstrings ..."

Section 7: (paragraph 3)
Change "For calls send with ..." to "For calls sent with ..."

Section 8: (paragraph 1)
Change "... media streams on RTP ... " to "... media stream using RTP ..."
or perhaps "... media streams via RTP ..."
Also, consider re-writing the 4th sentence as:
"Future IP-enabled PSAPs should accept a wider array of potential media 
types."

Section 8: (paragraph 2)
Add a period between "the offer" and "Silence suppression".

Section 10:
Change "... it specifies use of several ..." to "... it specifies the 
use of several ..."

Section 10.1: (paragraph 2)
Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the LCP, 
[RFC3118] ..." (add a comma)
Also, change "... spoofing would be ..." to "... spoofing is ..."

Section 10.1: (last paragraph)
Add an 's' to change "Client SHOULD" to "Clients SHOULD"

Section 10.2: (last paragraph)
Change "... signaling would help significantly." to "... signaling helps 
significantly."

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Jun 2007 08:35:55 -0400

Thanks for your comments.

The BCP really shouldn't be SIP specific.  We need to broaden it to, for
example, XMPP.  We can have SIP specific information, but it should be
discussed as just that.

There is a consensus, I believe, on how to mark emergency calls, represented
by the thread, but chairs have to call consensus, not me.  I think there are
three cases:
1. The endpoint recognizes it's an emergency call, does the LoST routing,
and passes the call to its outbound proxy server.  In this case the Request
URI will be the PSAP URI from LoST, and adds a Route header with the service
URN.  
2. The endpoint recognizes it's an emergency call, but doesn't LoST route
it.  In this case the Request URI would be the service URN.  The outbound
proxy server would do the LoST routing, put the Route header with the
service URN in and change the Request URI to the PSAP URI.
3. The endpoint doesn't even recognize it's an emergency call.  In this
case, the endpoint would put the dialstring in the Request URI.  The
outbound proxy would behave as in 2 above.

When the PSAP gets the call, it will always have its URI in the Request URI,
and there will be a service URN in a Route header.

Probably, phonebcp should say that more clearly.

Brian

> -----Original Message-----
> From: Matt Lepinski [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 12:49 AM
> To: ECRIT; James M. Polk; [email-masked]
> Subject: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> Brian and James:
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 16:35:14 -0500

I think that there is one other variant on two.

The End-point makes the call the service URN and includes a provided
locationURI. Outbound-proxy does nothing special.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 1 June 2007 10:36 PM
> To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> by the thread, but chairs have to call consensus, not me.  I think
there
> are
> When the PSAP gets the call, it will always have its URI in the
Request
> URI,
> > Also, consider deleting 12, I believe it is redundent given 9, 10
and
> 11.
> > Non-parallel sentence structure. Consider re-writing the last
sentence
> as:
> > Change "... media streams on RTP ... " to "... media stream using
RTP
> ..."

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Jun 2007 18:17:49 -0400

If by that you mean the endpoint gets location, recognizes an emergency
call, but does not route, then the proxy server has to route.  That case is
complex because without the LoST query, the endpoint doesn't have the local
dialstring(s).

If that was not what you mean, then who routes?

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 5:35 PM
> To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 17:23:55 -0500

I was assuming that the end-point is given a location URI, local
dialsring, and service URNs. Say in the location hiding case.

> Sent: Saturday, 2 June 2007 8:18 AM
> To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> call, but does not route, then the proxy server has to route.  That
case
> is
> > > The BCP really shouldn't be SIP specific.  We need to broaden it
to,
> > for
> > > and passes the call to its outbound proxy server.  In this case
the
> > > Request
> > > URI will be the PSAP URI from LoST, and adds a Route header with
the
> > > service
> > > URN.
> > > 2. The endpoint recognizes it's an emergency call, but doesn't
LoST
> > route
> > > > A) [Is this document supposed to be SIP-Centric?] It is unclear
to
> > me
> > > > whether the document is intended as a BCP for SIP User Agents
and
> > SIP
> > > > Section 6.4 is written as though SIP signaling were a special
case,
> > and
> > > > yet paragraph four of Section 5 indicates that all emergency
calls
> > on
> > > > document is SIP centric, or whether SIP is a special case, as
long
> > as
> > > > perform the LoST mapping) emergency calls are marked by putting
the
> > URN
> > > > in a Route header (with a "loose" parameter that I'm not
familiar
> > with
> > > > I'm not sure what an "ordinary" (RFC3261-compliant) proxy does
when
> > it
> > > > perhaps the more important question is "Has consensus been
reached
> > that
> > > > Is it clear what the "visited location's emergency number" means
in
> > this
> > > > It is unclear whether the antecedent of "it" in the last
paragraph
> > is
> > > > It seems that the point of this paragraph is to say that a
certain
> > class
> > > > think the point is not that automatic location is common/normal
but
> > that
> > > > Consider changing the phrase "the desired result" to something
like
> > "an
> > > > recommended that the network support a standardized LCP. (This
may
> > not
> > > > MUST support, consider changing "For all other devices" to "In
all
> > other
> > > > header allows for civic locations, I think using geo-location
here
> > is
> > > > Paragraph 5 says that devices MUST mark calls using a
service:sos
> > URN.
> > > > However, paragraph 6 says that mapping from dialstring to URN
SHOULD
> > be
> > > > done by the endpoint. Either both paragraphs should use "MUST"
or
> > else
> > > > I agree with Barbara that the use of IPSec should not be
prohibited
> > by
> > > > The sentence that begins "This can be an enclosing ..." is
unclear
> > to
> > > > me. Are you suggesting that when a PSAP coverage region is
complex,
> > that
> > > > Forward" bullet. (Consider removing the remark or re-wording it
if
> > it is
> > > > Add commas to second sentence "Future PSAPs will, however,
support
> > > > Change "... where it is the access network that knows the
location
> > > > "Note: It is undesirable for a user-interface to enable a user
to
> > place
> > > > Change "If it finds it it MUST:" to "If it finds the dialstring
it
> > > MUST:"
> > > > "In the case of civic location, the LoST server SHOULD report
that
> > the
> > > > same mapping is good within a community name or even a street,
as
> > this
> > > > (Or perhaps "Despite the fact that civic location is uncommon
for
> > mobile
> > > > Change "... URI of the service URN ..." to "... URI of a service
URN
> > > > performed," to the begining of the paragraph (to improve the
flow of
> > the
> > > > "Future IP-enabled PSAPs should accept a wider array of
potential
> > media
> > > > Change "... it specifies use of several ..." to "... it
specifies
> > the
> > > > Change "... signaling would help significantly." to "...
signaling
> > helps
------------------------------------------------------------------------
> --
> > ----------------------
------------------------------------------------------------------------
> --
> > ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Jun 2007 18:28:32 -0400

But that is case 1

> Sent: Friday, June 01, 2007 6:24 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 17:30:16 -0500

Except that the end-point doesn't do the LoST thing

> Sent: Saturday, 2 June 2007 8:29 AM
> > > complex because without the LoST query, the endpoint doesn't have
the
> > > local
> > > > > There is a consensus, I believe, on how to mark emergency
calls,
> > > > > represented
> > > > > 1. The endpoint recognizes it's an emergency call, does the
LoST
> > > > routing,
> > > > > it.  In this case the Request URI would be the service URN.
The
> > > > outbound
> > > > > proxy server would do the LoST routing, put the Route header
with
> > > > > 3. The endpoint doesn't even recognize it's an emergency call.
In
> > > > this
> > > > > case, the endpoint would put the dialstring in the Request
URI.
> > The
> > > > > > proxies, or whether it is more generally a BCP for end
points
> > > > > > signaling component). Personally, I don't care whether or
not
> > > > > > ... can someone provide me with a reference) and that the
URN is
> > > > placed
> > > > > > in the Request-URI when the end-point is unable to perform
the
> > LoST
> > > > > > mapping). Personally, I don't understand the current
mechanism
> > > > because
> > > > > > sees a service URN in the top Route header. However, given
the
> > > > > > (something like) the current mechanism is an appropriate way
to
> > mark
> > > > > > I agree with Barbara that if this is intended to an overview
of
> > call
> > > > > > setup for the special case of an Ethernet connected phone
then
> > the
> > > > > > bullets should match up more clearly with the numbered items
in
> > > > > > it is necessary since most users are unable to provide
accurate
> > > > > location.
> > > > > > I think "cellular" (or "traditional wireless")  is more
precise
> > than
> > > > > > Consider addition a phrase to the last sentence indicating
why
> > > > > > be obvious to the reader). Also, consider changing
"recommended"
> > > > > > Note: This comment also applies to the use of "geo reported"
in
> > > > > > between the time it takes to generate a precise location and
the
> > > > desire
> > > > > > to route the call quickly." (Also, in the following sentence
I
> > think
> > > > > > I don't understand what it means to be "roaming" or
"nomadic" in
> > a
> > > > > > These instructions are for the User Agent,
P-Asserted-Identity
> > > > headers
> > > > > > This item is unclear to me. Is the author's intention that
this
> > item
> > > > > > handles the case where a UA does not know its own location?
If
> > so, I
> > > > > > guess that updating this item should be deferred until
consensus
> > > > > > Also, consider deleting 12, I believe it is redundent given
9,
> > 10
> > > > and
> > > > > 11.
> > > > > >
> > > > > > Section 6.2: (number 1)
> > > > > > Consider adding an example after "... URN appropriate for
the
> > > > emergency
> > > > > > a LoST server SHOULD return a simple polygon that (a)
contains
> > the
> > > > > > location of the device; and (b) is entirely contained within
the
> > > > PSAP
> > > > > > coverage region?
> > > > > >
> > > > > > Section 6.5: (number 3)
> > > > > > This seems to imply that proxies should expect to SUBSCRIBE
to
> > > > Presence.
> > > > > > Do you mean that proxies should expect the PSAP to SUBSCRIBE
to
> > > > > Presence?
> > > > > > I'm afraid I don't understand the parenthetical remark after
the
> > > > "Call
> > > > > > manner, I think that that either paragraph 2 should either
be
> > > > removed or
> > > > > > location signing without providing additionaly guidence to
the
> > > > > > implementor).
> > > > > > Change "... related to the mobility of the device and ..."
to
> > "...
> > > > > > "When a device is aware that it has moved, for instance when
it
> > > > changes
> > > > > > Change "... getting more recent location ..." to "...
getting
> > > > updated
> > > > > > First sentence has too many words modifying the word
"element".
> > > > > Consider:
> > > > > > "... in other countries there are several 3 digit numbers
used
> > > > > > Change "... is expected be supported ..." to "... is
expected to
> > > > > > Also, change "... for the endpoint" to "... of the end
device."
> > > > (note
> > > > > > Consider adding the phrase "Once the mapping to a PSAP URI
has
> > been
> > > > > > Change "The emergency dialstrings ..." to "Emergency
dialstrings
> > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is
the
> > LCP,

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Jun 2007 18:39:44 -0400

So far, the location hiding thing is you get coarse location and you LoST
route with it.  There are people unhappy with that, who want the LCP to
return LoST data, or LoST to do dereference.  My read of rough consensus was
coarse location, but chairs have to call that one.

Brian

> Sent: Friday, June 01, 2007 6:30 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 17:42:16 -0500

I don't think so.
The carriers have largely said that they prefer solution 3, but COULD
work with solution 1. That to me is not consensus on solution 1 but more
consensus on solution 3. I am yet to see anyone suggest how solution 1
could possibly be done with civic locations. Solution 3 will work with
both civic and geo without any problems.

So I think this is where the disagreement comes from.

> Sent: Saturday, 2 June 2007 8:40 AM
> return LoST data, or LoST to do dereference.  My read of rough
consensus
> was
> > > > > > > The BCP really shouldn't be SIP specific.  We need to
broaden
> > it
> > > > to,
> > > > > > for
> > > > > > > example, XMPP.  We can have SIP specific information, but
it
> > > > should be
> > > > > > > by the thread, but chairs have to call consensus, not me.
I
> > > > > > > URI will be the PSAP URI from LoST, and adds a Route
header
> > > > > > > When the PSAP gets the call, it will always have its URI
in
> > > > > > > > document is SIP centric, or whether SIP is a special
case,
> > > > > > > > B) [Is there consensus on how to mark emergency calls?]
The
> > > > current
> > > > > > > > version of phonebcp indicates that (in the normal case
when
> > > > > > end-points
> > > > > > > > I'm not sure what an "ordinary" (RFC3261-compliant)
proxy
> > does
> > > > > > > > Is it clear what the "visited location's emergency
number"
> > means
> > > > > > > > location" or providing a forward reference to the
discussion
> > > > > > > > of devices that communicates over IP networks should
support
> > > > > > emergency
> > > > > > > > calls. However, I find the phrase "using current
(evolving)
> > > > > > standards"
> > > > > > > > to be unclear and in particular I'm not sure what the
phrase
> > > > > > modifies.
> > > > > > > > (E.g. Do you mean "Devices that create media sessions
using
> > > > current
> > > > > > > > Consider replacing "the norm" with "required" (or a
similar
> > > > word). I
> > > > > > > > Given that the paragraph covers what both devices and
access
> > > > > > networks
> > > > > > > > MUST support, consider changing "For all other devices"
to
> > "In
> > > > > > > > The term "geo-location" is not used in RFC 3825 to
describe
> > > > > > > > However, paragraph 6 says that mapping from dialstring
to
> > > > > > > > The last sentence of this paragraph seems to be
redundent.
> > > > Consider
> > > > > > > > I'm not very familiar with Session Timers, can you
provide a
> > > > > > reference.
> > > > > > > > Forward" bullet. (Consider removing the remark or
re-wording
> > it
> > > > if
> > > > > > it is
> > > > > > > > important).
> > > > > > > >
> > > > > > > > Section 7:
> > > > > > > > Given the text in Section 4.4 it seems to me that the
first
> > > > > > paragraph of
> > > > > > > > Given the difficulty of implementing location signing in
a
> > > > useful
> > > > > > > > else it should reference some other document that
explains
> > > > location
> > > > > > > > signing in more detail. (That is, one paragraph does not
do
> > > > > > > > Change "... process engaged from establishing a VPN ...
" to
> > > > > > > > "A device (or a downstream signaling element) identifies
an
> > > > > > emergency
> > > > > > > > call by an "address", which in most cases is a
dialstring,
> > > > although
> > > > > > > > "Note: It is undesirable for a user-interface to enable
a
> > user
> > > > > > > > Change "... some entity needs to ..." to "... some
entity on
> > the
> > > > > > > > signaling path must ..."
> > > > > > > >
> > > > > > > > Section 5: (paragraph 9)
> > > > > > > > Change "... from North America, the home ..." to "...
from
> > North
> > > > > > > > is helpful for WiFi connected devices that roam and
obtain
> > civic
> > > > > > > > Re-write the last sentence as: "The proxy then replaces
the
> > > > > > Request-URI
> > > > > > > > Change "... media streams on RTP ... " to "... media
stream
> > > > using
> > > > > > > > Also, change "... spoofing would be ..." to "...
spoofing is

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Jun 2007 18:47:44 -0400

I'll let the chairs decide, and -phonebcp will follow.

You can choose any civic location in the service area to return as a
"coarse" location.  For example, pick a street that lies within the service
boundary, and return it with no house number.  Of course, in the majority of
cases, the community name will do.

Brian

> Sent: Friday, June 01, 2007 6:42 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 17:49:53 -0500

I think that it would do very well to again re-canvas the group before
we make a decision there.
So that it is very clear what people want.

> Sent: Saturday, 2 June 2007 8:48 AM
> boundary, and return it with no house number.  Of course, in the
majority
> > > So far, the location hiding thing is you get coarse location and
you
> > LoST
> > > route with it.  There are people unhappy with that, who want the
LCP
> > > > > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James
M.
> > Polk'
> > > > > > > If by that you mean the endpoint gets location, recognizes
an
> > > > > > emergency
> > > > > > > call, but does not route, then the proxy server has to
route.
> > > > That
> > > > > > case
> > > > > > > is
> > > > > > > complex because without the LoST query, the endpoint
doesn't
> > have
> > > > > > > > The End-point makes the call the service URN and
includes a
> > > > provided
> > > > > > > > > 1. The endpoint recognizes it's an emergency call,
does
> > the
> > > > LoST
> > > > > > > > routing,
> > > > > > > > > and passes the call to its outbound proxy server.  In
this
> > > > > > > > > 3. The endpoint doesn't even recognize it's an
emergency
> > call.
> > > > > > > > > > A) [Is this document supposed to be SIP-Centric?] It
is
> > > > unclear
> > > > > > to
> > > > > > > > me
> > > > > > > > > > whether the document is intended as a BCP for SIP
User
> > > > Agents
> > > > > > > > > > signaling-path devices which may or may not use SIP.
For
> > > > > > instance,
> > > > > > > > > > Section 6.4 is written as though SIP signaling were
a
> > > > special
> > > > > > > > > > signaling component). Personally, I don't care
whether
> > > > > > > > > > perform the LoST mapping) emergency calls are marked
by
> > > > putting
> > > > > > > > > > ... can someone provide me with a reference) and
that
> > > > > > > > > > perhaps the more important question is "Has
consensus
> > been
> > > > > > reached
> > > > > > > > that
> > > > > > > > > > (something like) the current mechanism is an
appropriate
> > way
> > > > > > > > > > Consider changing to "the local emergency number for
its
> > > > > > > > > > bullets should match up more clearly with the
numbered
> > items
> > > > > > > > > > It seems that the point of this paragraph is to say
that
> > > > > > > > > > recommended that the network support a standardized
LCP.
> > > > (This
> > > > > > > > > > "coordinate-based geolocation"). Also, given that
the
> > > > > > "geolocation"
> > > > > > > > > > Consider re-writing the second-to-the-last sentence
as:
> > > > "Certain
> > > > > > > > > > commonly-used techniques for measuring location
create a
> > > > > > conflict
> > > > > > > > > > between the time it takes to generate a precise
location
> > > > > > > > > > done by the endpoint. Either both paragraphs should
use
> > > > "MUST"
> > > > > > > > > > This item is unclear to me. Is the author's
intention
> > > > > > > > > > Also, consider deleting 12, I believe it is
redundent
> > given
> > > > 9,
> > > > > > 10
> > > > > > > > and
> > > > > > > > > 11.
> > > > > > > > > >
> > > > > > > > > > Section 6.2: (number 1)
> > > > > > > > > > Consider adding an example after "... URN
appropriate
> > > > > > > > > > I'm afraid that I don't understand the meaning of
this
> > > > sentence.
> > > > > > > > > > The sentence that begins "This can be an enclosing
..."
> > is
> > > > > > unclear
> > > > > > > > to
> > > > > > > > > > me. Are you suggesting that when a PSAP coverage
region
> > > > > > > > > > location of the device; and (b) is entirely
contained
> > within
> > > > > > > > > > I'm afraid I don't understand the parenthetical
remark
> > after
> > > > > > > > > > signing justice and it seems irresponsible to
strongly
> > > > recommend
> > > > > > > > > > location signing without providing additionaly
guidence
> > > > > > > > > > Change "... where it is the access network that
knows
> > the
> > > > > > location
> > > > > > > > ..."
> > > > > > > > > > to "... when only the access network knows the
location
> > > > > > > > > > Change "... related to the mobility of the device
and
> > > > > > > > > > "When a device is aware that it has moved, for
instance
> > > > > > > > > > Change "signaling Method" to "signaling method"
(lower
> > > > case).
> > > > > > > > > > Also change "sips MUST be ..." to "a sips URI MUST
be
> > > > > > > > > > Non-parallel sentence structure. Consider re-writing
the
> > > > last
> > > > > > > > sentence
> > > > > > > > > as:
> > > > > > > > > > "In the case of civic location, the LoST server
SHOULD
> > > > report
> > > > > > that
> > > > > > > > the
> > > > > > > > > > same mapping is good within a community name or even
a
> > > > street,
> > > > > > > > > > Change "... URI of the service URN ..." to "... URI
of a
> > > > > > > > > > Consider adding the phrase "Once the mapping to a
PSAP
> > URI
> > > > has
> > > > > > been
> > > > > > > > > > performed," to the begining of the paragraph (to
improve
> > > > > > > > > > Change "For calls send with ..." to "For calls sent
with
> > > > > > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "...
DHCP
> > > > > > > > immediately and delete the original.  Any unauthorized
use

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Jun 2007 17:52:52 -0500

Brian,

I actually think that the only difference is who does the LoST lookup,
so adding the extra function to LoST and allowing more than one
technique for location hiding if probably not a bad idea. Ulitmately I
suspect that only one will end up being deployed, and that will be the
one that is easiest for the location providers to deploy.

Cheers
James

majority
you
LCP
M.
an
route.
doesn't
includes a
does
this
emergency
is
User
For
a
whether
by
that
consensus
appropriate
its
numbered
that
LCP.
the
create a
location
use
intention
redundent
appropriate
this
..."
region
contained
remark
strongly
guidence
knows
location
and
instance
(lower
be
the
SHOULD
a
of a
PSAP
improve
with
DHCP
use