[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Paul George" <pgeorge@saraf.com>, <ietf-provreg@cafax.se>
From: "James Seng/Personal" <James@Seng.cc>
Date: Sat, 3 Feb 2001 05:08:08 +0800
Sender: owner-ietf-provreg@cafax.se
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)

Go take a look at the annoucement made by the IESG. It is obviously not
there so somehow, somewhere, someone make a mistake.

No, it is not too late to give them an update copy. In fact, there is no
such thing as too late.

-James Seng

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


> Okay, so why are there differences?  Are they looking at an older
version?
> Is there a problem with giving them the new version?  Please forgive
my
> ignorance, I thought this one was the version they were
considering.....
>
> Paul George
> SARAF Software Solutions
>
>
> -----Original Message-----
> From: James Seng/Personal [mailto:James@Seng.cc]
> Sent: Friday, February 02, 2001 3:53 PM
> To: Paul George; ietf-provreg@cafax.se
> Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
>
>
> 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
> >
> >
>
>


Home | Date list | Subject list