Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc

From: "Peter Williams" <[email-masked]>
Date: Mon, 14 Jun 2004 14:37:32 -0400

From: Adrian Georgescu <ag at ag-projects.com>
To: "Stastny Richard" <Richard.Stastny at oefeg.at>
CC: enum at ietf.org, Patrik Fältström <paf at cisco.com>
Subject: Re: AW: [Enum] Please start thinking about agenda items for 
IETFSanDiego etc
Date: Mon, 14 Jun 2004 14:46:54 +0200

Richard,
Point taken.
Probably with carrier ENUM and public ENUM having different meanings this 
naming gets even more complicated. I guess Patrick's idea to itemize roles 
instead of using words like TierX that overlap themselves is better.

So how somebody  managing NAPTR records for both public and the entreprise 
ENUM should be called?

In the X.500 world, the (orthognal) schematic descriptor for the opeartional 
entity is "DMO" or domain management organization. A DMO can administer 1 or 
more MDs - each of which is either public or private. However, any MD has 
multiple adminsitrative (and security) regions, any one of which can be 
replicated as part of another (security-level compatible) MD - providing the 
user with the illusion that one MD supports both public name spaces and 
private name spaces. To the adminsitrator, the security role and domain 
management privileges required for the right to manage entities in each 
class of name space are distinct, however, and are enforced within the 
naming architecture (i.e. tiering class hierarchy).

The fun part of this in ENUM is enforcing the sharing of distribution and 
security knowledge between the servers mastering adminsitrative regions 
(e.g. a global carrier's services in each proxy country), so they all 
correctly provide access points to a uniform discovery service, whilst 
providing per-MD security policy for users, and while conforming to the 
common security policy concerning backroom knowledge distribution within the 
provider community. In the X.500 case, the latter's protocols and 
operational practices are standardized: in ENUM they appear to be destined 
for proprietary implementation only, probably to enable the 2 main providers 
to keep control of their distribution channels, ensure fee arrangements etc 
when building out the hub and spokes, or the outsourcing business for their 
telco clients.

Its hard to decide whether to bother specifying a common public (ie. 
internet) adminsitration (and security) model for ENUM. ENUM has all the 
properties of the Directory, PKI/VPN, and EDI worlds: in which users simply 
do not seek a common internet-infrastructure - they simply wish interworking 
standards that support hub-spoke and PTT-centered outreach infrastructures. 
For the latter goals, work to standardized the proprietary management 
practice within the industry are unlikely to get much traction, judging from 
ENUM's parallels.

On Jun 14, 2004, at 12:58 PM, Stastny Richard wrote:

Adrian wrote:
Generally the Registrars are the ones hosting the zones with the
records. Technically is not mandatory of course you could outsource the
DNS management to a third-party but there is never enough money in the
chain to outsource such activity.
Adrian, you are mixing up entities and role:
BTW: in the ETSI document we speak about a Tier 1 Registry, a Tier 2
Nameserver provider and a Registrar. Note that the Registrar does
not have a Tier attached to it. I support Patrik's view that
a Registrar is really a Tier 1 function, but one could also say it
is somewhere between Tier 1 and Tier 2.
Now, as you say, the "Registrar entity" may perform both
the Registrar role and the Tier 2 Nameserver provider role,
(in case of a residential subscriber)
or eg with an enterprise, the "Registrar" may only perform
the registrat role and the enterprise is operating
the Tier 2 Nameserver on its own.
Do not mix up roles and entities.
regards
Richard
-----Original Message-----
From: Adrian Georgescu [mailto:ag at ag-projects.com]
Sent: Monday, June 14, 2004 11:23 AM
To: Patrik Fältström
Cc: 'enum at ietf.org'
Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF
SanDiego etc
On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote:
On Jun 14, 2004, at 10:12, Adrian Georgescu wrote:
Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers
(aka Registry function)
Is it the one managing the DNS zone (do the technical delegation),
Yes it adds NS records, populating Whois etc..
the one which approve the delegation,
Yes
the one which talk with the end-user (registrar), or...
Tier2 provider does the management of the records inside delegated
zones (aka Registrar function)
A registrar in the DNS sense is not managing records inside delegated
zone, but is only a front-end for the registry. I.e. a registry and
registrar in the DNS sense is working with the same level of the DNS
hierarchy and there is _no_ delegation between them.
Generally the Registrars are the ones hosting the zones with the
records. Technically is not mandatory of course you could outsource the
DNS management to a third-party but there is never enough money in the
chain to outsource such activity.
     paf
Adrian
On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote:
On Jun 11, 2004, at 22:39, Michael Haberler wrote:
do I understand this correctly that you plan to run service which
combines delegation and NAPTR hosting (= Tier1 and Tier2)?
Can we please have discussions like these without using the terms
"tier" as it is not well defined.  Talk explicitly about the
functions provided instead.
(No, the ETSI documents are not good enough.)
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Mon, 14 Jun 2004 15:09:20 -0400

>>>>> "Peter" == Peter Williams <home_pw at msn.com> writes:

    Peter> Its hard to decide whether to bother specifying a common
    Peter> public (ie.  internet) adminsitration (and security) model
    Peter> for ENUM. ENUM has all the properties of the Directory,
    Peter> PKI/VPN, and EDI worlds: in which users simply do not seek
    Peter> a common internet-infrastructure - they simply wish
    Peter> interworking standards that support hub-spoke and
    Peter> PTT-centered outreach infrastructures.  For the latter
    Peter> goals, work to standardized the proprietary management
    Peter> practice within the industry are unlikely to get much
    Peter> traction, judging from ENUM's parallels.

I must be missing something. For (user or operator or enterprise) ENUM
to fly, there has to be a single. consistent name space. That name
space can be different depending on where you look from. Many
organisations already do this with their DNS data. The technique is
called split DNS. What you see for VeryBigCompany.com depends on
whether you're on the public internet or on VeryBigCompany's net or
even on a net for one of VeryBigCompany's business partners. In each
case, there's exactly one VeryBigCompany.com name space. This may or
may not have commonality with the other instances of that name
space. The same model could be used for e164.arpa: eg a telco or
enterprise has its own e164.arpa tree for internal use only.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 15 Jun 2004 06:56:13 -0400

Jim Reid said:
> even on a net for one of VeryBigCompany's business partners.

But it's a kludge, and it won't do everything that Operator ENUM will need.

> The same model could be used for e164.arpa: eg a telco or

Why not put Operator ENUM in op.e164.arpa? Use the same layout as for
public ENUM.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Jim Reid <[email-masked]>
Date: Tue, 15 Jun 2004 07:39:43 -0400

>>>>> "Clive" == Clive D W Feather <clive at demon.net> writes:

    >> I must be missing something. For (user or operator or
    >> enterprise) ENUM to fly, there has to be a single. consistent
    >> name space. That name space can be different depending on where
    >> you look from. Many organisations already do this with their
    >> DNS data. The technique is called split DNS. What you see for
    >> VeryBigCompany.com depends on whether you're on the public
    >> internet or on VeryBigCompany's net or even on a net for one of
    >> VeryBigCompany's business partners.

    Clive> But it's a kludge, and it won't do everything that Operator
    Clive> ENUM will need.

Please elaborate. What are the things Operator ENUM will need that
can't be achieved with a private instance of e164.arpa but could be
achieved with some other domain name? Just because the domain name for
Operator and User ENUM could/should be the same IMO, it doesn't follow
that they have to use the same infrastructure or administrative models.

Yes, split DNS is a kludge. But there doesn't seem to be a better
solution IMO.

    >> enterprise has its own e164.arpa tree for internal use only.

    Clive> Why not put Operator ENUM in op.e164.arpa? Use the same
    Clive> layout as for public ENUM.

Suppose I'm a developer of some ENUM-aware VoIP application that talks
to SIP servers. I sell this to telcos, enterprises and end users. How
is the software to know which domain name to use depending on where my
customers are using it today? And might use it tomorrow, which could
be somewhere different...

---

From: Richard Shockey <[email-masked]>
Date: Tue, 15 Jun 2004 10:09:40 -0400

At 06:44 AM 6/15/2004, Clive D.W. Feather wrote:

Because carriers do not want to expose their internal routing data to the 
global internet.

The essential distinguishing feature of public vs infrastructure ENUM is 
its visibality.

If consumers or enterprises, for what ever reason OPT-OUT of e164.arpa , or 
the politics cant be fixed as in the case of +1, then we are collectively 
stuck with default PSTN routing indefinitely and that is not acceptable.

--
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 18 Jun 2004 12:50:30 -0400

Jim Reid said:
> achieved with some other domain name?

The ability to conveniently and easily have both Operator-owned and
User-owned records for the same phone number. The split DNS would be a
nightmare for this. Far better to put them into separate trees.

> Just because the domain name for

You seem to be assuming that the operators will never need to see the user
records. You are wrong.

> Yes, split DNS is a kludge. But there doesn't seem to be a better

Separate trees is a better solution.

> be somewhere different...

It's part of configuring the software, of course. You aren't going to
hardwire e164.arpa into the code, are you?

Apart from anything else, the ability to change the base of the tree will
be vital for testing purposes.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 18 Jun 2004 12:50:35 -0400

> Because carriers do not want to expose their internal routing data to the 

What's that got to do with it?

Putting it into a different tree doesn't mean they have to expose it. On
the contrary, it makes hiding the Operator ENUM data *easier*.

> The essential distinguishing feature of public vs infrastructure ENUM is 

Wrong. The essential distinguishing feature is what the data is used for.

> stuck with default PSTN routing indefinitely and that is not acceptable.

And that has nothing to do with separate trees.