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

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

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

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> Sent: Friday, June 01, 2007 6:42 PM
> To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> 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.
> 
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:br at brianrosen.net]
> > Sent: Saturday, 2 June 2007 8:40 AM
> > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > > Sent: Friday, June 01, 2007 6:30 PM
> > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> > >
> > > Except that the end-point doesn't do the LoST thing
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > > Sent: Saturday, 2 June 2007 8:29 AM
> > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> > > >
> > > > 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]
> > > >
> > >
> > >
> ------------------------------------------------------------------------
> > --
> > > ----------------------
> > > 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