RE: WG Review: Provisioning Registry Protocol (provreg)

["Ross Wm. Rader" <ross@tucows.com>]

I too am left scratching my head.

<  -----Original Message-----
<  From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On
<  Behalf Of Paul George
<  Sent: Friday, February 02, 2001 3:38 PM
<  To: ietf-provreg@cafax.se
<  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
<
<