Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 14 Jun 2004 07:42:32 -0400

> OK, I'll bite - we always use these terms, they're quite 
> useful, and so 
> far it's
> obvious that folk mix them up. The conflation seems to be 
> reflected in 
> EPP-E164,
> and maybe in Adrian's comment.

I'm not sure where the situation is reflected in epp-164 since there's no
mention of tiers, registrars, or registries in the document.  It talks only
about the technical aspects of provisioned data, using generic terms like
"client" and "server", leaving the policy aspects out completely.

-Scott-

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 15 Jun 2004 06:37:12 -0400

Hi Scott, folks,
  Forgive the loose comments - I really don't understand how the client 
and server
model is embodied (and where).

AFAICT, the model is:
[Client]    --EPP-E164--->    [Server] ----> [database shared with...] 
[DNS Server]

The Client could be embodied in a Registrant. They use EPP-E164 to tell 
the Server
the way they want NAPTRs populated in their delegated domain. That EPP 
Server somehow
gets the data into a form that can be used to "publish" over DNS - 
either writing to
a shared database, or using standard DNS zone update, or file transfer, 
or whatever.
[Email automaton, anyone?]

Of course, the EPP-E164 deals only with the protocol - any program to 
specify the
NAPTR content will be embedded in the Client.

For our user ENUM implementations, the model we've used so far is for 
secured access
to a Web service, so the Client becomes a pure https Browser, and the 
Server deals
with the validation/sanity checking for the NAPTRs - no human gets to 
see the NAPTR
that the web service constructs.

For iENUM, the CSP who is the Registrant for some number blocks may 
well want to
have a program to set up their multiple zone contents. They will have a 
potentially
huge number of NAPTRs to populate in different zones, and will almost 
certainly have
their own provisioning application (with its own internal formats) to 
do this.
However...

In this case why do they want EPP-E164 rather than sending the Zone 
files (or some
other format) directly to their 3rd party DNS service provider, 
assuming that they
aren't doing this themselves?

Is the goal of EPP-E164 just to specify a common format of the data to 
be sent,
along with a single application protocol to carry the data?

How is this going to help a CSP who may have to convert from their own 
internal
provisioning system formats into another to be sent over the net 
anyway? A more likely
scenario is a CSP saying to the DNS provider "this is my format in 
which you will get
the data - sort it out yourself".

I fear I'm being stupid here, but I genuinely don't understand how to 
sell this concept
to folk who WILL see it as yet another layer that (at best) benefits 
only the Server,
and need some help.

all the best,
  Lawrence
----
On 14 Jun 2004, at 12:32, Hollenbeck, Scott wrote:
OK, I'll bite - we always use these terms, they're quite
useful, and so far it's obvious that folk mix them up. The conflation 
seems to be
reflected in EPP-E164, and maybe in Adrian's comment.
I'm not sure where the situation is reflected in epp-164 since there's 
no
mention of tiers, registrars, or registries in the document.  It talks 
only
about the technical aspects of provisioned data, using generic terms 
like
"client" and "server", leaving the policy aspects out completely.
-Scott-
Note:
https://www1.ietf.org/mailman
Should we propose an EPP interface to mailman?
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum