Re: [stir] Adding categories from sipcore-callinfo-spam to draft-ietf-sipcore-callinfo-rcd-04

[Paul Kyzivat <[e-mail]>]

I hadn't yet seen this when I just now queried about your earlier post.
It answers most of my questions.

	Thanks,
	Paul

On 3/12/22 3:44 PM, Henning Schulzrinne wrote:
> The basic idea originated in the FCC robocall strike force a few years 
> ago, with lots of carrier participation, so you could go back to the 
> various FCC reports that were produced at the time for the motivation 
> and background (e.g., 
> https://transition.fcc.gov/cgb/Robocall-Strike-Force-Final-Report.pdf 
> <https://transition.fcc.gov/cgb/Robocall-Strike-Force-Final-Report.pdf> 
> and https://www.fcc.gov/file/12311/download 
> <https://www.fcc.gov/file/12311/download>). This I-D and requirements 
> have been discussed since 2017, so this is hardly a new idea. The draft 
> itself has been through IESG review - I just never got around to 
> implement the changes requested.
> 
> The basic requirement is that we want the receiving callee to make 
> automated or semi-automated judgements. Currently, the RCD draft has a 
> free-form field, but that doesn't really help for anything automated 
> (or, say, displaying icons or other graphical elements).
> 
> Like all spam labeling, this is probabilistic, i.e.,  if you're waiting 
> for perfection, this isn't for you. Current robocall filtering services 
> already label numbers with categories (they are in the same ballpark, 
> but not exactly the same and each seems to differ a bit). There are at 
> least two possible sources:
> 
> * For some labels, the calling party (with signing) will insert the 
> information, presumably for the more "positive" labels like "health" or 
> "government" or "personal". If a carrier lies, this becomes either a 
> reputational issue ("never trust labels from carrier X") or enforcement 
> matter (e.g., as a potential deficiency in robocall mitigation). 
> The label may be part of the KYC process when a carrier signs up a 
> customer - after all, in almost all cases this is pretty obvious ("your 
> business says Joe's Travel Agency. You are picking the healthcare 
> designation how?") A terminating carrier may, for example, decide to 
> only trust known carriers (say, T-Mobile) in deciding whether to convey 
> this information to the called party.
> 
> * An intermediary service used by the terminating carrier labels 
> (signed) numbers based on honeypots, crowdsourcing or number databases, 
> probably more focused on negative labels like "telemarketing" or 
> "fraud". Again, versions of this exist today.
> 
> Henning
> 
> On Sat, Mar 12, 2022 at 3:10 PM Holmes, David <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Henning,
> 
>     Interesting idea, but who could define the categories, and who would
>     verify the claims?
> 
>     There may be something here, but this is a good example of where we
>     should agree the use cases and then define requirements before
>     leaping to solutions.
> 
>     BR/David Holmes/T-Mobile USA
> 
>     Get Outlook for Android <https://aka.ms/ghei36>
>     ------------------------------------------------------------------------
>     *From:* stir <[e-mail] <mailto:[e-mail]>>
>     on behalf of Henning Schulzrinne <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Saturday, March 12, 2022 9:24:47 AM
>     *To:* [e-mail] <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; SIPCORE <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* [stir] Adding categories from sipcore-callinfo-spam to
>     draft-ietf-sipcore-callinfo-rcd-04
>     [External]
> 
>     In trying to get back to looking at my ancient, dusty draft, a
>     thought: I think RCD would be significantly more useful if it
>     contained standardized categories of callers, such as the one
>     included in callinfo-spam. This allows much better user interfaces
>     and automated handling ("send all political calls to voicemail",
>     "play special ringtone for personal calls").
> 
>     Henning
> 
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir