Public Safety Answering Point (PSAP) Callback
draft-ietf-ecrit-psap-callback-13

I support Barry's Discuss wrt FQDN. note that town.com is an ongoing business and should not be abused in this way.

There is no reasonable reason not to conform to RFC 2606

Version -13 addresses my comments, and thanks very much for that.

When I asked for changes to the example domains, to follow the recommendations in 2606, I had intended changing "town.com" and "state.org" to "town.example" and "state.example" to keep the sense of the relationship (rather than "example.com" and "example.net", which don't).  Of course, the change that was made does follow 2606, so if you're happy, I'm happy.  You're certainly right that it's a pity that 2606 didn't reserve a shorter TLD, such as "xmp", for examples.  Waddyagonnado?

While these are non blocking comments regarding the document publication, let's have a discussion about those.
Note: I already discussed those two points with Hannes over the phone.

1.
   In the case where the SIP
   Priority header value, 'psap-callback', is supported by the SIP UA,
   it would override user interface configurations, such as vibrate-only
   mode, to alert the caller of the incoming call.

Is it a good idea?

I'm witnessing a crime: I call or page the police, put the silent mode, hide in a corner while waiting for the police, and now the police calls me back: no more silent mode. I'm now dead.

2.
 In the SIP proxy case, what prevents the VoIP provider to use this mechanism for support calls.
It's not emergency, but it will save the VoIP provider time and money. So they might tempted to use it. 

Richard's new sentence:

    The indicator described in Section 4 can be inserted by any SIP entity, including attackers.  So it is critical that the indicator only lead to preferential call treatment in cases where the recipient has some trust in the caller, as described in the next section.

I've have some trust in my VoIP provider, but it doesn't mean that he should get priority to call me back, by-passing all my policies.

What prevents some state/government to say: "I'm important. I want this priority feature when I call one of my citizen".

I believe that you need to impose, that, even in the proxy case, this mechanism only works in case of callback.

Editorial:
- Not sure what LoST is:

   In
   this scenario we consider a SIP UA that uses LoST to learn the next
   hop destination closer to the PSAP.

I support Barry's and Stephen's DISCUSS positions.

One thought.

   When there is a local relationship between
   the VoIP provider and the PSAP then populating the whitelist is
   fairly simple.  For SIP UAs there is no need to maintain a list of
   PSAPs.  Instead SIP UAs are assumed to trust the correct processing
   of their VoIP provider, i.e., the VoIP provider processes the PSAP
   callback marking and, if it cannot be verified, the PSAP callback
   marking is removed.  If it is left untouched then the SIP UA should
   assume that it has been verified successfully by the VoIP provider
   and it should therefore be obeyed.

This seems to presume that UA's in fact have trust with respect to what their voip provider does when in fact that may not be the case. if this facility can be abused and can't be ignored it will become untenable rather quickly.

I share Barry's concerns regarding security. It sounds like that DISCUSSion is moving along.

I implore you to take Barry's advice regarding the Introduction. Please shorten it.

I'm going to support Stephen and Barry here.

I agree with Barry's Discuss concerns on Security Considerations. I'm not a Discuss because I think the problems Barry identified are more general than the problems ECRIT is chartered to solve. 

For example, a STIR Secure Telephony Identity would help prevent spoofed use of psap-callback, but is much more broadly applicable than just assisting with PSAP Callbacks.

The conversations I've had with carriers make me think penalizing spoofed psap-callbacks by doing anything worse than treating them as ordinary calls is too risky to deploy.

But I'd love to be wrong, and I look forward to learning during the discussion.

Thanks for handling my discuss & comment