Subject: Re: [Ecrit] PhoneBCP

From: "Elwell, John" <[email-masked]>
Date: Fri, 01 May 2009 08:25:25 +0100

I can't recall any. We sometimes state the opposite, i.e., some RFCs
(e.g., those specifying P-headers) state that they are not suitable for
the Internet, only for use in closed environments. For the majority of
SIP specs there is no such applicability statement.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Marc Linsner
> Sent: 30 April 2009 20:52
> To: Ted Hardie; [email-masked]
> Subject: Re: [Ecrit] PhoneBCP
> 
> Ted,
> 
> I searched a small amount for comparison type language in 
> other IETF drafts.
> I'm struggling with the notion that anyone who would read 
> IETF drafts would
> get confused as to their solution/applicability space.
> 
> Since my search was small and cycles are short, are you aware 
> if there is
> any such language in any of the ream of SIP drafts that point out the
> solution space and explicitly exclude IMS?
> 
> -Marc-
> 
> 
> On 4/30/09 1:40 PM, "Ted Hardie" <[email-masked]> wrote:
> 
> > At 9:48 AM -0700 4/30/09, Dawson, Martin wrote:
> >> Understanding ECRIT means understanding that broadband 
> Internet access is
> >> broadband Internet access is broadband Internet access.
> > 
> > To put it mildy, this is far from true.  There is a whole 
> class of offerings
> > that
> > is voice-as-a-service (the IMS/NGN group) which absolutely 
> do not act like
> > voice-as-an-application.    The solution we've defined is for
> > voice-as-an-application,
> > which has the natural result that the end user device has 
> the primary role.
> > 
> > The root of the problem we're facing is that there is a 
> difference between
> > using IP and using the Internet model.  IMS uses IP, but 
> uses a different
> > model entirely (Whatever you think of that model, I don't 
> think anyone
> > who looked at how it works could argue that it is the same 
> as the Internet
> > model.)
> > 
> > The documents we're dealing with contrast the offering with 
> PSTN, but
> > don't really see any differentiation among "packet-switched 
> networks".
> > Take this early text from the Framework document:
> > 
> >> It is beyond the scope of this document to enumerate and 
> discuss all
> >>   the differences between traditional (Public Switched Telephone
> >>   Network) and IP-based telephony, but calling on the Internet is
> >>   characterized by:
> >>   o  the interleaving over the same infrastructure of a 
> wider variety
> >>      of services;
> >>   o  the separation of the access provider from the application
> >>      provider;
> >>   o  media other than voice (e.g. video and text in several forms);
> >>   o  the potential mobility of all end systems, including endpoints
> >>      nominally thought of as fixed systems and not just those using
> >>      radio access technology.  For example, consider a wired phone
> >>      connected to a router using a mobile data network 
> such as EV-DO as
> >>      an uplink.
> >> 
> >>   This document focuses on how devices using the Internet can place
> >>   emergency calls and how PSAPs can handle Internet multimedia
> >>   emergency calls natively, rather than describing how 
> circuit-switched
> >>   PSAPs can handle VoIP calls.  In many cases, PSAPs making the
> >>   transition from circuit-switched interfaces to packet-switched
> >>   interfaces may be able to use some of the mechanisms 
> described here,
> >>   in combination with gateways that translate packet-switched calls
> >>   into legacy interfaces, e.g., to continue to be able to 
> use existing
> >>   call taker equipment.  There are many legacy telephone 
> networks that
> >>   will persist long after most systems have been upgraded to IP
> >>   origination and termination of emergency calls.  Many of 
> these legacy
> >>   systems route calls based on telephone numbers.  Gateways and
> >>   conversions between existing systems and newer systems defined by
> >>   this document will be required.  Since existing systems 
> are governed
> >>   primarily by local government regulations and national 
> standards, the
> >>   gateway and conversion details will be governed by 
> national standards
> >>   and thus are out of scope for this document.
> > 
> > The real contrast being made is between circuit-switched 
> and Internet
> > model, but the terms used mix "packet-switched", 
> "IP-based", and "Internet";
> > there is even an explicit mention of EV-DO, but in a mode 
> that treats
> > it as a pure IP bearer (which is not what is being sold in 
> most markets
> > today).  The reality on the ground today is that there are at least
> > circuit-switched,
> > Internet model IP, and IP with operator services out there 
> in the real
> > world.  This document set doesn't acknowledge that, and it 
> treats all
> > packet-switched services/IP-based services as if they were 
> Internet model.
> > That's simply not true.
> > 
> > The argument that Steven and others have made is that the 
> document set
> > needs to have an explicit acknowledgement of the other 
> model, so that
> > there is a realization by those reading them that just 
> because they have
> > IP, doesn't mean they are dealing with the Internet model.  
>  You could
> > argue that everyone knows that, but the document itself muddies it
> > far enough that it is far from evident.
> > 
> > Do I, personally believe the Internet model version is 
> better?  Yep.  Do
> > I, personally believe that it will eventually subsume other 
> versions?  Maybe,
> > and I think it would be nice.  But I also recognize that it 
> is not the case
> > now,
> > and we're trying to define a system that  will actually 
> work to deliver
> > emergency
> > calls in the real world.  Explicit acknowledgement seems to 
> me valuable
> > in that case.  The other option is to re-write the 
> documents to clarify that
> > not any packet-switched network nor any network using IP 
> fits this set
> > of assumptions; that seems to me likely to take longer and 
> not add much.
> > 
> > You've already had Keith note that he would object to the 
> documents if
> > they did not contain language like that which was in -09.  
> If it is taken out,
> > I believe the documents will need a major editing pass to 
> accomplish the
> > clarification without the explicit text.  This text is a 
> compromise already,
> > and the issue it deals with is important.  Unless we are 
> going to pretend
> > that the IMS model simply doesn't exist and won't be used 
> to deliver a
> > substantial fraction of emergency calls for a good long 
> time to come,
> > we need it.  If we are going to pretend that, I think we 
> are being very
> > foolish
> > indeed.
> > 
> > Ted
> > 
> > 
> > 
> >> Having to change the way the device initiates an emergency 
> call when
> >> something as prosaic as the access technology changes is 
> akin to having to
> >> change your web browser just because the access technology 
> has changed. It's
> >> neither helpful nor harmless to have such a restriction.
> >> 
> >> A helpful statement to put in the BCP might be "Other 
> architectures, such as
> >> IMS Emergency calling defined by 3GPP and 3GPP2, which are 
> not based on the
> >> ECRIT framework are likely to not be compatible with 
> devices and emergency
> >> networks which assume this framework - e.g. such as is 
> defined by NENA as
> >> i3."
> >> 
> >> I don't endorse the inclusion of such a statement; it's 
> commentary - as is
> >> the proposed "applicability statement" and commentary is 
> unnecessary.
> >> Nevertheless, I think it's a more accurate 
> characterization. That is, it's
> >> more the case that the 3GPP IMS emergency architecture 
> doesn't fit ECRIT than
> >> it is that ECRIT doesn't fit a 3GPP access network.
> >> 
> >> Cheers,
> >> Martin
> >> 
> >> 
> >> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> >> Edge, Stephen
> >> Sent: Friday, 1 May 2009 2:29 AM
> >> To: Bernard Aboba; Thomson, Martin; [email-masked]
> >> Subject: Re: [Ecrit] PhoneBCP
> >> 
> >> Bernard and others
> >> 
> >> This is an interesting view - an admission that the Ecrit 
> solution will
> >> probably not be universally applied and when it is may be 
> subject to
> >> modification. On the 3GPP/3GPP2 sides, solutions are 
> defined with a specific
> >> and explicit scope and are expected to be - and nearly 
> always actually are -
> >> supported exactly as defined in the appropriate spec.s for 
> all scenarios
> >> covered by the scope. A solution whose deployment is 
> unpredictable will be
> >> less useful because of the implied interworking problems 
> between incompatible
> >> implementations. That is a main reason why I and others 
> initially tried to
> >> include a more precise applicability/scope statement than 
> the one we are now
> >> discussing. Specifically, the Ecrit solution will probably 
> not be deployed by
> >> 3GPP/3GPP2 operators for cellular terminals because they 
> have defined a
> >> somewhat different solution more suitable for cellular 
> operation. That means
> >> that a terminal supporting only the Ecrit solution (based 
> on an assertion of
> >> universal ap
> >  plicability) will encounter problems when its user 
> attempts an emergency call
> > on a 3GPP/3GPP2 network. If I can extend your analogies, 
> this would be like
> > not including a precise menu description for a meal 
> containing meat and/or
> > fish in a restaurant catering to both vegetarians and 
> non-vegetarians.
> >> 
> >> Kind Regards
> >> 
> >> Stephen
> >> 
> >> From: Bernard Aboba [mailto:[email-masked]]
> >> Sent: Thursday, April 30, 2009 1:13 AM
> >> To: Edge, Stephen; [email-masked]; [email-masked]
> >> Subject: RE: [Ecrit] PhoneBCP
> >> 
> >>> Your interpretation of applicability is certainly extreme 
> (yes or qualified
> >>> yes to all questions) - removing any dependence on suitability or
> >>> feasibility (which are the more normal benchmarks) and 
> simply making a
> >>> legalistic blanket assertion. (I can now more understand 
> incidentally why
> >>> the fictitious protocol police are so often invoked on matters of
> >>> conformance.)
> >>> 
> >>> But do others have any views on this?
> >> 
> >> Here is my 2 pence.   As noted in the Introduction, the 
> Phone BCP document
> >> and framework documents are closely related documents that 
> need to be read
> >> (and understood) together.  In looking at Phone BCP, there 
> have been many
> >> situations in which  I wondered what the justification was 
> for a requirement,
> >> only to find the (usually persuasive) explanation in the 
> corresponding
> >> section of the framework document.
> >> 
> >> IMHO, the separation of the two documents is somewhat 
> unnatural. It's a bit
> >> like taking a meal, freeze drying it, and then presenting 
> the diner with a
> >> cup of powder and a cup of water and wondering why they 
> are left with a
> >> quizical look on their faces.  Including cooking 
> instructions along with the
> >> two cups is not a fully satisfactory answer.
> >> 
> >> Given this reality, if there is a need for text explaining 
> the fundamental
> >> assumptions of the architecture, the place for that text 
> is not in the BCP
> >> document, but in the framework document.  As has been 
> noted by others, the
> >> entire BCP document is an applicability statement, and 
> when viewed in that
> >> way, the proposed text is not only unnecessary, but 
> somewhat confusing since
> >> required context for the BCP document belongs in the 
> framework document.  If
> >> anything more is necesary, it would probably be some 
> additional instructions
> >> for the reader  delving into the document set for the first time.
> >> 
> >> Like any IETF effort, the framework and BCP documents will 
> be evaluated on
> >> their own merits. Athough this is an area with a 
> considerable regulatory
> >> component, I see little evidence that the world at large 
> is so in awe of the
> >> IETF that every word will be taken as immutable truth.  No 
> doubt other SDOs
> >> will take issue with these documents in whole or in part 
> and will explain the
> >> basis of their assessments and where necessary, their 
> alternatives. As a
> >> result, some portions of the architecture may be adopted, 
> some portions may
> >> be ignored, and others will be revised in an effort to 
> address the issues
> >> encountered and improve their chances for deployment.
> >> 
> >> With respect to this process, the addition of cautionary 
> text is a bit like
> >> the warning labels that we find on consumer products.  
> While it may be
> >> necessary in some legalistic sense, given the expertise of 
> the individuals
> >> assessing these documents, one wonders what the practical 
> effect will be.
> >> Typically these are individuals who already understand 
> that it is a good idea
> >> to double-cup hot coffee.
> >> 
> >> 
> >> 
> >> 
> --------------------------------------------------------------
> ---------------
> >> -------------------
> >> 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]
> >> 
> >> Content-Type: text/plain; name="ATT00001.txt"
> >> Content-Description: ATT00001.txt
> >> Content-Disposition: attachment; filename="ATT00001.txt"; size=194;
> >> creation-date="Thu, 30 Apr 2009 09:49:15 GMT";
> >> modification-date="Thu, 30 Apr 2009 09:49:15 GMT"
> >> 
> >> Attachment converted: Macintosh HD:ATT00001 5257.txt 
> (TEXT/ttxt) (0040366B)
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 1 May 2009 14:48:00 +0200

That question has not been put to the list yet, but it has to be before it goes to publication request. 

I believe the statement helps the reading community understand the context in which the document is used, versus other solutions. It is therefore helpful to our end customers.

I agree the wording could probably be better, but it was drafted in a spirit of trying to find some middle ground. You don't seem to be prepared to enter the middle ground.

Well two of us can adopt intransient positions. In my view you haven't justified yours. I therefore don't need to justify mine further.

Keith 

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Friday, May 01, 2009 2:10 AM
> To: DRAGE, Keith (Keith); Brian Rosen; Richard Barnes; Ted Hardie
> Cc: ECRIT
> Hi Keith,
> So you are saying that you will object to the document 
> leaving the WG unless the statement is included, on the 
> grounds that there have been discussions about what the 
> statement should say?  This is despite the fact that no 
> consensus was ever reached to include the statement in the 
> first place.
> 
> I believe that other than this debate these documents are 
> good to go, and that once this hum is completed the consensus 
> will be reached and the documents can leave the WG.
> 
> Cheers
> James
> 
> 
> 
> 
> 
> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, 27 April 2009 6:08 PM
> To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie
> Cc: ECRIT
> I hum for the applicability statement.
> 
> I would also note that if we go the way you want to go, we 
> have a hum for whether the document is acceptable without 
> this. Having had the discussion to agree an applicability 
> statement, I warn that I will hum against a document without it.
> 
> You need some form of consensus to get the document out of the WG.
> 
> regards
> 
> Keith 
> 
> [mailto:[email-masked]] On Behalf 
> > Of Winterbottom, James
> > Sent: Saturday, April 25, 2009 10:58 PM
> > To: Brian Rosen; Richard Barnes; Ted Hardie
> > Cc: ECRIT
> > My point is that because there was no consensus at the 
> IETF, in fact 
> > the document should have remained unchanged.
> > 
> > I want a hum first as to whether the applicability statement is 
> > required at all. As I have stated more then one I don't 
> believe it is, 
> > and no reasonable argument has yet been provided to changed my mind.
> > 
> > So let us first establish with a clear consensus that the 
> > applicability statement is required.
> > 
> > I HUM against the inclusion of an applicability statement.
> > 
> > 
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Sat 4/25/2009 1:04 PM
> > To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie'
> > Cc: 'ECRIT'
> > Actually, I think the list hum is whether or not you accept the 
> > change, as proposed, and consider the document ready to send to the 
> > IESG.  It's kind of a combination of is an applicability statement 
> > acceptable, and is this particular one acceptable (and are you 
> > otherwise okay with the document, which is implied in 
> Marc's message, 
> > but I think important to recognize).
> > 
> > Brian
> > 
> > 
> [mailto:[email-masked]] On Behalf 
> > Of Winterbottom, James
> > Sent: Saturday, April 25, 2009 4:51 AM
> > To: Richard Barnes; Ted Hardie
> > Cc: ECRIT
> > So is this turning into a list "hum" as to whether we 
> should have an 
> > applicability statement or not?
> > 
> > ISTM that this would be an appropriate course of action 
> given the lack 
> > on consensus at the actually meeting.
> > 
> > 
> > Cheers
> > James
> > 
> > 
> > From: [email-masked] on behalf of Richard Barnes
> > Sent: Fri 4/24/2009 9:32 PM
> > To: Ted Hardie
> > Cc: ECRIT
> > +1
> > Ted Hardie wrote:
> > > At 11:23 AM -0700 4/24/09, Marc Linsner wrote:
> > >>
> > <http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp
> > -09.txt>http:/
> > /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt
> > >>
> > >> At the San Francisco meeting and ensuing list threads, the
> > last issue
> > around PhoneBCP was whether or not to include an 'applicability 
> > statement'.
> > The hum during the meeting was inconclusive.  The draft editor has 
> > included text in this latest version in an attempt to compromise on 
> > this issue.
> > >>
> > >> Please review this version and respond by Friday May 1 to
> > the list as
> > >> to
> > your acceptance of this change.
> > >>
> > >> Thanks,
> > >>
> > >> Marc, Hannes, & Roger
> > > 
> > > I support the current draft going forward to publication 
> requested.
> > > 
> > > 				regards,
> > > 					Ted
> > > 
> > > 
> > > 
> > >> 	creation-date="Fri, 24 Apr 2009 11:24:11 GMT";
> > >> 	modification-date="Fri, 24 Apr 2009 11:24:11 GMT"
> > >>
> > >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt)
> > (003FF52C)
> > > 
> > --------------
> > --------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > --------------
> > --------------------
> > ----------------------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > ----------------------------------
> > [mf2]
> > 
> ----------------------------------
> ----------------------------------
> [mf2]
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 May 2009 06:50:04 -0600

On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote:

> I assume you’re referring to the following paragraph in the  
> introduction:
> “   This document focuses on the case in which all three steps in the
>    emergency calling process -- location configuration, call routing,
>    and call placement - can be and are performed by the calling
>    endpoint, with the endpoint's Access Service Provider supporting  
> the
>    process by providing location information.  Calls in this case  
> may be
>    routed via an application-layer Communications Service Provider
>    (e.g., a Voice Service Provider), but need not be.  The underlying
>    protocols can also be used to support other models in which parts  
> of
>    the process are delegated to the Communications Service Provider.
>    This document does not address in detail either these models or
>    interoperability issues between them and the model described here.”
>
>

I've read this text several times and I'm trying to decide if anyone  
outside this WG could ever decide what it means. Can someone clearly  
explain all the implications of this paragraph? Particularly the last  
two sentences.

Thanks, Cullen in my AD role

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 May 2009 09:07:53 -0400

The underlying protocols can support models where the location of the
endpoint can be determined by the calling network and/or the calling network
can do the routing (LoST lookup or some nation specific routing), and even
the marking of the call.  --framework and phonebcp don't really discuss that
model.  An example of that is IMS, which has an element called an E-CSCF
that is capable of querying a mobile network's location infrastructure to
determine the location of the caller, and can perform any routing tasks
appropriate to the location of the caller.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Friday, May 01, 2009 8:50 AM
To: Stark, Barbara
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote:

> I assume you're referring to the following paragraph in the  
> introduction:
> "   This document focuses on the case in which all three steps in the
>    interoperability issues between them and the model described here."
>
>

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 1 May 2009 10:38:42 -0700

And I'd say, that for a while yet, these other types of call routing
architectures are going to be in vogue, because of the following
constraints:

-- a mobile context - a device w/o a location at the time that an
emergency request is made, does shouldn't hold up the call.
-- a rough vs. precise location routing decision at the edge is assumed
(yet this isn't too worked out for edge devices).
-- location determination takes time based on today's available
real-time location technology.

Therefore, the (mobile) edge device either:

	1. waits for a location to be determined before edge routing,
	2. acquires a placeholder (in the form of a location URI), and
routes based on pre-provisioned rules to a core element which either
"has" or "gets" a LO, or
	3. (in classic 3GPP style) the endpoint call routing occurs
immediately based on pre-provisioned routing rules, lands at a core
element which can do immediate (rough) or eventual (precise) routing to
parts beyond.

I am ok with the applicability statement being left in.

-roger marshall.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Friday, May 01, 2009 6:08 AM
> To: 'Cullen Jennings'; 'Stark, Barbara'
> Cc: 'ECRIT'
> the marking of the call.  --framework and phonebcp don't really
discuss
> Thanks, Cullen in my AD role

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 2 May 2009 22:21:08 -0400

Without prejudice to the hum, I believe these are covered by the phonebcp
architecture:
1. The phone will get a location URI from its LIS 
2. If a routing location is requested by dereferencing the location URI, it
will get an immediate response which equates to cell/sector location
3. When dispatch location is requested, the actual (precise) location will
be returned

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Friday, May 01, 2009 1:39 PM
To: Brian Rosen; Cullen Jennings; Stark, Barbara
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

-roger marshall.

discuss
> Of

CONFIDENTIALITY NOTICE: The information contained in this message may be
privileged and/or confidential. If you are not the intended recipient, or
responsible for delivering this message to the intended recipient, any
review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please notify the sender immediately, and
delete it and all attachments from your computer and network.

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 4 May 2009 09:23:59 -0700

Only the first of three scenarios are covered by Phonebcp/Framework.
The second and third,

> element which can do immediate (rough) or eventual (precise) routing
to

...are not covered.  These rely on other key material (dial string
analysis) and pre-set rules to get the call moving into the core.  At
the edge, there is no location based routing at all.  3GPP would have to
change their call architecture to include a location URI, and then do
edge routing, in order to truly be Phonebcp/Framework compliant.

-roger.

> Sent: Saturday, May 02, 2009 7:21 PM
> To: Roger Marshall; 'Cullen Jennings'; 'Stark, Barbara'
> Cc: 'ECRIT'
> > can do the routing (LoST lookup or some nation specific routing),
and
> > even
> > that is capable of querying a mobile network's location
> infrastructure
> > to

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 12:45:57 -0400

> real-time location technology.

-framework and -phonebcp are designed to deal with those constraints, which
is what I pointed out.

There ARE other ways to do it, which have various problems; the usual one we
trot out is the raw packet problem.  -framework and -phonebcp only describe
the endpoint LCP/route model.  It IS a solution to the constraints.  It's an
excellent solution.  It's not the only one.

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 12:24 PM
To: Brian Rosen; Cullen Jennings; Stark, Barbara
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

-roger.

and

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 4 May 2009 16:42:44 -0400

Is this hum over yet? Marc, you said Friday, May 1. Have the results
been tabulated? Will we be having another hum, then, as to whether
phonebcp is good to go? Inquiring minds want to know.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 4 May 2009 15:31:26 -0500

Actually I think the words mask the reality. If there's a routing
decision to be made, then location adequate for routing has to be
determined. And it doesn't matter if the location is represented as a
cell-identity (a dangerous assumption where reliable routing in a US

> emergency request is made, does shouldn't hold up the call.

An initial location has to be determined. The device gets it or the
network gets it. There's no definitive basis for assuming one approach
is superior to another. As Brian says, PhoneBCP says it's coarse request
(sub-second latency in any type of public access technology is a
reasonable expectation) plus Location-URI for later dispatch-accuracte
location determination.

> -- a rough vs. precise location routing decision at the edge is

You can't "assume" a location. It still has to be based on some sort of
logic. Even if you deployed E-CSCF at a PSAP routing granularity (I'm
sure that'd be popular), then the E-CSCF discovery step becomes your
routing question and you're back where you started. A "pre-provisioned
routing rule" still needs some sort of location determination. For that
matter, LoST routing rules are also "pre-provisioned".

> (yet this isn't too worked out for edge devices).

Isn't worked out by who? I don't think any standards forum, no matter
how much they narrow the scope of their solution, can provide a magic
design for this in a wide area wireless context. Nearest we've come to
"zero wait" routing is POTS via direct LEC trunks to the selective
router... and, even then, there's an SR DB dip against the logical
location represented by the ANI before routing was complete.

> real-time location technology.

Everything takes time.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roger Marshall
Sent: Tuesday, 5 May 2009 2:24 AM
To: Brian Rosen; Cullen Jennings; Stark, Barbara
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

-roger.

and

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: Randall Gellens <[email-masked]>
Date: Mon, 4 May 2009 14:36:50 -0700

At 10:40 AM -0700 4/30/09, Ted Hardie wrote:

>  The root of the problem we're facing is that there is a difference between
>  using IP and using the Internet model.  IMS uses IP, but uses a different
>  model entirely (Whatever you think of that model, I don't think anyone
>  who looked at how it works could argue that it is the same as the Internet
>  model.)

>  The argument that Steven and others have made is that the document set
>  needs to have an explicit acknowledgement of the other model, so that
>  there is a realization by those reading them that just because they have
>  IP, doesn't mean they are dealing with the Internet model.   You could

These are helpful insights into what we're really arguing about here.

The statement added in -09 is a compromise; even the most fervent 
argument against it comes down to "it isn't needed".  Given the 
choice between a compromise statement that clearly does no harm, and, 
depending on one's viewpoint is either vitally needed or redundant, 
it seem clear that we should progress the document with the text in 
it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A bird in the hand is safer than one overhead.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 May 2009 17:00:52 -0500

I had hoped to stay quiet in this thread, and this is NOT a late hum, either 
for or against, but

> The statement added in -09 is a compromise; even the most fervent argument 
> against it comes down to "it isn't needed".  Given the choice between a 
> compromise statement that clearly does no harm, and, depending on one's 
> viewpoint is either vitally needed or redundant, it seem clear that we 
> should progress the document with the text in it.

I'm having a difficult time thinking of "clearly does no harm" as sufficient 
justification for including text in a document that's still tagged as a 
BCP...

:-(

Thanks,

Spencer

---

From: Randall Gellens <[email-masked]>
Date: Mon, 4 May 2009 15:26:28 -0700

At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote:

>> choice between a compromise statement that clearly does no harm, 
>> and, depending on one's viewpoint is either vitally needed or 
>> redundant, it seem clear that we should progress the document with 
>> the text in it.
>
>  I'm having a difficult time thinking of "clearly does no harm" as 
> sufficient justification for including text in a document that's 
> still tagged as a BCP...

I never said "clearly does no harm" is *sufficient* justification for 
adding it, rather, it's justification for not removing it given the 
arguments for it.  There are a number of people who have made 
well-reasoned and detailed cases for why this text is needed; since 
it is already a compromise that does no harm, the choice to leave it 
in seems clear.

-------------- Randomly selected tag: ---------------
Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures.    --'Ceaser Smith' in _Hot_Millions_

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 May 2009 19:16:44 -0500

Under the same reasoning Randy, since there was never consensus in the
WG to add it, it should never have been added, and since no real
justification for its inclusion has been provided, we should revert back
to the previous version of the document and proceed to last call the
document.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randall Gellens
Sent: Tuesday, 5 May 2009 8:26 AM
To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen;
BernardAboba; Thomson, Martin; [email-masked]; RandallGellens
Subject: Re: [Ecrit] PhoneBCP

---

From: Randall Gellens <[email-masked]>
Date: Mon, 4 May 2009 17:29:19 -0700

At 7:16 PM -0500 5/4/09, James Winterbottom wrote:

>  WG to add it,

There may not have been a formal consensus call, but there was 
significant discussion on the list, and my impression was that we had 
general agreement to add it.

>   it should never have been added, and since no real
>  justification for its inclusion has been provided,

There has been much justification with detailed reasoning for adding it.

>   we should revert back

It was added as a compromise based on the discussion in SFO and on 
the list subsequently.  It's a compromise, like much of the text we 
publish.

-------------- Randomly selected tag: ---------------
I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body.
              --Benjamin Franklin

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 May 2009 19:33:08 -0500

There was no consensus to add the text, whether the wording is a
compromise is irrelevant at this stage. It was added without consensus
and needs to be removed.

Cheers
James

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Tuesday, 5 May 2009 10:29 AM
To: Winterbottom, James; Spencer Dawkins; Ted Hardie; Dawson, Martin;
Edge,Stephen; BernardAboba; Thomson, Martin; [email-masked]
Subject: Re: [Ecrit] PhoneBCP

>  it is already a compromise that does no harm, the choice to leave it
------------------------------------------------------------------------
------------------------
>  this email is prohibited.
------------------------------------------------------------------------
------------------------

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 4 May 2009 20:18:37 -0700

Perhaps "mostly harmless" then?

Note that we are having this discussion now as a result of a previous discussion concerning the suitability of the Ecrit solution for any type of public IP access. Those contending that the solution is suitable are (by and large) the ones now objecting to including the statement although they were not objecting just over 5 weeks ago when the statement was introduced as a means of settling the first discussion. Those contending that the solution is not universally suitable are (as far as I am aware) prepared to drop that issue (at least as regards having the solution go through last call) if the statement is included.

If the statement is in the end removed, we may find ourselves back again to the first discussion. If that happens, I will consider the solution fair game for some more specific and detailed criticism than has so far been provided - since after all, any solution that claims universal applicability is setting itself up as rather large and inviting target.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 5:33 PM
To: Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson, Martin; Edge, Stephen; BernardAboba; Thomson, Martin; [email-masked]
Subject: RE: [Ecrit] PhoneBCP

Cheers
James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 6 May 2009 12:32:09 +0300

Hi Stephen, 

I believe what James is saying is that there was never a HUM to include
an applicability statement into the document. He is correct about this
aspect.  

Instead, there were some folks in the group who thought they should
discuss how a potential text could look like and Brian included it into
the document.

This has upset a few folks. 

When it comes to important things like these the working group always
has to make a conscious decision
* whether they want to include an applicability statement at all, and 
* if so, what it should say. 

What we should also keep in mind is that our document might bounce back
from the IESG with the indication that we should resolve the technical
issues that prevent applicability of the work in a certain environment. 

In this weeks 3GPP IETF conference call Cullen has asked Hannu to
solicit feedback from the 3GPP about the technical issues that prevent
the work being used in the cellular environment. He very well
understands that the 3GPP is working on IMS and has crafted many things
on their own. 

Ciao
Hannes

>On Behalf Of ext Edge, Stephen
>Sent: 05 May, 2009 06:19
>To: Winterbottom, James; Gellens, Randall; Spencer Dawkins; 
>Hardie,Ted; Dawson, Martin; BernardAboba; Thomson, Martin; 
>[email-masked]
>Note that we are having this discussion now as a result of a 
>previous discussion concerning the suitability of the Ecrit 
>solution for any type of public IP access. Those contending 
>that the solution is suitable are (by and large) the ones now 
>objecting to including the statement although they were not 
>objecting just over 5 weeks ago when the statement was 
>introduced as a means of settling the first discussion. Those 
>contending that the solution is not universally suitable are 
>(as far as I am aware) prepared to drop that issue (at least 
>as regards having the solution go through last call) if the 
>statement is included.
>
>If the statement is in the end removed, we may find ourselves 
>back again to the first discussion. If that happens, I will 
>consider the solution fair game for some more specific and 
>detailed criticism than has so far been provided - since after 
>all, any solution that claims universal applicability is 
>setting itself up as rather large and inviting target.
>
>Kind Regards
>
>Stephen
>To: Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson, 
>Martin; Edge, Stephen; BernardAboba; Thomson, Martin; [email-masked]
>There was no consensus to add the text, whether the wording is 
>a compromise is irrelevant at this stage. It was added without 
>consensus and needs to be removed.
>
>Cheers
>James
>
>
>To: Winterbottom, James; Spencer Dawkins; Ted Hardie; Dawson, 
>Martin; Edge,Stephen; BernardAboba; Thomson, Martin; [email-masked]
>significant discussion on the list, and my impression was that 
>we had general agreement to add it.
>
>>   it should never have been added, and since no real  justification 
>> for its inclusion has been provided,
>
>It was added as a compromise based on the discussion in SFO 
>and on the list subsequently.  It's a compromise, like much of 
>the text we publish.
>
>
>>  -------------- Randomly selected tag: ---------------  Procedures!  
>> Of course, that's what you'd use with a *sophisticated*
>> immediately and delete the original.  Any unauthorized use of  this 
>> email is prohibited.
>> 
>>
>-------------- Randomly selected tag: --------------- I have 
>made it a rule, whenever in my power, to avoid becoming the

---

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 6 May 2009 17:27:41 -0700

Hi Hannes

Thanks for the FYI. Hannu has now invited 3GPP comments from SA2 so we will see what will happen. I have effectively told Hannu (you and Cullen were CC'd) that since SA2 are meeting next week (in Estonia), that a couple of weeks could be needed.

Kind Regards

Stephen
-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 2:32 AM
To: Edge, Stephen; Winterbottom, James; Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson, Martin; BernardAboba; Thomson, Martin; [email-masked]
Subject: RE: [Ecrit] PhoneBCP

Hi Stephen, 

Ciao
Hannes

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 May 2009 15:52:20 +0200

In general, I have trouble thinking of any SIP RFC that cannot be applied, or attempted to be applied somehow in the IMS environment. Not all operators may deploy all capabilities, but that applies to all of SIP. Even something like RFC 4474 can be applied across the top of IMS if one so wished, asssuming someone had not stuck an SBC in the way.

Those considerations do not apply for Phone BCP, where if attached in an IMS environment, in order to make an emergency call, the sequence followed is somewhat different, and the IETF procedures just will not work.

regards

Keith

> On Behalf Of Ted Hardie
> Sent: Thursday, April 30, 2009 8:55 PM
> To: Marc Linsner; [email-masked]
> At 12:52 PM -0700 4/30/09, Marc Linsner wrote:
> >Ted,
> >
> IETF drafts
> >would get confused as to their solution/applicability space.
> >
> >Since my search was small and cycles are short, are you
> aware if there
> >is any such language in any of the ream of SIP drafts that point out
> >the solution space and explicitly exclude IMS?
> >
> >-Marc-
>
> Besides the long-running argument over SBCs?  I am not sure;
> possibly Keith would be able to point to comparison text.
>
>                                       Ted
>
>
>
> >
> >>> Understanding ECRIT means understanding that broadband Internet
> >>> access is broadband Internet access is broadband Internet access.
> >>
> >> To put it mildy, this is far from true.  There is a whole class of
> >> offerings that is voice-as-a-service (the IMS/NGN group) which
> >> absolutely do not act like
> >> The root of the problem we're facing is that there is a difference
> >> between using IP and using the Internet model.  IMS uses
> IP, but uses
> >> a different model entirely (Whatever you think of that
> model, I don't
> >> think anyone who looked at how it works could argue that it is the
> >> same as the Internet
> >> model.)
> >>
> >> The documents we're dealing with contrast the offering
> with PSTN, but
> >> don't really see any differentiation among
> "packet-switched networks".
> >>>   origination and termination of emergency calls.  Many
> of these legacy
> >> model, but the terms used mix "packet-switched", "IP-based", and
> >> "Internet"; there is even an explicit mention of EV-DO,
> but in a mode
> >> that treats it as a pure IP bearer (which is not what is
> being sold
> >> in most markets
> >> Internet model IP, and IP with operator services out there in the
> >> real world.  This document set doesn't acknowledge that, and it
> >> treats all packet-switched services/IP-based services as
> if they were Internet model.
> >> That's simply not true.
> >>
> >> The argument that Steven and others have made is that the document
> >> set needs to have an explicit acknowledgement of the other
> model, so
> >> that there is a realization by those reading them that
> just because they have
> better?  Yep.
> >> Do I, personally believe that it will eventually subsume other
> >> versions?  Maybe, and I think it would be nice.  But I
> also recognize
> >> that it is not the case now, and we're trying to define a
> system that
> >> will actually work to deliver emergency calls in the real world.
> >> Explicit acknowledgement seems to me valuable in that case.  The
> >> other option is to re-write the documents to clarify that not any
> >> packet-switched network nor any network using IP fits this set of
> >> assumptions; that seems to me likely to take longer and
> not add much.
> >>
> documents
> >> if they did not contain language like that which was in
> -09.  If it
> >> is taken out, I believe the documents will need a major
> editing pass
> >> to accomplish the clarification without the explicit text.
>  This text
> >> is a compromise already, and the issue it deals with is
> important.
> >> Unless we are going to pretend that the IMS model simply doesn't
> >> exist and won't be used to deliver a substantial fraction of
> >> emergency calls for a good long time to come, we need it.
> If we are
> >> going to pretend that, I think we are being very foolish indeed.
> >>
> >> Ted
> >>
> >>
> >>
> >>> Having to change the way the device initiates an
> emergency call when
> >>> something as prosaic as the access technology changes is akin to
> >>> having to change your web browser just because the access
> technology
> >>> has changed. It's neither helpful nor harmless to have
> such a restriction.
> >>>
> architectures,
> >>> such as IMS Emergency calling defined by 3GPP and 3GPP2,
> which are
> >>> not based on the ECRIT framework are likely to not be compatible
> >>> with devices and emergency networks which assume this framework -
> >>> e.g. such as is defined by NENA as i3."
> >>>
> commentary -
> >>> as is the proposed "applicability statement" and
> commentary is unnecessary.
> >>> Nevertheless, I think it's a more accurate characterization. That
> >>> is, it's more the case that the 3GPP IMS emergency architecture
> >>> doesn't fit ECRIT than it is that ECRIT doesn't fit a
> 3GPP access network.
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of Edge, Stephen
> solution
> >>> will probably not be universally applied and when it is may be
> >>> subject to modification. On the 3GPP/3GPP2 sides, solutions are
> >>> defined with a specific and explicit scope and are
> expected to be -
> >>> and nearly always actually are - supported exactly as
> defined in the
> >>> appropriate spec.s for all scenarios covered by the scope. A
> >>> solution whose deployment is unpredictable will be less useful
> >>> because of the implied interworking problems between incompatible
> >>> implementations. That is a main reason why I and others initially
> >>> tried to include a more precise applicability/scope
> statement than
> >>> the one we are now discussing. Specifically, the Ecrit
> solution will
> >>> probably not be deployed by
> >>> 3GPP/3GPP2 operators for cellular terminals because they have
> >>> defined a
> operation.
> > >> That means
> >>> that a terminal supporting only the Ecrit solution (based on an
> >>> assertion of universal ap
> >>  plicability) will encounter problems when its user attempts an
> >> emergency call on a 3GPP/3GPP2 network. If I can extend your
> >> analogies, this would be like not including a precise menu
> >> description for a meal containing meat and/or fish in a
> restaurant catering to both vegetarians and non-vegetarians.
> >>>
> >>> Kind Regards
> >>>
> >>> Stephen
> >>>
> >>>> Your interpretation of applicability is certainly
> extreme (yes or
> >>>> qualified yes to all questions) - removing any dependence on
> >>>> suitability or feasibility (which are the more normal
> benchmarks)
> >>>> and simply making a legalistic blanket assertion. (I can
> now more
> >>>> understand incidentally why the fictitious protocol
> police are so
> >>>> often invoked on matters of
> >>>> conformance.)
> >>>>
> >>> and framework documents are closely related documents
> that need to
> >>> be read (and understood) together.  In looking at Phone
> BCP, there
> >>> have been many situations in which  I wondered what the
> >>> justification was for a requirement, only to find the (usually
> >>> persuasive) explanation in the corresponding section of
> the framework document.
> >>>
> >>> IMHO, the separation of the two documents is somewhat unnatural.
> >>> It's a bit like taking a meal, freeze drying it, and then
> presenting
> >>> the diner with a cup of powder and a cup of water and
> wondering why
> >>> they are left with a quizical look on their faces.  Including
> >>> cooking instructions along with the two cups is not a
> fully satisfactory answer.
> >>>
> >>> Given this reality, if there is a need for text explaining the
> >>> fundamental assumptions of the architecture, the place
> for that text
> >>> is not in the BCP document, but in the framework
> document.  As has
> >>> been noted by others, the entire BCP document is an applicability
> >>> statement, and when viewed in that way, the proposed text is not
> >>> only unnecessary, but somewhat confusing since required
> context for
> >>> the BCP document belongs in the framework document.  If anything
> >>> more is necesary, it would probably be some additional
> instructions for the reader  delving into the document set
> for the first time.
> >>>
> >>> Like any IETF effort, the framework and BCP documents will be
> >>> evaluated on their own merits. Athough this is an area with a
> >>> considerable regulatory component, I see little evidence that the
> >>> world at large is so in awe of the IETF that every word will be
> >>> taken as immutable truth.  No doubt other SDOs will take
> issue with
> >>> these documents in whole or in part and will explain the basis of
> >>> their assessments and where necessary, their alternatives. As a
> >>> result, some portions of the architecture may be adopted, some
> >>> portions may be ignored, and others will be revised in an
> effort to address the issues encountered and improve their
> chances for deployment.
> >>>
> text is a
> >>> bit like the warning labels that we find on consumer products.
> >>> While it may be necessary in some legalistic sense, given the
> >>> expertise of the individuals assessing these documents,
> one wonders what the practical effect will be.
> that it is a
> >>> good idea to double-cup hot coffee.
> >>>
> >>>
> >>>
> >>>
> --------------------------------------------------------------------
> >>> ---------
> >>> -------------------
> --------------------------------------------------------------------
> >>> ---------
> > >> -------------------
> >>> [mf2]
> >>>
> >>> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt)
> >>> (0040366B)
> >>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 May 2009 10:13:59 -0400

Please be careful.

What you mean is that 3GPP has chosen to go a different direction.  The
phonebcp procedures would work fine in IMS systems if operators chose to
implement them.  There is no inherent disconnect. 

At the moment, it would seem that IMS operators will have to provide all the
tools to allow devices and services on their underlying packet network to be
phonebcp compliant.  The mobile WiFi to wireless network bridge plus any
standard phonebcp compliant client for example.  The services that the
operators provide directly may use different procedures, given the current
3GPP standards direction.

Brian

> Of DRAGE, Keith (Keith)
> Sent: Thursday, May 14, 2009 9:52 AM
> To: Ted Hardie; Marc Linsner; [email-masked]
> In general, I have trouble thinking of any SIP RFC that cannot be
> applied, or attempted to be applied somehow in the IMS environment. Not
> all operators may deploy all capabilities, but that applies to all of
> SIP. Even something like RFC 4474 can be applied across the top of IMS
> if one so wished, asssuming someone had not stuck an SBC in the way.
> 
> Those considerations do not apply for Phone BCP, where if attached in
> an IMS environment, in order to make an emergency call, the sequence
> followed is somewhat different, and the IETF procedures just will not
> work.
> 
> regards
> 
> Keith
>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 May 2009 18:04:02 -0700

>  implement them.  There is no inherent disconnect.

Phonebcp makes pretty sweeping statements about the way that 
emergency calls are placed, and makes a large number of statements 
instructing phone-centric behavior which doesn't work well for 
cellular phones.  There are very small number of statements allowing 
in some cases for network elements to handle some of the 
phone-centric tasks.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 May 2009 21:37:53 -0400

Please cite an instance.

We do not believe that the requirement for the endpoint to query the LIS or
the LoST server is onerous on any cellular network.  In the scheme of things
that IP based devices (we are talking about IP connected devices, not
current GSM/CDMA systems) are expected to do, a HELD and LoST query is very
modest in bandwidth, code size and compute power.

Brian

> Sent: Thursday, May 14, 2009 9:04 PM
> To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 'Marc Linsner';
> [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 May 2009 20:39:02 -0500

At 08:04 PM 5/14/2009, Randall Gellens wrote:
>in some cases for network elements to handle some of the phone-centric tasks.

I'm beginning to think the worst mistake we've made (possibly as an 
SDO) is to call anything a "phone", which is legacy and has a whole 
host of baggage attached.

We should just say "UA" (or UAC or UAS) and let the reader figure out 
what we mean...  At least IMS doesn't call their endpoints UAs, 
choosing UEs instead - hence, eliminating the confusion (if we use 
different acronyms)

<mumble>

...you can continue with your regularly scheduled programming now....

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 May 2009 21:47:00 -0700

>  modest in bandwidth, code size and compute power.

The instructions are for devices to determine their location when 
powered on and frequently thereafter, and do LoST queries afterwards. 
This may be fine for many devices, but not for cellphones.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 May 2009 00:09:22 -0500

Randy,

Do you agree that when a call is made from a mobile device (IP or
otherwise), that the steps of acquiring the device's location, then
determining the route to the correct PSAP are necessary?

23.167 allows the device to acquire its location ahead of time from the
IP can, how is this different to ECRIT? Are you saying that 23.167
requires explicit wording to say that if the device is a cellphone it
must not do this?

Perhaps the rules in phone BCP surrounding wireless devices needing to
poll periodically is not desired behaviour. Perhaps the correct
behaviour is do it when you first connect, do it at call time, do it if
you change networks because your LIS will have changed. In each of these
cases the device will need to be active anyway, so the argument of
consuming more battery because the device has to move out of idle mode
is totally moot.

Brian, do you take exception to my proposed change?
It still provides a fallback option if the attempt fails at call time,
and it still allows the device to route with the best data possible if
everything is working okay.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randall Gellens
Sent: Friday, 15 May 2009 2:47 PM
To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 'MarcLinsner';
[email-masked]
Subject: Re: [Ecrit] PhoneBCP

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 May 2009 02:11:57 -0500

I've got a G1 here that says you're wrong...

And an iPhone on someone else's desk over there... though those devices
are not to my taste.

It's all IP to them and the clients are dead easy to make.

Is 3G somehow "fake Internet" in your opinion then?

Cheers,
Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 May 2009 02:10:40 -0500

Amen.

The whole concept of a phone is so... 20th century.

At best it's anachronistic term. In not too many more years, it'll just
sound quaint.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Friday, 15 May 2009 11:39 AM
To: Randall Gellens; Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie';
'Marc Linsner'; [email-masked]
Subject: Re: [Ecrit] PhoneBCP

<mumble>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 May 2009 08:12:09 -0400

Since an increasing proportion of devices are used with location based
services, that would seem to be incorrect.  The text says "periodically" not
"frequently", and the location you acquire is routing location, which is
cell tower based for most mobiles.  That is not in the least onerous.

Brian

> Sent: Friday, May 15, 2009 12:47 AM