Re: Charter last call summary

[Marcel Schneider <schneider@switch.ch>]

On Tuesday, 9 Jan 2001, "Paul George" writes:

Hi Paul

>> All I try to say is that there is an entity (something)
>> btw. registrant and registry. And that this entity is
>> from now on called registrar. It does not specify any
>> specific function of this intermediate 'layer'.

> Welllll....  That's a tough concept to push when it has been accepted for a
> while now that specific roles relate to each title.  The roles as I have
> learned them are as follows:

> Registrant : "Entity" that wants to register a domain.
> Registrar  : "Entity" that requests (to a registry)
>               the registration of a domain for a registrant.
> Registry   : "Entity" that accepts and holds registrations
>              for a registrar.

> I have also been learning about another entity:

> Reseller   : "Entity" that requests domain registration through
>              a registrar for a registrant.

> Also, doing this basically says: "There are three and only three layers in
> our model."  I do not think we should limit the number of valid "layers" in
> the process, but we DO need to catagorize the functionality of the
> envisioned system in a finite number of "roles".

> In your model (and please correct me if I am wrong) it sounds like the
> "agent" layer does virtually nothing with registering a domain compared to a
> what is now commonly thought of as a registrar.  Furthermore, your registry
> is acting also as a registrar.

Right.

> This being the case, your "agent" entity COULD then fall into a "reseller"
> definition. 

Right.

> I think it all boils down to symantics.

Not only. There are legal aspects:

A registry will have a labour contract with registrants
when the registry has agents and some kind of a broker
contract with the agent. The broker will on the other
hand  have a broker contract with registrants. The
important contract is registry - registrant.

A registry will have a labour contract with registrars
and the registrars will have labour contracts with 
registrants. The important contract from the registrant's
point of view is the registrant - registrar contract.

And there is 'the understanding' aspect:

The problem I see when we only speak of registrars, that
nobody ever will understand the other system, but
- unfortunately - it is used by most ccTLD's (also
ours).

There is a tendency for Americans that they 'only' know
COM/NET/ORG - nothing against that but it is not the
only show in town :).

So I wanted to make sure that right from the beginning (the
charter) nobody will be able to nail the RRP to the
registry - registrar model only. And I really hope that
the new protocol will be able to accomodate both models.
Therefore the wording should be chosen to allow for
different models.

Let's say we define the protocol to be able to be used
by fat registries (those requiring a most complete set
of data) also. The registry - registrar model will just 
need a subset. I already can hear peoply cry why the hell
the protocol is so complicated ;-).

The two also most probably will have different financial
consequences. Will not go into that here.

>> If the registry is also acting in this intermediate function,
>> why should it use the rrp and why should we then distinguish
>> btw. front- and backend services ? It simply would be - as
>> Ed points out - be one that is not 'increasingly use' the
>> above functions ;-).

> As Peter Mott just stated in a seperate email, if that entity will forever
> and ever work in such a closed env., there is no reason to use the RRP.  But
> the protocol must allow for and work under both scenerios if it ever wants
> to be accepted as a standard.

Agree completely.

> Paul George
> Saraf Software Solutions


Marcel



> -----Original Message-----
> From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On
> Behalf Of Marcel Schneider
> Sent: Tuesday, January 09, 2001 1:39 PM
> To: Paul George
> Cc: ietf-provreg@cafax.se
> Subject: Re: Charter last call summary


> On Tuesday, 9 Jan 2001, "Paul George" writes:

> Hi Paul

>> 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???

> All I try to say is that there is an entity (something)
> btw. registrant and registry. And that this entity is
> from now on called registrar. It does not specify any
> specific function of this intermediate 'layer'.

> The reason is that we e.g. could use the word 'dummy'
> or whatever at other places (e.g. in other documents)
> for this entity, or even agent ;-). But here it is
> called registrar.

> If the registry is also acting in this intermediate function,
> why should it use the rrp and why should we then distinguish
> btw. front- and backend services ? It simply would be - as
> Ed points out - be one that is not 'increasingly use' the
> above functions ;-).


> Marcel


>> -----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.