Re: WG Review: Provisioning Registry Protocol (provreg)

["James Seng/Personal" <James@Seng.cc>]

Not in the charter published by the IESG.

-James Seng

----- Original Message -----
From: "Paul George" <pgeorge@saraf.com>
To: <ietf-provreg@cafax.se>
Sent: Saturday, February 03, 2001 4:38 AM
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)


> James, I don't understand.  The charter states:
>
>
>      "Subsequent versions of the specification will
>       extend the protocol to exchange other
>       information needed to organize the Internet,
>       such as IP address allocations."
>
>
> I think we are merely *starting* with DNS because of the time
constraints of
> the new TLDs, but the protocol can clearly be extended at a later time
to
> include all kinds of registration environments.  I don't see the
problem.
> (?)
>
> Paul George
> SARAF Software Solutions
>
>
>
> -----Original Message-----
> From: owner-ietf-provreg@cafax.se
[mailto:owner-ietf-provreg@cafax.se]On
> Behalf Of James Seng/Personal
> Sent: Friday, February 02, 2001 7:42 AM
> To: ietf-provreg@cafax.se
> Cc: Patrik Faltstrom
> Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
>
>
> I would like to object this proposed charter for provreg. Its scope
has
> been so specific defined for DNS only and has no mention of anything
> beyond DNS.
>
> I propose shortening the charter and balancing it slightly. If it is
out
> of line, feel free to shoot it.
>
> ---
> Registration of Domain Names Service (DNS) involves various objects
> transfer from multiple Registrars to a back-end Registry database.
> Conversely, there is a desire to standardized the process allowing
> multiple Registrars to access multiple Registries database which may
> differ in operational models. Such registration procotcol has many
> benefits which may tranverse beyond domain names objects.
>
> This working group will investigate the requirements for a
registration
> protocol of objects between two or more entities and to developed such
a
> provision protocol that satisfied these requirements.
>
> 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.
>
> The Action Item(s) for the Working Group are
>
> 1. An Informational RFC specifying the requirements of the Provision
>    Registration protocol.
>
> 2. An Informational RFC specifying the objects exchange during the
>    registration process for the Domain Name; at a minimum includes:
>    domain names, IP address and contact details for registrant.
>
> 3. A Standard RFC specifying the Provision Registration Protocol.
>    This document should have specification for domain names
>    object registration but also include extension capability for
>    non-domain names objects.
>
> Goals and Milestones:
>
> ....
>
> -James Seng
>
> --- Original Message ---
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet.
>
> The following Description was submitted, and is provided for
> informational purposes only:
>
> Provisioning Registry Protocol (provreg)
> ----------------------------------------
>
>  Current Status: Proposed Working Group
>
>
>  Mailing Lists:
>      General Discussion:ietf-provreg@cafax.se
>      To Subscribe:      ietf-provreg-request@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 database.  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-nn) and the Extensible Provisioning
> Protocol presentation, documented in (draft-hollenbeck-epp-nn).
>
> 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
>
>