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

[Hadriel Kaplan <[e-mail]>]

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