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

["Richard Shockey" <[e-mail]>]

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

For number assignment, we currently have an industry-cooperative model
(NANC, North American Numbering Council) that ensures that the system is run
reasonably efficiently 

[RS> ]  you are very very charitable Henning.  

To your point we also have industry operational entities such as the NAPM
North American Portability Management LLC which actually contracts for the
LNP function in the US where the NANC is more a policy body and is a formal
US TAC under the Federal Advisory Act of 1972 and the COIN Association in
the Netherlands that runs the LNP DB there and is a Non Profit Corporation
of 70 Dutch Carriers. There are lots of these in the EC.   In Canada there
is the Canadian Steering Committee on Numbering.  In the UK there is NICC
though OFFCOM directly administers the +44 plan. 

http://www.niccstandards.org.uk/

http://www.crtc.gc.ca/cisc/eng/cisf3f.htm

The term of art for these cooperative industry entities comes from the UK
QUANGO.. Quasi Non Governmental whatever's. Operationally no matter what
technical model selected virtually every nation state has some entity that
can deal with these kinds of things.   That is the least of our problems. 


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

[RS> ]  Correct! 

We will now return you to your regularly scheduled program. 





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

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