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

Thanks Axel for this clarification.
 
To clarify this issue, I would propose to change the filename
of your draft slightly eg by adding -arch or token
 
Nevertheless there seems to be some overlap. 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.
 
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