Re: [Ecrit] PhoneBCP

["Dawson, Martin" <[e-mail]>]

Or would it be like a statement on the menu saying "You might find a
dish of the same name in other restaurants, this menu does not attempt
to describe the contents of their dish"? I'm surprised diners aren't
crying out for this sort of helpful note... not.

 

I think this is an object lesson in convergence. "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". This is exactly where walled-garden presumption collides with
convergence reality. Understanding ECRIT means understanding that
broadband Internet access is broadband Internet access is broadband
Internet access. 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: [e-mail] [mailto:[e-mail]] On Behalf
Of Edge, Stephen
Sent: Friday, 1 May 2009 2:29 AM
To: Bernard Aboba; Thomson, Martin; [e-mail]
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 applicability) 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:[e-mail]] 
Sent: Thursday, April 30, 2009 1:13 AM
To: Edge, Stephen; [e-mail]; [e-mail]
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]