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

[Michael Hammer <[e-mail]>]

I would suspect that if a called party attempt to fetch a cert and is told
to pay, you will find users will just not accept the call.
That could occur prior to ringing based on service provisioning.
So, if countries don't want their calls to cross boundaries, that will do
it.

Mike


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Peterson, Jon
Sent: Monday, June 17, 2013 2:59 PM
To: Hadriel Kaplan
Cc: [e-mail]; Henning Schulzrinne
Subject: Re: [stir] current draft charter - ENUM and databases


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
>

_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir