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

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

But that is case 1

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> Sent: Friday, June 01, 2007 6:24 PM
> To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> I was assuming that the end-point is given a location URI, local
> dialsring, and service URNs. Say in the location hiding case.
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:br at brianrosen.net]
> > Sent: Saturday, 2 June 2007 8:18 AM
> > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > > 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
> > >
> > > 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.
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > > 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
> > > >
> > > > 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:mlepinski at bbn.com]
> > > > > Sent: Friday, June 01, 2007 12:49 AM
> > > > > To: ECRIT; James M. Polk; br at brianrosen.net
> > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01
> > > > >
> > > > > 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
> > > > Ecrit at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >
> ------------------------------------------------------------------------
> > --
> > > ----------------------
> > > 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]
> >
> 
> --------------------------------------------------------------------------
> ----------------------
> 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]


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