Re: [Ecrit] PhoneBCP

["Edge, Stephen" <[e-mail]>]

Hi Marc

It seems that RFC 5012 would be a useful acknowledgement (assuming that its requirements are all or mostly supported). But I do not have the impression that RFC 5069 is supported - but if it is, then it's also another good reference.

Neither of these, however, is an effective substitute for a clear simple statement like the one we are discussing (and I saw no equivalent statement in either of the RFCs).

Kind Regards

Stephen
-----Original Message-----
From: Marc Linsner [mailto:[e-mail]] 
Sent: Thursday, April 30, 2009 5:48 AM
To: Edge, Stephen; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

As I pondered on the new text, I saw no great harm with it, but the reason I
hummed against it, I don't see that it adds any value.

If we declare in either/both drafts that this solution is based on the
requirements in RFC5012/RFC5069, would that satisfy your concern...??
(I'm somewhat surprised this isn't in either draft.)

-Marc-



On 4/30/09 3:35 AM, "Edge, Stephen" <[e-mail]> wrote:

> Hi James
> 
> The current statement being debated does not say that Ecrit is not applicable
> to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others more on
> the 3GPP/3GPP2 side are now perfectly willing to let that drop given the
> current statement which essentially characterizes the main principles of the
> Ecrit solution, admits the potential existence of other solutions and the fact
> that they are not defined within the Ecrit solution.
> 
> The detailed points you raise below may not be worth answering if you also
> take the same view as Martin namely that suitability and feasibility are
> irrelevant when it comes to Ecrit (though not of course when it comes to 3GPP
> and 3GPP2 I should note).
> 
> But I am still awaiting answers to my original questions from others in the
> Ecrit community.
> 
> Kind Regards
> 
> Stephen
> -----Original Message-----
> From: Winterbottom, James [mailto:[e-mail]]
> Sent: Wednesday, April 29, 2009 9:00 PM
> To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne;
> Stark, Barbara; ECRIT
> Subject: RE: [Ecrit] PhoneBCP
> 
> 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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> 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]
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit