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

Hi Richard,Axel, et al.,

On Tue, 7 Jun 2005, Stastny Richard wrote:

> Nevertheless there seems to be some overlap.

So far I have been in the strong believe that since -01 verison of 
draft-hoeneisen-enum-validation-epp there is no longer overlap between the 
two drafts. I have split it up into two schemas, one for extending EPP
by validation information elements and the other for the validation 
information itself (which is usually policy dependent). The latter is just 
a simple example in draft-hoeneisen-enum-validation-epp, whereas the 
solution in draft-mayrhofer-enum-validation is more advanced, and 
can use the former schema for transport with EPP.

However, I might have overseen something. May I ask you which parts you 
think are still overlapping?

> I would suggest
> that you and Bernie get together and make a proposal for
> the next IETF on the enum list:to Rich regarding the aganda
> 1. to make both documents WG items eventually one on standards track and one
> informational.
> 2. eventually to move some parts from one document to the other
> to make them consistent. This could be discussed in Paris.

I'd suggest to split up draft-mayrhofer-enum-validation into two drafts:

- One describing the general stuff about validation such as roles,
   duties, interfaces of the involved parties in the validation process.

- The other draft would specify the validation token solution of enum.at

The scope of draft-hoeneisen-enum-validation-epp would be kept limited to 
an EPP extension for adding ENUM Validation information elements / tokens.

What do you think about this, Axel?


cheers,
  Bernie

>
> Any comments, Rich?
>
> best regards
> Richard
>
> ________________________________
>
> Von: enum-wg-admin at ripe.net im Auftrag von Alexander Mayrhofer
> Gesendet: Di 07.06.2005 09:21
> An: Andrzej Bartosiewicz
> Cc: Bernie Hoeneisen; enum-wg at ripe.net
> Betreff: Re: [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
>
>
>
>