Re: [Ecrit] PhoneBCP

["Winterbottom, James" <James.Winterbottom at andrew.com>]

Stephen,

As someone that has been vocal on this topic all along I will respond.

Would you agree that this solution does allow the ultimate destination
of the PSAP being reached using legacy TDM trunks? 
If you want to take the debate offline I can clearly show to you the
solution does, and as preparation please take a look at some of the NENA
i3 and i2 work.

So this makes quite a lot of your argument below irrelevant.

You have continually argued that there is something special about IMS
and cellular despite continual evidence being presented that there is
not. Voice is not special when it comes to IP traffic, it is just
another data stream. What you are doing is coming here and saying that
3GPP are introducing a whole bunch of complex machinations to maintain a
bundling of access and service, so please would we put an applicability
statement into our documents to say that they don't apply to 3GPP
networks. This is unreasonable.

If I read 23.167 correctly, then the calling device can obtain its
location directly from the IP CAN, at least one of the IETF LCP is even
mentioned, and I have seen a CR that suggested that HELD could also be
used.

23.167 also makes use of SIP location conveyance. So far, this is 2 of
the 3 elements we require for ECRIT to just work.

I think it is perfectly reasonable to assume that if I get my location
from the IP CAN, I can probably get the serving domain also, in which
case I can do a LoST lookup. Alternatively I can go back to my home LoST
server and rely on forest guides. In either case, these are quite
reasonable assumptions, and the onus on an infrastructure provider is a
provisioning record, rather than E-SLP.... hmmmm which is cheaper and
easier I wonder?

Now what does TS23.167 say to do if my SIP client directs a call to a
URI that it obtained from a LoST Server?
I would place odds that it would just deliver the call.

Further more, if that SIP INVITE included both a CID header and a
location URI what happens? For i2 and i3 we know what happens. Again,
the LRF in 23.167 at a minimum will provide a route to the PSAP based on
the provided location.

Now, lets take Martin's argument a bit more.
I have a device that can operate on 3G, 4G or WiFi. If it connect to a
non-IMS WiFi hotspot (basically all of them) what happens? Where is the
E-CSCF, where is the E-SLP, how can it help me?

The point I am making is that ECRIT will actually work even in IMS
architectures, but the IMS architecture doesn't work in the vast
majority of IP cases. Any applicability statement you want please go and
add it to 3GPP and not here, it is 3GPP that has the applicability
issues and not the IETF.

Cheers
James
 

-----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
-----Original Message-----
From: Richard Barnes [mailto:rbarnes at bbn.com] 
Sent: Tuesday, April 28, 2009 1:07 PM
To: Edge, Stephen
Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

As was noted in the meeting, it is *always* possible that there are 
alternative solutions out there when you're talking about the Internet. 
  TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. 
XMPP, SASL vs. TLS, S/MIME vs. OpenPGP.  None of the many RFCs out there

have explicit statements that somebody else might do it differently 
because it's obvious that they can.

So I don't really think conveying the possibility of other 
implementations is actually useful at all, technically speaking.

That means that the only real purpose of such a statement is rhetorical,

and as we've seen in a few messages here, some people misconstrue the 
rhetoric to mean that this system has constrained applicability.  Given 
that, I'd rather leave it off unless we can avoid that impression.

--Richard




Edge, Stephen wrote:
> All
> 
> I would have thought that motivation should be irrelevant. There are a
lot of motives at work here. Should we assume that the document was
originally written with only the purest and most altruistic motives
(e.g. no thought of business or academic interest at stake)?
> 
> The issue is whether the current statement serves a useful purpose in
conveying the possibility (well known to be true) of alternative
solutions not fully aligned with the current drafts. Nothing in the
statement implies that the current drafts are necessarily deficient or
that alternative solutions must necessarily be used for some scenarios
(even though they optionally can be).
> 
> Kind Regards
> 
> Stephen
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of Randall Gellens
> Sent: Tuesday, April 28, 2009 9:57 AM
> To: Henning Schulzrinne; Stark, Barbara
> Cc: ECRIT
> Subject: Re: [Ecrit] PhoneBCP
> 
> At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote:
> 
>>  It is clear that the text has ulterior motives to restrict the 
>> applicability of the document.
> 
>  From my view, the text does not restrict the applicability, nor is 
> there a desire to do so.  The text does clarify the assumptions of 
> the rest of the text in the document, which I think is helpful.
> 
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.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]