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

["Peterson, Jon" <[e-mail]>]

Definitely I agree that there needs to be a root here, at least at the
national level. A few people have commented that working from the national
level makes more sense than trying to delegate something globally from on
high. Choosing that scope could make it harder to guarantee your vision of
a tariff-free identity, admittedly. I've name-dropped LoST a couple times
here as a place to look for inspiration, perhaps.

But at the end of the day I was also envisioning that this revisited
identity system would still work for regular domain names per RFC4474, and
that we'd probably even keep CID as an option for Identity-Info (or its
successor). So I was anticipating there'd be diversity in the means by
which credentials could be indicated by Identity-Info, and that having a
"root" wouldn't be exclusive in that there are identifiers other than
telephone numbers in the system too.

So again, to the question of how golden the root is, I at least pictured a
national-level root for telephone number identity that would, if at all
possible, eliminate the problem of multiple trust anchors issuing
credentials for the same identity. Just like the same cert could be
included by CID or referred to by HTTP, though, I imagine there could be
more than one protocol for getting at those credentials.

As for whether or not we need NPAC-style databases - agreed that here we
don't need most of the data that's in them (like, LRNs aren't obviously
material to solving our problem), but the authority structures they
reflect are absolutely integral to this. Ultimately, STIR proposes only to
project onto the Internet the authority over numbers that is today
administered in those databases.

I'd hesitate to start talking about delivering CNAM via STIR lest we get
into some serious mission creep. But perhaps more materially, a root which
is completely public can begin to have privacy implications when we start
looking at adding in more personally identifiable information to the
system. 

Jon Peterson
Neustar, Inc.

On 6/17/13 2:03 PM, "Hadriel Kaplan" <[e-mail]> wrote:

>
>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
>