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

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

In line 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, June 13, 2013 9:13 PM
To: Dan York
Cc: [e-mail]
Subject: Re: [stir] current draft charter - ENUM and databases

Instead of looking at this as an ENUM-like problem, another angle is to
consider this somewhat similar to the whois issue.

Also, I suspect there would be fewer concerns if the DNS-like database
mainly referred to other databases, which can then be access-controlled as
needed, and can evolve. This model might also allow for combining the
CDS-like approach with the PKI approach for the same number, and allow for
multiple operators for both models. The DNS (or similar) public database
would only indicate which methods the number supports and redirect to the
rendezvous or PKI service. I'm not sure that qualifies as DANE-like.

[RS> ]  For what it's worth several of the designs for Carrier 6116 systems
relied specifically on this model where the tree was essentially a "thin
registry" and the E2U functions relied on NS records of one form or another
to indicate a level of redirection where the carrier of record (or whomever)
for a TN was presumed authoritative and you could also use other protocol
methodologies like HTTPS for access control.  The other model assumed the
"thick registry" where indirection was not present and it more closely
resembled a CDB model like the NPAC where the registry preformed the role of
validating the provisioning and the URI data was ultimately "pushed" into
the carrier networks or was available through other means to smaller
carriers by whatever protocol method they choose 6116,  SIP Redirect so long
as they were able to be "certified" for access as a" licensed" user etc.

I'll say it again if we deal with Telephony carriers provisioning within
OSS/BSS systems has to be taken into account.  In the US that is, I think
700 Million or so assigned TN's It would be easy for some folks to check
with the NANPA Administrator to find out how many are actually active. 

I'm not saying STIR should go down this path only that that idea has had
some serious proposals associated with it.  



My general gut feeling is that we don't guess well on how public
infrastructure evolves (or doesn't), so allowing for multiple outcomes and
abstracting it, as well as allowing for functionality that gets better over
time, might be more productive, as this allows for partial success, rather
than just "exactly as planned" or "complete failure".

Also, keeping scale in mind helps: In our case, the scale for
"number-holding service providers" is currently a few thousand, not
millions, so management solutions that don't scale to millions are
acceptable to get started. The backend process today is pretty manual
(faxes, web pages and proprietary APIs), so expectations are fairly low.
[RS> ] 
[RS> ]   +1 to that ...


Henning

On Jun 12, 2013, at 4:40 PM, Dan York wrote:

> On 6/12/13 2:22 PM, "Peterson, Jon" <[e-mail]> wrote:
> 
> 
>> Agreed. Though I do think that even for the domain model, we could 
>> get some value from looking at DANE to improve the way that 
>> credentials are managed. Whether we put the keys in the DNS or just 
>> point to the approved cert by reference, we should probably have some 
>> means for the successor to
>> RFC4474 Identity-Info to tip off relying parties to DANE.
> 
> Agreed (as you would expect me to say). I've been thinking about how 
> DANE could help here, but...
> 
>> But yes, for the telephone model it seems unlikely that casting these 
>> as domain names will get us very far.
> 
> ... I think this issue will get in the way right now.  As much as I 
> would love to see this as a good example of where DANE can help, I 
> still haven't been able to wrap my brain around how we could use DNS 
> for telephone numbers without running into all the exact same issues 
> that made public ENUM non-deployable.  :-(
> 
> I agree, though, that it would be helpful to have some way for a 
> header to alert relying parties to DANE in the event that there is a way
it can work.
> 
> Dan
> 
> 

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