Subject: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy

From: "Stastny Richard" <[email-masked]>
Date: Thu, 18 Aug 2005 14:42:52 +0200

Jonathan wrote: 
> >
> > we need here sip:[email-masked];user=phone with
> > the same number to indicate the foo.com domain of the carrier
> > This is basically the essential information
> 
> Right, and this is an address.

Ok, let's say it is an address (in IETF terminology)

Just for avoidance of doubt:
A construct like sip:[email-masked];user=phone
does NOT indicate that foo.com is necessarily the 
carrier-of-record hosting the E.164 number. Therefor
your next statement does not hold for the to-field
(it may be true for the from field)
 
> >>Given this, the meaning of sip:<phone-number>@domain;user=phone
means
> >>that the domain is asserting ownership of the identity in the user
part,
> >>in this case a global phone number. As such, its appropriate to use
this
> >>form only when it is authoritatively known that the domain in
question
> >>"owns" that phone number.

Examples: this URI may be used to send a request from a UA to his proxy
in which case foo.com in most case does not have the ownership,
it is just indicating the digit dialled.
It is also used to send an invite to a gateway to the PSTN,
etc.

> 
> We have numerous specs covering conveyance and assertion of
identities.
> See in particular draft-rosenberg-sip-identity-privacy which talks
about
> how to properly support anonymous calling with
draft-ietf-sip-identity.

Will do and come back later on the CLI issue.

-richard

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Aug 2005 10:38:25 -0400

You make a good point, that inclusion of a number in an address does not 
equate to ownership.  Effectively, the same telephone number (an 
identifier) is potentially reachable through many addresses (i.e., many 
gateway-operating domains) if it is in the PSTN.  ENUM has chosen to add 
the concept of "ownership" to narrow down the range of possibilities ... 
and has thereby embroiled itself in politics.

> It is also used to send an invite to a gateway to the PSTN,
...

---

From: "Peter Williams" <[email-masked]>
Date: Thu, 18 Aug 2005 08:58:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom-PT Taylor
> Sent: Thursday, August 18, 2005 7:38 AM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: Re: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy
> 

Didn't Richard Stastny indicate that the sip number/domain name form is just
a source address, for application-layer relays? Only when the sip/tel URI is
in a certificate (or an authoritative DNS entry) can it be interpreted as a
ownership-grade statement - for secure routing (in the military Internet) or
wiretapping/connect-controls (in the civilian Internet).

What's the difference between the name form in sip/tel and
[email-masked], or [email-masked] in the
internet mail world (which was just a refinement on the extreme 30 year old
UUCP source routing patterns using the modems' phone numbers)?

Perhaps folks remember the weird ISO address syntaxes (that some IETF folks
used to harry and parry for the unweildiness) such as
peter%cs.ucl.ac.uk@ADMD=*;PRMD=AC;O=UCL-CS;OU=something. This was (just) the
carrier ENUM form of the routing backbone mail, with internet mapping at the
edges of the ADMD=* naming core for optional protocol translation between
the application domains.

In the mail world, such as that peter address does not indicate who the
authoritative DNS owner is, for any of the domains mentioned: its just an
application string, resolved by application resolvers. If those resolvers
have access to certified names/addresses (by whatever technology), ownership
and authority issues can also be resolved - not that this is necessary to
deliver facilitate the connect per se, or get the mail body through the
relay net.

I could have used more modern example than "old" mail - the core/edge naming
spaces of the secured class D network applications, where once again its not
the form of the address that matters for ownership/security controls. Its an
out of bound certified signal that conveys authority, for end-end security
policies; or, it's a carrier enum styled (src)-addressing architecture that
facilitates hop-by-hop security policy transfer between trusted
providers/IP-routers.

The main point of the original comment was "politics", of course. And, we
have to address the politics headon. We can no longer shroud ourselves in
the DARPA mystique: dominating technology to bring US-styled democracy to
all, through research and learning, and lots of defense spending on advanced
networks. We are no longer the nice guys! We are the instrument of public
policy.

The politics is now nasty: WE will wiretap, WE will do connect-time
interception and WE will do it in 2 years, and it WILL be 99% effective, or
YOU will be fined: and IETF members will now OVERTLY standardize the
wiretapping-capable (and trap and trace-capable) architecture, this time
around: not those "nasty carriers" working deviously in "ISO".

As the carrier-based URI architecture has worked in that (horrid, but
necessary) regulatory environment, we need to focus on what elements of the
broader standards toolkit we need to pick through: maintaining the
src-routable name/address form, separating ownership assertions from src
routing, and distinguishing DNS registration controls from the DNS data
distribution controls.
 
We can argue about names vs addressees, owernship vs name caching, for the
millionth time, and the "future" role of an authoritative DNS. But the clock
is ticking on the 2 year window. The Carrier ENUM folks WILL deploy a secure
naming core (they have no choice under the regulation regime), and the SIP
proxy operators WILL be constrained to use it (or a naming core with
equivalent effect) - so as to enforce the public policy on end-end
connect-time controls. 

Yes politics is here, in the form of wiretapping regulations on voip
connects and sip address registration/management. All that's really changed
is now the policy OVERTLY impacts the contents of the public IETF standards.
Its no longer a matter for "classified supplements".
 
We might aswell get used to the public policy issues, now forced into the
IETF technology politics.