Re: [stir] current draft charter - ENUM and databases

[Hadriel Kaplan <[e-mail]>]

On Jun 17, 2013, at 2:58 PM, "Peterson, Jon" <[e-mail]> wrote:

> 
> I agree it would be great to find a technical approach to this that
> simplified business relationships, but I don't think we can depend on
> technical standards to restrain policy. That would be like stipulating
> that intermediaries can't change RFC3261 request bodies in order to - but
> never mind.

I don't think that analogy holds.  Such a stipulation would fail because the guys who run the SIP networks themselves *must* change the request bodies to get things to actually *work*, for their users/customers.  Even if you think they change bodies to maintain existing charging practices: this caller-id verification thing is completely new, which is a horse of a different color.  There are no existing charging practices for this currently.

I believe the closest things would be:
1) CNAM, for which typically the called party pays.  I don't think the *carriers* want it to be that way, but it is that way.  This STIR work could end up being quite disruptive to the CNAM providers, because one could imagine a means of providing CNAM using the STIR infrastructure and cutting out the CNAM providers.  But to brutal about this: we don't need the CNAM providers to buy into this STIR work, so we don't need to care if it impacts their business or not.

2) NPAC-type databases, or anything already holding a bunch of E.164-based record entries.  I don't know what the business model is for them - obviously you would know a crapload more about that than I would.  I don't *think* it would be disruptive to make *only* E.164 caller-id certificates in the NPAC publicly and freely accessible for retrieval.  Maybe it would be disruptive.  But again to be brutal: we don't even really need the NPAC-type databases, although it would sure make things a heck of a lot easier.  But ultimately all we need is for the carriers to want to do this, with some model they're ok with.


> It is ingenious to turn the inability to authenticate queries
> to the DNS into a virtue in this regard, but I'm still not sure I
> understand how this model would really prevent middlemen from charging if
> they wanted to, short of recreating e164.arpa as some comparable public
> golden root. 

I am indeed claiming/assuming we do create a golden root if we do this DNS thing.  I don't care if it's cid.arpa, cid.sipforum.org, a new gTLD, or even hadriel.com. 

I didn't say it prevented middlemen - even just purely as a practical matter there will likely be middlemen to do the signing and verifying for mom&pop carriers, for example.  Or the CNAM provider might do the verifying function for their customer carriers.  They can charge their customers however they like, including on a per-query basis (e.g., private ENUM is already used for some CNAM providers today).

-hadriel