[enum-wg] Discuss: draft-hoeneisen-enum-validation-epp-01

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