Re: [Ecrit] PhoneBCP

["Edge, Stephen" <sedge at qualcomm.com>]

Martin

Thanks for the detailed reply. Actually the current delay (if any) is due to those now humming No to a statement added 5 weeks ago following support from a number of others who in general continue to support the statement now. I am in fact not proposing anything new at this moment.

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?

Kind Regards

Stephen
-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson at andrew.com] 
Sent: Wednesday, April 29, 2009 8:49 PM
To: Edge, Stephen
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

Stephen,

The consensus call was requested so that we could close this issue.  What you propose only adds delays.  Your questions are hardly "simple".  On the whole, your questions are either not of interest to this organisation (by definition), or conclusions have already been arrived at to the satisfaction of most.

Asking for an applicability statement is a nice, innocuous sounding request.  It's expedient because you can label opposition as "unreasonable".  Label me thus as you wish.  I've seen applicability statements abused too many times before.  I prefer now to let the audience decide what a specification is good for, because that's usually pretty clear.  Applicability statements only artificially constrain scope.


For interest, however, since you asked for answers, I'll humour you...

Q: "If so, is it irrelevant whether the solution is actually suitable for a particular type of AN or VSP (e.g. cellular AN, IMS based VSP)? "

A: Mu (Yes).

This is beyond questions of "suitability".  ECRIT will work for any AN, Device, or VSP that follows the (quite frankly, simple) rules.  This might not be an "easy" solution, or a JSTD-036-B lookalike, or whatever you'd like it to be.  No superior solution has been offered that meets all the requirements.

Of course, the solution has to be deployable.  But that's never been the concern, has it?

I have every confidence that ECRIT could be deployed in a 3GPP access network.  It might even work already in some networks, as long as no steps have already been taken to prevent it.  Give me MO-LR and an IP connection and I'm good to go.

However, that doesn't play well with visitors to the network.  Unless you maintain the illusion that you are able to control all devices that enter your network, you will need to support the mechanisms that they expect.  That is, as long as a network provides Internet access, ECRIT support is needed to provide emergency calling.

BTW, a LIS isn't really very hard to deploy when you already have location infrastructure, it looks a little like a protocol translator.  

There's a similar story for the voice service.  Location-based call routing is not especially complex to implement.  You can make it more complicated, but only if you'd prefer it that way.

Q: "For example, is it irrelevant whether significant additional support from an AN or VSP to which the solution might be applied would be needed in order to access legacy PSAPs, handoff to the circuit domain, authenticate the caller and provide access to non-subscribed users?"

A (legacy PSAPs): Yes.

Of course, the question of how to deal with legacy PSAPs is one of interest, but it's a not a problem that has been ignored.  Read NENA i2 for a description on how this is done.  (Oh yeah, and there is a good case of an applicability statement being abused - i2 is supposedly only applicable for non-mobile devices - which is wholly false.)

A (circuit handoff): Yes.

Again, nothing stops you from working this one out if you feel that way inclined.  The IETF does tend to limit its concerns to the Internet though, so I wouldn't expect to see any solution to that problem here.  It's a problem that could still be solved in a compatible way.

The basic paradigm is still applicable: device acquires location, device determines destination PSAP, device makes call, with the caveat that another entity can act on behalf of the device given sufficient constraints.

A (caller authentication and unauthenticated access): Mu (Yes).

Obviously, there are concerns to resolve.  Which did sort of authentication were you referring to?  AN or VSP?  Or are we authenticating users to PSAPs?  As far as the framework is concerned, these are not important questions - policy (legislation, terms of service for AN and VSP) determine what need, if any authentication is required before access is granted.

Q: "Is it further irrelevant whether the solution would even work for a particular device, AN or VSP without substantial changes to the latter? In other words, is the solution now considered so sacrosanct that any adaptation must come from the rest of the infrastructure and not from the solution itself in the case of any mismatch?"

A: Yes.

That is the way you have to do these things.  We pick a solution, and then everyone lives with it.  We do our best to pick a good solution, but there is no pretence of infallibility, or any assumption that a solution is "sacrosanct".  It's not like we are expected to produce a perfect solution on the first attempt.  The community isn't going to hold us to that impossible standard.  If there is a problem in the document, we'll just have to fix it.

I don't see that there is a mismatch, but then you continue to imply that there is.  ECRIT does something that has not been attempted before: emergency services for the entire Internet.  You can't reasonably expect there to be an existing solution to the problem.  That means changes to existing networks if they want to be part of the solution.


Since I've answered yes to all the relevant questions, I conclude that the applicability statement is "inconsistent and unnecessary".  The reasons I previously stated still equally apply.

--Martin


> -----Original Message-----
> From: Edge, Stephen [mailto:sedge at qualcomm.com]
> Sent: Thursday, 30 April 2009 11:21 AM
> To: Thomson, Martin; Richard Barnes; Gellens, Randall; Henning
> Schulzrinne; Stark, Barbara; ECRIT
> Subject: RE: [Ecrit] PhoneBCP
> 
> Martin
> 
> You are one of those humming against the current statement. You
> seemingly don't believe that any statement of applicability or scope is
> needed (or am I wrong?). Yet you have ducked my simple questions which
> are clearly relevant in that context.
> 
> I would appreciate some answers to those questions - perhaps from
> others.
> 
> Kind Regards
> 
> Stephen
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson at andrew.com]
> Sent: Wednesday, April 29, 2009 5:12 PM
> To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning
> Schulzrinne; Stark, Barbara; ECRIT
> Subject: RE: [Ecrit] PhoneBCP
> 
> Hi Stephen,
> 
> I'm convinced that the ECRIT architecture is the only solution that
> will work for ALL forms of Internet access.
> 
> I then offer you an alternative to the "applicability statement" you
> request:
> 
>   Where you believe that the ECRIT architecture does not apply, state
> why.  Include also a description of why interworking with such an
> architecture is not necessary.
> 
> The great thing about this is that you can do this in the forum of your
> choice.  You don't have to deal with the recalcitrant bunch at the
> IETF.  In fact, I'd encourage you to consider that approach.
> 
> --Martin
> 
> > -----Original Message-----
> > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On
> Behalf
> > Of Edge, Stephen
> > Sent: Thursday, 30 April 2009 9:23 AM
> > To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark,
> > Barbara; ECRIT
> > Subject: Re: [Ecrit] PhoneBCP
> >
> > Richard and all others
> >
> > I wonder if those now humming against this statement (and who were
> all
> > strangely silent 5 weeks ago) would support any kind of statement
> > concerning applicability and scope. Or is it the case that the
> solution
> > supported by both drafts is considered to apply to all devices, ANs
> and
> > VSPs that provide some form of internet access. If so, is it
> irrelevant
> > whether the solution is actually suitable for a particular type of AN
> > or VSP (e.g. cellular AN, IMS based VSP)? For example, is it
> irrelevant
> > whether significant additional support from an AN or VSP to which the
> > solution might be applied would be needed in order to access legacy
> > PSAPs, handoff to the circuit domain, authenticate the caller and
> > provide access to non-subscribed users? Is it further irrelevant
> > whether the solution would even work for a particular device, AN or
> VSP
> > without substantial changes to the latter? In other words, is the
> > solution now considered so sacrosanct that any adaptation must come
> > from the rest of the
> >   infrastructure and not from the solution itself in the case of any
> > mismatch? If the consensus answers to these questions are all yes,
> then
> > I would have to agree that including the currently disputed statement
> > or anything of a similar nature would be inconsistent and
> unnecessary.
> > Of course, the representatives of the potentially affected portions
> of
> > infrastructure should be forgiven for disagreeing with the basic
> > premise - and may be expected to offer some type of protest!
> >
> > Kind Regards
> >
> > Stephen


------------------------------------------------------------------------------------------------
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]