Ballot for draft-ietf-sipcore-status-unwanted
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Thanks, short, sweet and to the point. One minor comment: "These may use call characteristics such as call duration and call volumes for a particular caller, as well changes in those metrics over time" s/as well changes/as well as changes/ (missing a word) Please also see Al Morton's OpsDir comment at: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02571.html (for an earlier version)
See also Brett Tate's comment about which document to reference for call transfer: https://www.ietf.org/mail-archive/web/sipcore/current/msg07898.html
I agree with Warren - short, clear, and to the point. I agree with EKR and Kathleen about requiring authentication. In this text, Thus, the call is rejected due to the called party's (temporary) disposition. I'm having trouble matching dictionary definitions to the use of "disposition" here. I guess it's an OK use of the word, and I know what's intended based on context clues, but if another word would be clearer, that would be helpful. This text, The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls. is unchanged from the previous version, where the response code number was 666. Is that intentional? Just checking - in this text, The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party identity to consumer complaint databases operated by government authorities. there's no standardized way for the called party to signal that this action should be reversed, is there? I ask, because the next paragraph says, The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user. and I use the "this is not spam" button on email fairly frequently. The security considerations section does talk about the protected party notifying the service provider using unstandardized mechanisms - I see that. Maybe a forward pointer to that discussion would be helpful.
It seems like the security considerations here probably need to cover what's needed to prevent forged 607 responses. This seems like an issue for on-path attackers, who could block the real response and inject a 607. This isn't usually that great an attack, but if you can use it in a sort of bounce attack to really gag a sender, that would be bad. Probably what's needed here is text about only accepting 607s over TLS (and filtering at the other endpoint). It's also worth mentioning that in a post-STIR world, you could send the PASSporT object as proof of the existence of the call (though not of its unwantedness).
I agree with EKR's comment and would like to see additional security considerations that spell out the dangers of not sending this over secure network or without mutual authentication (MiTM attack he describes). I just noticed the text called out by the SecDir review and would like to know if the following change could be made since it is just part of a list of examples: OLD: or report the calling party identity to consumer complaint databases operated by government authorities. NEW: or report the calling party identity to consumer complaint databases. It doesn't seem necessary to call out government authorities here and there is the potential for abuse with such databases (government or otherwise managed). I was glad to see the explanation for the existence of this draft in the shepherd report and ballot text, but think the explanation should be in the draft as well. I was curious about implementations as there is the potential for trouble with this option. It seems like it should be experimental first, but I guess we could always make it historic later if unforeseen problems arise.
I actually have one mostly technical question: It is not fully clear to me if the Unwanted response code always indicates a user action or if the same code is used when an automated system declines the call? My understanding is that the idea is that this could also be automated if the user has some kind of control of the system (which is probably hard to verify). Or would it make sense to distinct between the cases where the user actively rejects a call or an automated system is generating the response code (on behalf of the user)?