Secure Telephone Identity Threat Model
draft-ietf-stir-threats-04

Not sure what the following text adds to the document. Either there is too much or too little information. 
I have no idea what some of these attacks mean:

   Some of the attacks that should be considered in the future include
   the following:

   Attacks Against In-band

      Token replay

      Baiting a call to a chosen number with a REFER

      Removal of in-band signaling features

   Attacks Against Out-of-Band

      Provisioning Garbage CPRs

      Data Mining

   Attacks Against Either Approach

      Attack on directories/services that say whether you should expect
      authenticated calling number data or not

      Canonicalization attacks

The draft was an interesting read, thanks for your work on it to develop the threat models.  I just have some questions from thinking about a few of the discussion point and not being familiar with the controls currently in place, so please bear with me (all non-blocking questions/comments):

In Sect 3.2, The following seems odd to me, wouldn't the robocall program know to avoid numbers that raise suspicion and why aren't they just blocked outright as source numbers?
   A robocaller may impersonate
   a number that is not an assignable number (for example, in the United
   States, a number beginning with 0),

Beyond checking that a number is valid, is there really much that can be done?  If there is some sort of validation check against incoming numbers, helpful robocalling or texting could be blocked (local robocalls for storms, airlines notifying on changes, etc.).  Source numbers can change, if you block based on an unknown source (maybe something you have not subscribed to receive), you may miss something important.  If someone has not opted out (asked to not receive unsolicited calls), in the US at least, nothing prevents the caller from placing the call (legally).  Is anything changing on that or are we bound to those restrictions?

I'll also watch for a response to Benoit's comments.  Thanks.

- section 1, last para: I'm glad the names stuff is out of
scope, thanks.

- 2.3, 2nd last para: I don't get why an attacker who
compromises an intermediary is out of scope here. Do you only
mean within the PSTN though? (Which I'd understand.) The last
sentence there is also ambiguous - I think the countermeasures
you mean are those to be defined by STIR, but that isn't what
is stated.