Subject: [Enum] How to correctly set up the request URI?

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Jun 2006 15:06:07 +0200

Folks,

Question for clarification:

In the discussions here on how to populate sip URI in Infrastructure 
ENUM to derive the Call Routing data for SPEERMINT  two
lines of thought exist:

The Enumservice SIP in Infrastructure ENUM should contain 
1. the address-of-record of the user: e.g. sip:[email-masked]
2. the ingress point into the provider network:
e.g. sip:[email-masked]

The originating UAC has in this case set the To: field to 
tel:+4319793321 and the Request-URI to e.g. 
sip:+4319793321provA.net;user=phone. This caused the
ENUM query at the proxy of provider A

The question is how the proxy of provider A is now
setting up the request URI in cases mentioned above?

Does the UAS from provider B accept calls to sbc7411.provB.net,
or must the request URI set to the proper AoR as described in
8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM.

I would also like to draw the attention to section 3 of
RFC3761 (SIP Enumservice) explaining the usage of AoR in
ENUM.

Regards

-sta

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

---

From: "Creighton, Tom" <[email-masked]>
Date: Thu, 1 Jun 2006 10:36:19 -0400

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, June 01, 2006 09:06
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Enum] How to correctly set up the request URI?
> 
> Folks,
> 

[Tom Creighton wrote:] 
>From section 8.2.2.1 of RFC3261:	"If the Request-URI does not
identify an address that the UAS is willing to accept requests for, it
SHOULD reject the request with a 404 (Not Found) response."

As long as the UAS from provider B is "willing" to accept the request,
either should work.  Since provider B is populating Infrastructure ENUM,
one would hope that they would coordinate this data with the
configuration of their proxies.

Besides, how do you actually know that sbc4441.provB.net is actually a
hostname and isn't a subdomain?

In either case, after the provider A proxy performs an ENUM query and
rewrites the request URI, it should behave as a UAC and follow the
procedures outlined in Section 4 of RFC3263 to determine the IP address,
port, and transport protocol for the provider B UAS.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Jun 2006 17:30:19 +0200

Thank you, Tom

> port, and transport protocol for the provider B UAS.

If I have to do this according to RFC3263 anyway, why put
the sbc4711.provB.net into ENUM in the first place?

-sta

> From: Creighton, Tom [mailto:[email-masked]]
> Sent: Thursday, June 01, 2006 4:36 PM
> To: Stastny Richard; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Enum] How to correctly set up the request URI?
> 
> 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Jun 2006 19:12:44 +0200

I see,
 
but how do you solve this problem if the users can also be reached by AoRs direct?
 
-sta

________________________________

Von: Creighton, Tom [mailto:[email-masked]]
Gesendet: Do 01.06.2006 17:57
An: Stastny Richard; [email-masked]
Cc: [email-masked]
Betreff: RE: [Enum] How to correctly set up the request URI?

Maybe the service provider has some sort of segregated network
(physically or logically) and wants/needs to associate each its
subscribers with a particular network segment.  If the provider went
with the flat model of provB.net, each of its proxies would have to
accept requests destined to all of its customers and would then have to
route the request to the appropriate region or division of its network.
If the provider went with the hierarchical approach of
sbc4711.provB.net, all of the requests would already be routed to the
appropriate ingress point.  This could very well save a service provider
a lot of money in route proxy equipment although might cost more on the
provisioning side.

That is my guess.

> Sent: Thursday, June 01, 2006 11:30
> To: Creighton, Tom; [email-masked]
> Cc: [email-masked]

---

From: "Creighton, Tom" <[email-masked]>
Date: Thu, 1 Jun 2006 13:45:40 -0400

Agreed, in this case the proxy associated with provB.net would be an
intermediate device that would have to perform some sort of internal
lookup in order to route the request to the next hop. 

> From: Lee, Yiu
> Sent: Thursday, June 01, 2006 13:34
> To: Stastny Richard; Creighton, Tom; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
request
> URI?
> 
> In this case, I guess when the originating proxy resolves the domain
part
> of the AOR (sip:[email-masked]), it will return the IP address
of
> the root domain "provB.net" which may be a redirect proxy. So
"provB.net"
> has two choices:
> 
> (1) It accesses its local routing table and sends a 305 to the
originating
> proxy with "sbc4711.provB.net" in the contact header.
> 
> (2) It replaces the domain part in the r-uri to more specific like
> "proxy.austria.provB.net" and forward the message to the next-hop.
> 
> Either case, the assumption is provB.net will have a way to find out
where
> the home proxy of user +4319793321.
> 
> This is only my guess.
> 
> Sent: Thursday, June 01, 2006 1:13 PM
> Subject: [Speermint] Re: [Enum] How to correctly set up the request
URI?
> 
> I see,
> 
> but how do you solve this problem if the users can also be reached by
AoRs
> direct?
(physically
> or logically) and wants/needs to associate each its subscribers with a
> particular network segment.  If the provider went with the flat model
of
> provB.net, each of its proxies would have to accept requests destined
to
> all of its customers and would then have to route the request to the
> appropriate region or division of its network.
sbc4711.provB.net,
> all of the requests would already be routed to the appropriate ingress
> point.  This could very well save a service provider a lot of money in
> route proxy equipment although might cost more on the provisioning
side.
> > If I have to do this according to RFC3263 anyway, why put the
> > sbc4711.provB.net into ENUM in the first place?
> >
> > -sta
> >
> >
> > > > ENUM to derive the Call Routing data for SPEERMINT  two lines of
> > > > thought exist:
> > > >
> > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the
> > > > address-of-record of the user: e.g.
> sip:[email-masked]
> > > > sip:+4319793321provA.net;user=phone. This caused the ENUM query
at
> > > > the proxy of provider A
> > > >
> > > > The question is how the proxy of provider A is now setting up
the
> > > > request URI in cases mentioned above?
> > > >
or
> > > > must the request URI set to the proper AoR as described in
> > > identify an address that the UAS is willing to accept requests
for,
> it
> > > Besides, how do you actually know that sbc4441.provB.net is
actually
> a
> > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM.
> > > >
> > > > Regards
> > > >
> > > > -sta
> > > >
> > > >
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Jun 2006 20:06:48 +0200

so basically the IMS I-CSCF -  HSS - S-CSCF way?
 
Richard

Von: Creighton, Tom [mailto:[email-masked]]
Gesendet: Do 01.06.2006 19:45
An: Lee, Yiu; Stastny Richard; [email-masked]
Cc: [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

request
part
of
"provB.net"
originating
where
URI?
AoRs
(physically
of
to
sbc4711.provB.net,
side.
at
the
or
for,
actually

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Jun 2006 20:43:15 +0200

Just out of curiosity:

Do I have to replace the request URI with "proxy.austria.provB.net,
or could I just leave it to "provB.net", assuming that "proxy.austria.provB.net
accepts "provB.net"?
 
-sta

Von: Lee, Yiu [mailto:[email-masked]]
Gesendet: Do 01.06.2006 19:34
An: Stastny Richard; Creighton, Tom; [email-masked]
Cc: [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

In this case, I guess when the originating proxy resolves the domain
part of the AOR (sip:[email-masked]), it will return the IP
address of the root domain "provB.net" which may be a redirect proxy. So
"provB.net" has two choices:

(1) It accesses its local routing table and sends a 305 to the
originating proxy with "sbc4711.provB.net" in the contact header.

Either case, the assumption is provB.net will have a way to find out
where the home proxy of user +4319793321.

This is only my guess.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Thursday, June 01, 2006 1:13 PM
To: Creighton, Tom; [email-masked]
Cc: [email-masked]
Subject: [Speermint] Re: [Enum] How to correctly set up the request URI?

I see,

AoRs direct?

-sta

That is my guess.

> > > sip:+4319793321provA.net;user=phone. This caused the ENUM query at

> > > the proxy of provider A
> > >
> > > The question is how the proxy of provider A is now setting up the
> > > Does the UAS from provider B accept calls to sbc7411.provB.net, or

---

From: "Creighton, Tom" <[email-masked]>
Date: Thu, 1 Jun 2006 14:50:03 -0400

Provider B could be using an internal ENUM database, an HSS-like
database, an LDAP database, or even static route table.  I was merely
using this as an example and certainly did not mean to imply or suggest
that provider B was or had to follow any particular religion. ;-)

Another way to look at it would be the case of a city government in the
U.S. that acted as its own PSTN provider and wanted to use its .us TLD
to provision its records into Infrastructure ENUM.

For example:

1. The originating UAC has the To: field set to tel:+12155551234 and the
Request-URI to sip:[email-masked];user=phone.

2. The provider A proxy performs a query to Infrastructure ENUM.

3. Infrastructure ENUM returns the following AoR:
sip:[email-masked]

In this fictitious example, the entity that manages pa.us sub-delegated
langhorne.pa.us to the Township of Langhorne which gives them full
administrative and technical control of their domain.  They in turn
provision RFC3263 compliant NAPTR and SRV records that point to their
SIP proxy.  

I am just trying to point out that it is impossible to determine the
difference between a hostname and a domain name if a provider's ingress
sip proxy is configured to accept what is provisioned on the right side
of the @ in Infrastructure ENUM.

Tom

> Sent: Thursday, June 01, 2006 14:07
> To: Creighton, Tom; Lee, Yiu; [email-masked]
> Cc: [email-masked]
request
> Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the
request
> > > > In either case, after the provider A proxy performs an ENUM
query
> > and
> > > > either should work.  Since provider B is populating
Infrastructure
> > > ENUM,
> > > > In either case, after the provider A proxy performs an ENUM
query
> > and

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 1 Jun 2006 13:34:24 -0400

This is only my guess.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 1:13 PM
To: Creighton, Tom; [email-masked]
Cc: [email-masked]
Subject: [Speermint] Re: [Enum] How to correctly set up the request URI?

I see,

-sta

That is my guess.

---

From: "Creighton, Tom" <[email-masked]>
Date: Fri, 2 Jun 2006 15:19:21 -0400

Richard:

All examples aside, I attempted to craft some words that would not set
any limitations on what can or cannot be used in the host portion of a
SIP URI while maintaining a consistent method for resolving whatever is
used in the host portion of a SIP URI.

When a SIP URI is used in Infrastructure ENUM, the procedures outlined
in RFC3263 MUST be followed for locating a UAS that will accept a
request for the given URI.  For providers assuming the role of a UAS,
this means that they MUST provision RFC3263 compliant NAPTR records and
SRV records that correspond to the host portion of the SIP URI
provisioned in Infrastructure ENUM.  For providers assuming the role of
a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST
follow the procedures outlined in Section 4 of RFC3263 to determine the
IP address, port, and transport protocol of a UAS that will accept a
request for the given URI.

Please let me know what you think.

Regards,

Tom

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 21:41:07 +0200

Tom,
 
being in favor of the usage of an AoR in Infrastructure ENUM, I have no
problems with your proposed words. There are only two issues:
 
1. There will be some people objecting, I assume.
2. Where should this words go?
-in the ENUM requirements or in the SPEERMINT requirements?
 
could the esteemed chairs of the two WGs please give their advice?
 
-sta

Von: Creighton, Tom [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 21:19
An: Stastny Richard; [email-masked]
Cc: [email-masked]
Betreff: RE: [Enum] How to correctly set up the request URI?

Richard:

Regards,

Tom

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 21:50:17 +0200

Penn,
 
I just wanted to give a similar reply:
the user part of the SIP URI should either be the E.164 phone number and an
identifier not allowing to derive any information about the identity of the
user e.g. an internal number or so.
 
Regarding this issue, we need to add a security section to
draft-ietf-enum-infrastructure anyway, so this issue should be covered
there.
 
-sta

Von: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 21:30
An: James McEachern; Lee, Yiu; Stastny Richard; Creighton, Tom; [email-masked]; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

James
I think what this means is that a provider should not provision an AoR
that would a) provide personally identifiable information beyond the
called phone number or b) allow direct access to the user's CPE.
Or are you referring to a user supplied SIP URI?

Penn

-----Original Message-----
From: James McEachern [mailto:[email-masked]]
Sent: Friday, June 02, 2006 3:12 PM
To: Lee, Yiu; Stastny Richard; Creighton, Tom; [email-masked];
[email-masked]
Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

In the past it has been suggested that if Infrastructure ENUM is openly
accessible, then for data privacy reasons it would not be acceptable to
list the user AOR.  Do we still believe this is the case, or do we now
think providing the user AOR would be acceptable?

James

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]]
Sent: Thursday, June 01, 2006 2:22 PM
To: Stastny Richard; Creighton, Tom; [email-masked]
Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

Actually, I think it is sufficient for the Enum to return the user AOR
because the routing decision should happen in the provB.net network.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Thursday, June 01, 2006 2:18 PM
To: Lee, Yiu; Creighton, Tom; [email-masked]
Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request
URI?

Ok, so I am back to my original question:

if I implement both types of public user identities:
E.164 numbers and SIP AoRs, why doing the mapping to different hosting
proxies in two places (in this case ENUM and the HSS), if I can do it
only in one place?

-sta

Von: Lee, Yiu [mailto:[email-masked]]
Gesendet: Do 01.06.2006 20:10
An: Stastny Richard; Creighton, Tom; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

Yes. IMS is using Option 2. Option 1 is also possible if the operator
decides to use just a redirect proxy.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Thursday, June 01, 2006 2:07 PM
To: Creighton, Tom; Lee, Yiu; [email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

Richard

Von: Creighton, Tom [mailto:[email-masked]]
Gesendet: Do 01.06.2006 19:45
An: Lee, Yiu; Stastny Richard; [email-masked]
Cc: [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

request
part
of
"provB.net"
originating
where
URI?
AoRs
(physically

of
to
sbc4711.provB.net,

side.

at
the
or
for,
actually

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 23:03:24 +0200

Exactly,
 
A service provider will never populate Infrastructure ENUM with a user provided URI,
(even if the user may have one), it will always be the alias used by the
service provider.
 
We should not mix this up with the discussion in SPEERMINT on user provided
AoR such as sip:[email-masked]. This will always be an alias in addition
to the AoR used by the provider.
 
Of couse the user may use this AoR in User ENUM.
 
-sta

Von: James McEachern [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 22:51
An: Creighton, Tom; Lee, Yiu; Stastny Richard; [email-masked]; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

Ok, I think I see now.  Presumably I can have a SIP URI that clearly identifies me, but this is not the AOR that would be populated in Infrastructure ENUM.  That AOR would either be based on my E.164 number, or on some other random string created by the carrier.  Have I got it right?

James

-----Original Message-----
From: Creighton, Tom [mailto:[email-masked]]
Sent: Friday, June 02, 2006 3:49 PM
To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; [email-masked]; [email-masked]
Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

I think we have two separate issues:

1. An issue of misunderstanding of the term AoR.  Section 6 of RFC3261
defines an Address-of-Record as:

"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
         that points to a domain with a location service that can map
         the URI to another URI where the user might be available.
         Typically, the location service is populated through
         registrations.  An AOR is frequently thought of as the "public
         address" of the user."

Based on that definition and the examples provided by Richard, a user's
privacy would not be compromised because it doesn't directly reach or
identify the customer.

2. There is confusion around what is or is not acceptable in the host
portion of a SIP URI.  As long as RFC3263 is followed, it shouldn't
matter what is placed in the host portion of the SIP URI as long as it
doesn't compromise a user's privacy.  So in the examples Richard
provided earlier, either are acceptable and would resolve in an
identical manner.

Tom

> Sent: Friday, June 02, 2006 15:12
request
request
request
request
request
query
Infrastructure
query

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 23:05:53 +0200

This is also my preference, but it is basically what SPEERMINT
expects to be the CRD output from Infrastructure ENUM
(so it could also be a BCP what to put into Infrastucture ENUM ;-)
 
-sta

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 22:59
An: 'Creighton, Tom'; Stastny Richard; [email-masked]
Cc: [email-masked]
Betreff: RE: [Enum] How to correctly set up the request URI?

This discussion is best kept in SPEERMINT. IMHO.

s/

your bewildered ENUM WG co-chair

> > Sent: Friday, June 02, 2006 15:41
> > Subject: Re: [Enum] How to correctly set up the request URI?
> >
> > Tom,
> >
> I welcome any comments or recommendations that anyone has to help move
> beyond this discussion.
>
> My initial reaction would be to keep it in SPEERMINT as this is a
> peering architecture issue and not a specific ENUM protocol issue, but
> as you said, advice from the 4 chairs would be appreciated.

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 3 Jun 2006 16:20:54 +0200

I think this discussion is getting a bit confused in terminology
My I try to get this back in track from my knowledge:
 
The terms Public User ID and Private User ID are from 3GPP specifications

A Public User ID is defined as an ID somebody may put on his business card:

Examples are:
a) tel:+4319793321 (a E.164 number)
b) sip:[email-masked] (an E.164 number and an address-of-record)
c) sip:[email-masked] (also an AoR)
d) sip:[email-masked]
 
All of these could be aliases linked to one Private User Identity
The private user identity is defined in 3GPP as a realm, used for registration
e.g. in the format richard.stastny @ provider.com
To be compatible with existing 2G systems, it could also be
derived from the IMSI with a predefined algorithm.
Private User Identities are our of scope in Speermint (I think)

a) cannot be user fro routing between SIP based networks, so it must be translated
to a SIP AoR. This can be done with ENUM. As we also stated here, not to disclose
and privacy, it should be in format b)
This mapping is publicly visible in Infrastructure ENUM

But this does not preclude me to put sip:[email-masked]
or sip:[email-masked] on my business card, so it will
be used outside the providers network.

The routing of sip:[email-masked] is
straightforward, for the mapping of the stastny.com part
sip:[email-masked] to provider.com an
entry (e.g. a NAPTR as Otmar described) is necessary
in the stastny.com domain to get the call proverly routed
to my network.

The mapping of the user part "richard" to "richard.stastny"
or +4319793321 takes place in the providers network
and is not visible outside

I hope this helps to clarify

-sta

Von: Tim Dwight [mailto:[email-masked]]
Gesendet: Sa 03.06.2006 15:11
An: 'Creighton, Tom'; 'James McEachern'; 'Lee, Yiu'; Stastny Richard; [email-masked]; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

What good does this globally-visible public-user-ID to private-user-ID
visible only within the serving network scheme do, if the means of
translating globally-visible public user ID to private user ID is publicly
accessible (public DNS)?  Or, are we assuming that it's not publicly
accessible, e.g., that the serving network has a split DNS and these "final
translations" are only visible within that network?

tim

> Sent: Friday, June 02, 2006 3:58 PM
> To: James McEachern; Lee, Yiu; Stastny Richard;
> [email-masked]; [email-masked]
> That is correct.  The SIP URI that clearly identifies you, as
> you described, would only be used within your provider's network.
>
> > Sent: Friday, June 02, 2006 16:52
> > To: Creighton, Tom; Lee, Yiu; Stastny Richard; [email-masked];
> > [email-masked]
> > Ok, I think I see now.  Presumably I can have a SIP URI
> that clearly
> > identifies me, but this is not the AOR that would be populated in
> > Infrastructure ENUM.  That AOR would either be based on my E.164
> number,
> > or on some other random string created by the carrier. 
> Have I got it
> > right?
> >
> > James
> >
> > > accessible, then for data privacy reasons it would not be
> acceptable
> > to
> > > > but how do you solve this problem if the users can also
> be reached
> > by
> > > AoRs
> > > > direct?
> > > >
> > > > -sta
> > > >
> > > > or logically) and wants/needs to associate each its subscribers
> with
> > a
> > >
> > > > point.  This could very well save a service provider a lot of
> money
> > in
> > >
> > > > > > rewrites the request URI, it should behave as a UAC
> and follow
> > the
> > >
> > > > > > procedures outlined in Section 4 of RFC3263 to determine the
> IP
> > > > > address,
> lines
> > > > > > > The Enumservice SIP in Infrastructure ENUM should
> contain 1.
> > the
> > >
> > > > > > As long as the UAS from provider B is "willing" to
> accept the
> > > > request,
> > > > > > rewrites the request URI, it should behave as a UAC
> and follow
> > the
> > >
> > > > > > procedures outlined in Section 4 of RFC3263 to determine the
> IP
> > > > > address,

---

From: "Creighton, Tom" <[email-masked]>
Date: Mon, 5 Jun 2006 11:15:14 -0400

Who has the authority to make that decision?  Is it the ITU, IETF, a
combination of the two, or each country that opts to participate in
Infrastructure ENUM?  I think that is the 64B question.

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Saturday, June 03, 2006 10:48
> To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee,
Yiu;
> 'Stastny Richard'; [email-masked]; [email-masked]
request
> > From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
> > Sent: Friday, June 02, 2006 4:56 PM
> > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard;
request
> > URI?
> >
> > Yes. Again, there might be exceptions, for example a business might
want
> > a URI with their name to be used and some SPs might agree to that,
but
> > generally the point of infrastructure ENUM is to be invisible to the
> > user
> >
> 
> 
> Now the 64B question is the "infrastructure" URI invisible to the
global
> DNS?

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 5 Jun 2006 18:17:22 +0200

>My  original statement about invisibility was that the end user doesn't
>need to specify/know the URI that the SP provides in infrastructure ENUM
>- or even that infrastructure ENUM even exists at all.

ok 

>The issue seems to have evolved to that of how much of the
>infrastructure ENUM tree and its products will be openly visible. This
>is a decision that many parties may have some level of input to.
>National regulators may well be able to veto public visibility if they
>so choose. 

I agree that national regulators may have some saying on what kind
of URIs should be placed in Infastructure ENUM (e.g. none that
jeopardizes the end-user privacy), but I do not see why the regulators
do not want to have the Infrastructure ENUM data not public at all.
 
I already said that a security and privacy section is missing in
draft-ietf-enum-infrastructure

The Infrastructure ENUM data is basically providing a E.164 to SPID 
mapping, and part of this is available on every regulators web-site
(the block assignment). What is not is the numbers ported out of
this blocks and this seems more to be a concern of the providers
and not of the regulators.

The problem here is that this information hiding is more to other
providers and not to the public.

But then a non public Infrastructure ENUM does not help either ;-)
 
-sta
 
>Service providers may wish to control resolution to some
>degree although making the infrastructure ENUM Tier 1 inaccessible would
>not seem to be something the IETF would want to do other things being
>equal.

Penn

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Monday, June 05, 2006 11:49 AM
To: Creighton, Tom; [email-masked]; Pfautz, Penn L, GBLAM;

want
but
global
>Infrastructure ENUM?  I think that is the 64B question

?
I am confused
Could anybody please explain to me what you are talking about
I cannot parse this thread

What is the "point of Infrastructure ENUM"?
What is an "Infrastructure URI" and why should it be invisible?
And what has this to do with an enterprise specific URI?

-sta

Von: Creighton, Tom [mailto:[email-masked]]
Gesendet: Mo 05.06.2006 17:15
An: [email-masked]; Pfautz, Penn L, GBLAM; James McEachern; Lee,
Yiu; Stastny Richard; [email-masked]; [email-masked]
Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request
URI?

Yiu;
request
request
want
but
global