Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
draft-ietf-stir-passport-shaken-08

I am balloting "Yes" because I want to see the anti-robocalling framework get deployed sooner than later. But I share some of the privacy concerns that have been raised by others. I will follow that conversation on the thread resulting from Ekr's DISCUSS.

Some additional comments:

*** Substantive Comments ***

§3: "The second claim is a unique origination identifier that should be
used by the service provider..."
Was that "should" meant as a "SHOULD"?

§4
- Some of the terminology in the definitions of the attestation types seems vague to me.  Does "authenticated relationship with the initiator" mean the same as "has authenticated the originator of the call"? Does "established a verified association with the calling party telephone number" mean the same as "verified that the calling party has the right to use the calling identity"? (The ATIS doc has more detailed explanations, which makes me wonder if it wouldn't have been better to just reference those definitions.)

- The type "C" description includes "Has no relationship with the initiator of the call (e.g.,
international gateways)" in the list of MUST conditions. Is it the intent that an operator can only use a Type C attestation if it does not have that relationship? That is, an operator that did have a relationship with the initiator of the call is not allowed to use a type C attestation to avoid disclosure of the relationship? (How would one test that?)

§10:
- As Alissa mentioned, the fact that similar information that might be gleaned from originid is carried in SIP is not very convincing. It's historically been common for operators to use SBCs to hide things like Record-Route and Via. (and I presume History-Info).

- Is originid required? Could an operator who had privacy concerns simply choose not to include it? (Maybe that operator has sufficient internal records to hunt down bad actors.)

- The ATIS doc talks about using the originid in type B attestations to track "reputation". I assume this sort of tracking could be done by parties other than the attesting operator? If so, I think that's worth some discussion.

*** Editorial Comments ***

- Abstract: Please expand SHAKEN in the abstract.

§1: Please expand VoIP, TDM, and SS7

I echo Ben's "Yes assuming the Discusses can be resolved". It's about time we provided this capability!

I did have a couple of comments you might want to consider, along with anything else that pops up during IESG Evaluation.

"SHAKEN" isn't spelled out in either the title or Abstract - that would probably help almost all the readers of this document ...

I did find it odd that 

  This indicator allows for both identifying the service provider that
   is vouching for the call as well as clearly indicating what
   information the service provider is attesting to.  The 'attest' claim
   can be one of the following three values: 'A', 'B', or 'C' as defined
   in [ATIS-1000074].

used "A", "B", and "C", instead of something like "F"(ull), "P"(artial), and "G"(ateway), because if you discover a need for a fourth value, it's not clear whether anyone would be assuming "A" < "B" < "C" ordering in their code, that would break if the fourth value was naturally between "A" and "B".  If you're sure no one but Spencer would be so dumb, that's a fine response ...