Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 09 Apr 2004 10:53:01 -0400

Michael,

Note that there is no mention of tiers in my document.  Back when I first
wrote the document the tiered functional/business model didn't really exist,
so I made a conscious decision to not make any assumptions about which role
a registry was fulfilling.

Now, though, if you're saying that the situation has evolved in such a way
that some registries will be receiving and publishing different bits of the
data needed to make enum work, thanks -- that's good info.  I can deal with
that by making the data blocks distinct, referencing the other if needed.
So what should go where, and how do the two tie together?

-Scott-

> -----Original Message-----
> From: Michael Haberler [mailto:[email-masked]] 
> Sent: Friday, April 09, 2004 10:41 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt
> 
> 
> Hi Scott,
> thanks for tackling the ENUM provisioning problem.
> A question on your updated draft:
> in 3.2.1 on the <create> command, you're saying that besides 
> the Tier1 
> delegation stuff in <create> (nameservers etc) the mandatory 
> <extension> 
> block MUST contain the NAPTR records for that domain, which 
> is a Tier2 
> business.
> Do I understand this correctly that you assume a combined tier1/tier2 
> operation including both delegation and NAPTR hosting in this draft?
> I doubt wether you can assume both operations will go through 
> the same 
> registry? So far I've been assuming this will be split in most 
> jurisdictions, which would limit applicability of your draft.
> -Michael
> At 19:15 06.04.2004, [email-masked] wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> >This draft is a work item of the Telephone Number Mapping 
> Working Group of 
> >the IETF.
> >
> >         Title           : E.164 Number Mapping for the Extensible 
> > Provisioning Protocol
> >         Author(s)       : S. Hollenbeck
> >         Filename        : draft-ietf-enum-epp-e164-03.txt
> >         Pages           : 17
> >         Date            : 2004-4-5
> >
> >This document describes an Extensible Provisioning Protocol (EPP)
> >    extension mapping for the provisioning and management of E.164
> >    numbers representing domain names stored in a shared central
> >    repository. Specified in XML, this mapping extends the EPP domain
> >    name mapping to provide additional features required for the
> >    provisioning of E.164 numbers.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-03.txt
> >
> >To remove yourself from the I-D Announcement list, send a message to
> >[email-masked] with the word unsubscribe in 
> the body of the 
> >message.
> >You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >to change your subscription settings.
> >
> >
> >Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> >"anonymous" and a password of your e-mail address. After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-enum-epp-e164-03.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         [email-masked].
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-enum-epp-e164-03.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before 
> the "FILE"
> >         command.  To decode the response(s), you will need 
> "munpack" or
> >         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which 
> have been split
> >         up into multiple messages), so check your local 
> documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >
> >Content-Type: text/plain
> >Content-ID:     <[email-masked]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-enum-epp-e164-03.txt
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-03.txt>
> 

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

---

From: Michael Haberler <[email-masked]>
Date: Fri, 09 Apr 2004 12:04:01 -0400

Scott,

my conjecture how the industry will evolve:

- Tier1 registries will just do delegations.
- Tier2 registries (competitive service providers) will host the zone for a 
customer's number and provide secondary NS.
- Tier2 will either
1. populate the NAPTR records for their customers automatically according 
to some service bundle (and a contract where the user 'opted in' to ENUM) - 
for users who dont care what ENUM ís about but like the effect
2. or they will give the user a, say, web portal, where they can manage 
their own NAPTR records - for those PhD's inclined to do so
3. or the tier2 will redelegate to a customer tier3 name server (if DNAME 
works, or directly request tier1 delegation to a tier3 name server)
4. or they will give the enduser a protocol interface to manage their NAPTR 
records which are hosted at Tier2

1) that's what we're doing with www.at43.at service; the users dont even 
get a chance to break their naptr records
2) many ENUM trials have done that, and some tier2 SP's might go that route
3) that would be typically the case for a large corporate customer with 
clue, or an IP PBX which includes a Tier3 server.
4) I could imagine this could evolve as well, for many customers its less 
painful to use a hosted service which could be driven by an automatic 
protocol - from a sip server, or an IP PBX for instance.

(btw there is a converged IP PBX out which has a Tier3 name server - 
www.innovaphone.de - you configure an extension on the PBX, and the naptr 
gets automatically added to the zone - all one needs to do is point Tier1 
delegation at this NS).

I'm unsure wether we'll actually see combined tier1/tier2 service at all.

So this points to actually two protocols, first the tier1 delegation used 
by the tier2 service provider, and potentially a second one where *the 
customer* or his management system accesses hosted records in standardized way.

Now the first one could be achieved by pretty much using standard "domain" 
EPP. On the second protocol, modifying hosted napt'rs, that would be a 
different entity, with authentication at the domain level, but likely no 
contact handles as we use them in TLD land - it's not a delegation, it's 
remote data management.

There is an experimental first cut of such a remote naptr management 
protocol, done by T-Systems in Germany. It currently only supports only a 
single tier2 operation ("setEntries"), and that is: set the list of NAPTR 
records according to a parameter array for a single Domain.
It is SOAP over TLS, userid/password authentication to access a given 
domain, pus a client transaction reference field (see 
http://www.enum-trial.de/docs/ENUM-Trial_Projekt-SOAP_ENUM-SSt_v1_0.pdf; 
unfortunately teutsch only).

My suggestion would be to take the tier1/tier2 combined operation 
assumption out of the protocol, and make the naptr-relevant data elements 
optional. On the second protocol, I'm unsure wether EPP is a potentially 
popular choice of protocol - many IP PBX's, SIP servers etc have stack 
support for Web services, but implanting EPP might be a lot of effort for a 
non-delegation problem to solve.

How do other folks see this evolve?

-Michael

Michael,

-Scott-

---

From: Richard Shockey <[email-masked]>
Date: Fri, 09 Apr 2004 13:09:01 -0400

At 11:59 AM 4/9/2004, Michael Haberler wrote:

Scott,

Well Michael this is exactly the kind of discussion I was hoping to see 
evolve here.

Which means the registration object for the Tier 1 needs the social and 
technical contact data ( name address etc) as well as the NS data for the 
delegation.

Whether or not the T1 actually uses this data in a thick registry model or 
recompiles it into some form of WHOIS or preferably IRIS infrastructure is 
a national specific issue as we all know.

As a reminder the US ENUM forum produced a document generally outlining the 
Implementation issues and the proposed structure of the tiers.

http://www.enum-forum.org

If folks have other documents from national forums that might impact 
requirements here ..please post them.

many of the national trials have similar documents outling the proposed 
structure.

- Tier2 registries (competitive service providers) will host the zone for 
a customer's number and provide secondary NS.
- Tier2 will either
1. populate the NAPTR records for their customers automatically according 
to some service bundle (and a contract where the user 'opted in' to ENUM) 
- for users who dont care what ENUM ís about but like the effect
2. or they will give the user a, say, web portal, where they can manage 
their own NAPTR records - for those PhD's inclined to do so
3. or the tier2 will redelegate to a customer tier3 name server (if DNAME 
works, or directly request tier1 delegation to a tier3 name server)

do we have to bring up the DNAME issue again :-)

4. or they will give the enduser a protocol interface to manage their 
NAPTR records which are hosted at Tier2

exactly ..

Well maybe in Liechtenstein.

Not unlike the domain name industry itself where most of the core 
principals here were developed.  For the benefit of the list BTW these are 
the PROVREG Extensiable Provisioning Protocol documents and Scott is the 
principal author of that suite.

The PROVREG WG BTW is now concluded.

Whatever protocol element we develop here will need to support multiple 
transport layers and clearly SOAP strikes me as an eventual necessity. The 
reason I say this is that the requirements of the domain name industry 
(.COM, .US , .AT ) are not necessarily the same as what some of us see as 
the requirements for the ENUM registration industry.

In the first case the number of potential players Registries - Registrars 
not to mention Registrants are exponential orders of magnitude greater we 
should not expect that the tools appropriate for one industry are 
appropriate for another.

My suggestion would be to take the tier1/tier2 combined operation 
assumption out of the protocol, and make the naptr-relevant data elements 
optional. On the second protocol, I'm unsure wether EPP is a potentially 
popular choice of protocol - many IP PBX's, SIP servers etc have stack 
support for Web services, but implanting EPP might be a lot of effort for 
a non-delegation problem to solve.

again lets not get bogged down in potential transport issues. Michael I 
totally agree with you that some of the EPP defined transports will be 
completely inappropriate for many of the possible transaction scenarios 
that will surely evolve here.

I know I'm committing IETF heresy here but we cannot exclude SOAP based 
transport for the simple reason it is a well defined corporate standard for 
query response and data transfer applications.

This is certainly the right track ..

Well one other way to look at it is to evolve some potential use cases 
which might be helpful in defining what the protocol data elements need to do.

For instance.

A. I call up a ITSP and want to buy a SIP based VoIP service.  The service 
provider in this case fulfills the function of registrar who then provides 
the T1 registry with the social- technical contact data and appropriate NS 
record for the ENUM FQDN. The ITSP then maintains the T2 on behalf of the 
customer or the customer may contract with an independent hosted DNS 
provider for T2 management. The ITSP acting as registrar would then pass on 
the T2 data to what ever entity the consumer required.

B. Company A may wish to peer its dial plan with Business Partner B it is 
not interested in public enum at all. It needs to exchange only the TN and 
T2 records to be mapped into internal tables.

C. For competitive reasons Company A sells a service to the consumer but 
needs to populate the Tier 2 held by another company or entity.

D. Company A's PBX adds modifies or deletes a user. The PBX directly sends 
the new T1 T2 data to the registrar for provisioning.

We're skipping a lot of authentication issues here but I think you 
understand the direction I'm thinking.

-Michael

Michael,

-Scott-

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Jim Reid <[email-masked]>
Date: Fri, 09 Apr 2004 13:49:01 -0400

>>>>> "Richard" == Richard Shockey <[email-masked]> writes:

    >> - Tier1 registries will just do delegations.

    Richard> Which means the registration object for the Tier 1 needs
    Richard> the social and technical contact data ( name address etc)
    Richard> as well as the NS data for the delegation.

Not necessarily. They could have a tag for the contact data: for
instance an authentication token validating that the number "belongs"
to the entity that registered it. The actual contact data could stay
with the registrar/ASP.

    Richard> Whether or not the T1 actually uses this data in a thick
    Richard> registry model or recompiles it into some form of WHOIS
    Richard> or preferably IRIS infrastructure is a national specific
    Richard> issue as we all know.

Yup. In the UK we've not bothered with whois in our trial and see no
reason to introduce a whois-like service in a commercial phase. After
all, the name that's being registered already contains contact data:
the registrant's phone number!

---

From: Richard Shockey <[email-masked]>
Date: Fri, 09 Apr 2004 13:57:01 -0400

OK the thin registry model the one that everyone has been trying to move 
away from. .. as I said before this is a national specific issue but the 
data object MUST be able to carry social data if necessary.

But what about the technical contact data. Who is the DNS manager for the 
T2 records?  I cant believe the UK is not considering a registry centric 
repository for technical contact data..this goes to issues of security and 
stability of DNS.

---

From: Michael Haberler <[email-masked]>
Date: Fri, 09 Apr 2004 14:08:02 -0400

That brings us to another interesting issue: the public phone directory and 
its relation to 'ENUM whois'.

is there any? if there's directory information and ENUM whois, what gives?

re: tag - I thought the consensus is on a thick registry (not Nominet-style?)

as ENUM-driven number ranges become more prevalent, the location of the 
authoritative social data might move to the ENUM registry. In fact we're 
looking into supplying directory records to the local directory publisher. 
A thin registry will make it hard to do that.

-Michael

ps: I disagree on the search strategy - directory lookup by phone number 
aint it; lookup by 'whois in ENUM' is valuable

---

From: Michael Haberler <[email-masked]>
Date: Fri, 09 Apr 2004 14:33:01 -0400

At 18:59 09.04.2004, Patrik Fältström wrote:

On Apr 9, 2004, at 17:59, Michael Haberler wrote:

Personally, I have never understood (== seen a good definition) of the 
various tiers, and what for example "Tier 1" should do and not. The word 
"tier" to me means a relationship between parties more than what they do.

Tier1 is a natural monopoly. Tier2 isnt. That's why I assume there will be 
competitive interest to keep Tier1 as slim as possible. I mean I could live 
with a fat Tier1... but others might not. The separation is done for the 
same reason like we did in TLD land - scaling and competition at the 
service level (this separation might include naptr management and name 
service).

Ok.

Why should the Tier2 provider provider secondary NS? If they host the 
zone, they are the ones running the primary NS which holds the SOA for the 
zone where NAPTR for the E.164 is stored. I don't see why they should also 
run secondary NS. Some other organisation might do that.

I agree with your diagram of relations and it maps closely to the model 
used by our regulator; I left out the NS provider as from the interface 
perspective regarding Scott's proposal I didnt deem it essential. Also, 
it's more of a business decision as to whom to contract what, being it user 
or Tier2.

In the Austrian trial the separate NS provider sort of dropped from the 
scene; I guess nobody considered starting a service just for that.

- Tier2 will either

Ok.

Ok

But, above you said Tier 2 should be the one which run the DNS for the 
NAPTR. Here it seems the Tier2 is the one approving the delegation and the 
"registrar" which can request the delegation at the Tier1.

You can not have both. Only one definition of the tiers.

"redelegate" clearly was the wrong term.. Tier2 might be hosting DNS, it 
might also just effect the delegation for the user directly.

my understanding is a Tier2 SP provides a service to the end user, and to 
do so signs a contract with the Tier1. That includes interaction with Tier1 
(like registrars do for TLD's); it might in many cases involve NAPTR 
hosting, which implies some nameservice - with our without secondary; it 
might also mean just 'passing through' the delegation without actually 
being in the DNS resolution chain.

In the Austrian Trial we explicitely permitted direct delegations to a 
Tier3 (customer) nameserver from Tier1 by means of a Tier2-handled 
registration (for PBXes; not for service provider number blocks).

-Michael

See attached picture. This is what I have seen at trials I have followed. 
In some cases the different roles are run by the same organisation, and in 
some (other) cases one have more than one DNS operator between the two you 
see on the picture. In any case, people mean different
things when they use the "Tier" terminology, so I would recommend either 
defining it in _great_ detail, or try to not use it.

BTW, if you have comments on the picture, please let me know.

   paf

---

From: Jim Reid <[email-masked]>
Date: Fri, 09 Apr 2004 15:10:02 -0400

>>  Not necessarily. They could have a tag for the contact data:
    >> for instance an authentication token validating that the number
    >> "belongs" to the entity that registered it. The actual contact
    >> data could stay with the registrar/ASP.

    Richard> OK the thin registry model the one that everyone has been
    Richard> trying to move away from. .. as I said before this is a
    Richard> national specific issue but the data object MUST be able
    Richard> to carry social data if necessary.

We are in violent agreement here. All I was saying was that the
registry isn't necessarily bound by legal or purely technical
constraints into holding that data. The Tier-1 doesn't *have* to hold
that data, though it probably should. It doesn't need that data to
maintain or provide DNS service for the Tier-1 zone.

    >>  Yup. In the UK we've not bothered with whois in our trial and
    >> see no reason to introduce a whois-like service in a commercial
    >> phase. After all, the name that's being registered already
    >> contains contact data: the registrant's phone number!

    Richard> But what about the technical contact data. Who is the DNS
    Richard> manager for the T2 records?  I cant believe the UK is not
    Richard> considering a registry centric repository for technical
    Richard> contact data..this goes to issues of security and
    Richard> stability of DNS.

I'm not sure that it does. Although registries maintain this contact
data, its value in stabilising the DNS is debatable. Firstly, the
contact data is often out of date or inaccurate, as a quick peek at
some random whois server will show. Even if it's correct, how often is
it actually used (and acted on) when somebody's servers go lame? Sure,
people can and do use it for that purpose, myself included. But I'm not
convinced the benefits outweigh the costs.

As for the UK Tier-1, the registry may or may not hold this data. It
depends on the registration. We have logically separated the role of
DNS provider from the T2 registrar, though in practice these may well
be combined. So if some other DNS provider is used, the registry might
only be able to give a referral to the registrar who can provide the
contact info for the DNS provider.

---

From: Jim Reid <[email-masked]>
Date: Fri, 09 Apr 2004 15:16:02 -0400

>>>>> "Michael" == Michael Haberler <[email-masked]> writes:

    Michael> re: tag - I thought the consensus is on a thick registry
    Michael> (not Nominet-style?)

Yes. All I was saying was this isn't necessarily the only game in
town. 

    Michael> ps: I disagree on the search strategy - directory lookup
    Michael> by phone number aint it; lookup by 'whois in ENUM' is
    Michael> valuable

We can agree to differ on this Michael. We should be used to that by
now. :-)

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 09 Apr 2004 15:49:05 -0400

On Apr 9, 2004, at 20:28, Michael Haberler wrote:

In the Austrian trial the separate NS provider sort of dropped from 
the scene; I guess nobody considered starting a service just for that.

I am thinking of the case where an end-user want the same organisation 
running DNS for all his domain names, regardless of if it is foo.com or 
1.2.3.4.5.e164.arpa.

That was my reason for having the NS provider separate.

edelegate" clearly was the wrong term.. Tier2 might be hosting DNS, it 
might also just effect the delegation for the user directly.

Aha! Ok.

my understanding is a Tier2 SP provides a service to the end user, and 
to do so signs a contract with the Tier1. That includes interaction 
with Tier1 (like registrars do for TLD's); it might in many cases 
involve NAPTR hosting, which implies some nameservice - with our 
without secondary; it might also mean just 'passing through' the 
delegation without actually being in the DNS resolution chain.

So, Tier-2 is from your point of view the organisation which can ask 
the tier 1 for the delegation, regardless of from where and to where 
the DNS is delegated?

That makes sense to me.

   paf

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 09 Apr 2004 18:02:00 -0400

This a view from the field.

Whois is useful to store information about zone delegation. Whois is 
not suitable to store information at subscriber level. If ENUM means 
power to the masses including self control over NAPTR records the same 
should apply for the "to be" ENUM phonebook. As mentioned, this social 
facet will shift radically with the evolution of ENUM so more control 
about address book has to move into the hands of the NAPTR owners. 
Whois allows no control from the end-user so one option could be to 
replace it with a cleverer system.

On 9 Apr 2004, at 22:00, Jim Reid wrote:

---

From: Richard Shockey <[email-masked]>
Date: Fri, 09 Apr 2004 21:24:01 -0400

At 05:25 PM 4/9/2004, Adrian Georgescu wrote:

Whois is useful to store information about zone delegation. Whois is not 
suitable to store information at subscriber level. If ENUM means power to 
the masses including self control over NAPTR records the same should apply 
for the "to be" ENUM phonebook. As mentioned, this social facet will shift 
radically with the evolution of ENUM so more control about address book 
has to move into the hands of the NAPTR owners. Whois allows no control 
from the end-user so one option could be to replace it with a cleverer system.

Thank you .. zone delegation issues are IMHO central to over all security 
and stability issues in the DNS.  Social or subscriber issues are properly 
defined by each nation state implementation. I agree that ENUM is not the 
"phone book" or "white pages" to be mined by well known spam scum etc.

Though Jim Reid does have a point on the value of such technical data being 
up to data I do suggest that if voice services are folded into the general 
class of IP applications the need to discover such data may increase.

 I would note that the IRIS work in the IETF looks at a more AA rich WHOIS 
structure that may be useful as commercial ENUM deployments as are about to 
occur in Austria.

We have had several presentation on IRIS ( aka not classic whois) at 
various IETF meetings but I would suggest that WG members take a renewed 
look at that work as it might relate to national deployments.

That said .. I hope the WG will start to focus some attention on these 
important issues since as commercial deployments are on the horizon ( GO 
AUSTRIA !!!) and we have unique opportunity to provide direction to 
implementors here.

Our charter gives us wide latitude to take on these tasks and Scott's draft 
was already a WG item. Now that PROVREG is concluded and even though Scott 
has new constraints as APPS AD I think we give his work the proper 
attention it deserves.

_______________________________________

PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 
815.333.1237

---

From: Jeff Williams <[email-masked]>
Date: Sat, 10 Apr 2004 02:11:02 -0400

Richard and all,

> data object MUST be able to carry social data if necessary.

 Why?

> repository for technical contact data..this goes to issues of security and

 This is a politically motivated issue. ICANN has effectively "hossed-up"
Whois data requirements and many countries in the EU are not going
along for very good security AND privacy reasons.  No ENUM user
should be forced/required to expose themselves to have their ENUM
number/name listed, just as most americans have the option of having
their phone number as a unlisted number...

  Social engineering in software development of any kind is a very
slippery slope...

> <http://www.neustar.biz> ; <http://www.enum.org>

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 14 Apr 2004 12:25:14 -0400