RE: Charter last call summary

["Paul George" <pgeorge@saraf.com>]

Marcel,

In the case you describe, if the registry is also acting as the registrar
wouldn't it then still fit into the current definition?

It would be a little awkward because the registry is interacting with
itself, but if you view the one *entity* two different ways (playing two
roles) then it is still a registrar interacting between a registrant and
itself (the registry).

Maybe I am not fully understanding your concerns over the workding???

Paul George
Saraf Software Solutions

-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On
Behalf Of Marcel Schneider
Sent: Tuesday, January 09, 2001 11:50 AM
Cc: ietf-provreg@cafax.se
Subject: Re: Charter last call summary


On Tuesday, 9 Jan 2001, Edward Lewis writes:

I like the charter as it is with a minor exception: it
only speaks of registrars. Suggestion:

"...versus "front-end" support services by *entities*
who interact with registrants and with the registry,
*subsequently called 'registrars'*.

The reason is that for smart registries (those performing
policy checking and usually billing) the registrar is
more of an agent. The agent simply acts on behalf of
the registrant (the registrant could do it himself, like
when you order someone to buy a house for you: you pay
for just that service, the contract terminates afterwards),
a registrar does a job for you that may never end and
that you may not have been able to perform yourself.

In contracual law different types of contracts apply
for the two functions.


Marcel


> This is the charter I am preparing to send "upwards" real soon now.  This
> incorporates the comments I have seen on the list.
>
============================================================================

> Provisioning Registry Protocol (ProvReg)
> ------------------------------

>   CHAIR(S):
>          Edward Lewis <lewis@tislabs.com>
>          Jaap Akkerhius <jaap@sidn.nl>

>   APPLICATIONS AREA DIRECTOR(S):
>          Patrik Fältström <paf@cisco.com>
>          Ned Freed <Ned.Freed@innosoft.com>

>   AREA ADVISOR:
>          Patrik Fältström <paf@cisco.com>

>   MAILING LISTS:
>   General Discussion: ietf-provreg@cafax.se
>   To Subscribe: majordomo@cafax.se
>     In Body: subscribe ietf-provreg
>   Archive: http://www.cafax.se/ietf-provreg/maillist/

> DESCRIPTION OF WORKING GROUP:

> Administration of Domain Name Service (DNS) registration increasingly
> distinguishes between the operation of a "back-end" registry data base
> service for registrations, versus "front-end" support services by
> registrars who interact with registrants and with the registry.
Especially
> for various Top-Level Domains, the desire is to permit multiple registrars
> to share access to the data base.  Conversely, there is a desire to allow
a
> registrar to access multiple registries via the same protocol, even if the
> registries differ in operational models.

> This working group will develop a specification of the requirements and
> limitations for a protocol that enables a registrar to access multiple
> registries and will develop a  protocol that satisfies those requirements.
> The protocol will permit interaction between a registrar's own application
> and registry applications.

> The initial specification will allow multiple registrars to register and
> maintain domain names within multiple Top Level Domains (TLDs). The
> specification should be flexible enough to support the different
operational
> models of registries.  The specification should allow extension to support
> other registration data, such as address allocation and contact
information.

> The working group will use as input the "Generic Registry-Registrar
> Protocol Requirements" <draft-hollenbeck-grrp-reqs-05.txt> and the
> Extensible Provisioning Protocol presentation, documented in
> <draft-hollenbeck-epp-00.txt>.

> The group will consider support for multiple operational choices, such as
> for transport and security; it will create no new transport or security
> protocols.  The group may consider use of the new protocol for diverse
> registration and update scenarios, in order to understand limitations and
> possible extensions that are appropriate.  Specification for user
interface
> access, such as by a web front end, is beyond the scope of this working
group.

> Documentation from the working group will:

> *       Specify the objects exchanged between the registry repository and
> registrars, the relationships among the objects, and the protocol for
> exchanging objects between a registrar and the registry; at a minimum the
> objects will include:  domain name, IP address, and contact details for
> registrants

> *       Describe appropriate mechanisms for security during registrar
access

> *       List useful examples of registrar access transactions

> GOALS AND MILESTONES:
> Jan, 2001       WG charter

> Feb, 2001       Working group agreement on functional requirements for
protocol

> Apr, 2001       Initial specification of provreg protocol

> Jun, 2001       Second draft specification

> Sep, 2001       Submit draft for standards track

> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: lewis@tislabs.com

> Dilbert is an optimist.

> Opinions expressed are property of my evil twin, not my employer.