Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)

[Paul Kyzivat <[e-mail]>]

On 10/5/15 11:48 AM, Rosen, Brian wrote:
> What is the PSAP supposed to do with this URL?  Create a bridge and bridge in the URL?

This all makes little sense to me. It seems there are two cases:

1) on original call, some agent acting for the caller bridged in a relay.

2) on the original call, some agent acting for the callee (the PSAP) 
bridged in a relay.

ISTM that in the case of a callback, the relay should again be bridged 
in by an agent for the end that got the relay originally. It makes 
little sense to me, when the caller originally bridged in the relay, for 
the PSAP to attempt to bridge in the same relay on a callback.

So in case (1), making a callback call to the callback URI (probably the 
contact from the original call) should implicitly cause the relay to be 
brought back in. Hence there would be no need to pass a URI for the 
relay to the PSAP.

	Thanks,
	Paul

> Brian
>> On Oct 3, 2015, at 4:58 PM, Gunnar Hellström <[e-mail]> wrote:
>>
>> Den 2015-10-03 kl. 20:51, skrev Paul Kyzivat:
>>> On 10/3/15 8:10 AM, Gunnar Hellström wrote:
>>>> A comment on the 24/7 discussion on section 4.1.5:
>>>> Relay services are supposed to be data providers.
>>>> Sadly, the deployment of relay services is very slow in some regions,
>>>> and if they exist, they often operate limited hours.
>>>> This is of course a problem when making emergency calls, but the wording
>>>> in 4.1.5 should not discourage relay services from registering and
>>>> providing data because they currently have limited opening hours.
>>>> ----------------
>>>> Another issue around relay services: It would be good to get a URI that
>>>> can be used for bridging in the relay service together with a call-back.
>>>> This is because the relay service might have been invoked in a way so
>>>> that the call-back address to the original caller does not automatically
>>>> invoke the relay service. None of the provided data seem to specify that
>>>> kind of URI.
>>>> ----------------
>>>
>>> If the relay service was included in such a way that callbacks don't bring it back in, then having the URL of the relay service won't necessarily mean that the entity doing the callback will be authorized to obtain relay services on the callback call.
>>>
>>> I don't see a good way to solve that except for the relay service to be authorized based on whichever end of the call desires/needs the relay service.
>> Yes, that would be included in a recommendation for how to use a URL field in Additional-Data.
>> A region could have requirements that the relay services who are registered as data providers also authorize calls from the region.
>> But it would be equally good if you can propose another field to convey such an URL in. It does not seem to be the intention of Additional-Data to provide operational information.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> /Gunnar Hellstrom
>>>>
>>>> Den 2015-10-02 kl. 23:38, skrev Ben Campbell:
>>>>> Oops, I just ran across this going back over old messages. I don't
>>>>> think I responded; apologies for that. Comments inline. I deleted
>>>>> sections that don't seem to need further discussion.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben.
>>>>>
>>>>> On 13 Sep 2015, at 18:51, Randall Gellens wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>
>>>>>>> [Edit: I asked a question below about what happens if you dereference a
>>>>>>> block, and find the URL points to something other than what you
>>>>>>> expected.
>>>>>>> On reflection, I should expand that  to ask how dereferencing errors
>>>>>>> should be handled in general.]
>>>>>>
>>>>>> In general, since this is an emergency call, we want the call to go
>>>>>> through even if there are errors.  It's better that the call go
>>>>>> through with some data blocks missing or unusable than for the call
>>>>>> to fail.
>>>>>
>>>>> That makes sense--is there any text that says that? If not, it might
>>>>> be worth adding.
>>>>>
>>>>> [...]
>>>>>
>>>>>>>> This draft implicitly assumes that the emergency calls are signaled
>>>>>>>> with
>>>>>>> SIP. I don't dispute that assumption, but I think it should it's
>>>>>>> worth a
>>>>>>> paragraph stating it explicitly.
>>>>>>
>>>>>> The Introduction says:
>>>>>>
>>>>>> This document extends the basic set of data communicated with an IP-
>>>>>> based emergency call, as described in [RFC6443] and [RFC6881]
>>>>>>
>>>>>> Both those RFCs are explicitly SIP-based.  However, I'd be happy to
>>>>>> change the text from "IP-based" to "SIP-based" if people feel it
>>>>>> would add clarity.  E.g., to:
>>>>>>
>>>>>> This document extends the basic set of data communicated with a SIP-
>>>>>> based emergency call, as described in [RFC6443] and [RFC6881]
>>>>>>
>>>>>> Or perhaps to:
>>>>>>
>>>>>> This document extends the basic set of data communicated with a
>>>>>> Session Initiation Protocol (SIP) based emergency call, as
>>>>>> described in [RFC6443] and [RFC6881]
>>>>>>
>>>>>> Let me know if you feel this change would be helpful.
>>>>>
>>>>> I think the second version would be helpful.
>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>> -- 3:
>>>>>>> Is there a critical need for the bit about "certain private-use
>>>>>>> situations"? That seems like license for abuse, without more
>>>>>>> elaboration
>>>>>>> about "prexisting relationship" and "privacy issues addressed".
>>>>>>
>>>>>> The reason for that text is to permit re-use of the mechanisms within
>>>>>> private telematics calls between a vehicle and a telematics service
>>>>>> center (which in turn simplifies the use of the mechanisms when such
>>>>>> calls are emergency calls from the telematics service center to a
>>>>>> PSAP).  The text appears as an exception to a ban on using the
>>>>>> mechanisms outside of an emergency call, so without it, such use
>>>>>> would be violating the RFC.  I thought the text was pretty
>>>>>> restrictive, since it says:
>>>>>>
>>>>>> certain private-use situations where the endpoints
>>>>>> have a preexisting relationship and privacy issues are addressed
>>>>>> within the relationship or do not apply because of it
>>>>>>
>>>>>> If you still feel this text is a "license for abuse" I'd be open to
>>>>>> tightening it, but it seems pretty limited to me.
>>>>>
>>>>> Thanks for the explanation. I can live with what's there.
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>> -- 4.1.5:
>>>>>>> Do you intend 24x7 support to be a prerequisite to be a data
>>>>>>> provider?
>>>>>>
>>>>>> It's not within scope of the IETF to make this requirement, but the
>>>>>> expectation is that calls will be processed by mainstream providers
>>>>>> who have 24/7 support for PSAPs.
>>>>>
>>>>>
>>>>> The descriptions says "...information MUST be a URI to a 24/7 support
>>>>> organization..." That sounds like the IETF is making the requirement.
>>>>>
>>>>> I'd be happy to have a non-normative statement that this is expected
>>>>> by the community to be a 24/7 support organization, but the MUST
>>>>> doesn't seem to fit.
>>>>>
>>>>>>> Also, it seems like there are vcard fields that are not useful to this
>>>>>>> purpose and might still have privacy implications. Do we really need
>>>>>>> people
>>>>>>> to send everything?
>>>>>>
>>>>>> The text does not mandate which fields to send.  It encourages
>>>>>> sending all fields because there are some unusual circumstances where
>>>>>> a seemingly irrelevant field might be useful to a call-taker (e.g.,
>>>>>> anniversary might conceivably be useful with a suicidal caller) and
>>>>>> suggests a minimum set.
>>>>>
>>>>> I think there needs to be a balance between "conceivably useful" and
>>>>> "likely to be privacy-sensitive". But IIRC, this discussion is
>>>>> happening separately, isn't it?
>>>>>
>>>>> [...]
>>>>>
>>>>>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of
>>>>>>> data
>>>>>>> (by its MIME subtype) that is available at the URI"
>>>>>>> What happens if the URL points to something other than the indicated
>>>>>>> thing?
>>>>>>
>>>>>> Then the PSAP doesn't get what it expects, and likely will ignore the
>>>>>> retrieved data, and the call will be processed as if the block wasn't
>>>>>> provided at all.  The PSAP will likely file a discrepancy report with
>>>>>> the provider, which is done out of band.  If the information in the
>>>>>> block is potentially urgent for handling the call, the call-taker or
>>>>>> a supervisor might contact the provider's PSAP support line.
>>>>>
>>>>> That's probably fine, although I wonder if there might be room for
>>>>> guidance that the PSAP shouldn't just load arbitrary data if it gets
>>>>> something unexpected.
>>>>>
>>>>> [...]
>>>>>>> -- 8:
>>>>>>> It might be worth discussing the potential harm done by a malicious
>>>>>>> proxy
>>>>>>> modifying a data element, or a compromised data source return incorrect
>>>>>>> information when dereferencing a URL.
>>>>>>
>>>>>> If an element in the call path is compromised and under the control
>>>>>> of an attacker, it can wreak havoc, but this is generally true for
>>>>>> any system that isn't using end-to-end protection, and even then is
>>>>>> true if an endpoint is compromised.  I'm not sure what would be
>>>>>> helpful to say about this in the Security Considerations section.
>>>>>
>>>>> I'm not going to push the point--but keep in mind the "compromised
>>>>> data source" case involves something _not_ in the call path.
>>>>>
>>>>> [...]
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>