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

[Henning Schulzrinne <[e-mail]>]

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.

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.

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