I support the desire to standardize ENUM provisioning interfaces between Tier 2 to Tier 1, and would like specifications around this to share with the CC1 ENUM LLC. The RFP that they will be developing for the Tier 1 registry should be based on a common interface to the extent possible. Some of this is documented in the US ENUM Forum requirements, but identifying a wider standardization than US/North America in preferred. _ _ Robert W Schafer, MCI Network Architecture & Standards 2400 N Glenville Dr,Richardson,TX 75082/Ofc +1972 7296125 This message is privileged, confidential and not for public use. If received in error, please delete it. _ _ Adrian Georgescu wrote:

Hello Bernie,

1. There is interest in EPP provisioning from Tier 2 to Tier1. So far there are at least 3 implementations I know of (AU, PL and CH) and standardizing such interfaces is a very good thing

2. It would have been very useful if you would have come to the ENUM Plugtest held by ETSI last week

I will look at your implementation and hopeful we can build a client to test with your implementation. The lack of feedback is caused mostly by the slow speed of ENUM adoption in the regulatory area. Your work is definitely not in vain, you are yet another early bird with a wonderful ENUM system that WORKS !

Adrian

On Jun 6, 2005, at 4:54 PM, Bernie Hoeneisen wrote:

...

Hi!

As some of you know, in the IETF, there is some work on-going concerning ENUM and validation of E.164 numbers. At the IETF-62 in Minneapolis. the draft referred below has been approved as a Working Group item of the IETF ENUM WG:

Abstract

This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names.

URLs

* http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.txt * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.html

In Switzerland we are running an EPP Server including this extension for the ENUM Tier-1 Registry. So far we did not run into any trouble.

I am about to write an update of this draft. So far I have not received any feedback. Does this mean, that everything in there is just fine or that people are not interested / have not read it at all? ;-)

Besides the technical and other feedback, I'd be interested: - Who is planning to use this EPP extension for ENUM? - Who cannot use this extensions and what are the reasons?

Looking forward for lots of comments!

cheers, Bernie Hoeneisen, Switch, Project Manager ENUM

Hi Edward! On Mon, 6 Jun 2005, Edward Lewis wrote:

...

* http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.txt

1) In 4.5.1 and 4.5.2, you refer to "The Registry". By this I assume you mean the server-side organization of the EPP connection and not IANA.

Yes, with Registry I always mean the EPP Server side and not IANA. Maybe I should think about an additional definitions section or refer the the definitions in the enum.at draft.

2) s/The validation process shall ensure,/The validation process shall ensure/ (The "dreaded extraneous comma.")

Yep! Will be corrected in the next version. Thanks for your feedback! cheers, Bernie

Hi Andrzej, Concerning your question, there has been a presentation at the IETF-62: http://ietf.hoeneisen.ch/ietf62-enum-validation_v02.pdf On Page 6 of this presentation, I have depicted the framework on high level. The Switch I/D proposes a framework including one simple example for the policy dependent part, enum.at proposes a more advanced solution for the policy dependent part. cheers, Bernie On Tue, 7 Jun 2005, Andrzej Bartosiewicz wrote:

Bernie, Alexander,

I'm really interested how similar/different are Switch and ENUM.AT (draft-mayrhofer-enum-validation-01) solutions...

Could you guys enumerate the major differences and similarities between your implementations (Internet-Drafts)?

Andrzej

On Mon, 6 Jun 2005, Bernie Hoeneisen wrote:

...

Hi!

As some of you know, in the IETF, there is some work on-going concerning ENUM and validation of E.164 numbers. At the IETF-62 in Minneapolis. the draft referred below has been approved as a Working Group item of the IETF ENUM WG:

Abstract

This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names.

URLs

* http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.txt * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.html

In Switzerland we are running an EPP Server including this extension for the ENUM Tier-1 Registry. So far we did not run into any trouble.

I am about to write an update of this draft. So far I have not received any feedback. Does this mean, that everything in there is just fine or that people are not interested / have not read it at all? ;-)

Besides the technical and other feedback, I'd be interested: - Who is planning to use this EPP extension for ENUM? - Who cannot use this extensions and what are the reasons?

Looking forward for lots of comments!

cheers, Bernie Hoeneisen, Switch, Project Manager ENUM

Andrzej Bartosiewicz wrote:

Bernie, Alexander,

I'm really interested how similar/different are Switch and ENUM.AT (draft-mayrhofer-enum-validation-01) solutions...

Could you guys enumerate the major differences and similarities between your implementations (Internet-Drafts)?

Hi Andrzej and all, first of all, i would like to make sure that we (SWITCH / enum.at) are not competing in terms of validation standards - we are of course talking to each other, and have been working together on the drafts as well. Our intention is to provide a validation infrastructure on which the industry can agree on - my vision is that a registrar working with a registry in at least the EU does not have to take a steep learning curve for each new registry he's talking to. The two drafts cover´quite different parts of the validation "business" (Bernie, i'd like you to correct me if there'S anything wrong with my description): - draft-hoeneisen-enum-validation-epp-01 covers how to embed validation information as an extension in EPP. Additionally, it covers a few validation related fields, which are transported in the extension. The extension itself allows extending the validation related data to additional fields (see Section 4.4) - draft-mayrhofer-enum-validation-00 covers general validation architecture (which might be out of scope for an IETF draft, please comment), and provides a so called "validation token" - an (optionally cryptographically signed) XML document which is used to transport validation related information beyond that specified in bernie's draft. Any feedback on this draft is very much appreciated since i'm going to provide an update of this document for the upcoming IETF. So, those 2 drafts don't contradict each other - they can easily be used together for eg. transporting a validation token via EPP. Once again, i'd appreciate any comments on this - we've been using the validation token in ENUM procudtion enviroments since about half a year, and didn't experience any architectural problems. We are going to adapt the data scheme a bit, eg. we're going to add a "credential" section, where the registrar can provide eg. a passwort, a client certificate fingerprint, IMSI, etc. which the subscriber can in turn use to identify himself upon revalidation. hope that helps cheers Alex Mayrhofer enum.at