Re: Fw: WG Review: Provisioning Registry Protocol (provreg)

[Sheer El-Showk <sheer@saraf.com>]

I like this new charter; I think it is more clear than the original and
more readable.

Aren't we too far along in the process (ie we've already submitted the
charter to  IETF for approval) to try and change the charter now?

Sheer


On Fri, 2 Feb 2001, James Seng/Personal wrote:

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