[drinks] Regarding domains in usecases-02

[Otmar Lendl <[e-mail]>]

I've written about this already a few times in various IETF / RIPE lists,
but it seems to be relevant to the current draft as well, so here is
a repeat:

According to the usecases draft, SSPs report the public identities of their
customers to the registry so that the registry can store the mapping to
destination groups. All fine and dandy for TN based public identities, but
what about sip:user@domain?

These URIs come in (at least) two flavors:

a) the domain is the provider's domain (e.g. "verizon.com")
b) the domain is owned by the customer (e.g. "shockey.us")

The first one makes it easy for the SSP to authoritatively tell the
registry that it provides service for whatever URI it is going to
provision. So from the point of drinks, this is easy.

[I still very much doubt that solely offering such PIs to customer is
dangerous to the SSPs as they might be forced to offer PI portability,
which would really mess up a lot of assumptions.]

So what about b)? Portability is a given, and ISPs are used to deal with
customer-owned domains for email and web. Good. So what's the authorization
mechanism? For email and the web it's simple: the entity which controls the
domain must set the respective MX and CNAME/A records so that the rest of
the world know who provides email/web services for this domain. If the
control over the domain changes, so does instantly change the control over
email and the website.

Now, if a SSP can provision any URI regardless of the domain ownership
status / domain content, this opens up a pandora's box of interesting
errors. We now duplicate who operates SIP service for a domain in two
databases which can and will run out of sync with each other.

I consider it thus a lot more in line with the rest of the Internet
protocols to store the mapping domain -> destination group in the DNS and
not some other registry.

/ol
-- 
// Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933 //