Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Aug 2012 07:49:47 -0700

+1

Hannes Tschofenig <[email-masked]> wrote:

I agree with you Marc.

On 8/21/12 3:16 PM, "Marc Linsner" <[email-masked]> wrote:

> If a PSAP callback *could* be something other than an emergency, what's
> wrong with using less ambigous 'PSAP-callback' as the indicator?
>
> -Marc-
>
> -----Original Message-----
> From: "Rosen, Brian" <[email-masked]>
> Date: Monday, August 20, 2012 4:19 PM
> To: John-Luc Bakker <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator
>
>> I don't care much about this decision.
>>
>> I'd prefer a new one.  My reason is that 3261 says:
>> It is RECOMMENDED
>>   that the value of "emergency" only be used when life, limb, or
>>   property are in imminent danger.
>>
>> Call backs don't necessarily have that implication. They might, but it
>> also can be much less important.
>>
>> I think most implementors would view the emergency call as having
>> priority emergency, but not necessarily the call back.  That's why I
>> think it would be better to create a new value.
>>
>> But, as I said, I don't care much.
>>
>> Brian
>>
>> On Aug 20, 2012, at 3:38 PM, John-Luc Bakker <[email-masked]> wrote:
>>
>>> Folks,
>>>
>>> Going back to the original question:
>>>
>>>> Resolve to use "emergency" as the Private header value, since any new
>>>> (other) value doesn't offer a real advantage.
>>>>
>>>> Does anyone disagree as to wg acceptance of this approach in the
>>>> meeting?
>>>
>>> I haven't understood the position against using "emergency". I am happy
>>> to use "emergency" as the Private header value.
>>>
>>> Kind regards,
>>>
>>> JL
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Paul Kyzivat
>>> Sent: Friday, August 17, 2012 10:38 AM
>>> To: [email-masked]
>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator
>>>
>>> On 8/17/12 3:52 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> I am saying that if the value has been verified, other entities within
>>>> the trust domain don't need to perform the verification. And, using a
>>>> new value, those entities will also know that it is a PSAP callback.
>>>
>>> If you are working within a domain you can use whatever criteria you
>>> want to decide whether to preserve or remove this header when it comes
>>> across the boundary of the domain. If you want, the border elements can
>>> only permit it from PSAPs.
>>>
>>> One it is inside the trust domain, it is what it is. If it's
>>> Priority:emergency, then that's what it is. Something inside the trust
>>> domain could have put it in. Or something on the boundary of the domain
>>> might have a different policy to let it in from some class of users
>>> other than PSAPs.
>>>
>>> My point is that it is an emergency call, which might have a high
>>> probability of being an emergency callback from a PSAP. It isn't
>>> definitively an emergency callback. And then there needs to be a set of
>>> policies for how to handle emergency calls. That might include things
>>> like calling barred numbers that you don't want just anybody to be able
>>> to do.
>>>
>>> Of course this is just a philosophical difference from what you said.
>>>
>>> Thanks,
>>> Paul
>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> ________________________________________
>>>> From: [email-masked] [[email-masked]] On Behalf Of
>>>> John-Luc Bakker [[email-masked]]
>>>> Sent: Thursday, August 16, 2012 6:22 PM
>>>> To: [email-masked]
>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator
>>>>
>>>> Hi Christer,
>>>>
>>>> What you describe below is a trust domain applicable only to a
>>>> particular header field's value, right?
>>>> Are you saying only if the new value is present, the UA can derive
>>>> that the header field value can be trusted as it must have been
>>>> "subjected to verification" (any other value for that header field
>>>> cannot be trusted)?
>>>>
>>>> I need to look deeper into trust domains, as I hadn't realized
>>>> existing (legacy?) header fields could be subjected to trust domain,
>>>> based on that header field's value.
>>>>
>>>> I was so far leaning towards Martin's and Paul's position, where they
>>>> claim "emergency" is the right word.
>>>>
>>>> Regards,
>>>>
>>>>         John-Luc
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of Christer Holmberg
>>>> Sent: Thursday, August 16, 2012 4:28 AM
>>>> To: Martin Thomson; Paul Kyzivat
>>>> Cc: [email-masked]
>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator
>>>>
>>>> Hi,
>>>>
>>>> It is true that some entity in the network needs to verify the
>>>> context, and that the call comes from a PSAP. But, once that is done,
>>>> other entities within the same network (trust domain) do not need to do
>>>> that.
>>>>
>>>> So, for that reason I think a new value would be good.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> ________________________________________
>>>> From: Martin Thomson [[email-masked]]
>>>> Sent: Wednesday, August 15, 2012 7:36 PM
>>>> To: Paul Kyzivat
>>>> Cc: Christer Holmberg; [email-masked]
>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator
>>>>
>>>> On 14 August 2012 14:19, Paul Kyzivat <[email-masked]> wrote:
>>>>> As I said, I'm *ok* with a new value.
>>>>> But it offends me to have to add a new value when we already have a
>>>>> value "emergency" and this *is* an emergency. It sets a precedent
>>>>> that nobody can use predefined values that weren't assigned for their
>>>>> own specific case. Its another example of a philosophy that we need
>>>>> to signal features or use cases rather than simply assemble basic
>>>>> primitives to accomplish features.
>>>>
>>>> I'm with Paul on this one.  These are just labels that have
>>>> essentially arbitrary or context-specific semantics.  This looks very
>>>> much like a case where context is everything.
>>>>
>>>> "emergency" is the right word.  The only concern is that it might have
>>>> some other meaning.  But those uses are specifically in some other
>>>> context.  This is a new context (probably based on identification of
>>>> the PSAP, but that's simply an example).
>>>>
>>>> If context provides insufficient information to enable the sorts of
>>>> decision that we want to enable, then a new label isn't going to fix
>>>> that.
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>> ---------------------------------------------------------------------
>>>> This transmission (including any attachments) may contain confidential
>>>> information, privileged material (including material protected by the
>>>> solicitor-client or other applicable privileges), or constitute
>>>> non-public information. Any use of this information by anyone other
>>>> than the intended recipient is prohibited. If you have received this
>>>> transmission in error, please immediately reply to the sender and
>>>> delete this information from your system. Use, dissemination,
>>>> distribution, or reproduction of this transmission by unintended
>>>> recipients is not authorized and may be unlawful.
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential
>>> information, privileged material (including material protected by the
>>> solicitor-client or other applicable privileges), or constitute
>>> non-public information. Any use of this information by anyone other than
>>> the intended recipient is prohibited. If you have received this
>>> transmission in error, please immediately reply to the sender and delete
>>> this information from your system. Use, dissemination, distribution, or
>>> reproduction of this transmission by unintended recipients is not
>>> authorized and may be unlawful.
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit