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

[Henning Schulzrinne <[e-mail]>]

For number assignment, we currently have an industry-cooperative model (NANC, North American Numbering Council) that ensures that the system is run reasonably efficiently and for the benefit of the industry participants. Clearly, this isn't the only model, but I suspect there are existing arrangements that can be extended. (Also, since the large carriers are likely to both originate and validate a huge fraction of the legitimate calls, there are built-in incentives for reasonable behavior. For other behaviors, there is always 47 USC 201(b).)

On Jun 17, 2013, at 2:58 PM, Peterson, Jon 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. 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. Without it, there will always be ways that nation-states
> could restrict access to queries from outside their borders, say, unless
> they go through this for-pay VPN or what have you.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 6/17/13 10:37 AM, "Hadriel Kaplan" <[e-mail]> wrote:
> 
>> 
>> On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" <[e-mail]>
>> wrote:
>> 
>>> I think the advantages below, with the exception of 4, would be true of
>>> any golden root we created for whatever protocol, be it HTTP or
>>> something
>>> else. I'm sure I could define an HTTP golden root such that the
>>> verification service could synthesize the proper fetch request from the
>>> URI in the From with an Identity-Info, one that updated in real time so
>>> you never needed to worry about revocation, one for which there was only
>>> one CA, and which you could locally cache (well, okay, 5 does conflict a
>>> bit with 2).
>> 
>> Sure, there's no debate one could replicate the DNS protocol and
>> architecture to use HTTP as the accessing protocol instead of DNS
>> query/response.  I have no idea why one would want to make a simple
>> database query protocol heavier for no benefit gain, but sure it's
>> possible. :)
>> 
>> 
>>> Also, all of the (snipped) concerns you raised about access control,
>>> middlemen, charging, etc are just as likely to arise for DNS as for any
>>> other proposal.
>> 
>> No, they're not.  For the middlemen issue, middlemen are of course also
>> possible using a DNS approach (they already exist today), but the
>> protocol used for the client to access the middleman would be
>> well-specified, because it's exactly the same as that used for cases
>> where there is no middleman: DNS.
>> 
>> With regards to the access control and charging, the important point is
>> DNS would make it virtually impossible to *have* an access control and
>> charging model for queries.  The protocol's characteristics actually make
>> it practically impossible to do.  Country-A couldn't charge Country-B to
>> access the calling cert info for Country-A; and Carrier-A couldn't charge
>> Carrier-B to access the calling cert info for Carrier-A.  Instead,
>> Country-A would incur the cost for managing their own E.164 entries in
>> DNS, and likewise Country-B pays for Country-B's numbers; or Carrier-A
>> would incur the cost for their E.164 numbers, and likewise Carrier-B.
>> 
>> I know that's a controversial position.  It means deciding, up front,
>> that the only supportable pricing model for this thing in the grand scale
>> would be the same as for DNS domain names: charging only for
>> adding/managing entries in the database, not charging _other_ entities
>> per-query of the database.  I think (but don't know) that this would
>> actually make this thing easier to get adoption for.  At least in my
>> simple naive view, it might help international adoption if the decisions
>> each country makes are only technical and logistic for their own country,
>> rather than involve money between countries.
>> 
>> [Note: this doesn't mean NPAC can't be used for this database in the
>> NANP, even though NPAC is a closed model and charged for query access I
>> think.]
>> 
>> -hadriel
>> 
> 
>