Re: [Ecrit] PhoneBCP

[Marc Linsner <mlinsner at cisco.com>]

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" <hardie at qualcomm.com> 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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
>> Edge, Stephen
>> Sent: Friday, 1 May 2009 2:29 AM
>> To: Bernard Aboba; Thomson, Martin; ecrit at ietf.org
>> 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:bernard_aboba at hotmail.com]
>> Sent: Thursday, April 30, 2009 1:13 AM
>> To: Edge, Stephen; martin.thomson at andrew.com; ecrit at ietf.org
>> 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
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit