[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01

To: "Brian Rosen" <br at brianrosen.net>, "Matt Lepinski" <mlepinski at bbn.com>, "ECRIT" <ecrit at ietf.org>, "James M. Polk" <jmpolk at cisco.com>
Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
From: "Winterbottom, James" <James.Winterbottom at andrew.com>
Date: Fri, 1 Jun 2007 17:49:53 -0500
Cc:
In-reply-to: <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com>
List-help: <mailto:ecrit-request@ietf.org?subject=help>
List-id: ecrit.ietf.org
List-post: <mailto:ecrit@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <E51D5B15BFDEFD448F90BDD17D41CFF102F3388C@AHQEX1.andrew.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <E51D5B15BFDEFD448F90BDD17D41CFF102F338B5@AHQEX1.andrew.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> <E51D5B15BFDEFD448F90BDD17D41CFF102F6F8A2@AHQEX1.andrew.com> <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> <E51D5B15BFDEFD448F90BDD17D41CFF102F6F8A6@AHQEX1.andrew.com> <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com>
Thread-index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQAAAVaoAAADC5YAAAHo0g
Thread-topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
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.

> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Saturday, 2 June 2007 8:48 AM
> To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> 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]
> 

------------------------------------------------------------------------------------------------
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
References:
- [Ecrit] Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Matt Lepinski
- [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Brian Rosen
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Winterbottom, James
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Brian Rosen
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Winterbottom, James
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Brian Rosen
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Winterbottom, James
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Brian Rosen
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Winterbottom, James
- RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
  - From: Brian Rosen
Prev by Date: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
Next by Date: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
Previous by thread: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
Next by thread: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
Index(es):
- Date
- Thread