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

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

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
>