Subject: RE: Merging RRP and Whois
From: "Brian W. Spolarich" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Wed, 31 Jan 2001 15:26:01 -0500

| That's ok. Email address is unique and has nothing to do
| with domain registration and such. Most people keep their
| email addresses as their identities.

  As someone has already pointed out, e-mail addresses do not
necessarily have the property of always binding to the same human 
(although no identifier really does).

  Dumb question:  Instead of inventing new identifiers or bending
existing ones in perhaps ungraceful ways, why not use a URL as the
identifier?  If the protocol specified LDAP as the transport protocol
then LDAP DNs would serve nicely.

  Maybe I'm misinterpreting this thread (I've only started following
this proto-WG and haven't yet digested the mail archives completely),
but it seems like there's a tendency in the IETF to invent Yet 
Another Protocol, which at this point seems unnecessary.

  If a URN resolution mechanism were to be deployed (i.e. NAPTR), 
then this seems like a good place to use URNs as well.  Apparently 
Michael Mealling thinks so too, according to RFC3043. :-)

Date: Wed, 31 Jan 2001 13:28:34 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Interim Meeting Reminder
Cc: [email-masked]
Sender: [email-masked]

I have gotten a few questions about the meeting, so I'm sending this reminder.

1) The meeting is on...
2) When/where details are below
3) The size of the room is for 50 people.  We drew 100 for the BOF in San
Diego, which I partially attribute to the overall IETF attendence. I doubt
that nearly that many folks would travel for just this one meeting.

The details...

The provreg (proto-)WG has decided to have an Interim
meeting.  The meeting will occur at the Washington Dulles
Airport Marriott, Tuesday 20 February, 10am - 5pm.  Hotel
details are here:

http://www.marriotthotels.com/dpp/PropertyPage.asp?MarshaCode=IADAP

If you would like to attend the interim meeting, look for
notices on [email-masked] or send mail to [email-masked]
and I will mail the details to you as they are available.

PS.  The charter has been send to IETF announce, meaning we are getting
considered under a wider audience.  The next IESG meeting is a week from
tomorrow, I don't expect to hear anything regarding WG status until then -
at the earliest.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: =?windows-1252?Q?=27J=F6rg_Bauer/Denic=27?= <[email-masked]>, [email-masked]
Subject: RE: Interim Meeting
Date: Wed, 31 Jan 2001 06:56:13 -0500
Sender: [email-masked]

Meeting details were sent to this list on Monday 22 January:

http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00188.html

<Scott/>

> -----Original Message-----
> From: Jörg Bauer/Denic [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2001 4:01 AM
> To: [email-masked]
> Subject: Interim Meeting
> 
> 
> 
> Are we having a interim Meeting at 20.Feb. ???
> 
> Could anybody post exact Place/Date ????

Subject: Interim Meeting
To: [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Wed, 31 Jan 2001 10:00:45 +0100
Sender: [email-masked]

Are we having a interim Meeting at 20.Feb. ???

Could anybody post exact Place/Date ????

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

Subject: Antwort: Unique "Handles"?
To: Bill Manning <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Wed, 31 Jan 2001 09:59:21 +0100
Sender: [email-masked]

On 31.01.2001 00:42 Bill Manning <[email-masked]> wrote:
>
> % > NIC handles are used by people who have nothing to do with domains.
> % ...
> %
> % That's ok. Email address is unique and has nothing to do
> % with domain registration and such. Most people keep their
> % email addresses as their identities.
> %
> % -- budi
>
>
>  Er... not really. I've had email addresses that
>  have been revolked and reassigned to new people.
>  Email addresses are not the persistant indentifer
>  you are looking for.
>
> --
> --bill

I strongly agree !!!!

>

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

From: Bill Manning <[email-masked]>
Subject: Unique "Handles"?
To: [email-masked]
Date: Tue, 30 Jan 2001 15:42:08 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

% > NIC handles are used by people who have nothing to do with domains. 
% ...
% 
% That's ok. Email address is unique and has nothing to do
% with domain registration and such. Most people keep their
% email addresses as their identities.
% 
% -- budi

	Er... not really. I've had email addresses that
	have been revolked and reassigned to new people.
	Email addresses are not the persistant indentifer 
	you are looking for. 

-- 
--bill

From: [email-masked]
To: [email-masked]
Date: Wed, 31 Jan 2001 05:19:35 +0700
Subject: Re: Merging RRP and Whois
CC: [email-masked]
Sender: [email-masked]

On 27 Jan 01, at 18:01, Shane Kerr wrote:

...
> > I'm sure this has come up in the past, but why not email addresses?
> > They're unique, and identify the source. Master information on the
> > handle is kept by whatever registry handles the TLD in question.
> 
> I can see that sending to both ietf-provreg and ietf-whois is going to
> cause some problems.  :(
> 
> NIC handles are used by people who have nothing to do with domains. 
...

That's ok. Email address is unique and has nothing to do
with domain registration and such. Most people keep their
email addresses as their identities.

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

Content-return: allowed
Date: Tue, 30 Jan 2001 15:25:31 -0500
From: "Lu, Ping" <[email-masked]>
Subject: RE: Sorry -- Re: Merging RRP and Whois
To: "'Shane Kerr'" <[email-masked]>, "Lu, Ping" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I totally agree that the external (outside the local registry) reference is
a difficult 
problem to solve.

But nontheless there is a need to use them. Because the alternative ( let
each ISPs to maintain a different set of objects for each IR ) is a manual
process and is more prone to
error.

Just like the driver license. People only register in one state then all
other states can 
reference the information even there is a risk this license may be revoked
if you don't
check frequently enough.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: [email-masked]

> -----Original Message-----
> From: Shane Kerr [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 1:17 PM
> To: Lu, Ping
> Cc: [email-masked]; [email-masked]
> Subject: RE: Sorry -- Re: Merging RRP and Whois
> 
> 
> On Tue, 30 Jan 2001, Lu, Ping wrote:
> 
> > As you mentioned the NIC-HANDLE problem is a global one.
> > 
> > There is no question that NIC-HANDLE should be unique inside each
> > Registry's database.
> > 
> > But what happen if you want to peer with other ISPs who is
> > registered all over the world ?
> > 
> > Either you REFERENCE their objects from all the RIRs (ARIN, RIPE,
> > APNIC ...) or you ask them to replicate their objects in your own
> > Registry. The former will require the NIC-HANDLE to be global
> > unique, the later will need all ISPs to maintain a seperate set of
> > objects for each IR.
> 
> Indeed it will require much more than being globally unique.  For
> instance, what happens if you have a database, PING, which a reference
> to an object, XYZ, in another database, KERR.  If someone wants to
> delete XYZ from KERR, KERR can either prevent the delete or not.
> 
> If KERR does not prevent the delete, you have a dangling 
> reference, and
> possibly no contact information for the objects in PING that refer to
> XYZ.  Suggestions have been made that PING could cache the object, and
> use the undeleted object.  However, in this case, you would 
> have either:
> 
> 1. A copy of an object, say XYZ-KERR, that is not in the KERR 
> database.
> 
> 2. A renamed copy of the object, say XYZ-PING, that XYZ did not create
>    or explicitly request the creation of.
> 
> If KERR prevents the delete, then you have authentication issues.  For
> example, if PING does not implement the same authentication that KERR
> does, then a user can create a reference to XYZ in PING and prevent an
> authenticated user from deleting the object in KERR.
> 
> In the cases where a new object is created from cache or a deletion is
> prevented, KERR needs some sort of registration mechanism to know that
> PING has a reference to the object.  (In the case of creation from
> cache, KERR needs to make sure that PING has the latest copy of the
> object before deleting it.)
> 
> I haven't touched on modification here, but it should follow the same
> general issues.  Creation will require appropriate 
> registration for any
> foreign keys used and such.  This registration and checking will of
> course slow down the modification of the databases, and also 
> add a level
> of unreliability.
> 
> In the case of objects in the RIPE database, we are extremely
> read-heavy, and write-light.  However, referring to foreign objects
> means occasionally querying other servers to get the data.  With a
> proper registration mechanism, objects can be cached locally.  I would
> prefer NOT to see a DNS-style system, where it is just assumed that
> queries provide incorrect data occasionally.  It may be the 
> best answer,
> but I think it is avoidable.
> 
> I believe that using references to other Whois databases requires a
> great deal of cooperation, at least on the protocol level.  Is it
> scalable?  I suggest that it probably is, for small numbers of Whois
> servers.  For large numbers of servers, you'll probably need some sort
> of graph - a tree perhaps? ;) - to distribute the load.  Perhaps some
> simulations should be done before moving too far along?
> 
> A bigger question is whether organizations would be willing to bind
> their databases together like this, and if so in what fashion.  I get
> very nervous considering the politics involved.  Am I the only one who
> thinks it may be an unsurmountable problem?
> 
> I've said it several times now, but this is a Hard Problem.  I have
> heard Bill Manning say that he thinks it would be worthwhile solving.
> Others (unnamed) just seem to want a global NIC-HDL, which I 
> don't think
> buys you anything unless you can use it.  I don't think you can use it
> unless you tackle the issues here.  It seems like a lot of 
> work for very
> little real gain!
> 
> Shane
> 

Date: Tue, 30 Jan 2001 15:15:37 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Mail thread clean up
Cc: [email-masked]
Sender: [email-masked]

Folks - two items of list etiquette.

Please make sure that the Subject: relates to the contents of the message.
If you want to start a tangent, a good idea is to do something of the sort:

    <new subj>, was <old subj>

Also, please limit cross posts!  Personally, I prefer to not cross post at
all. I realize that there are those who do not have a problem with
cross-posting and I'm okay with that.  But please make sure it is justified.

I am sending this because the issue of merging Provreg and whois seems to
have been settled, but there are still messages with that subject.  Worse
yet, the thread is being cross-posted and (arguably) shouldn't be.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 30 Jan 2001 19:17:12 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: "Lu, Ping" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Sorry -- Re: Merging RRP and Whois
Sender: [email-masked]

On Tue, 30 Jan 2001, Lu, Ping wrote:

> As you mentioned the NIC-HANDLE problem is a global one.
> 
> There is no question that NIC-HANDLE should be unique inside each
> Registry's database.
> 
> But what happen if you want to peer with other ISPs who is
> registered all over the world ?
> 
> Either you REFERENCE their objects from all the RIRs (ARIN, RIPE,
> APNIC ...) or you ask them to replicate their objects in your own
> Registry. The former will require the NIC-HANDLE to be global
> unique, the later will need all ISPs to maintain a seperate set of
> objects for each IR.

Indeed it will require much more than being globally unique.  For
instance, what happens if you have a database, PING, which a reference
to an object, XYZ, in another database, KERR.  If someone wants to
delete XYZ from KERR, KERR can either prevent the delete or not.

If KERR does not prevent the delete, you have a dangling reference, and
possibly no contact information for the objects in PING that refer to
XYZ.  Suggestions have been made that PING could cache the object, and
use the undeleted object.  However, in this case, you would have either:

1. A copy of an object, say XYZ-KERR, that is not in the KERR database.

2. A renamed copy of the object, say XYZ-PING, that XYZ did not create
   or explicitly request the creation of.

If KERR prevents the delete, then you have authentication issues.  For
example, if PING does not implement the same authentication that KERR
does, then a user can create a reference to XYZ in PING and prevent an
authenticated user from deleting the object in KERR.

In the cases where a new object is created from cache or a deletion is
prevented, KERR needs some sort of registration mechanism to know that
PING has a reference to the object.  (In the case of creation from
cache, KERR needs to make sure that PING has the latest copy of the
object before deleting it.)

I haven't touched on modification here, but it should follow the same
general issues.  Creation will require appropriate registration for any
foreign keys used and such.  This registration and checking will of
course slow down the modification of the databases, and also add a level
of unreliability.

In the case of objects in the RIPE database, we are extremely
read-heavy, and write-light.  However, referring to foreign objects
means occasionally querying other servers to get the data.  With a
proper registration mechanism, objects can be cached locally.  I would
prefer NOT to see a DNS-style system, where it is just assumed that
queries provide incorrect data occasionally.  It may be the best answer,
but I think it is avoidable.

I believe that using references to other Whois databases requires a
great deal of cooperation, at least on the protocol level.  Is it
scalable?  I suggest that it probably is, for small numbers of Whois
servers.  For large numbers of servers, you'll probably need some sort
of graph - a tree perhaps? ;) - to distribute the load.  Perhaps some
simulations should be done before moving too far along?

A bigger question is whether organizations would be willing to bind
their databases together like this, and if so in what fashion.  I get
very nervous considering the politics involved.  Am I the only one who
thinks it may be an unsurmountable problem?

I've said it several times now, but this is a Hard Problem.  I have
heard Bill Manning say that he thinks it would be worthwhile solving.
Others (unnamed) just seem to want a global NIC-HDL, which I don't think
buys you anything unless you can use it.  I don't think you can use it
unless you tackle the issues here.  It seems like a lot of work for very
little real gain!

Shane

Content-return: allowed
Date: Tue, 30 Jan 2001 12:35:02 -0500
From: "Lu, Ping" <[email-masked]>
Subject: RE: Sorry -- Re: Merging RRP and Whois
To: "'Sheer El-Showk'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

As you mentioned the NIC-HANDLE problem is a global one.

There is no question that NIC-HANDLE should be unique inside each Registry's
database.

But what happen if you want to peer with other ISPs who is registered all
over the world ?

Either you REFERENCE their objects from all the RIRs (ARIN, RIPE, APNIC ...)
or you ask them to replicate their objects in your own Registry.
The former will require the NIC-HANDLE to be global unique, the later will
need all ISPs to maintain a seperate set of objects for each IR.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: [email-masked]

> -----Original Message-----
> From: Sheer El-Showk [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 8:55 AM
> To: [email-masked]; [email-masked]
> Subject: Sorry -- Re: Merging RRP and Whois
> 
> 
> Hi,
> 
> Sorry about the two double postings.  I was using a 
> non-subscribed email
> address and the postings didn't go through so I reposted ... 
> I didn't know
> they'de just be delayed.
> 
> Sheer
> 
> On Sun, 28 Jan 2001, Sheer El-Showk wrote:
> 
> > > Now, having lambasted the idea of lumping whois into 
> provreg, I've a goofy
> > > idea.  Can PROVREG recommend a scalable solution to the 
> consideration of
> > > NIC-HANDLES? To my knowledge, this has never been 
> addressed properly, at 
> > > least since the days when the IR was split. When we did 
> the RA project, the
> > > thought was to tag the NIC-HANDLE with the registrars 
> "stamp", e.g.
> > > 
> > > 	WM110-NSI
> > > 	WM110-RIPE
> > > 	WM110-ARIN
> > > 
> > > but this leads, as friend Bush commented at the RIPE-37 
> mtg, to inconsistancies
> > > between registration agents. IN a nutshell, do we need 
> globally unique IDs 
> > > to the registering agents?  If so, who administers that ID space?
> > 
> > Why would we want global NIC handles?  Transfers?  
> Data-consistency?  Making 
> > life easier for the registrant?
> > 
> > None of these seem sufficiently important to merit the kind 
> of effort
> > (either bureacratic -- if its one big NIC Handle registry; 
> or technical --
> > if the registries used a shared/synced NIC Handle DB).  
> Especially because
> > registries may not want to share their NIC handles for 
> various privacy or
> > reasons.
> > 
> > That having been said, what I like about an idea like this 
> is it would
> > make it simpler to determine who is authoritative owner of 
> a domain - an
> > issue I think we should really consider since it seems to 
> be done mostly
> > by "out-of-band" methods (email's sent by the registry -- at least
> > Verisign -- to determine the domain owner) -- which I agree should 
> > be eliminated.  Still I think a focus on digitally 
> certifying a domain is
> > the right way to go, rather than centralizing user information.
> > 
> > Sheer
> > 
> > 
> 

Date: Tue, 30 Jan 2001 08:54:46 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: [email-masked], [email-masked]
Subject: Sorry -- Re: Merging RRP and Whois
Sender: [email-masked]

Hi,

Sorry about the two double postings.  I was using a non-subscribed email
address and the postings didn't go through so I reposted ... I didn't know
they'de just be delayed.

Sheer

On Sun, 28 Jan 2001, Sheer El-Showk wrote:

> > Now, having lambasted the idea of lumping whois into provreg, I've a goofy
> > idea.  Can PROVREG recommend a scalable solution to the consideration of
> > NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
> > least since the days when the IR was split. When we did the RA project, the
> > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.
> > 
> > 	WM110-NSI
> > 	WM110-RIPE
> > 	WM110-ARIN
> > 
> > but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies
> > between registration agents. IN a nutshell, do we need globally unique IDs 
> > to the registering agents?  If so, who administers that ID space?
> 
> Why would we want global NIC handles?  Transfers?  Data-consistency?  Making 
> life easier for the registrant?
> 
> None of these seem sufficiently important to merit the kind of effort
> (either bureacratic -- if its one big NIC Handle registry; or technical --
> if the registries used a shared/synced NIC Handle DB).  Especially because
> registries may not want to share their NIC handles for various privacy or
> reasons.
> 
> That having been said, what I like about an idea like this is it would
> make it simpler to determine who is authoritative owner of a domain - an
> issue I think we should really consider since it seems to be done mostly
> by "out-of-band" methods (email's sent by the registry -- at least
> Verisign -- to determine the domain owner) -- which I agree should 
> be eliminated.  Still I think a focus on digitally certifying a domain is
> the right way to go, rather than centralizing user information.
> 
> Sheer
> 
> 

Date: Mon, 29 Jan 2001 17:12:24 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: George Belotsky <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

On Mon, 29 Jan 2001, George Belotsky wrote:

> The assumption of a centralized store would be made at the 
> protocol level.  The underlying implementation could well
> be distributed.  Assuming a distributed database at the
> protocol level would complicate the client.

Not necessarily.  HTTP+HTML implements a distributed database with an
extremely simple client (until you decide to render the HTML, I
suppose) - not that it can't be done wrong (see "RWhois").

Shane

Date: Sun, 28 Jan 2001 06:49:19 +0000 (WET)
From: Sheer El-Showk <[email-masked]>
To: Bill Manning <[email-masked]>
cc: George Belotsky <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

> Now, having lambasted the idea of lumping whois into provreg, I've a goofy
> idea.  Can PROVREG recommend a scalable solution to the consideration of
> NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
> least since the days when the IR was split. When we did the RA project, the
> thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.
> 
> 	WM110-NSI
> 	WM110-RIPE
> 	WM110-ARIN
> 
> but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies
> between registration agents. IN a nutshell, do we need globally unique IDs 
> to the registering agents?  If so, who administers that ID space?

Why would we want global NIC handles?  Transfers?  Data-consistency?  Making 
life easier for the registrant?

None of these seem sufficiently important to merit the kind of effort
(either bureacratic -- if its one big NIC Handle registry; or technical --
if the registries used a shared/synced NIC Handle DB).  Especially because
registries may not want to share their NIC handles for various privacy or
reasons.

That having been said, what I like about an idea like this is it would
make it simpler to determine who is authoritative owner of a domain - an
issue I think we should really consider since it seems to be done mostly
by "out-of-band" methods (email's sent by the registry -- at least
Verisign -- to determine the domain owner) -- which I agree should 
be eliminated.  Still I think a focus on digitally certifying a domain is
the right way to go, rather than centralizing user information.

Sheer

Date: Sun, 28 Jan 2001 06:20:54 +0000 (WET)
From: Sheer El-Showk <[email-masked]>
To: [email-masked]
Subject: Re: Exentisibility in the requirements
Sender: [email-masked]

On Wed, 24 Jan 2001, George Belotsky wrote:

> Actually, it is quite clear that provreg is quite broad in capability.
> 
> This is why merging the Whois functionality into the RRP would work so
> well.  Whois will eventually need more features, while the RRP has
> methods to accomplish Whois-type queries (one does need to just look
> at the registered objects).  Both the Whois and RRP must reference the
> same objects in any case: the RRP at a very high privilege, and the
> Whois at the lowest possible privilege.

I don't think privilage level is really the relevant consideration -- as
an extensible protocol, ProReg/RRP would benefit greatly from a privilage
scheme whether or not it is used for whois.  Nor do I think the argument
about different usage types and load are relevant in considering whether
to integrate whois into the protocol we are considering.  The protocol
just defines the way we access the data ... the backend system
implementation will just have to be different for the transaction based
ProReg and the anonymous/read-only whois, but that doesn't mean they can't
share the same protocol.

I think the real reason _not_ to incorporate whois into the protocol is
the fundemental difference in the way data is accessed and stored in the
two cases (someone mentioned this point before but I havn't seen more
disucssion of it).

Whois requires a referral (possibly) to another agency, while ProReg does
not.  While this clearly diffrentiates them in terms of implementation, I
would argue that it would not be a good idea to mix them, even at the
level of a standard or protocol.  The resultant protocol would have to
support terminology for transactions and non-transactions, local and
referred lookups, anonymous and access-based privileges.  While such
extensibility would be admirable, most of these fundemental design changes
would be due to the very particular nature of whois and not benefit the
protocol in general (though I would be very interested to hear of any
other possible uses for these extentions to the basic nature of the
ProReg protocol).

To summerize I think whois is a very particular problem differing greatly
in character from the issues involved in ProvReg and I see no benefit in
mixing the two.

Sheer

> 
> 
> 
> On Wed, Jan 24, 2001 at 12:55:09PM -0500, Edward Lewis wrote:
> > With this talk about merging provreg and whois, it seems to me that some
> > folks have gotten the impression that provreg is limited to domain names.
> > Provreg is looking at domain names in the near term with an eye towards
> > other data types in the future.  That is what the charter says.
> > 
> > Perhaps the current requirements document does not reflect this.  The
> > current requirements document is focused at domain names because of the
> > near-term effort.  Perhaps the requirements need to strenghten the notion
> > that the protocol must be extensible.
> > 
> > I would enourage anyone who feels that the requirements document is too
> > domain- name-centric submit comments and words to reflect that domain names
> > are just a current focus, more work is to follow.  I don't want to bog the
> > requirements document in discussion of other data types but rather strongly
> > recognize that other data types will be considered in the future.
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Edward Lewis                                                NAI Labs
> > Phone: +1 443-259-2352                      Email: [email-masked]
> > 
> > Dilbert is an optimist.
> > 
> > Opinions expressed are property of my evil twin, not my employer.
> > 
> > 
> 
> -- 
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
> 

Date: Sat, 27 Jan 2001 18:01:56 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: Christopher Ambler <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

On Fri, 26 Jan 2001, Christopher Ambler wrote:

> > Now, having lambasted the idea of lumping whois into provreg, I've a goofy
> > idea.  Can PROVREG recommend a scalable solution to the consideration of
> > NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
> > least since the days when the IR was split. When we did the RA project, the
> > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.
> 
> I'm sure this has come up in the past, but why not email addresses?
> They're unique, and identify the source. Master information on the
> handle is kept by whatever registry handles the TLD in question.

I can see that sending to both ietf-provreg and ietf-whois is going to
cause some problems.  :(

NIC handles are used by people who have nothing to do with domains. 

I'd prefer something that ties the NIC-HDL with the database storing
information, which will not be the database storing the domain on the
e-mail address of the contact, except in domain databases.  Otherwise
either I must form some sort of relationship with a domain database
operator, or I just can't use them.

Shane
~~

Date: Sat, 27 Jan 2001 17:41:59 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: Bill Manning <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

On Fri, 26 Jan 2001, Bill Manning wrote:

> % 
> % I have envisioned the following rough sequence of events/solution as
> % minimizing the required effort (by the ProvReg group and others) while
> % maximizing the achieved benefits.  I want to make this explicit, in
> % case some of the discussion here resulted because of confusion.
> % 
> %   1. The ProvReg group designs a protocol.  This protocol allows/assumes:
> %       * A centralized object repository (registry) is assumed.
> 
> 	Why is this assumption in place?
> 	One could (rightly) argue that the single largest cause of
> 	instability and scaleability is the insistance on using 
> 	"A centralized ... repository".  The problems with that 
> 	tactic caused the original IR to segment into multiple
> 	regional IRs, each retaining/maintaining "A centralized
> 	repository". Its gotten worse with the addition of each new
> 	"routing database" & whois service by agency.  Each presumes
> 	a single "centralized repository".
> 
> 	I'd rather see a protocol to allow a composite, non authoritative
> 	structure be fabricated from collections of hundreds/thousands 
> 	of broadly distributed attributes. That way I would own my 
> 	data and be able to direct its distribution to/through others
> 	non-auth copies of my data.

Agreed.  As a simplifying assumption, a master data source is nice.  
But I can see a migration path from the current RIR (APNIC, ARIN, and
RIPE NCC) and IRR (RADB, RIPE NCC, etc.) registries to a system that
doesn't involve a centralized, or even a heirarchical, structure.  Some
centralization may end up being required (e.g. the standardized NIC
handle format you mentioned earlier), but that doesn't mean we need a
Registry/Registrar setup for all data sets.

Again, RRP evolved into a Faster, Stronger, Smarter RRP doesn't really
do anything for non-domain Whois users.

Shane

From: Bill Manning <[email-masked]>
Subject: Re: Merging RRP and Whois
To: [email-masked] (George Belotsky)
Date: Fri, 26 Jan 2001 13:18:29 -0800 (PST)
Cc: [email-masked] (Shane Kerr), [email-masked], [email-masked]
Sender: [email-masked]

% 
% I have envisioned the following rough sequence of events/solution as
% minimizing the required effort (by the ProvReg group and others) while
% maximizing the achieved benefits.  I want to make this explicit, in
% case some of the discussion here resulted because of confusion.
% 
%   1. The ProvReg group designs a protocol.  This protocol allows/assumes:
%       * A centralized object repository (registry) is assumed.

	Why is this assumption in place?
	One could (rightly) argue that the single largest cause of
	instability and scaleability is the insistance on using 
	"A centralized ... repository".  The problems with that 
	tactic caused the original IR to segment into multiple
	regional IRs, each retaining/maintaining "A centralized
	repository". Its gotten worse with the addition of each new
	"routing database" & whois service by agency.  Each presumes
	a single "centralized repository".

	I'd rather see a protocol to allow a composite, non authoritative
	structure be fabricated from collections of hundreds/thousands 
	of broadly distributed attributes. That way I would own my 
	data and be able to direct its distribution to/through others
	non-auth copies of my data.

--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: WG Review: Provisioning Registry Protocol (provreg)
Date: Mon, 29 Jan 2001 19:24:44 -0500
Sender: [email-masked]

FYI -- our WG proposal has finally hit the wires.

<Scott/> 

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: Monday, January 29, 2001 1:54 PM
To: IETF-Announce; IETF-Announce; @loki.ietf.org
Cc: [email-masked]
Subject: WG Review: Provisioning Registry Protocol (provreg)

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:[email-masked]
     To Subscribe:      [email-masked]
         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

Date: Mon, 29 Jan 2001 11:01:32 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: George Belotsky <[email-masked]>
cc: Bill Manning <[email-masked]>, Shane Kerr <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

> > %   1. The ProvReg group designs a protocol.  This protocol allows/assumes:
> > %       * A centralized object repository (registry) is assumed.
> > 
> > 	Why is this assumption in place?
> > 	One could (rightly) argue that the single largest cause of
> > 	instability and scaleability is the insistance on using 
> > 	"A centralized ... repository".  The problems with that 

Well, I wouldn't say this is necassarily true.  DNS is extremely
distributed, both in location and in authority (well ICANN on top, but
at lower levels everyone only sees the servers above them as local
authority, they don't all go straight to the root servers) and that has
not helped make it any more stable (it just means you can have that many
more sources of inaccuracy -- the authoritative domain server, a glue
record in a higher level domain, a none-updated record in a secondary
server).

As for scalability of a centralized repository ... it shouldn't be a
problem.  Centralized doens't mean one server or one network ... it means
one central authority.  They can use as many redundant, load-balancing
servers as they want -- the idea is that there is always one entity to
turn to to get authoritative information regarding a domain or other
registered object.

> > 	tactic caused the original IR to segment into multiple
> > 	regional IRs, each retaining/maintaining "A centralized
> > 	repository". Its gotten worse with the addition of each new
> > 	"routing database" & whois service by agency.  Each presumes
> > 	a single "centralized repository".
> > 
> > 	I'd rather see a protocol to allow a composite, non authoritative
> > 	structure be fabricated from collections of hundreds/thousands 
> > 	of broadly distributed attributes. That way I would own my 
> > 	data and be able to direct its distribution to/through others
> > 	non-auth copies of my data.

This sounds nice in principle, but how do you maintain data consistency,
data-uniqueness, and how do you protect against data corruption.  I'd be
genuinly interested in discussing a system that would allow the data to be
maintain its own integrity in some way and be distributed (eg just an
interesting idea: unique world-wide NIC handle with your region specific
NIC info being held in the ccTLD registries keyed to your unique
identifier with local privilage systems in place -- sounds nice but a
little complicated).

Sheer

Date: Mon, 29 Jan 2001 10:39:32 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: Shane Kerr <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

The assumption of a centralized store would be made at the 
protocol level.  The underlying implementation could well
be distributed.  Assuming a distributed database at the
protocol level would complicate the client.

On Fri, Jan 26, 2001 at 01:18:29PM -0800, Bill Manning wrote:
> % 
> % I have envisioned the following rough sequence of events/solution as
> % minimizing the required effort (by the ProvReg group and others) while
> % maximizing the achieved benefits.  I want to make this explicit, in
> % case some of the discussion here resulted because of confusion.
> % 
> %   1. The ProvReg group designs a protocol.  This protocol allows/assumes:
> %       * A centralized object repository (registry) is assumed.
> 
> 	Why is this assumption in place?
> 	One could (rightly) argue that the single largest cause of
> 	instability and scaleability is the insistance on using 
> 	"A centralized ... repository".  The problems with that 
> 	tactic caused the original IR to segment into multiple
> 	regional IRs, each retaining/maintaining "A centralized
> 	repository". Its gotten worse with the addition of each new
> 	"routing database" & whois service by agency.  Each presumes
> 	a single "centralized repository".
> 
> 	I'd rather see a protocol to allow a composite, non authoritative
> 	structure be fabricated from collections of hundreds/thousands 
> 	of broadly distributed attributes. That way I would own my 
> 	data and be able to direct its distribution to/through others
> 	non-auth copies of my data.
> 
> 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Sun, 28 Jan 2001 20:19:06 +0100
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: Unique NIC handles (was: Merging RRP and Whois)
Sender: [email-masked]

I changed the subject, because the content of this thread of the discussion
does not match anymore. Although I hate copied text from old messages, this
time it makes it easier, so here we go
>> Now, having lambasted the idea of lumping whois into provreg, I've a
>> goofy idea.  Can PROVREG recommend a scalable solution to the
>> consideration of NIC-HANDLES? To my knowledge, this has never been
>> addressed properly, at  least since the days when the IR was split. When
>> we did the RA project, the thought was to tag the NIC-HANDLE with the
>> registrars "stamp", e.g.
>> 
>> 	WM110-NSI
>> 	WM110-RIPE
>> 	WM110-ARIN
>> 
>> but this leads, as friend Bush commented at the RIPE-37 mtg, to
>> inconsistancies between registration agents. IN a nutshell, do we need
>> globally unique IDs  to the registering agents?  If so, who administers
>> that ID space?
> 
> Why would we want global NIC handles?  Transfers?  Data-consistency?
> Making  life easier for the registrant?
> 
> None of these seem sufficiently important to merit the kind of effort
> (either bureacratic -- if its one big NIC Handle registry; or technical --
> if the registries used a shared/synced NIC Handle DB).  Especially because
> registries may not want to share their NIC handles for various privacy or
> reasons.
It would make life easier for many parties involved, not only for the
registrant. Using the e-mail address as NIC handle is a simple and
effective idea, because three big problems are solved: scalability,
distributed management and the reachability of the owner.

The idea looks good, but we need to forget about it, stomp on it so it
never ever raises its head again. Here is why:

Different registries need different attributes for a person. Some need a
name and an e-mail address, others a name and a postal address, others a
name and a credit card number. Registering a NIC handles means storing and
maintaining the supperset of all possible attributes that registries
require. I would never ever agree to this. But most importantly it is plain
impossible under current data protection laws of various countries.

Urs.

Date: Sun, 28 Jan 2001 09:09:12 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois (fwd)
Sender: [email-masked]

> Now, having lambasted the idea of lumping whois into provreg, I've a goofy
> idea.  Can PROVREG recommend a scalable solution to the consideration of
> NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
> least since the days when the IR was split. When we did the RA project, the
> thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.
> 
> 	WM110-NSI
> 	WM110-RIPE
> 	WM110-ARIN
> 
> but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies
> between registration agents. IN a nutshell, do we need globally unique IDs 
> to the registering agents?  If so, who administers that ID space?

Why would we want global NIC handles?  Transfers?  Data-consistency?  Making 
life easier for the registrant?

None of these seem sufficiently important to merit the kind of effort
(either bureacratic -- if its one big NIC Handle registry; or technical --
if the registries used a shared/synced NIC Handle DB).  Especially because
registries may not want to share their NIC handles for various privacy or
reasons.

That having been said, what I like about an idea like this is it would
make it simpler to determine who is authoritative owner of a domain - an
issue I think we should really consider since it seems to be done mostly
by "out-of-band" methods (email's sent by the registry -- at least
Verisign -- to determine the domain owner) -- which I agree should 
be eliminated.  Still I think a focus on digitally certifying a domain is
the right way to go, rather than centralizing user information.

Sheer

Date: Sun, 28 Jan 2001 08:59:18 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: [email-masked]
Subject: Re: Exentisibility in the requirements (fwd)
Sender: [email-masked]

On Wed, 24 Jan 2001, George Belotsky wrote:

> Actually, it is quite clear that provreg is quite broad in capability.
> 
> This is why merging the Whois functionality into the RRP would work so
> well.  Whois will eventually need more features, while the RRP has
> methods to accomplish Whois-type queries (one does need to just look
> at the registered objects).  Both the Whois and RRP must reference the
> same objects in any case: the RRP at a very high privilege, and the
> Whois at the lowest possible privilege.

I don't think privilage level is really the relevant consideration -- as
an extensible protocol, ProReg/RRP would benefit greatly from a privilage
scheme whether or not it is used for whois.  Nor do I think the argument
about different usage types and load are relevant in considering whether
to integrate whois into the protocol we are considering.  The protocol
just defines the way we access the data ... the backend system
implementation will just have to be different for the transaction based
ProReg and the anonymous/read-only whois, but that doesn't mean they can't
share the same protocol.

I think the real reason _not_ to incorporate whois into the protocol is
the fundemental difference in the way data is accessed and stored in the
two cases (someone mentioned this point before but I havn't seen more
disucssion of it).

Whois requires a referral (possibly) to another agency, while ProReg does
not.  While this clearly diffrentiates them in terms of implementation, I
would argue that it would not be a good idea to mix them, even at the
level of a standard or protocol.  The resultant protocol would have to
support terminology for transactions and non-transactions, local and
referred lookups, anonymous and access-based privileges.  While such
extensibility would be admirable, most of these fundemental design changes
would be due to the very particular nature of whois and not benefit the
protocol in general (though I would be very interested to hear of any
other possible uses for these extentions to the basic nature of the
ProReg protocol).

To summerize I think whois is a very particular problem differing greatly
in character from the issues involved in ProvReg and I see no benefit in
mixing the two.

Sheer

> 
> 
> 
> On Wed, Jan 24, 2001 at 12:55:09PM -0500, Edward Lewis wrote:
> > With this talk about merging provreg and whois, it seems to me that some
> > folks have gotten the impression that provreg is limited to domain names.
> > Provreg is looking at domain names in the near term with an eye towards
> > other data types in the future.  That is what the charter says.
> > 
> > Perhaps the current requirements document does not reflect this.  The
> > current requirements document is focused at domain names because of the
> > near-term effort.  Perhaps the requirements need to strenghten the notion
> > that the protocol must be extensible.
> > 
> > I would enourage anyone who feels that the requirements document is too
> > domain- name-centric submit comments and words to reflect that domain names
> > are just a current focus, more work is to follow.  I don't want to bog the
> > requirements document in discussion of other data types but rather strongly
> > recognize that other data types will be considered in the future.
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Edward Lewis                                                NAI Labs
> > Phone: +1 443-259-2352                      Email: [email-masked]
> > 
> > Dilbert is an optimist.
> > 
> > Opinions expressed are property of my evil twin, not my employer.
> > 
> > 
> 
> -- 
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
> 

From: "James Seng/Personal" <[email-masked]>
To: "Bill Manning" <[email-masked]>, "George Belotsky" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois
Date: Sun, 28 Jan 2001 09:02:21 +0800
Sender: [email-masked]

While I like the idea of having a collectives of distributed repository,
ie not centralized, in some cases, a centralized repository is
unavoidable.

I think what we need is a balance of both. A centralized repository is
probably very bad for scaling but you have control. A distributed
repositories infrastructure may scale but it is slightly chaotic.

Not all system needs to be centralized. A registry/directory for email
address for example can be distributed (and should be).

-James Seng

> Why is this assumption in place?
> One could (rightly) argue that the single largest cause of
> instability and scaleability is the insistance on using
> "A centralized ... repository".  The problems with that
> tactic caused the original IR to segment into multiple
> regional IRs, each retaining/maintaining "A centralized
> repository". Its gotten worse with the addition of each new
> "routing database" & whois service by agency.  Each presumes
> a single "centralized repository".
>
> I'd rather see a protocol to allow a composite, non authoritative
> structure be fabricated from collections of hundreds/thousands
> of broadly distributed attributes. That way I would own my
> data and be able to direct its distribution to/through others
> non-auth copies of my data.

Date: Sat, 27 Jan 2001 23:32:37 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: [email-masked]
Sender: [email-masked]

At 11:29 PM -0500 1/27/01, Eric Brunner-Williams in Portland Maine wrote:
>>> Neither RRP nor Whois emerged from San Diego BoF with charters, and
>
>> That's not true.  The IESG has a copy of the charter below, and the IESG's
>> regularly scheduled bi-weekly meeting is scheduled for today...
>
>was the charter approved?

No word...I haven't see it posted to ietf-announce either (as a WG under
consideration).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Sat, 27 Jan 2001 23:29:08 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>> Neither RRP nor Whois emerged from San Diego BoF with charters, and

> That's not true.  The IESG has a copy of the charter below, and the IESG's
> regularly scheduled bi-weekly meeting is scheduled for today...

was the charter approved?

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois
Date: Fri, 26 Jan 2001 16:27:25 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

> Now, having lambasted the idea of lumping whois into provreg, I've a goofy
> idea.  Can PROVREG recommend a scalable solution to the consideration of
> NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
> least since the days when the IR was split. When we did the RA project, the
> thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.

I'm sure this has come up in the past, but why not email addresses? They're
unique, and identify the source. Master information on the handle is kept
by whatever registry handles the TLD in question.

That is, [email-masked] information is handled by NSI. [email-masked]
is handled by the registry that runs "newtld." 

Transfer of handle information can be part of the RRP. Any registry,
after authenticating, can accept changes to the handle info and pass
it (along with the authentication information) to the registry that holds
the records for that contact. This allows for email address changes,
as they do change.

It also allows for up-to-date contact information for each handle
(subject, of course, to whatever privacy protection is in place),
for messages of a technical nature (with a specifically wary eye
towards adequate protection from spam harvesting).

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]

Date: Fri, 26 Jan 2001 18:52:43 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: George Belotsky <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

On Fri, 26 Jan 2001, George Belotsky wrote:

> 1. There is not enough time to consider the Whois extensions.
> ---
> This is not an argument.

Agreed here.  If people don't have enough time, then implement now and
standardize later.  IETF is about protocol standards (well, at least
that's what I thought).

> 2. The Whois is not on my agenda.  I don't want to think about it.
> --- 

Well, to be fair, RRP is not on my agenda.  :)  

I think extending RRP to include a read-only mode may have value for
those who use it, but to me that's not the same as merging.  Change the
topic to "Include Whois functionality in RRP" and take the thread off of
the ietf-whois mailing list, I suppose....

> 3. The RRP and Whois are different from each other.
> ---
> The letters 'a' and 'b' are different from each other.  Should I make
> separate keyboards for each one?  <snip/>

I hesitate to extend a possibly bogus analogy, but...do I need a
keyboard that can input Kanji, Arabic, and Cyrillic symbols if I only
speak English?

> Before severely limiting the scope of a complex and extensible
> protocol, the consequences of such an action must be fully realized.

Sure.  But there's a reason that people use Internet protocols (SMTP,
POP/IMAP, RFC822, etc.) and not X.400 for e-mail, and a large part of it
is that X.400 was designed to solve all problems everywhere.  It has a
lot of nice things: delivery receipt, read receipt, message expiry (if
not delivered by a certain date), and so on.  But it's also a fat
bloated pig, and costs a fortune to implement.

> Everywhere, the trend is towards generic programming, polymorphic
> interfaces, and broad standards that unite large problem domains
> across many platforms.  There are strong reasons for these trends.
> The complexity of modern systems, and the speed of their development,
> make it impossible to view things in a fragmented, isolated fashion.
> Broad similarities must be exploited over minute differences to create
> flexible and adaptable solutions.

Maybe.  But we have:

  Whois: anonymous read-only access to something (possibly a database)
    RRP: authenticated read/write access to a domain database

Extending RRP to allow anonymous read-only access is probably
straightforward (said with the eternal optimism of an implmentor).  It
is not clear to me that adding authenticattion OR read/write access to
the Whois protocol make sense.  Again, stop discussing "RRP/Whois merge"
and start talking RRPng and that's fine with me.

If you were to think about extending RRP from a client/server database
to a generic distributed registration database, then I'd love to start
talking.  But the domain folks have quite reasonably decided that this
is a Hard Problem and to concentrate on making a workable business model
instead.  

Are the RRP folks really interested in making a protocol that worries
about object consistency in databases run by their competitors?  If so,
that would be cool, but I just can't imagine any responsible CTO buying
into such a scenerio.  DNS does this, because it's very narrowly
focused with incentives for everybody to carefully manage the data,
without any access concerns (it's all public), and so on.

Personally, I don't think the idea of a global Whois handle nomenclature
really buys that much.  You need to take the next step of actually
allowing foreign data into your registry.  If you're going to do that,
then you need to resolve all the sticky issues that implies.  Again, if
that's really what people want to develop, then lets get into it.  But
if it's not, then please let it die.

So does anybody want to work on that problem in the Whois and/or RRP
group?  Non-heirarchical, distributed registration database.  The topic
of distributed databases has been covered a lot in academia, and we can
steal a lot of work there.  Also, some problems (database partitioning
comes to mind) that PhD-types have spent a lot of time worrying about
can possibly be ignored.  But it's a big, scary, nasty problem.

--
Shane Kerr <[email-masked]>
Database Software Engineer
RIPE NCC
+31 20 535 4427

From: Bill Manning <[email-masked]>
Subject: Re: Merging RRP and Whois
To: [email-masked] (George Belotsky)
Date: Fri, 26 Jan 2001 09:37:03 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

% 3. The RRP and Whois are different from each other.
% ---
% The letters 'a' and 'b' are different from each other.  Should I make
% separate keyboards for each one?  Maybe a different keyboard for each
% character?  It is possible to find differences in any two things.  The
% point is, are they *sufficiently* different to warrant separating
% them.  Uniform treatment makes for a consistent view, and greatly
% reduces information overload.

	I'd say yes, they are different enough to seperate.
	Roughly the whois protcol, in all its varients & extentions is 
	basically a READ-ONLY protocol.
	Roughly, the "provreg" protocol, whatever that is, will be a
	READ/WRITE protocol. 

	One is a frontend for the "great unwashed" to learn about
	what is/can be seen (modulo appropriate credentials)
	while the other is a "back-office" protocol for syncronizing
	data between the cabals.

% The Whois functionality will have to be extended. Entities other than
% domain names will soon have to be registered, and made accessible in a
% Whois-like facility.  The RRP will take considerable effort to
% implement.

	What... again!  NSI extended SRIs whois, RIPE twisted it again
	as did the RA project. At least by that time, we had enough
	sense to move our perversity to another port. Then there is 
	the venerable rWHOIS varient. It will run on both the traditional
	port 43 as well as its own port (thank the PTB!) 

	Tweeking whois is "easy" for two reasons:  Its dirt simple
	and its there... sort of the way DNS used to be :)
	I'd rather not see this WG jump down that rathole. Been there,
	Done that, and still smell bad.

Now, having lambasted the idea of lumping whois into provreg, I've a goofy
idea.  Can PROVREG recommend a scalable solution to the consideration of
NIC-HANDLES? To my knowledge, this has never been addressed properly, at 
least since the days when the IR was split. When we did the RA project, the
thought was to tag the NIC-HANDLE with the registrars "stamp", e.g.

	WM110-NSI
	WM110-RIPE
	WM110-ARIN

but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies
between registration agents. IN a nutshell, do we need globally unique IDs 
to the registering agents?  If so, who administers that ID space?

--bill

Date: Fri, 26 Jan 2001 16:11:02 +0100 (CET)
From: Shane Kerr <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Sender: [email-masked]

On Tue, 23 Jan 2001, Eric Brunner-Williams in Portland Maine wrote:

> > Why is it that people here automatically assumed that RRP/WHOIS only
> > serves Domain Names information?
> 
> Are you suggesting that an RRP doesn't, or making a subset
> arguement? Who cares, other than extensibility-in-principle, about
> more junk than the necessary and sufficient minimum, viz dns data? I
> made the assumption as those are exactly the problems I'm trying to
> solve, if my state of mind is that interesting.

As someone who may have to actually implement a merged RRP/Whois
protocol if someone in IETF decides that RRP should consume the hoary
Whois spec, and has no interest (at all! really!!!) in Domain Name
information, I care.  

I don't envision RRP being useful for a more general purpose distributed
database (I could be wrong here), but even if it is, it really seems to
be orthogonal to Whois.  Other people have noted this already, and
they're right.  :)

--
Shane Kerr <[email-masked]>
Database Software Engineer
RIPE NCC
+31 20 535 4427

To: "James Seng/Personal" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Fri, 26 Jan 2001 08:36:22 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

Thank you for the clarification, your earlier mention of resellers had me
confused, I now understand you to mean arbitrary 3rd-parties, authentication
by arbitrary means, access modality acquisition/delegation/revocation by
arbitrary means, data not restricted to dns data, registry not restricted
to dns, with scaling properties equal to or better than those used for
routing.

Let me know if I missed anything, its quite possible.

Eric

Date: Fri, 26 Jan 2001 14:56:36 -0500
From: George Belotsky <[email-masked]>
To: Shane Kerr <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

I have envisioned the following rough sequence of events/solution as
minimizing the required effort (by the ProvReg group and others) while
maximizing the achieved benefits.  I want to make this explicit, in
case some of the discussion here resulted because of confusion.

  1. The ProvReg group designs a protocol.  This protocol allows/assumes:
      * A centralized object repository (registry) is assumed.
      * The protocol allows registries with different properties to
        be implemented.  The different registries do not have to talk
        to each other.
      * The protocol supports authentication, and grants levels of
        privilege based on the submitted credentials.  Possibilities 
        for access by registrars, registrants, unrelated third parties, etc.
        are all allowed (by the mechanism) and configurable.  The policy for 
        who is finally allowed access would be set elsewhere, and would likely
        vary from registry to registry.
      * Thought is given to future extensions -- but just enough not to cripple 
        the protocol.  This group does not spend much time on this issue, nor
        does it work on the extensions themselves.

  2. The work of the ProvReg group becomes a standard.

  3. The Whois group extends this protocol to handle Whois queries.  The old
     Whois protocol remains, but future development proceeds with the new protocol.
     This work can start even before Step 2, above.

  4. The Whois extensions become standard.

  5. The protocol is extended to objects other than domain names.  This work could 
     possibly start before Step 4, above.

The key concept here (others have proposed similar things as well) is
that the ProvReg protocol becomes the standard method that the world
uses to communicate with a registry.  Thus, we get fewer things that
need to be designed, fewer things that need to be implemented, and --
most importantly -- fewer (diverging) things that need to be
maintained.

George.

On Fri, Jan 26, 2001 at 06:52:43PM +0100, Shane Kerr wrote:
> On Fri, 26 Jan 2001, George Belotsky wrote:
> 
> > 1. There is not enough time to consider the Whois extensions.
> > ---
> > This is not an argument.
> 
> Agreed here.  If people don't have enough time, then implement now and
> standardize later.  IETF is about protocol standards (well, at least
> that's what I thought).
> 
> > 2. The Whois is not on my agenda.  I don't want to think about it.
> > --- 
> 
> Well, to be fair, RRP is not on my agenda.  :)  
> 
> I think extending RRP to include a read-only mode may have value for
> those who use it, but to me that's not the same as merging.  Change the
> topic to "Include Whois functionality in RRP" and take the thread off of
> the ietf-whois mailing list, I suppose....
> 
> > 3. The RRP and Whois are different from each other.
> > ---
> > The letters 'a' and 'b' are different from each other.  Should I make
> > separate keyboards for each one?  <snip/>
> 
> I hesitate to extend a possibly bogus analogy, but...do I need a
> keyboard that can input Kanji, Arabic, and Cyrillic symbols if I only
> speak English?
> 
> > Before severely limiting the scope of a complex and extensible
> > protocol, the consequences of such an action must be fully realized.
> 
> Sure.  But there's a reason that people use Internet protocols (SMTP,
> POP/IMAP, RFC822, etc.) and not X.400 for e-mail, and a large part of it
> is that X.400 was designed to solve all problems everywhere.  It has a
> lot of nice things: delivery receipt, read receipt, message expiry (if
> not delivered by a certain date), and so on.  But it's also a fat
> bloated pig, and costs a fortune to implement.
> 
> > Everywhere, the trend is towards generic programming, polymorphic
> > interfaces, and broad standards that unite large problem domains
> > across many platforms.  There are strong reasons for these trends.
> > The complexity of modern systems, and the speed of their development,
> > make it impossible to view things in a fragmented, isolated fashion.
> > Broad similarities must be exploited over minute differences to create
> > flexible and adaptable solutions.
> 
> Maybe.  But we have:
> 
>   Whois: anonymous read-only access to something (possibly a database)
>     RRP: authenticated read/write access to a domain database
> 
> Extending RRP to allow anonymous read-only access is probably
> straightforward (said with the eternal optimism of an implmentor).  It
> is not clear to me that adding authenticattion OR read/write access to
> the Whois protocol make sense.  Again, stop discussing "RRP/Whois merge"
> and start talking RRPng and that's fine with me.
> 
> If you were to think about extending RRP from a client/server database
> to a generic distributed registration database, then I'd love to start
> talking.  But the domain folks have quite reasonably decided that this
> is a Hard Problem and to concentrate on making a workable business model
> instead.  
> 
> Are the RRP folks really interested in making a protocol that worries
> about object consistency in databases run by their competitors?  If so,
> that would be cool, but I just can't imagine any responsible CTO buying
> into such a scenerio.  DNS does this, because it's very narrowly
> focused with incentives for everybody to carefully manage the data,
> without any access concerns (it's all public), and so on.
> 
> Personally, I don't think the idea of a global Whois handle nomenclature
> really buys that much.  You need to take the next step of actually
> allowing foreign data into your registry.  If you're going to do that,
> then you need to resolve all the sticky issues that implies.  Again, if
> that's really what people want to develop, then lets get into it.  But
> if it's not, then please let it die.
> 
> So does anybody want to work on that problem in the Whois and/or RRP
> group?  Non-heirarchical, distributed registration database.  The topic
> of distributed databases has been covered a lot in academia, and we can
> steal a lot of work there.  Also, some problems (database partitioning
> comes to mind) that PhD-types have spent a lot of time worrying about
> can possibly be ignored.  But it's a big, scary, nasty problem.
> 
> --
> Shane Kerr <[email-masked]>
> Database Software Engineer
> RIPE NCC
> +31 20 535 4427
> 
> 
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Fri, 26 Jan 2001 12:07:38 -0500
From: George Belotsky <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

At this point in the discussion, it helps to summarize some key points.

Those who objected to using the same protocol for the Whois and RRP
have basically made three types of arguments, as listed below.  The
counter-arguments are given along with each type of argument.

1. There is not enough time to consider the Whois extensions.
---
This is not an argument.  The same point can be raised in any context,
on any issue.  Having a deadline does not justify cutting corners.  If
you cut corners to meet a deadline, you have not done your job.  Once
again, the Challenger disaster is the classic example of this.
Launching something 'on time' is no achievement if everyone then has
to deal with the horrible consequences for years afterwards.

2. The Whois is not on my agenda.  I don't want to think about it.
--- 
Protocol design is one of the most difficult tasks in our field of
endeavor -- it requires a lot of thought.  The more inclusive a
protocol is, the more value it has.  In general, a limited protocol is
not worth implementing unless it is very simple.  It is clear that he
RRP has to be a complex protocol.  Thus, every effort should be made
to leverage it as much as possible in sufficiently analogous situations.

3. The RRP and Whois are different from each other.
---
The letters 'a' and 'b' are different from each other.  Should I make
separate keyboards for each one?  Maybe a different keyboard for each
character?  It is possible to find differences in any two things.  The
point is, are they *sufficiently* different to warrant separating
them.  Uniform treatment makes for a consistent view, and greatly
reduces information overload.

Before severely limiting the scope of a complex and extensible
protocol, the consequences of such an action must be fully realized.

The Whois functionality will have to be extended. Entities other than
domain names will soon have to be registered, and made accessible in a
Whois-like facility.  The RRP will take considerable effort to
implement.

It is not necessary to decide every single detail now.  The exact form that
the Whois extensions will take, whether the new service will continue
running on port 43, etc. can be taken up by the Whois group in due
course.  

To squander the effort required to adopt the RRP -- by ignoring the
coming needs to extend the Whois and to register other entities --
would be an unforgivable mistake.

Everywhere, the trend is towards generic programming, polymorphic
interfaces, and broad standards that unite large problem domains
across many platforms.  There are strong reasons for these trends.
The complexity of modern systems, and the speed of their development,
make it impossible to view things in a fragmented, isolated fashion.
Broad similarities must be exploited over minute differences to create
flexible and adaptable solutions.

Let us not lose the rare opportunity to create a lasting, growing
protocol for working with registered objects on the Internet.  The
problems we disregard today will not disappear tomorrow.  If we are
thus forced to confront them in the near future, the deadlines will
press harder, the work will be considerably larger in scope, and the
mistakes of the past will make a heavy burden.  The most likely result
-- obsolescence of the RRP -- would be a benefit to no-one.

George.

-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Fri, 26 Jan 2001 15:11:14 +0800
Sender: [email-masked]

Eric,

> you appear to be observing is that "resellers" aren't contained in
> the "registrant-registrar-registry"-tuple, and concluding that the
> provisioning protocol, whatever one calls it, must provide access to
> 3rd-parties, regardless of the modality of the operation (anonymous
> read vs write, etc.)

No, I am talking about 3rd parties. They are not reseller, agents
whatever. I am talking about people who has interest in the object
registered (any level, from registry down to the registrant) to Internet
user at large who has no authentication access to objects.

Let me remind you that I do not see ProReg only for DNS uses only. I
have a design in mind which covers beyond the current what you see in
the current players DNS space.

> What exactly do you suggest?
> - transparent to registry, registrar delegates registrar
>   access to reseller?
> - opaque to registry, ditto?
> - transparent to registrar, registry extends registrar
>   access to reseller?
> - opaque to registrar, ditto?
> - anonymous access promoted to non-anonymous access at (pick
>   any of r, r, r, r) discretion?
> - registrant acquisition of registrar access upon demand
> - other? (specify, please)

These are all related to policies, depending on what kind you referring,
they have different answer. Some people who may use ProReg are thick,
some are thin. Some allows only their resellers to access, some allows
anonymous access. Some requires audit trail, some does not permit any
logging.

What I am suggesting is a requirement for the protocol which can handle
any policy, in whatever configuration for whatever policy set. This is
what I mean by 'not embedding any policy into protocol'.

> In the above, where the 4th "r" is "reseller", the authentication
> problem is not sufficiently degraded to bother with, however if the
> 4th "r" is "jay-random-other" then, ignoring the utility, necessity
> and sufficiency issues which seem to get the values of "some", "don't
> know" and "don't know", respectively, the authentication mechanism
> needs to scale to ... your figure was one billion endpoints.

And your problem is...scale? Welcome to IETF.

> Why exactly does the provisioning protocol need to have better scaling
> properties than several historic, and current network routing
protocols?

Because it will grow! If it cant grow, then it will get hack to grow in
future which what some say 'kludge'.

> Is the protocol stateful, in your mind, and if so, where is the state
> held?

In design I am still drafting, yes. And it is held at both end. But I do
not see that enforce as an requirement.

> What exactly does a registry look like which authenticates, services
and
> journals provisioning operations originating from a billion endpoints
in
> some service interval?

A service whereby they can/may authenticate billion of users in some
distributed directory lookup mechansim. (Note, I am *not* suggesting it
must/should be DNS).

> Maybe if you offered a "NATS are Evil(tm)" line of proof for the
> non-necessity, or worse, of registrars. Seriously, what prevents a
> dns registry and registrant from direct key exchange?

Great. So what why not? :-)

> Charter TLDs may require direct registry-registrant communication, how
> does this become a requirement on the provisioning protocol? Where
> is the communication predicated upon the provisioning protocol for
> e2e transport? For e2e anything?

In the DNS space, there are a lot of Charter TLDs. Beyond the DNS space,
there are more. Not every registry in the world is "open", pay "$6 per
registration and you get one". I am currently at Amsterdam and a couple
of European Registries did mention the lack of support of
charter/policied TLDs in the current RRP spec.

Hence, I do see a requirement for some sort of answer to Charter TLD
need.

-James Seng

To: "James Seng/Personal" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Thu, 25 Jan 2001 20:58:28 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

you appear to be observing is that "resellers" aren't contained in
the "registrant-registrar-registry"-tuple, and concluding that the
provisioning protocol, whatever one calls it, must provide access to
3rd-parties, regardless of the modality of the operation (anonymous
read vs write, etc.)

What exactly do you suggest?
	- transparent to registry, registrar delegates registrar
	  access to reseller?
	- opaque to registry, ditto?
	- transparent to registrar, registry extends registrar
	  access to reseller?
	- opaque to registrar, ditto?
	- anonymous access promoted to non-anonymous access at (pick
	  any of r, r, r, r) discretion?
	- registrant acquisition of registrar access upon demand
	- other? (specify, please)

In the above, where the 4th "r" is "reseller", the authentication
problem is not sufficiently degraded to bother with, however if the
4th "r" is "jay-random-other" then, ignoring the utility, necessity
and sufficiency issues which seem to get the values of "some", "don't
know" and "don't know", respectively, the authentication mechanism
needs to scale to ... your figure was one billion endpoints.

Why exactly does the provisioning protocol need to have better scaling
properties than several historic, and current network routing protocols?

Is the protocol stateful, in your mind, and if so, where is the state
held?

What exactly does a registry look like which authenticates, services and
journals provisioning operations originating from a billion endpoints in
some service interval?

This is a lot of headache for something of little utility, which was
my original comment to Patrik. I'm sure you've proved the converse,
I just don't see how.

> On allowing 3rd party to access the RRP servers,
> a) DNSSEC. Keys needs to be exchanged directly with the Registry.
> b) Charter TLDs may requires direct communication with registrant.

Maybe if you offered a "NATS are Evil(tm)" line of proof for the
non-necessity, or worse, of registrars. Seriously, what prevents a
dns registry and registrant from direct key exchange? Where is the
trust model predicated upon the provisioning protocol for e2e transport?
For e2e anything?

Charter TLDs may require direct registry-registrant communication, how
does this become a requirement on the provisioning protocol? Where
is the communication predicated upon the provisioning protocol for
e2e transport? For e2e anything?

> I could also cite examples outside DNS space but I will pass for now.

Thanks for the restraint.

Your comment on iteration in standards processes was interesting. It
was also in the same bit of mail that mentioned some unknown factors
in defense of a "don't know" answer to a specific question. Fortunately,
this is just scope discussion.

Cheers,
Eric

To: "James Seng/Personal" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Thu, 25 Jan 2001 14:13:51 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> If you are having a private conversation with Patrik then please do it
> offline.

See Message-Id: <p05100858b694cded21a1@[193.0.4.72]>

> If you post it to the list, then be prepare for disagreement,
> from anyone on the list.

We are discussing requirements. And doing so with some confusion (is
it whois:43 or whois:xx?) and some list overuse (provreg and whois).
Disagreement is useful, when it leads to correction, or at least the
discovery of error, or ambiguity.

> Your TODO list is only _part_ of the consideration. I am certain the

If you would cite or somehow motivate a requirement for a registry
protocol to provide access to 3rd-parties, regardless of the modality
of the operation (anonymous read vs write, etc.) it would assist my
understanding.

Which of the registrant, registrar, registry interests are augmented
by access via the provreg protocol of parties who are neither registrant,
registrar, nor registry? Some clearly are depricated, either by anonymous
3rd-party access, or by the (possible) delay in the standards process,
even if experimental, by mission creep in the specifications phase.

> group welcome your input but this does not mean the group are here to
> solve your problem only. (third time I am putting this down. please...do
> I have to do it 4th time?).

Sure.

> I am not going to disagree with your analysis here because that is true
> now.
        
Progress.

> And IMHO, there is no technical reason to forbid a registrant to access
> the registry directly

Please share your solution to the aaa problem, on one hand I've on the order
of 100 or 1,000 or so endpoints a registry, or any set of registries, must
authenticate, etc., and on the other hand I (or rather _you_) have got on
the order of 10,000,000 endpoints a registry, or ..., must authenticate, etc.

 [necessity and sufficiency discussion, snip]
> Perhaps. Perhaps not.

As neither necessity nor sufficiency tests appear to get any more clear
than what looks like "don't know", the proponents of the claim haven't
made a case.

>> and key management. "Out of band" means by another mechanism.

> Great. I look forward to the day we repeat this all over again in some
> other WG formed to solve this "out of band" registration problem.
 
Iteration with selective scope is an alternative to single pass with unlimited
scope.

ietf-whois trimmed from the cc's.

Eric

From: [email-masked]
To: <[email-masked]>
Date: Fri, 26 Jan 2001 06:22:39 +0700
Subject: Re: Merging RRP and Whois 
CC: <[email-masked]>
Sender: [email-masked]

> And IMHO, there is no technical reason to forbid a registrant to access
> the registry directly, should certain policy or technical reqirement
> needs it. I am not saying the registry SHOULD (or MUST) do this, but
> that they MAY.

Agree. Why can't we simplify the requirement, ie. the
system (protocol/implementation) should only allow
*one* entity to access (read/write/update) to a record?
This *one* entity could be registrar, reseller, registrant,
registry, whatever. As long it is *one* entity.
(That way it can accomodate any business model.)

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Fri, 26 Jan 2001 06:54:49 +0800
Sender: [email-masked]

> If you would cite or somehow motivate a requirement for a registry
> protocol to provide access to 3rd-parties, regardless of the modality
> of the operation (anonymous read vs write, etc.) it would assist my
> understanding.

RRP is not just a registry protocol. It does not prevent a registrar to
use it with their reseller.

On allowing 3rd party to access the RRP servers,
a) DNSSEC. Keys needs to be exchanged directly with the Registry.
b) Charter TLDs may requires direct communication with registrant.

I could also cite examples outside DNS space but I will pass for now.

> Which of the registrant, registrar, registry interests are augmented
> by access via the provreg protocol of parties who are neither
registrant,
> registrar, nor registry? Some clearly are depricated, either by
anonymous
> 3rd-party access, or by the (possible) delay in the standards process,
> even if experimental, by mission creep in the specifications phase.

Disagree.

We are not here to fight for anyone interest. We are here to design a
standard. And such a standard protocol have implication beyond the 3
groups of people you stated here.

> > And IMHO, there is no technical reason to forbid a registrant to
access
> > the registry directly
>
> Please share your solution to the aaa problem, on one hand I've on the
order
> of 100 or 1,000 or so endpoints a registry, or any set of registries,
must
> authenticate, etc., and on the other hand I (or rather _you_) have got
on
> the order of 10,000,000 endpoints a registry, or ..., must
authenticate, etc.

100 or 1,000 or 10,000,000 or 1,000,000,000,000. If we design it
correctly, we can do it. One often hear that "IETF only have one
problem: Scalability". This is no exception. It is not easy but running
away from scalablity is not an option.

> As neither necessity nor sufficiency tests appear to get any more
clear
> than what looks like "don't know", the proponents of the claim haven't
> made a case.

Don't know is a valid answer considering that there are factors which we
are not able to answer yet. And until we do know these factors, like
what what protocol and what infrastructure is been proposed, my best
answer is 'don't know'.

> > Great. I look forward to the day we repeat this all over again in
some
> > other WG formed to solve this "out of band" registration problem.
>
> Iteration with selective scope is an alternative to single pass with
unlimited
> scope.

No. Iteration with selective scope is a typical software design
methology, not a design methology.

We dont come here to design version 1 only to release version 2, version
3 etc in future. Things dont happen this way in IETF.

-James Seng

From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Fri, 26 Jan 2001 01:43:02 +0800
Sender: [email-masked]

Eric,

> Patrik (AD hatted) wrote about cases for extending the RRP. I replied,
> in part pointing out that anonymous read access isn't on my todo list,
> or any registry provisioning requirement I have seen. Perhaps you have
> misunderstood the exchange. Perhaps I misunderstand your commentary.

If you are having a private conversation with Patrik then please do it
offline. If you post it to the list, then be prepare for disagreement,
from anyone on the list.

Your TODO list is only _part_ of the consideration. I am certain the
group welcome your input but this does not mean the group are here to
solve your problem only. (third time I am putting this down. please...do
I have to do it 4th time?).

> The second part of my reply concerned the role of the registrar. In
the
> case Patrik offered, registrant modification of registry data without
> interposition by a registrar, several issues arise which don't in the
> interposition case:
[snip]

I am not going to disagree with your analysis here because that is true
now.

10 years ago, no one see any business in domain names. IANA do it as a
matter-of-fact. 3 years ago, people start tieing down the NSI and wanted
a share of the $$. Can you predict what will happen 3 or 5 years later?
Will your issues remains true?

So, please see beyond immediate needs. There are greater issues at
large. And enforcing certain policy onto a protocol is probably the
worst mistake we could make.

And IMHO, there is no technical reason to forbid a registrant to access
the registry directly, should certain policy or technical reqirement
needs it. I am not saying the registry SHOULD (or MUST) do this, but
that they MAY.

> Since the actors having the roles of registrant, reseller, registrar,
and
> registry are not fixed, in particular, the reseller and registrar
parts
> may be fluid, and the registrant's policy not required to be fixed, if
the
> protocol does not also notice the registrant of changes in the
upstream
> service providors, then the direct access (to intermediaries!)
mechanism
> fails to meet the sufficiency test for policing of provisioned data.

Perhaps. Perhaps not. I don't think we reach a stage whereby we know the
protocol enough to say this. It is certainly something we need to
consider while desiging.

> The third part of my reply concerned Patrik's speculation w.r.t.
dnssec
> and key management. "Out of band" means by another mechanism.

Great. I look forward to the day we repeat this all over again in some
other WG formed to solve this "out of band" registration problem.

-James Seng

To: "James Seng" <[email-masked]>
cc: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "George Belotsky" <[email-masked]>, "Paul George" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Thu, 25 Jan 2001 09:53:37 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

Patrik (AD hatted) wrote about cases for extending the RRP. I replied,
in part pointing out that anonymous read access isn't on my todo list,
or any registry provisioning requirement I have seen. Perhaps you have
misunderstood the exchange. Perhaps I misunderstand your commentary.

The second part of my reply concerned the role of the registrar. In the
case Patrik offered, registrant modification of registry data without
interposition by a registrar, several issues arise which don't in the
interposition case:

Technical issues (non-exhaustive):
	scaling the RRP aaa mechanisms,
	scoping the registry access mechanism,

Economic issues (non-exhaustive):
	scoping registrar liability and compensation,

Public Policy issues (non-exhaustive):
	registry competition with registrars

As I mentioned, where the write-access is registrar-mediated, the aaa
and access mechanism issues are simplified, and other issues don't
arise in addition to those which already exist for the registrar-mediated
service.

In your commentary you mentioned privacy as a motivation, positing the
"thickness" of the data, and presumably the policed data, in the care of
several actors -- you listed registry, registrar, and reseller, then
placed the duty to notice any of the registrant's privacy policy (which
may be something other than a preference or a consideration, and need not
be static) upon the registrant, to necessitate registrant participation
in a registrar-registry service model. 

Since the actors having the roles of registrant, reseller, registrar, and
registry are not fixed, in particular, the reseller and registrar parts
may be fluid, and the registrant's policy not required to be fixed, if the
protocol does not also notice the registrant of changes in the upstream
service providors, then the direct access (to intermediaries!) mechanism
fails to meet the sufficiency test for policing of provisioned data.

Non-necessity was my point to Patrik, non-sufficiency my point to you (James).

The third part of my reply concerned Patrik's speculation w.r.t. dnssec
and key management. "Out of band" means by another mechanism. 

Eric

Date: Thu, 25 Jan 2001 09:25:18 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: [email-masked]
Sender: [email-masked]

At 9:43 PM -0500 1/23/01, Eric Brunner-Williams in Portland Maine wrote:
>Neither RRP nor Whois emerged from San Diego BoF with charters, and

That's not true.  The IESG has a copy of the charter below, and the IESG's
regularly scheduled bi-weekly meeting is scheduled for today.  I know that
the charter has been presented for consideration.  Note that I do not mean
to give the impression that the charter will be approved.

---The submited charter:

Provisioning Registry Protocol (ProvReg)

-------------------------------

  CHAIR(S):
         Edward Lewis <[email-masked]>
         Jaap Akkerhuis <[email-masked]>

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström <[email-masked]>
         Ned Freed <[email-masked]>

  AREA ADVISOR:
         Patrik Fältström <[email-masked]>

  MAILING LISTS:
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
    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).  Subsequent
versions of the specification will extend the protocol to exchange other
information needed to organize the Internet, such as IP address allocations.
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 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,
including authentication and authoriztion of the participants, confidentiality
of data where needed and allowed

*       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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 25 Jan 2001 12:23:53 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: open RRP implementations
Organization: Gandi
Sender: [email-masked]

On Wed, Jan 24, 2001 at 02:56:14PM -0500, Ross Wm. Rader took time to write:
> What I was trying get at was the there are a number of RRP/EPP
> implementations that are/will be exclusively private in nature. It *can* be
> a public implementation, but currently, I know of none. Whois on the other

Perl modules exist, set Net::RRP, for client and server RRP [1]. 
Probably not mature and fully functionnal, but they exist.
If I obtain permission from my employers, I also expect to open my
own RRP modules, part of a whole scheme of independant Registry
access à la DBI/DBD, already functionnal and used.

Patrick.

[1] http://search.cpan.org/search?dist=Net-RRP

From: "James Seng" <[email-masked]>
To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "George Belotsky" <[email-masked]>, "Paul George" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Thu, 25 Jan 2001 13:10:52 +0800
Sender: [email-masked]

Eric,

Once again, your problem is only a subset of the issue we dealing with.

> Anonymous read access isn't on my todo list. Non-critical features
should > be footnoted for the benefit of subsequent requirements
gathering parties.

Whois, by its current nature, is anonymous read-access. The most info
you can extract would be the IP address of the querier.

> Registrant write-access is trivially accomodated via registry access,
so
> it isn't necessary. Why is a common mechanism useful?

No, it is neccessary for key-management whereby registrant _may_ have to
contact the registry directly.

And in domain names context, due to different policy, the "thickness" of
the registrant data may sometimes be at the registry, sometimes at the
registrar sometimes at the reseller etc. There need to be a way for
registrant to inform all of them about their privacy consideration, and
bear in mind this would somehow interact with the different local data
privacy laws in various countries depending where the thickeness
resident.

> Registrant key management (as an instance of many things outside the
scope
> of dns registrations) can be handled out-of-band, and need not require
> registrar participation.

"out-of-band" means?

If it is manual, it is kind of stupid considering we are trying to
reduce man-power.

If it is automatic, do you suggest we have another set of protocol to
handle it?

Either way, I think you are too short-sighted here.

> Wearing my participant hat I've yet to see a case for an RRP-like
mechanism
> having whois-like semantics. Please have a look at the cpexchange
work, we
> did try to make some progress on all three of these use cases, keeping
the
> several privacy/data protection frameworks in mind, though from a
marketer
> and/or large-sized vertically integrated vendor perspective -- we stll
have
> the same regulatory shoals to work through.

As an implementor who has tried to integrate WHOIS into RRP (our
registry allows registrant to do whois-like queries thru our RRP), I can
understand why you say this. It does makes life easier as software
developers since it is one source, one semantic.

It is unfortunate you can't hear the horrible yell of joy from my
operation folk.

-James Seng

From: Randy Bush <[email-masked]>
To: "Paul George" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 21:56:21 +0100
Sender: [email-masked]

> Fair enough, thanks for the info Randy.  But I think my question is still
> valid.  Does "whois" have a valid place in a generic regsitry/registrar
> protocol?

we can't know that until the requirements of the application are well and
clearly stated.  until then, all else is hot air.

randy

To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: George Belotsky <[email-masked]>, Paul George <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Wed, 24 Jan 2001 15:20:01 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Patrik,

Wearing your AD hat you suggest three cases for utility of a unique mechanism
(rrp + whois sugar):

	anonymous access

	registrant access 

	key management

Anonymous read access isn't on my todo list. Non-critical features should be
footnoted for the benefit of subsequent requirements gathering parties.

Registrant write-access is trivially accomodated via registry access, so
it isn't necessary. Why is a common mechanism useful?

Registrant key management (as an instance of many things outside the scope
of dns registrations) can be handled out-of-band, and need not require
registrar participation.

Wearing my participant hat I've yet to see a case for an RRP-like mechanism
having whois-like semantics. Please have a look at the cpexchange work, we
did try to make some progress on all three of these use cases, keeping the
several privacy/data protection frameworks in mind, though from a marketer
and/or large-sized vertically integrated vendor perspective -- we stll have
the same regulatory shoals to work through.

Cheers,
Eric

From: Randy Bush <[email-masked]>
To: "Paul George" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 17:30:56 +0100
Sender: [email-masked]

> Isn't whois simply a means of looking up Internet domain name
> information?

no it is not.  while the domain indu$try uses he protocol, many others do
too.  and they have just as legitimate claims to its functionality as the
domain exploition indu$try.

randy

To: "James Seng/Personal" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Karl Auerbach" <[email-masked]>, "George Belotsky" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 21:43:02 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

Extensibility of schema(s) is a given, in fact, the idea of an
inextensible protocol using XML is sort of funny. Unity is not
a given, not merely due the differences in schemas, as one AD
noted, the process models are not equivalent.

Registration in arbitrary object identifier schemes which may share a
property of hierarchical delegation is a fruitful field of research.
To be fair, the same observation applies to self-labeled data and to
labeled flows, which may share the properties of registrant data schemas.

I don't expect an IETF WG charter to be quite that broad however, for
either value of abstraction to the point of ... well, absurdity.
(Again, to be fair, an IRTF WG charter is another matter, e.g., for
labeled flows)

Neither RRP nor Whois emerged from San Diego BoF with charters, and
I haven't seen an announcement on ietf-announce concerning either,
so I guess there is nothing wrong with your advocating a particular
scoping, nor with George advocating merging, or Karl advocating ident
and/or authorization over privacy, or out-calls to policy mavens.

I'd like to keep the RRP-list scope closer to the SRS and RRP sense of
scope, and keep the post-port-43 scope specific to some port other than
43, with a 43-like, but "improved", services.

Eric

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: Karl Auerbach <[email-masked]>, George Belotsky <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 16:57:01 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

> Why is it that people here automatically assumed that RRP/WHOIS only
> serves Domain Names information?

Are you suggesting that an RRP doesn't, or making a subset arguement?
Who cares, other than extensibility-in-principle, about more junk than
the necessary and sufficient minimum, viz dns data? I made the assumption
as those are exactly the problems I'm trying to solve, if my state of
mind is that interesting.

> And what makes ICANN the default authority beyond IP and Names and that
> RRP/WHOIS is only used by the 80+ Registrars?           

That set of registrars and registries is convienient to mention, frequently
in less than complete awe. There are of course ccTLD registries and their
own registrars. This is the same space we worked on at the SRS BoF in
Orlando, and in mini-BoF at Minneapolis.

Was there something else, other than several orders of magnitude difference
in the number of endpoint identifiers, between the RRP and whois models, or
the rather modest span of known policies in either model, which caught your
attention? These were the sole motivations I gave for mentioning ICANN. If
you've some other concern, I don't yet know what it is.

Eric

From: "James Seng/Personal" <[email-masked]>
To: "Karl Auerbach" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "George Belotsky" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Wed, 24 Jan 2001 05:15:46 +0800
Sender: [email-masked]

Why is it that people here automatically assumed that RRP/WHOIS only
serves Domain Names information?

And what makes ICANN the default authority beyond IP and Names and that
RRP/WHOIS is only used by the 80+ Registrars?

IMHO, it is best we do not discuss nor constraint our design based on
ICANN or any defined policy of any group in IETF. Organisation and
Policy will change but Protocol will get stuck for a long time.

-James Seng

> As I mentioned earlier, when used as intended, whois repurposes and
> redistributes registrant-originated data. It isn't "customer as status
> querier" (which I think means registrant) but non-registrant, e.g.,
> Acxiom, or DoubleClick or, ...
>
> I understand, but don't share, the view that
identification/authentication
> of both the querier and the responder are bigger issues than what our
> friends in Europe refreshingly refer to as "data self-determination".
>
> Failing over to a policy server, a la Shai Herzog's original paper, is
a
> fine idea, but (presumably) is unnecessary within the ICANN scope of
an
> RRP, where policy is reasonably finite and well-known. How useful it
may
> be where the restriction on query initiators is removed ("public"
whois)
> is TBD.
>
> I also agree that with only 67 or so ICANN approved Registrars,
sneakernet
> is a viable trust model.
>
> Eric

To: Karl Auerbach <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, George Belotsky <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 16:00:02 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Karl,

As I mentioned earlier, when used as intended, whois repurposes and
redistributes registrant-originated data. It isn't "customer as status
querier" (which I think means registrant) but non-registrant, e.g., 
Acxiom, or DoubleClick or, ...

I understand, but don't share, the view that identification/authentication
of both the querier and the responder are bigger issues than what our
friends in Europe refreshingly refer to as "data self-determination".

Failing over to a policy server, a la Shai Herzog's original paper, is a
fine idea, but (presumably) is unnecessary within the ICANN scope of an
RRP, where policy is reasonably finite and well-known. How useful it may
be where the restriction on query initiators is removed ("public" whois)
is TBD.

I also agree that with only 67 or so ICANN approved Registrars, sneakernet
is a viable trust model.

Eric

To: George Belotsky <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 15:30:28 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

George,

Wearing my rrp-implementor hat, I'm implementing bulk transport of user
profiles[1], including a mechanism to support registry, registrar, and
also promoted registrant "hints" for policed access mechanisms. I've got
all the reliable, non-repudiation, secure hurdles to clear as well. Bulk
is zero-or-more user profiles, aka "registrar-provided registrant data".

One "hint" I think is required is the controlling jurisdiction(s) for
any specific datum, registrant originated, registrar originated, or
registry originated.

My idea of "extensible" is that the rrp _might_ be useful to the ccTLD
actors, or any other form of Registry-Registrar model ICANN posits in
the near future, as my rrp-implementor hat reads "gTLD(s) first".

Wearing my who-wannabe-implementor hat, I'm implementing non-bulk-query
of user profiles, and transporting data with hints intact for use at
some unspecified point where policy (or hints) are evaluated, isn't part
of the less-than-pelucid-spec. In fact, what spec? For all I know, the
lookup could point to registries having little or nothing to do with
DNS registry data, e.g., Acxiom.

Finding a schema, or bits of several, that can be recycled, isn't very
hard, but is it interesting? I don't think the rest of the problem is as
amenable to reuse or recycling or a unifying software architectural
model as the schema question.

Cheers,
Eric
---

[1] see also www.cpexchange.org, which has a bulk user profile exchange
protocol with similar properties, created by the on-line marketers and
ultra-large vertically integrated vendors.

Date: Tue, 23 Jan 2001 19:13:14 +0100
From: Olivier Guillard / AFNIC <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Hi,

DNS is designed to reference an information
Whois is designed to provide an information

It is not a good idea to think about unifying
two inconsistent issues.

Regards,

Olivier

le 22 Jan, George Belotsky a écrit :
> Hello, All.
>  
> I have recently posted the information below to the Whois list.
>  
> The RRP group has made quite a bit of progress on a generic
> protocol for Registry-Registrar communication.
>  
> It would save a lot of duplicated effort if the Whois and RRP
> protocols could be merged into a single standard.  Registries,
> Registrars, and end users would then have to contend with a single   
> protocol, instead of two diverging ones.
>  
> At the most fundamental level, both Whois and RRP provide a view into
> the the repository of information associated with a domain name.  A
> sufficiently rich protocol would allow for these views to be finely
> adjusted.  In addition, it would be possible for other views to
> emerge, as necessity dictates.
>  
> Implementation effort, number of bugs, testing and troubleshooting
> should all be positively affected by having only a single protocol to
> deal with.  This would surely benefit everyone.
>  
> George.
>  
> 
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)

-- 
Olivier Guillard
---
||    A.F.N.I.C.
|| http://www.nic.fr

To: George Belotsky <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 12:41:30 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

George,

The decisions made now will affect rrp implementors _now_.

One of the failings of "extensibility" (a token periodically emitted
by bits of the W3C) is its lack of self-description. What is being
extended? A schema? A state machine? An access control mechanism?

Reference to rockets, and scientists, living or deceased, are not
sufficiently specific.

Since the specifics of privacy/data protection are fundamentally
scoped (temporally as well as spatially) and hence irreconcillable
with scope- free universalism(s), let alone any other actual property
of a rrp or a whois-successor protocol, please accept my "non-hum"
to the suggestion that A wait on B, etc.

Eric

From: "James Seng/Personal" <[email-masked]>
To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Jaap Akkerhuis" <[email-masked]>
Cc: "George Belotsky" <[email-masked]>, "Paul George" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Thu, 25 Jan 2001 12:59:59 +0800
Sender: [email-masked]

Please don't go there...

james

> To exagerate a bit, since DNS is does also do lookups, why not add
> a whois function to it?

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Exentisibility in the requirements
Date: Wed, 24 Jan 2001 16:54:49 -0500
Sender: [email-masked]

FWIW there _is_ a section in the draft (section 7.5) describing
extensibility requirements.

<Scott/> 

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Wednesday, January 24, 2001 12:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Exentisibility in the requirements

With this talk about merging provreg and whois, it seems to me that some
folks have gotten the impression that provreg is limited to domain names.
Provreg is looking at domain names in the near term with an eye towards
other data types in the future.  That is what the charter says.

Perhaps the current requirements document does not reflect this.  The
current requirements document is focused at domain names because of the
near-term effort.  Perhaps the requirements need to strenghten the notion
that the protocol must be extensible.

I would enourage anyone who feels that the requirements document is too
domain- name-centric submit comments and words to reflect that domain names
are just a current focus, more work is to follow.  I don't want to bog the
requirements document in discussion of other data types but rather strongly
recognize that other data types will be considered in the future.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: George Belotsky <[email-masked]>, Paul George <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Wed, 24 Jan 2001 21:13:56 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    I.e. if you do a protocol, and need overlapping functions, see if you 
    should not do _one_...

    What goes on port 43 is a completely different story, and it should 
    stay that way.
    
What is going on on port 43 is indeed a complete different story.
Looking at the dicussion going on about what the function of whois
should or shouldn't be is an example about of this.

But I wonder how big the overlap is really. In the hollenbeck draft
the lookup function of whether an object exists is just a small
portion of the whole draft.

To exagerate a bit, since DNS is does also do lookups, why not add
a whois function to it?

	jaap

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>, "George Belotsky" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Paul George" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 14:56:14 -0500
Importance: Normal
Sender: [email-masked]

Unfortunately, that didn't make as much sense as I thought it did...

What I was trying get at was the there are a number of RRP/EPP
implementations that are/will be exclusively private in nature. It *can* be
a public implementation, but currently, I know of none. Whois on the other
hand is mostly used in a public manner. There are private implementations,
but again, most are public. Anyways, my point is that merging the two will
lead to a point where one or the other must become more public or more
private in nature. In some of the implementations that we manage this would
be a good thing, in others, it would be a bad thing. I for one would prefer
to keep things a little bit simpler than what this arrangement implies....

<  -----Original Message-----
<  From: [email-masked] [mailto:[email-masked]]On
<  Behalf Of Ross Wm. Rader
<  Sent: Wednesday, January 24, 2001 2:50 PM
<  To: George Belotsky; Patrik Fältström; Paul George
<  Cc: [email-masked]; [email-masked]
<  Subject: RE: Merging RRP and Whois
<
<
<  Isn't the RRP (and therefore, won't the EPP likely be) a semi-private
<  protocol, whereas whois is inherently public in nature?
<
<  <  -----Original Message-----
<  <  From: [email-masked]
<  <  [mailto:[email-masked]]On Behalf Of George Belotsky
<  <  Sent: Wednesday, January 24, 2001 2:00 PM
<  <  To: Patrik Fältström; Paul George
<  <  Cc: [email-masked]; [email-masked]
<  <  Subject: Re: Merging RRP and Whois
<  <
<  <
<  <  It would not be necessary to run the new protocol on port 43.  The new
<  <  protocol, however, should become the standard for future Whois-type
<  <  queries.
<  <
<  <  Backwards compatibility with the current Whois should definitely be
<  <  maintained.  Fortunately, with the current Whois standard this is not
<  <  a problem.
<  <
<  <  The existing protocol on port 43 can remain as long as needed.  All
<  <  future extensions, however, should be to the new protocol.  In this
<  <  way, we would avoid forcing the development of incompatible and
<  <  diverging methods for accessing the same data.  We would also avoid
<  <  having to solve twice a large set set of very difficult problems, such
<  <  as authentication, security, privacy and internationalization.
<  <
<  <
<  <
<  <  On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote:
<  <  > At 12.37 -0500 01-01-24, George Belotsky wrote:
<  <  > >It would not take too much effort to simply use the Whois-like
<  <  > >features (perhaps with a little extension) of the RRP to
<  provide Whois
<  <  > >services to end users.
<  <  >
<  <  > I think this is a VERY interesting path that you should consider
<  <  > seriously! Including anonymous access, and ability for registrants
<  <  > (yes, registrants) to because of data protection laws
<  update whatever
<  <  > is necessary in the registry database in the case of a thick
<  <  > registry.  Also, this connection might be needed also for DNSSEC key
<  <  > signing issues...
<  <  >
<  <  > I.e. if you do a protocol, and need overlapping functions,
<  see if you
<  <  > should not do _one_...
<  <  >
<  <  > What goes on port 43 is a completely different story, and it should
<  <  > stay that way.
<  <  >
<  <  >    paf -- with my AD hat on as you can see in the signature
<  <  >
<  <  >
<  <  > --
<  <  > Patrik Fältström <[email-masked]>       Internet Engineering
<  Task Force
<  <  > Area Director, Applications Area
http://www.ietf.org
<  > Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
<  >         PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC
<
<  --
<  -----------------------------
<  George Belotsky
<  Senior Software Architect
<  Register.com, inc.
<  [email-masked]
<  212-798-9127 (phone)
<  212-798-9876 (fax)

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "George Belotsky" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Paul George" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 14:50:24 -0500
Importance: Normal
Sender: [email-masked]

Isn't the RRP (and therefore, won't the EPP likely be) a semi-private
protocol, whereas whois is inherently public in nature?

<  -----Original Message-----
<  From: [email-masked]
<  [mailto:[email-masked]]On Behalf Of George Belotsky
<  Sent: Wednesday, January 24, 2001 2:00 PM
<  To: Patrik Fältström; Paul George
<  Cc: [email-masked]; [email-masked]
<  Subject: Re: Merging RRP and Whois
<
<
<  It would not be necessary to run the new protocol on port 43.  The new
<  protocol, however, should become the standard for future Whois-type
<  queries.
<
<  Backwards compatibility with the current Whois should definitely be
<  maintained.  Fortunately, with the current Whois standard this is not
<  a problem.
<
<  The existing protocol on port 43 can remain as long as needed.  All
<  future extensions, however, should be to the new protocol.  In this
<  way, we would avoid forcing the development of incompatible and
<  diverging methods for accessing the same data.  We would also avoid
<  having to solve twice a large set set of very difficult problems, such
<  as authentication, security, privacy and internationalization.
<
<
<
<  On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote:
<  > At 12.37 -0500 01-01-24, George Belotsky wrote:
<  > >It would not take too much effort to simply use the Whois-like
<  > >features (perhaps with a little extension) of the RRP to provide Whois
<  > >services to end users.
<  >
<  > I think this is a VERY interesting path that you should consider
<  > seriously! Including anonymous access, and ability for registrants
<  > (yes, registrants) to because of data protection laws update whatever
<  > is necessary in the registry database in the case of a thick
<  > registry.  Also, this connection might be needed also for DNSSEC key
<  > signing issues...
<  >
<  > I.e. if you do a protocol, and need overlapping functions, see if you
<  > should not do _one_...
<  >
<  > What goes on port 43 is a completely different story, and it should
<  > stay that way.
<  >
<  >    paf -- with my AD hat on as you can see in the signature
<  >
<  >
<  > --
<  > Patrik Fältström <[email-masked]>       Internet Engineering Task Force
<  > Area Director, Applications Area                   http://www.ietf.org
<  > Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
<  >         PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC
<
<  --
<  -----------------------------
<  George Belotsky
<  Senior Software Architect
<  Register.com, inc.
<  [email-masked]
<  212-798-9127 (phone)
<  212-798-9876 (fax)

Date: Wed, 24 Jan 2001 13:59:35 -0500
From: George Belotsky <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, Paul George <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

It would not be necessary to run the new protocol on port 43.  The new
protocol, however, should become the standard for future Whois-type
queries. 

Backwards compatibility with the current Whois should definitely be
maintained.  Fortunately, with the current Whois standard this is not
a problem.

The existing protocol on port 43 can remain as long as needed.  All
future extensions, however, should be to the new protocol.  In this
way, we would avoid forcing the development of incompatible and
diverging methods for accessing the same data.  We would also avoid
having to solve twice a large set set of very difficult problems, such
as authentication, security, privacy and internationalization.

On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote:
> At 12.37 -0500 01-01-24, George Belotsky wrote:
> >It would not take too much effort to simply use the Whois-like
> >features (perhaps with a little extension) of the RRP to provide Whois
> >services to end users.
> 
> I think this is a VERY interesting path that you should consider 
> seriously! Including anonymous access, and ability for registrants 
> (yes, registrants) to because of data protection laws update whatever 
> is necessary in the registry database in the case of a thick 
> registry.  Also, this connection might be needed also for DNSSEC key 
> signing issues...
> 
> I.e. if you do a protocol, and need overlapping functions, see if you 
> should not do _one_...
> 
> What goes on port 43 is a completely different story, and it should 
> stay that way.
> 
>    paf -- with my AD hat on as you can see in the signature
> 
> 
> -- 
> Patrik Fältström <[email-masked]>       Internet Engineering Task Force
> Area Director, Applications Area                   http://www.ietf.org
> Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
>         PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 13:46:16 -0500
From: George Belotsky <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: Exentisibility in the requirements
Sender: [email-masked]

Actually, it is quite clear that provreg is quite broad in capability.

This is why merging the Whois functionality into the RRP would work so
well.  Whois will eventually need more features, while the RRP has
methods to accomplish Whois-type queries (one does need to just look
at the registered objects).  Both the Whois and RRP must reference the
same objects in any case: the RRP at a very high privilege, and the
Whois at the lowest possible privilege.

On Wed, Jan 24, 2001 at 12:55:09PM -0500, Edward Lewis wrote:
> With this talk about merging provreg and whois, it seems to me that some
> folks have gotten the impression that provreg is limited to domain names.
> Provreg is looking at domain names in the near term with an eye towards
> other data types in the future.  That is what the charter says.
> 
> Perhaps the current requirements document does not reflect this.  The
> current requirements document is focused at domain names because of the
> near-term effort.  Perhaps the requirements need to strenghten the notion
> that the protocol must be extensible.
> 
> I would enourage anyone who feels that the requirements document is too
> domain- name-centric submit comments and words to reflect that domain names
> are just a current focus, more work is to follow.  I don't want to bog the
> requirements document in discussion of other data types but rather strongly
> recognize that other data types will be considered in the future.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> Dilbert is an optimist.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 13:35:42 -0500
From: George Belotsky <[email-masked]>
To: Martin Oldfield <[email-masked]>
Cc: Patrik Fdltstrvm <[email-masked]>, Edward Lewis <[email-masked]>, James Seng/Personal <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, Karl Auerbach <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

I would expect that some object types (such as ones dealing with
domain names) will be fully specified as the result of the current
work on the RRP.  Some thought should be given to future types -- but
just enough to allow the protocol to grow later.  Very fortunately,
there is no need for too much work on these types now -- otherwise
there would be no time to do it.

A little can go a long way, however, to ensure the future of the
protocol.

On Wed, Jan 24, 2001 at 05:35:10PM +0000, Martin Oldfield wrote:
> >>>>> "George" == George Belotsky <[email-masked]> writes:
> 
> -> snip <-
> 
>     George> In order to do so, it is very helpful to view the
>     George> registration system as a number of object repositories
>     George> (which may contain things other than domain names), with
>     George> each repository being managed by a registry.  The object
>     George> repositories should all support a single interface, which
>     George> allows for a variety of users.  These include superusers
>     George> (i.e. the registry performing maintenance) and privileged
>     George> users (i.e. the registrars registering, modifying,
>     George> deleting and transferring objects) as well as users with
>     George> only moderate privileges (e.g. paid subscribers to an
>     George> advanced Whois service) and minimally privileged users
>     George> (i.e. users of the public Whois).
> 
>     George> If we start separating users into different privilege
>     George> categories by writing a different protocol for each
>     George> category, how many protocols will we end up with?
>     George> Clearly, a single protocol is the most logical solution.
> 
> Quite so!
> 
> Presumably besides the notion of a general object registry, we would
> also need to concoct standard definitions for e.g. a domain, a
> contact, &c. ? If we don't do this then we'll lose interoperability to 
> a proliferation of different domain definitions.
> 
> If we're going to embrace such diversity, then would it also be
> prudent to let each registry publish details of the classes of objects
> they store, and the access policies which apply to them ?
> 
> Cheers,
> -- 
> Martin Oldfield,
> AdamsNames Ltd.
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 19:25:11 +0100
To: George Belotsky <[email-masked]>, Paul George <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12.37 -0500 01-01-24, George Belotsky wrote:
>It would not take too much effort to simply use the Whois-like
>features (perhaps with a little extension) of the RRP to provide Whois
>services to end users.

I think this is a VERY interesting path that you should consider 
seriously! Including anonymous access, and ability for registrants 
(yes, registrants) to because of data protection laws update whatever 
is necessary in the registry database in the case of a thick 
registry.  Also, this connection might be needed also for DNSSEC key 
signing issues...

I.e. if you do a protocol, and need overlapping functions, see if you 
should not do _one_...

What goes on port 43 is a completely different story, and it should 
stay that way.

   paf -- with my AD hat on as you can see in the signature

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Wed, 24 Jan 2001 12:55:09 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Exentisibility in the requirements
Cc: [email-masked]
Sender: [email-masked]

With this talk about merging provreg and whois, it seems to me that some
folks have gotten the impression that provreg is limited to domain names.
Provreg is looking at domain names in the near term with an eye towards
other data types in the future.  That is what the charter says.

Perhaps the current requirements document does not reflect this.  The
current requirements document is focused at domain names because of the
near-term effort.  Perhaps the requirements need to strenghten the notion
that the protocol must be extensible.

I would enourage anyone who feels that the requirements document is too
domain- name-centric submit comments and words to reflect that domain names
are just a current focus, more work is to follow.  I don't want to bog the
requirements document in discussion of other data types but rather strongly
recognize that other data types will be considered in the future.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 24 Jan 2001 12:37:22 -0500
From: George Belotsky <[email-masked]>
To: Paul George <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Paul:

The RRP already includes Whois-style functionality.  One must be able
to view information on objects (domain names for now).  It is also
clear that the Whois will need a more advanced protocol than what
exists today.

In the future, a more comprehensive solution will be required.  With a
little thought now, the RRP, with its extensibility and authentication
features, can grow to be that comprehensive solutions.  End users and
other entities will then use the protcol also, not just registries and
registrars.  Alternatively, the RRP could become isolated as the
comprehensive solution develops, thus placing it firmly on the path to
deprecation.

It would not take too much effort to simply use the Whois-like
features (perhaps with a little extension) of the RRP to provide Whois
services to end users.

On Wed, Jan 24, 2001 at 11:39:16AM -0500, Paul George wrote:
> Fair enough, thanks for the info Randy.  But I think my question is still
> valid.  Does "whois" have a valid place in a generic regsitry/registrar
> protocol?  Will ALL registration systems need "whois" functionality?  Okay,
> if they don't need it, then they don't have to implement that part, but that
> could be said for a million other little bits of functionality.....  Even
> though I think of any right now, I'm sure someone else can. :-)
> 
> The fundemental question is :
> 
> Is 'whois' an integral part of a protocol that is intended to provide a
> means for the registration of objects?
> 
> IMHO, I think it is not.  And I hope we can move forward on this soon.
> 
> Paul
> 
> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 11:31 AM
> To: Paul George
> Cc: [email-masked]; [email-masked]
> Subject: RE: Merging RRP and Whois
> 
> 
> > Isn't whois simply a means of looking up Internet domain name
> > information?
> 
> no it is not.  while the domain indu$try uses he protocol, many others do
> too.  and they have just as legitimate claims to its functionality as the
> domain exploition indu$try.
> 
> randy
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 17:35:10 +0000 (GMT)
To: George Belotsky <[email-masked]>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, Edward Lewis <[email-masked]>, James Seng/Personal <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, Karl Auerbach <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "George" == George Belotsky <[email-masked]> writes:

-> snip <-

    George> In order to do so, it is very helpful to view the
    George> registration system as a number of object repositories
    George> (which may contain things other than domain names), with
    George> each repository being managed by a registry.  The object
    George> repositories should all support a single interface, which
    George> allows for a variety of users.  These include superusers
    George> (i.e. the registry performing maintenance) and privileged
    George> users (i.e. the registrars registering, modifying,
    George> deleting and transferring objects) as well as users with
    George> only moderate privileges (e.g. paid subscribers to an
    George> advanced Whois service) and minimally privileged users
    George> (i.e. users of the public Whois).

    George> If we start separating users into different privilege
    George> categories by writing a different protocol for each
    George> category, how many protocols will we end up with?
    George> Clearly, a single protocol is the most logical solution.

Quite so!

Presumably besides the notion of a general object registry, we would
also need to concoct standard definitions for e.g. a domain, a
contact, &c. ? If we don't do this then we'll lose interoperability to 
a proliferation of different domain definitions.

If we're going to embrace such diversity, then would it also be
prudent to let each registry publish details of the classes of objects
they store, and the access policies which apply to them ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Wed, 24 Jan 2001 12:19:38 -0500
From: George Belotsky <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: Edward Lewis <[email-masked]>, James Seng/Personal <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, Karl Auerbach <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Good idea.  Because the RRP group seems to be further along, 'here'
applies more to the RRP.  It is partially applicable to the Whois as
well.

Lots of issues have been raised on the two lists, including privacy
and authentication.  Of course, the policy is likely to be quite
complex, and determined by laws, customs, etc. in various parts of the
world.  We must create a mechanism that can support the large variety
of policies that are likely to emerge sooner or later.  Because of the
complexities involved, it would be best to create a single, evolving
mechanism.  

In order to do so, it is very helpful to view the registration system
as a number of object repositories (which may contain things other
than domain names), with each repository being managed by a registry.
The object repositories should all support a single interface, which
allows for a variety of users.  These include superusers (i.e. the
registry performing maintenance) and privileged users (i.e. the
registrars registering, modifying, deleting and transferring objects)
as well as users with only moderate privileges (e.g. paid subscribers
to an advanced Whois service) and minimally privileged users
(i.e. users of the public Whois).

If we start separating users into different privilege categories by
writing a different protocol for each category, how many protocols will
we end up with?  Clearly, a single protocol is the most logical
solution.

George.

On Wed, Jan 24, 2001 at 05:18:53PM +0100, Patrik Fältström wrote:
> At 11.11 -0500 01-01-24, George Belotsky wrote:
> >It very important to keep in mind that a _protocol_ is being created
> >here.
> 
> As this thread is cross-posted between two mailing lists, you should 
> be more specific than saying "here".
> 
>     paf
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Paul George" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 11:39:16 -0500
Importance: Normal
Sender: [email-masked]

Fair enough, thanks for the info Randy.  But I think my question is still
valid.  Does "whois" have a valid place in a generic regsitry/registrar
protocol?  Will ALL registration systems need "whois" functionality?  Okay,
if they don't need it, then they don't have to implement that part, but that
could be said for a million other little bits of functionality.....  Even
though I think of any right now, I'm sure someone else can. :-)

The fundemental question is :

Is 'whois' an integral part of a protocol that is intended to provide a
means for the registration of objects?

IMHO, I think it is not.  And I hope we can move forward on this soon.

Paul

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Wednesday, January 24, 2001 11:31 AM
To: Paul George
Cc: [email-masked]; [email-masked]
Subject: RE: Merging RRP and Whois

> Isn't whois simply a means of looking up Internet domain name
> information?

no it is not.  while the domain indu$try uses he protocol, many others do
too.  and they have just as legitimate claims to its functionality as the
domain exploition indu$try.

randy

From: "Paul George" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Merging RRP and Whois
Date: Wed, 24 Jan 2001 11:22:37 -0500
Importance: Normal
Sender: [email-masked]

Very well said George, however, if this truly is a generic protocol for the
registration of any kind of object, how does the whois functionality figure
into that?  Isn't whois simply a means of looking up Internet domain name
information?

If it is more than that, than perhaps we can think about incorporating it
into the protocol, but if it is specifically targeted toward internet domain
info, then it should be left out.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of George Belotsky
Sent: Wednesday, January 24, 2001 11:12 AM
To: Edward Lewis
Cc: James Seng/Personal; Eric Brunner-Williams in Portland Maine; Karl
Auerbach; [email-masked]; [email-masked]
Subject: Re: Merging RRP and Whois

It very important to keep in mind that a _protocol_ is being created
here.

A protocol's usefulness and longevity is dependent on how it adapts to
future situations.  Just solving today's immediate problem is not
enough.

Even with the assumption that everyone agrees to adopt the new
protocol, the 'nightmare' scenario will nevertheless occur if
multiple other protocols have to be developed to support the operation
of the registered object repositories.

There is a need to provide a consistent interface for registering,
maintaining and viewing various entities.  It is a historical accident
that domain names are the first entity that requires this.  We are
indeed fortunate that many decisions about future uses do not need to
be made right away.  It is vital, however, that some thought be given
to extensibility now, if the resulting protocol is to have longevity.

There can be little doubt that a unified entity registration, view,
search, etc. layer will eventually emerge.  This layer will handle
domain name registration, whois-like lookups, registration of other
objects, etc.  The alternative is a different protocol for
registration of each object type , and a different protocol for
whois-like lookups of objects of each type, etc., etc.  Clearly a
nightmare -- and enough people will eventually wake up.

Our choice today is whether the protocol being developed here can
evolve into the unified layer described above.  If it can, then indeed
this group will have done a great service to the Internet community.
If it cannot, then we will all have to suffer yet another painful
round of fragmentation, incompatibility, obsolescence and
deprecation.

On Wed, Jan 24, 2001 at 09:34:32AM -0500, Edward Lewis wrote:
> At 11:35 PM -0500 1/23/01, James Seng/Personal wrote:
> >Right. We are still probably doing scoping. However, I do want to remind
> >everyone that if ProReg is nothing more than an improved SRS/RRP for
> >ICANN-accredited registrar to Verisign, then IMHO we dont need this WG.
>
> Perhaps you should review the charter proposed for this group.  (It's in
> the archive, I can send you a copy off-list if you want.)  The charter is
> written to say that the results of the WG would be a generic protocol for
> registration information (domain names, IP addresses, etc.) but with a
> short term emphasis on domain names.
>
> >SRS/RRP is so specific to Verisign design that I am not sure how useful
> >it is to other Registries. If you are looking for an improved SRS/RRP,
> >then Verisign can do it on their own with their registrars.
>
> This is a "historical accident."  The drafts leading up to the BOF were
> produced by Verisign, and although input was sought, none was forthcoming
> (again, prior to the BOF).  Post-BOF, there have been lively discussions
on
> the mailing list, with input coming from a number of ccTLDs and ICANN
> gTLDs.  We are progressing on a requirements document that is intended to
> be the consensus of the group, not restricted to the original document as
> submitted by Verisign.
>
> The latest draft is:
>  http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt
> As we are not a WG yet, it is listed as an individual submission - that of
> Scott Hollenbenck, a memeber of Verisign.
>
> To help reduce bias in the final result, the co-chairs (myself and Jaap
> Akerhuis) work for a non-registr* company and a ccTLD company
respectively.
>
> >In the same way, if result of this WG (if created), is not suitable for
> >my absurd needs, I will move on design my own or modify it with my
> >partners to suit our need.
>
> Comments and additional text for the requirements document are welcome.  I
> am hoping for an always wider field of input.
>
> >Other registries may refused to adopted SRS/RRP just because it is
> >tailored to Verisign. I know quite a few Registries who has blantly
> >refused to use it so as not to create an association altho there is no
> >technical reason not to do so. Or they may use it and once again modify
> >it to their own.
> >
> >Unfortunately, this means we end-up with variant of the basically same
> >protocol but yet not exactly the same. That is interoperability
> >nightmare.
>
> This is why this WG is under consideration - to avoid that "nightmare."
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> Dilbert is an optimist.
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

--
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 17:18:53 +0100
To: George Belotsky <[email-masked]>, Edward Lewis <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: James Seng/Personal <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, Karl Auerbach <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 11.11 -0500 01-01-24, George Belotsky wrote:
>It very important to keep in mind that a _protocol_ is being created
>here.

As this thread is cross-posted between two mailing lists, you should 
be more specific than saying "here".

    paf

Date: Wed, 24 Jan 2001 11:11:58 -0500
From: George Belotsky <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: James Seng/Personal <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, Karl Auerbach <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

It very important to keep in mind that a _protocol_ is being created
here.

A protocol's usefulness and longevity is dependent on how it adapts to
future situations.  Just solving today's immediate problem is not
enough.

Even with the assumption that everyone agrees to adopt the new
protocol, the 'nightmare' scenario will nevertheless occur if
multiple other protocols have to be developed to support the operation
of the registered object repositories.

There is a need to provide a consistent interface for registering,
maintaining and viewing various entities.  It is a historical accident
that domain names are the first entity that requires this.  We are
indeed fortunate that many decisions about future uses do not need to
be made right away.  It is vital, however, that some thought be given
to extensibility now, if the resulting protocol is to have longevity.

There can be little doubt that a unified entity registration, view,
search, etc. layer will eventually emerge.  This layer will handle
domain name registration, whois-like lookups, registration of other
objects, etc.  The alternative is a different protocol for
registration of each object type , and a different protocol for
whois-like lookups of objects of each type, etc., etc.  Clearly a
nightmare -- and enough people will eventually wake up.

Our choice today is whether the protocol being developed here can
evolve into the unified layer described above.  If it can, then indeed
this group will have done a great service to the Internet community.
If it cannot, then we will all have to suffer yet another painful
round of fragmentation, incompatibility, obsolescence and
deprecation.  

On Wed, Jan 24, 2001 at 09:34:32AM -0500, Edward Lewis wrote:
> At 11:35 PM -0500 1/23/01, James Seng/Personal wrote:
> >Right. We are still probably doing scoping. However, I do want to remind
> >everyone that if ProReg is nothing more than an improved SRS/RRP for
> >ICANN-accredited registrar to Verisign, then IMHO we dont need this WG.
> 
> Perhaps you should review the charter proposed for this group.  (It's in
> the archive, I can send you a copy off-list if you want.)  The charter is
> written to say that the results of the WG would be a generic protocol for
> registration information (domain names, IP addresses, etc.) but with a
> short term emphasis on domain names.
> 
> >SRS/RRP is so specific to Verisign design that I am not sure how useful
> >it is to other Registries. If you are looking for an improved SRS/RRP,
> >then Verisign can do it on their own with their registrars.
> 
> This is a "historical accident."  The drafts leading up to the BOF were
> produced by Verisign, and although input was sought, none was forthcoming
> (again, prior to the BOF).  Post-BOF, there have been lively discussions on
> the mailing list, with input coming from a number of ccTLDs and ICANN
> gTLDs.  We are progressing on a requirements document that is intended to
> be the consensus of the group, not restricted to the original document as
> submitted by Verisign.
> 
> The latest draft is:
>  http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt
> As we are not a WG yet, it is listed as an individual submission - that of
> Scott Hollenbenck, a memeber of Verisign.
> 
> To help reduce bias in the final result, the co-chairs (myself and Jaap
> Akerhuis) work for a non-registr* company and a ccTLD company respectively.
> 
> >In the same way, if result of this WG (if created), is not suitable for
> >my absurd needs, I will move on design my own or modify it with my
> >partners to suit our need.
> 
> Comments and additional text for the requirements document are welcome.  I
> am hoping for an always wider field of input.
> 
> >Other registries may refused to adopted SRS/RRP just because it is
> >tailored to Verisign. I know quite a few Registries who has blantly
> >refused to use it so as not to create an association altho there is no
> >technical reason not to do so. Or they may use it and once again modify
> >it to their own.
> >
> >Unfortunately, this means we end-up with variant of the basically same
> >protocol but yet not exactly the same. That is interoperability
> >nightmare.
> 
> This is why this WG is under consideration - to avoid that "nightmare."
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> Dilbert is an optimist.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 24 Jan 2001 09:34:32 -0500
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Karl Auerbach" <[email-masked]>, "George Belotsky" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:35 PM -0500 1/23/01, James Seng/Personal wrote:
>Right. We are still probably doing scoping. However, I do want to remind
>everyone that if ProReg is nothing more than an improved SRS/RRP for
>ICANN-accredited registrar to Verisign, then IMHO we dont need this WG.

Perhaps you should review the charter proposed for this group.  (It's in
the archive, I can send you a copy off-list if you want.)  The charter is
written to say that the results of the WG would be a generic protocol for
registration information (domain names, IP addresses, etc.) but with a
short term emphasis on domain names.

>SRS/RRP is so specific to Verisign design that I am not sure how useful
>it is to other Registries. If you are looking for an improved SRS/RRP,
>then Verisign can do it on their own with their registrars.

This is a "historical accident."  The drafts leading up to the BOF were
produced by Verisign, and although input was sought, none was forthcoming
(again, prior to the BOF).  Post-BOF, there have been lively discussions on
the mailing list, with input coming from a number of ccTLDs and ICANN
gTLDs.  We are progressing on a requirements document that is intended to
be the consensus of the group, not restricted to the original document as
submitted by Verisign.

The latest draft is:
 http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt
As we are not a WG yet, it is listed as an individual submission - that of
Scott Hollenbenck, a memeber of Verisign.

To help reduce bias in the final result, the co-chairs (myself and Jaap
Akerhuis) work for a non-registr* company and a ccTLD company respectively.

>In the same way, if result of this WG (if created), is not suitable for
>my absurd needs, I will move on design my own or modify it with my
>partners to suit our need.

Comments and additional text for the requirements document are welcome.  I
am hoping for an always wider field of input.

>Other registries may refused to adopted SRS/RRP just because it is
>tailored to Verisign. I know quite a few Registries who has blantly
>refused to use it so as not to create an association altho there is no
>technical reason not to do so. Or they may use it and once again modify
>it to their own.
>
>Unfortunately, this means we end-up with variant of the basically same
>protocol but yet not exactly the same. That is interoperability
>nightmare.

This is why this WG is under consideration - to avoid that "nightmare."

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Karl Auerbach" <[email-masked]>, "George Belotsky" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Wed, 24 Jan 2001 12:35:23 +0800
Sender: [email-masked]

Eric,

Right. We are still probably doing scoping. However, I do want to remind
everyone that if ProReg is nothing more than an improved SRS/RRP for
ICANN-accredited registrar to Verisign, then IMHO we dont need this WG.

SRS/RRP is so specific to Verisign design that I am not sure how useful
it is to other Registries. If you are looking for an improved SRS/RRP,
then Verisign can do it on their own with their registrars.

In the same way, if result of this WG (if created), is not suitable for
my absurd needs, I will move on design my own or modify it with my
partners to suit our need.

Other registries may refused to adopted SRS/RRP just because it is
tailored to Verisign. I know quite a few Registries who has blantly
refused to use it so as not to create an association altho there is no
technical reason not to do so. Or they may use it and once again modify
it to their own.

Unfortunately, this means we end-up with variant of the basically same
protocol but yet not exactly the same. That is interoperability
nightmare.

-James Seng

> I'd like to keep the RRP-list scope closer to the SRS and RRP sense of
> scope, and keep the post-port-43 scope specific to some port other
than
> 43, with a 43-like, but "improved", services.
>
> Eric

From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Karl Auerbach" <[email-masked]>, "George Belotsky" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Date: Wed, 24 Jan 2001 06:54:47 +0800
Sender: [email-masked]

Eric,

> > Why is it that people here automatically assumed that RRP/WHOIS only
> > serves Domain Names information?
>
> Are you suggesting that an RRP doesn't, or making a subset arguement?

No, but it is too early to make a presumation or to restrict it to
Domain Names only. In fact, all discussion so far did suggest RRP to go
beyond Domain Names.

> Who cares, other than extensibility-in-principle, about more junk than
> the necessary and sufficient minimum, viz dns data?

I do. If ProReg turns out to be a protocol designed just for Domain
Names, then ProReg is less useful. One of the original discussion I have
with various people to stop calling it RRP for the same reason because
it should be a generic registration protocol, able to register objects
beyond domain names.

Beside, different registry have different policy, different fields in
objects. Unifying all of them is a hopeless utopia dream. IMHO, it is
probably better to define what is common stuff and let the rest of the
registry define their own object schema.

> I made the assumption as those are exactly the problems I'm trying
> to solve, if my state of mind is that interesting.

Your problem is only a subset of all the problems.

> Was there something else, other than several orders of magnitude
> difference in the number of endpoint identifiers, between the RRP
> and whois models, or the rather modest span of known policies in
> either model, which caught your attention? These were the sole
> motivations I gave for mentioning ICANN. If you've some other concern,
> I don't yet know what it is.

I have no issues with ICANN wrt to IP and Names. They are charter to do
that. But policy on those may change or even ICANN may not be around in
a few years. Who knows? What we need is a protocol which is flexible
enough to handle these changes.

Beside, it is best that a technical group dont get involves in the
higher level decision making process.

Secondly, please think beyond DNS. There are other multi-tier model
which could use ProReg such as CA/RA. Keywords system are also getting
popular. And believe it or not, I know of one company which uses RRP for
Email registration.

And why stop there? Any registration you do today can use this in
someway, e.g. Why not registration system for ID, driver license,
passport? No, it is not crazy because I am involved in a project whereby
I am using RRP which would really really stretch the meaning of
registration.

-James Seng

Date: Tue, 23 Jan 2001 12:38:50 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: George Belotsky <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois 
Sender: [email-masked]

My own feeling is different.  I consider that any reasonable
registrar-registry mechanism needs contain mechanisms by which one asks
for the existing registration state.

In the RRP case, that query mechanism is pretty much registrar
asking/registry responding.  And since we've got to leave the door open to
IPv6 and other kinds of data, the data representation needs to be
exensible.

It seems to me that it is only a matter of using that extensibility to
make that same mechanism work so that a client/customer may ask a status
question of a registry or registrar.

The larger issues to me are those of a) identification/authentication of
the parties and b) authorization and privacy.  I'd like to think that we
could be clever enough to invent mechanisms that would handle both
sitations - registrar as status querier and customer as status querier.

It seems to me that much of the issue of authorization and privacy can be
handled by having server implementations call out out policy servers much
as we are starting to do for configuration, QoS, and capacity
provisioning.  My sense is that if one comes up with a well structured
data representation for the queries and responses that one can come up
with a policy definition structure that meshes.

The biggest issue - that of identification/authentication of both the
querier and the responder are, to my mind, the biggest ones.  In the RRP
situation we have a limited set of players making it possible to simply
use sneakernet techniques to get id/auth data to the various participants.

		--karl--

To: Edward Lewis <[email-masked]>
cc: George Belotsky <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Tue, 23 Jan 2001 21:01:39 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

For the  record, I also think that is a bad idea to merge the two.
Foor quite a while I'm taken the position that the registration process
tries to solve something quite different then a (public) whois is lookup 
service.
    
    Note that the charter does not mention Whois by name - there has been no
    discussion up to now about a merging of Whois and RRP.
    
    Is there a copy of the Whois charter available?

I'm not sure wether once was actually made. According to the minutes, it
was only decided that there should another BOF on the subject.

	jaap

Date: Tue, 23 Jan 2001 13:35:40 -0500
From: George Belotsky <[email-masked]>
To: Olivier Guillard / AFNIC <[email-masked]>
Cc: [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Oliver:

Just to make things clear, nobody is proposing to unify the DNS and
Whois.

The discussion here is about unifying the RRP and Whois.

George.

On Tue, Jan 23, 2001 at 07:13:14PM +0100, Olivier Guillard / AFNIC wrote:
> 
> Hi,
> 
> DNS is designed to reference an information
> Whois is designed to provide an information
> 
> It is not a good idea to think about unifying
> two inconsistent issues.
> 
> Regards,
> 
> Olivier
> 
> le 22 Jan, George Belotsky a écrit :
> > Hello, All.
> >  
> > I have recently posted the information below to the Whois list.
> >  
> > The RRP group has made quite a bit of progress on a generic
> > protocol for Registry-Registrar communication.
> >  
> > It would save a lot of duplicated effort if the Whois and RRP
> > protocols could be merged into a single standard.  Registries,
> > Registrars, and end users would then have to contend with a single   
> > protocol, instead of two diverging ones.
> >  
> > At the most fundamental level, both Whois and RRP provide a view into
> > the the repository of information associated with a domain name.  A
> > sufficiently rich protocol would allow for these views to be finely
> > adjusted.  In addition, it would be possible for other views to
> > emerge, as necessity dictates.
> >  
> > Implementation effort, number of bugs, testing and troubleshooting
> > should all be positively affected by having only a single protocol to
> > deal with.  This would surely benefit everyone.
> >  
> > George.
> >  
> > 
> > -----------------------------
> > George Belotsky
> > Senior Software Architect
> > Register.com, inc.
> > [email-masked]
> > 212-798-9127 (phone)
> > 212-798-9876 (fax)
> 
> -- 
> Olivier Guillard
> ---
> ||    A.F.N.I.C.
> || http://www.nic.fr

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Tue, 23 Jan 2001 13:18:55 -0500
From: George Belotsky <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Eric:

The notion of "specific details" is no less general than
"extensibility".  If the "sufficiently specific" material was already
known, there would be no need to discuss designing a new protocol.

In the absence of such a priori knowledge, it becomes necessary to
seek out analogous situations to guide oneself towards the required
specifics.  These specifics are the desired end result, not the
initial starting point.

It is possible to make fine distinctions in virtually any case.
Experience generally shows, however, that a unifying approach is both
simpler and more useful.

There is absolutely no need here to reconcile the specifics of privacy
and data protection with scope-free universalism.  The Whois data is
universally accessible, but restricted in scope.  In operating
systems, for example, there is a huge range of access permissions from
the superuser to a minimally privileged user, sometimes even an
unauthenticated guest user.

Authentication and restricted access are already parts of the
requirement document for this protocol.  There is no reason why there
cannot be a 'guest user' with maximally restricted permissions.

George.

On Tue, Jan 23, 2001 at 12:41:30PM -0500, Eric Brunner-Williams in Portland Maine wrote:
> George,
> 
> The decisions made now will affect rrp implementors _now_.
> 
> One of the failings of "extensibility" (a token periodically emitted
> by bits of the W3C) is its lack of self-description. What is being
> extended? A schema? A state machine? An access control mechanism?
> 
> Reference to rockets, and scientists, living or deceased, are not
> sufficiently specific.
> 
> Since the specifics of privacy/data protection are fundamentally
> scoped (temporally as well as spatially) and hence irreconcillable
> with scope- free universalism(s), let alone any other actual property
> of a rrp or a whois-successor protocol, please accept my "non-hum"
> to the suggestion that A wait on B, etc.
> 
> Eric

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "James Seng/Personal" <[email-masked]>
To: "George Belotsky" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Merging RRP and Whois
Date: Wed, 24 Jan 2001 00:53:12 +0800
Sender: [email-masked]

I like to disagree with merging RRP and WHOIS. I think it is a mistake
to merge the two because basically they are designed to solve different
set of problems. Yes, they are related in the sense that they deals with
Domain Names but the similarity ends there.

RRP (or ProReg) is primarly designed in a enviroment where there is
multi-tier tree model. The registrant will send their registration at
the bottom to their reseller, which will then send the registration
upwards to the next level reseller etc until it reaches the registry.

In WHOIS, the model is more top down. The queries goes to the registry
first and then traverse down the tree. In fact, the referer queries may
not even be top-down and may goes side-ways etc.

Ideally, ProReg should be generic enough without been tied down to just
purely Domain Names Registration. There should be generic where by any
multi-tier registration system could use. Our current implementation of
RFC2832 has been extended to handle objects beyond Domain Names. What is
important to specify at the ProReg is the transcation layer which allows
audit and roll-back.

On the other hand, WHOIS is bascically lookup system. Transcation in
this case is not important and in fact, I wouldnt want to leave an audit
trail of WHOIS.

WHOIS have also a different set of problems to solve, such as bulk
lookup.

-James Seng

----- Original Message -----
From: "George Belotsky" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 24, 2001 12:32 AM
Subject: Re: Merging RRP and Whois

> Eric:
>
> I realize the deadlines involved, but it is also important to
> understand that the decisions made now will affect many people for
> years to come.
>
> It is not by accident that most of the great achievements in modern
> times involved the discovery of some unifying principle.  The process
> of unification allows more general constructs to emerge, and these
> constructs ultimately prove more practically useful than a fragmented
> view.
>
> Deadline pressure is today's universal disease -- I am not aware of
> any recent undertaking that has been given a sufficient amount of time
> (or money, for that matter) to be properly completed.  Even in such an
> environment, however, calm and steadfast respect for the fundamental
> nature of the task at hand is the only thing that can assure success.
>
> The loss of the Space Shuttle Challenger readily comes to mind as an
> example of what happens when fundamental nature is ignored.  As
> Richard Feynman said, nature cannot be fooled.  A looming deadline is
> not a reason to try something dangerous.
>
> In many cases, however, a little thought can safely accomodate a
> deadline.  The RRP-Whois unification is one such case.  Already, the
> RRP is being designed to be an extensible protocol.  Given that the
> Whois deadline is still far away, all that would be needed from the
> RRP group is to recognize that there will be one protocol, and leave
> enough hooks so that the Whois part can eventually be built.
>
> The small effort required to unify the two protocols now will save a
> great deal of effort in the future.
>
> On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in
Portland Maine wrote:
> > George,
> >
> > I brought this up during the BoF in San Diego, if only because I'd
spent
> > the last half of the previous week in Munich with the data
commissioners
> > from Berlin and Schleswig-Holstein ... Jaap made much the same point
in
> > the ietf-whois list w.r.t. the Dutch commissioners in his mail of
Jan 19.
> >
> > Whois (as we know it, aka the absurdly underspecified thingee on
port 43)
> > if used correctly, repurposes and adds 3rd-party recipients to
registrant
> > data, without notice or consent of the registrant.
> >
> > As you note, RRP and Whois both provide views into repositories of
data
> > associated with a transaction, however, the interests of registrants
(and
> > their associated jurisdictions) and the interests of registrars (and
their
> > competitive business models, and eventual liquidators, ala
toysmart's) and
> > the interests of the registries (and their competitive business
models, and
> > eventual successors), aren't trivially reduced to some sensible
service model.
> >
> > I wouldn't assume that the views are equivalent, or the scope of
repository
> > examination (temporal and spatial), or the underlying data, or even
the
> > basic original transaction. Maybe there is just one type of
"original
> > transaction", but I suspect legacy, transfer, bulk and so forth will
have
> > some property which distinguishes them from transactions in which
the role
> > of the registrar is minimal. I'm certain that the underlying data
isn't
> > equivalent, given the repurpose and recipient (marketers, law
enforcement,
> > original jurisdiction) aspects. I'm open on the unified vs disjoint
model
> > for repository examination, and examination ordering. Views just
revisits
> > the purpose and recipient issue, modified by the view construction
policy.
> >
> > One of these two activites is critical infrastructure, the other is
not.
> >
> > One of these two has a hard implementation date, as Ed mentioned,
and the
> > other does not, or has a schedule which requires ICANN's
participation,
> > if not other complications.
> >
> > Cheers,
> > Eric
>
> --
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)

Date: Tue, 23 Jan 2001 11:49:13 -0500
To: George Belotsky <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 11:32 AM -0500 1/23/01, George Belotsky wrote:
>It is not by accident that most of the great achievements in modern
>times involved the discovery of some unifying principle.  The process
>of unification allows more general constructs to emerge, and these
>constructs ultimately prove more practically useful than a fragmented
>view.

OTOH, there have been fatal cases of mission creep.  The OSI Session
Protocol comes to mind.  Also, in the defense industry, adding capability
(night flying) sometimes incurs costs (extra weight) that thwart the
original design (maneuverability/mobility).

I don't doubt that unity is a good thing, but deadlines are real
constraints that need to be factored into engineering decisions.

>In many cases, however, a little thought can safely accomodate a
>deadline.  The RRP-Whois unification is one such case.  Already, the
>RRP is being designed to be an extensible protocol.  Given that the
>Whois deadline is still far away, all that would be needed from the
>RRP group is to recognize that there will be one protocol, and leave
>enough hooks so that the Whois part can eventually be built.

I think this is already addressed in the proposed charter:

# The initial specification will allow multiple registrars to register and
# maintain domain names within multiple Top Level Domains (TLDs).  Subsequent
# versions of the specification will extend the protocol to exchange other
# information needed to organize the Internet, such as IP address allocations.
# 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.

(Eagle-eyed observers may notice a new sentence in there: "Subsequent
versions..."  This was added to an update sent to Patrik this morning - in
case questions of what was meant by "initial specification.")

Note that the charter does not mention Whois by name - there has been no
discussion up to now about a merging of Whois and RRP.

Is there a copy of the Whois charter available?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 23 Jan 2001 11:32:09 -0500
From: George Belotsky <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

Eric:

I realize the deadlines involved, but it is also important to
understand that the decisions made now will affect many people for
years to come.

It is not by accident that most of the great achievements in modern
times involved the discovery of some unifying principle.  The process
of unification allows more general constructs to emerge, and these
constructs ultimately prove more practically useful than a fragmented
view.

Deadline pressure is today's universal disease -- I am not aware of
any recent undertaking that has been given a sufficient amount of time
(or money, for that matter) to be properly completed.  Even in such an
environment, however, calm and steadfast respect for the fundamental
nature of the task at hand is the only thing that can assure success.

The loss of the Space Shuttle Challenger readily comes to mind as an
example of what happens when fundamental nature is ignored.  As
Richard Feynman said, nature cannot be fooled.  A looming deadline is
not a reason to try something dangerous.

In many cases, however, a little thought can safely accomodate a
deadline.  The RRP-Whois unification is one such case.  Already, the
RRP is being designed to be an extensible protocol.  Given that the
Whois deadline is still far away, all that would be needed from the
RRP group is to recognize that there will be one protocol, and leave
enough hooks so that the Whois part can eventually be built.

The small effort required to unify the two protocols now will save a
great deal of effort in the future.

On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in Portland Maine wrote:
> George,
> 
> I brought this up during the BoF in San Diego, if only because I'd spent
> the last half of the previous week in Munich with the data commissioners
> from Berlin and Schleswig-Holstein ... Jaap made much the same point in
> the ietf-whois list w.r.t. the Dutch commissioners in his mail of Jan 19.
> 
> Whois (as we know it, aka the absurdly underspecified thingee on port 43)
> if used correctly, repurposes and adds 3rd-party recipients to registrant
> data, without notice or consent of the registrant. 
> 
> As you note, RRP and Whois both provide views into repositories of data
> associated with a transaction, however, the interests of registrants (and
> their associated jurisdictions) and the interests of registrars (and their
> competitive business models, and eventual liquidators, ala toysmart's) and
> the interests of the registries (and their competitive business models, and
> eventual successors), aren't trivially reduced to some sensible service model.
> 
> I wouldn't assume that the views are equivalent, or the scope of repository
> examination (temporal and spatial), or the underlying data, or even the
> basic original transaction. Maybe there is just one type of "original
> transaction", but I suspect legacy, transfer, bulk and so forth will have
> some property which distinguishes them from transactions in which the role
> of the registrar is minimal. I'm certain that the underlying data isn't
> equivalent, given the repurpose and recipient (marketers, law enforcement,
> original jurisdiction) aspects. I'm open on the unified vs disjoint model
> for repository examination, and examination ordering. Views just revisits
> the purpose and recipient issue, modified by the view construction policy.
> 
> One of these two activites is critical infrastructure, the other is not.
> 
> One of these two has a hard implementation date, as Ed mentioned, and the
> other does not, or has a schedule which requires ICANN's participation,
> if not other complications.
> 
> Cheers,
> Eric

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

To: George Belotsky <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois 
Date: Mon, 22 Jan 2001 18:11:34 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

George,

I brought this up during the BoF in San Diego, if only because I'd spent
the last half of the previous week in Munich with the data commissioners
from Berlin and Schleswig-Holstein ... Jaap made much the same point in
the ietf-whois list w.r.t. the Dutch commissioners in his mail of Jan 19.

Whois (as we know it, aka the absurdly underspecified thingee on port 43)
if used correctly, repurposes and adds 3rd-party recipients to registrant
data, without notice or consent of the registrant. 

As you note, RRP and Whois both provide views into repositories of data
associated with a transaction, however, the interests of registrants (and
their associated jurisdictions) and the interests of registrars (and their
competitive business models, and eventual liquidators, ala toysmart's) and
the interests of the registries (and their competitive business models, and
eventual successors), aren't trivially reduced to some sensible service model.

I wouldn't assume that the views are equivalent, or the scope of repository
examination (temporal and spatial), or the underlying data, or even the
basic original transaction. Maybe there is just one type of "original
transaction", but I suspect legacy, transfer, bulk and so forth will have
some property which distinguishes them from transactions in which the role
of the registrar is minimal. I'm certain that the underlying data isn't
equivalent, given the repurpose and recipient (marketers, law enforcement,
original jurisdiction) aspects. I'm open on the unified vs disjoint model
for repository examination, and examination ordering. Views just revisits
the purpose and recipient issue, modified by the view construction policy.

One of these two activites is critical infrastructure, the other is not.

One of these two has a hard implementation date, as Ed mentioned, and the
other does not, or has a schedule which requires ICANN's participation,
if not other complications.

Cheers,
Eric

Date: Tue, 23 Jan 2001 07:35:53 +0100
From: Stig Venaas <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: George Belotsky <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Merging RRP and Whois
Sender: [email-masked]

On Mon, Jan 22, 2001 at 06:11:34PM -0500, Eric Brunner-Williams in Portland Maine wrote:
> I wouldn't assume that the views are equivalent, or the scope of repository
> examination (temporal and spatial), or the underlying data, or even the
> basic original transaction. Maybe there is just one type of "original
> transaction", but I suspect legacy, transfer, bulk and so forth will have
> some property which distinguishes them from transactions in which the role
> of the registrar is minimal. I'm certain that the underlying data isn't
> equivalent, given the repurpose and recipient (marketers, law enforcement,
> original jurisdiction) aspects. I'm open on the unified vs disjoint model
> for repository examination, and examination ordering. Views just revisits
> the purpose and recipient issue, modified by the view construction policy.

I think one should consider merging the two but as you say the uses are a
bit different. One main difference is that whois must be able to handle
many queries per second and data is only read. I know this is obvious,
but it may restrict our choices.

> One of these two activites is critical infrastructure, the other is not.
>
> One of these two has a hard implementation date, as Ed mentioned, and the
> other does not, or has a schedule which requires ICANN's participation,
> if not other complications.

It might be best to not disturb this work too much, but rather see if
there are parts that can be reused, if it can be simplified for whois
etc.

Stig

Date: Mon, 22 Jan 2001 14:58:14 -0500
To: George Belotsky <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Merging RRP and Whois
Cc: [email-masked]
Sender: [email-masked]

This is an issue that will certainly come up in the IESG.

Probably the number one concern to the members on this list is schedule.
There's a need to have an standard RRP in place soon to meet ICANN's needs.

At 2:15 PM -0500 1/22/01, George Belotsky wrote:
>It would save a lot of duplicated effort if the Whois and RRP
>protocols could be merged into a single standard.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 22 Jan 2001 14:15:11 -0500
From: George Belotsky <[email-masked]>
To: [email-masked]
Subject: Merging RRP and Whois
Sender: [email-masked]

Hello, All.
 
I have recently posted the information below to the Whois list.
 
The RRP group has made quite a bit of progress on a generic
protocol for Registry-Registrar communication.
 
It would save a lot of duplicated effort if the Whois and RRP
protocols could be merged into a single standard.  Registries,
Registrars, and end users would then have to contend with a single   
protocol, instead of two diverging ones.
 
At the most fundamental level, both Whois and RRP provide a view into
the the repository of information associated with a domain name.  A
sufficiently rich protocol would allow for these views to be finely
adjusted.  In addition, it would be possible for other views to
emerge, as necessity dictates.
 
Implementation effort, number of bugs, testing and troubleshooting
should all be positively affected by having only a single protocol to
deal with.  This would surely benefit everyone.
 
George.

-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Mon, 22 Jan 2001 10:59:50 -0500
To: Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Meeting notice and other proto-WG items
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

UPDATING the information included below, we now have a room reserved:

Washington Dulles Airport Marriott for Tuesday
20 February, 10am - 5pm.  Hotel details here:

http://www.marriotthotels.com/dpp/PropertyPage.asp?MarshaCode=IADAP

Note the different date (one day earlier).

At 4:35 PM -0500 1/21/01, Edward Lewis wrote:
>Officially we are still in limbo, but we are getting close.
>
>First, a few of us are working towards setting up an interim meeting in the
>Washington DC area on or about Feb 21.  The closet airport is Dulles (IAD).
>You may want to either being making arrangements for this or keep an eye
>out for the announcement on ietf-announce.  (Making ietf-announce is
>important because that reaches a wider audience than just this list.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: New Requirements Draft Available
Date: Mon, 22 Jan 2001 07:08:29 -0500
Sender: [email-masked]

The updated requirements draft can now be found in the I-D archives:

http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-06.txt

<Scott/>

To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Meeting notice and other proto-WG items 
Date: Sun, 21 Jan 2001 19:40:41 -0500
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

Ed,

> ... security concerns (privacy as opposed to
> transactions)

Yup. Lets be sure to cover the transaction-independent data collection
policy, as well as the transaction-specific policy.

Eric

Date: Sun, 21 Jan 2001 14:25:53 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Meeting notice and other proto-WG items
Sender: [email-masked]

Ed,

> Other topics that might be useful are short presentations on how some
> registries operate with regards to registrars (I doubt that we'd have time
> for good coverage of that though), security concerns (privacy as opposed to
> transactions), extensibility of the protocol to other (non-domain name)
> data.

I would prefer not to have presentations at the meetings but discussions.
If one of the topics include how various registries operate that would be
fine. I would prefer that the registries submit papers or I-Ds BEFORE the
meeting so that we can have the oppertunity to read and comment on them.

I feel that this meeting should have a well defined agenda and
deliverables, presentations IMHO are just fluff that would detract from us
realizing real work.

-rick

Date: Sun, 21 Jan 2001 16:35:35 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Meeting notice and other proto-WG items
Cc: [email-masked]
Sender: [email-masked]

Officially we are still in limbo, but we are getting close.

First, a few of us are working towards setting up an interim meeting in the
Washington DC area on or about Feb 21.  The closet airport is Dulles (IAD).
You may want to either being making arrangements for this or keep an eye
out for the announcement on ietf-announce.  (Making ietf-announce is
important because that reaches a wider audience than just this list.)

Second, our charter is now "before" the IESG.  They meet in a few days to
discuss it.  I sent the charter as it was on this list about 1-2 weeks ago,
but I will need to edit it - e.g., to remove the references to the draft
documents.  (Drafts get retired, hence they aren't really eligible to be
refered documents.)  More changes may be needed in response to the IESG
comments.

Third, I am trying to get a 1-hour meeting slot at the Minneapolis IETF.
(BTW, http://www.ietf.org will have information on that meeting beginning
Monday the 22nd.)

PS - For the interim meeting, I am thinking of starting around 10am and
going the full day (about 5pm).  For those arriving from Europe, there are
a number of flights departing Dulles around 6pm (1800) for Europe, so if
there is a desire to shut the meeting down earlier we can try to accomodate
this.

I think the agenda will be:
     Agenda bashing: (short)
     WG status: (short)
     The EPP proposal
     Other proposals
     Discussion of forming a design team

Other topics that might be useful are short presentations on how some
registries operate with regards to registrars (I doubt that we'd have time
for good coverage of that though), security concerns (privacy as opposed to
transactions), extensibility of the protocol to other (non-domain name)
data.

Let me know what should be on the agenda...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Updated Requirements Draft
Date: Fri, 19 Jan 2001 10:50:44 -0500
Sender: [email-masked]

I sent an updated requirements draft (draft-hollenbeck-grrp-reqs-06.txt) to
the I-D administrator earlier this morning.  Watch the usual places for the
publication announcement on Monday morning.

Liman or Patrik: could one of you put it up on the provreg web site today if
I send you a copy?

<Scott/>

Date: Fri, 19 Jan 2001 09:08:38 -0500
To: Jaap Akkerhuis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: Dave Crocker <[email-masked]>, Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Sender: [email-masked]

At 2:22 PM +0100 1/19/01, Jaap Akkerhuis wrote:
>Hi SCott,
>
>     The VeriSign gTLD registry is one.  While we're functioning
>     with the existing NSI RRP, there are needed improvements and
>     additional capabilities that require use of a new protocol.
>
>Yes of course. But I was wondering wether there are more. This to
>avoid discussions like ``these monopolistic idiots of NSI are
>forcing us to do this and we now need to invest in this technology
>but we don't have money, they want to kill us, they took over the
>IETF, look what they did with the power situation in California,
>global warning'' and similar rants.
>
>I vaguely remember once discussing the idea of a registration
>protocol with another registry quite some time ago but forgot which
>one.

Over the next few months, it is likely that several new gTLDs will be 
appearing (the seven provisionally approved by the ICANN board). 
Many of these emerging TLDs would very much like to implement a 
standard RRP, but there's also the market reality that these new 
registries have to get up and running in the relatively near future. 
That means that the window of opportunity for us to get this protocol 
adopted in a number of places very quickly (which I think would be 
nice, and give us some good operational experience for other TLDs who 
already have registration mechanisms in place) is rapidly closing.

>Another group which should be interested is the other R in RRP:
>the registrars. Registrars which deal with different TLD's have
>questioned why there is not a standard way to register domains and
>that it is a lot of work to figure out the different procedures
>etc.  Although, when they have figured it out they loose interest.
>(Because now this knowledge gives them an advantage over competitor,
>as one told me).

We have been using the NSI RRP for as long as anyone except NSI, and 
have extensive experience doing registrations with a lot of ccTLDs, 
but I can tell you categorically that we would much rather have a 
common protocol than leverage whatever minor competitive advantage 
you think we might be able to eek out of the existing arrangement.

As a registrar, we want a gRRP soon--in time for the new gTLDs to 
implement them so we don't have to write code and do extensive 
testing with a bunch of new gTLDS, and also to deal with the 
increasing number of ccTLDs that it seems will be adopting 
registry/registrar models.  This means we want a robust protocol that 
supports the needs of both the gTLDs and the ccTLDs, and we want it 
to do a good job, but a lot of the benefit is lost for us if we don't 
have something fairly well hammered out in the very near future.

Jordyn

Date: Fri, 19 Jan 2001 14:50:41 +0100
From: Patrick <[email-masked]>
To: Jaap Akkerhuis <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, Dave Crocker <[email-masked]>, Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Registries in need of new protocols...
Organization: Gandi
Sender: [email-masked]

On Fri, Jan 19, 2001 at 02:22:03PM +0100, Jaap Akkerhuis took time to write:
>     The VeriSign gTLD registry is one.  While we're functioning
>     with the existing NSI RRP, there are needed improvements and
>     additional capabilities that require use of a new protocol.
>
> Yes of course. But I was wondering wether there are more. This to

As far as I understand most of the Registries of the new 7 gTLD, in
their presentation[1] said they are thinking of other protocols
(besides using RRP at least for the beginning to start the pump).

.NAME for one will support RRP and their own SRRP (Stateless RRP)

Maybe it can be useful to see what they have in mind (they plan to go
for a RFC to have it as a standard, AFAIK).

Some of these new Registries plan to go online on Q2 2001.

.EU is also slowly taking shape. We are not at the stage of knowing
who will be the Registry and how it will work, but it will need a
protocol for reservation, that is for sure, without needing past
compatibility, since it will be a brand new Registry and TLD.

> Registrars which deal with different TLD's have
> questioned why there is not a standard way to register domains and
> that it is a lot of work to figure out the different procedures
> etc.  Although, when they have figured it out they loose interest.
> (Because now this knowledge gives them an advantage over competitor,
> as one told me).

I'm working in an ICANN Registrar. It is true it's hard to support many TLD,
no two are doing the same. Some ccTLD are doing registrations by
email for example (.be or .uk come in mind).

In our case, we are now developing an abstract registry interface[2],
able to cope with different registries and different protocols, in a
transparent way for the application.

We are still very much interested to have a standard well designed
way for registering all TLDs ;-)

Patrick, lurker on this list but very interested/concerned by this WG

[1] http://www.ec-pop.org/20010111/index.htm
[2] in the same vein as DBI/DBD under Perl, or ODBC for example.

To: "Hollenbeck, Scott" <[email-masked]>
cc: Dave Crocker <[email-masked]>, Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Why Interim Meetings? 
Date: Fri, 19 Jan 2001 14:22:03 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Hi SCott,

    The VeriSign gTLD registry is one.  While we're functioning
    with the existing NSI RRP, there are needed improvements and
    additional capabilities that require use of a new protocol.

Yes of course. But I was wondering wether there are more. This to
avoid discussions like ``these monopolistic idiots of NSI are
forcing us to do this and we now need to invest in this technology
but we don't have money, they want to kill us, they took over the
IETF, look what they did with the power situation in California,
global warning'' and similar rants.

I vaguely remember once discussing the idea of a registration
protocol with another registry quite some time ago but forgot which
one.

Another group which should be interested is the other R in RRP:
the registrars. Registrars which deal with different TLD's have
questioned why there is not a standard way to register domains and
that it is a lot of work to figure out the different procedures
etc.  Although, when they have figured it out they loose interest.
(Because now this knowledge gives them an advantage over competitor,
as one told me).

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving ahead
Date: Fri, 19 Jan 2001 06:59:48 -0500
Sender: [email-masked]

I'll have an individual submission update sent to the I-D administrator
later today.

<Scott/>

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 8:25 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: Moving ahead
> 
> 
> If you feel it is time for a new version, do it as an individual
> submission.  I've heard nothing on the state of the charter 
> (positive or
> negative).  I had been expecting something by two days ago.  
> That and my
> being tied up the last few days on something kept me from replying.
> 
> My guess is that the WG status won't be discussed for at 
> least a week, so
> let's count on doing more pre-WG activity.
> 
> As far as an in person meeting, I will see what kind of 
> meeting(s) will not
> cause heart burn.  I'll have something tomorrow.
> 
> At 1:44 PM -0500 1/18/01, Hollenbeck, Scott wrote:
> >I've been awaiting guidance from our (proposed) chairs 
> related to submitting
> >an updated requirements draft as an individual submission or 
> as a WG draft
> >before moving forward.  If we're still in limbo regarding WG 
> status, perhaps
> >doing another individual submission is the way to go.
> >
> ><Scott/>
> >
> >-----Original Message-----
> >From: Paul George [mailto:[email-masked]]
> >Sent: Thursday, January 18, 2001 10:37 AM
> >To: [email-masked]
> >Subject: Moving ahead
> >
> >
> >Seems the group is very quiet. :-)
> >
> >Scott, perhaps now is a good time to share the latest 
> revision with the
> >mailing list so we can all say yea or nay??
> >
> >Paul George
> >SARAF Software Solutions
> >(703)538-5666 x234
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> Dilbert is an optimist.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>, Dave Crocker <[email-masked]>
Cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: RE: Why Interim Meetings? 
Date: Fri, 19 Jan 2001 06:57:24 -0500
Sender: [email-masked]

Jaap,

The VeriSign gTLD registry is one.  While we're functioning with the
existing NSI RRP, there are needed improvements and additional capabilities
that require use of a new protocol.

<Scott/>

> -----Original Message-----
> From: Jaap Akkerhuis [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 5:22 AM
> To: Dave Crocker
> Cc: Edward Lewis; Ietf-Provreg
> Subject: Re: Why Interim Meetings? 
> 
> 
>     
>     Let me help:  Some registries need the specification yesterday.
> 
> I heard this claim before, can you provide some details about this?
> Which registries need this yesterday. It seems that a lot of the
> existing TLD's are still able to cope without this.
> 
> 	jaap

To: Dave Crocker <[email-masked]>
cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Why Interim Meetings? 
Date: Fri, 19 Jan 2001 11:21:51 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Let me help:  Some registries need the specification yesterday.

I heard this claim before, can you provide some details about this?
Which registries need this yesterday. It seems that a lot of the
existing TLD's are still able to cope without this.

	jaap

To: Dave Crocker <[email-masked]>
cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Why Interim Meetings? 
Date: Fri, 19 Jan 2001 11:14:15 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    If the meeting is for Design Team work, then it is closed.
    That is, it is by invitation only.  That is the nature of design
    teams.

    If the meeting is a full working group meeting, then there
    needs to be significant advance notice and an agenda, so people
    can determine what work will be done at the meeting.

My preference is that if there will be an interim meeting, it should
be an open meeting. I hear too often from existing TLD registries
that they feel locked out in this.

	jaap

Date: Thu, 18 Jan 2001 20:44:32 -0500
To: Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Moving ahead
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 8:24 PM -0500 1/18/01, Edward Lewis wrote:
>As far as an in person meeting, I will see what kind of meeting(s) will not
>cause heart burn.  I'll have something tomorrow.

I just realized, I won't have connectivity tomorrow...I'll have something soon.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 18 Jan 2001 20:24:57 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Moving ahead
Cc: [email-masked]
Sender: [email-masked]

If you feel it is time for a new version, do it as an individual
submission.  I've heard nothing on the state of the charter (positive or
negative).  I had been expecting something by two days ago.  That and my
being tied up the last few days on something kept me from replying.

My guess is that the WG status won't be discussed for at least a week, so
let's count on doing more pre-WG activity.

As far as an in person meeting, I will see what kind of meeting(s) will not
cause heart burn.  I'll have something tomorrow.

At 1:44 PM -0500 1/18/01, Hollenbeck, Scott wrote:
>I've been awaiting guidance from our (proposed) chairs related to submitting
>an updated requirements draft as an individual submission or as a WG draft
>before moving forward.  If we're still in limbo regarding WG status, perhaps
>doing another individual submission is the way to go.
>
><Scott/>
>
>-----Original Message-----
>From: Paul George [mailto:[email-masked]]
>Sent: Thursday, January 18, 2001 10:37 AM
>To: [email-masked]
>Subject: Moving ahead
>
>
>Seems the group is very quiet. :-)
>
>Scott, perhaps now is a good time to share the latest revision with the
>mailing list so we can all say yea or nay??
>
>Paul George
>SARAF Software Solutions
>(703)538-5666 x234

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Moving ahead
Date: Thu, 18 Jan 2001 13:44:17 -0500
Sender: [email-masked]

I've been awaiting guidance from our (proposed) chairs related to submitting
an updated requirements draft as an individual submission or as a WG draft
before moving forward.  If we're still in limbo regarding WG status, perhaps
doing another individual submission is the way to go.

<Scott/> 

-----Original Message-----
From: Paul George [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 10:37 AM
To: [email-masked]
Subject: Moving ahead

Seems the group is very quiet. :-)

Scott, perhaps now is a good time to share the latest revision with the
mailing list so we can all say yea or nay??

Paul George
SARAF Software Solutions
(703)538-5666 x234

Date: Thu, 18 Jan 2001 09:03:57 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Sender: [email-masked]

At 11:41 AM 1/18/2001 -0500, Edward Lewis wrote:
>Here's the deal.  I have not heard anything regarding the charter, hence we
>are still not an IETF WG.  I've been trying to balance "jumping the gun" on
>an IETF decision (as that may have a negative impact) with leaving enough
>time to make this meeting happen.

Official approval of a working group is, of course, significant.  On the 
other hand a desire to meet aggressive schedules thoroughly justifies 
conducting the group as if it were already chartered.  As long as it 
follows IETF procedures, the worst that can be said is that it is an open, 
extremely fair, private process...

>Without an IETF acceptance of the charter, I believe that it would be
>improper to have a *closed door* meeting as this would give the appearance
>of a small group trying to push through a "special interest" through the
>standards body.

It is never improper for a private group to meet and discuss whatever they 
want (except price-fixing and violent government overthrow, but that's a 
bit out of our scope...)  It IS improper for such a group to pursue its 
work coercively.

That is, a closed design team is a perfectly reasonable thing to have, as 
long as it follows IETF rules, namely that the team is fully responsive to 
the larger "working group" consensus.

>Another reason that I feel that a closed door meeting would send the wrong
>message is that we would be vulnerable to a charge that we didn't invite
>folks from a wide enough pool of interested parties.

Anyone is free to create their own design team and put the result before 
the larger, open working group.

If there is good reason to believe that a fully open meeting can achieve 
consensus, on requirements, specification, or whatever, without having 
design team input, then the right thing to do is have an open "working 
group" meeting.

It all depends on what works best... as long as the larger, open group 
retain real control over final decisions.

>As our effort has not
>been publicized on an IETF sanctioned channel (ietf-announce,
>www.ietf.org), some folks could argue that we haven't gone far enough in
>trying to get a broad base of input.

If the meeting is to be open, then yes it needs to be fully announced.

>Mind you, I am saying this as an IETF process puppet. (;))

Me too.  (I wrote about half of the original IETF standards process 
document, and co-authored the original Guidelines for Working Group Chairs.)

>To put this in perspective, there are two influences here.  One is the IETF
>desire to arrive at consensus through the right means and produce a
>protocol specification - this is a process I can quantify (if not fully
>explain).  The other group desire is the need to hurry along.  Although I
>know of this desire, I can't say I can quantify it in sufficient detail to
>help me negotiate our way through the IETF process.

Let me help:  Some registries need the specification yesterday.

>What I am asking here
>is for more information from folks quantifying why this effort should be
>"sped up."  If you want to send me this off-list, that's fine.

Can't hurt to issue an explicit, targeted query about urgency, separate 
from this message thread.

>For what it
>is worth, if I know of deadlines, I may be able to use this when working
>the process.

Excellent point.

>I do think that dynamic interaction (whether face-to-face or via phone) is
>beneficial at this point.  I just don't want to jeopardize WG status
>establishment.

Agreed, but I don't believe that running a working group as a working group 
-- as long as the usual rules are employed -- should offend anyone...

         unless there is serious reason to believe that the charter will 
undergo major changes.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Thu, 18 Jan 2001 11:41:17 -0500
To: Dave Crocker <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Sender: [email-masked]

Here's the deal.  I have not heard anything regarding the charter, hence we
are still not an IETF WG.  I've been trying to balance "jumping the gun" on
an IETF decision (as that may have a negative impact) with leaving enough
time to make this meeting happen.

Without an IETF acceptance of the charter, I believe that it would be
improper to have a *closed door* meeting as this would give the appearance
of a small group trying to push through a "special interest" through the
standards body.

Another reason that I feel that a closed door meeting would send the wrong
message is that we would be vulnerable to a charge that we didn't invite
folks from a wide enough pool of interested parties.  As our effort has not
been publicized on an IETF sanctioned channel (ietf-announce,
www.ietf.org), some folks could argue that we haven't gone far enough in
trying to get a broad base of input.

Mind you, I am saying this as an IETF process puppet. (;))

To put this in perspective, there are two influences here.  One is the IETF
desire to arrive at consensus through the right means and produce a
protocol specification - this is a process I can quantify (if not fully
explain).  The other group desire is the need to hurry along.  Although I
know of this desire, I can't say I can quantify it in sufficient detail to
help me negotiate our way through the IETF process.  What I am asking here
is for more information from folks quantifying why this effort should be
"sped up."  If you want to send me this off-list, that's fine.  For what it
is worth, if I know of deadlines, I may be able to use this when working
the process.  (I can't promise that it would help, but if y'all are willing
to let me know, I'd like to hear something more than rumors.)

I do think that dynamic interaction (whether face-to-face or via phone) is
beneficial at this point.  I just don't want to jeopardize WG status
establishment.

At 10:57 AM -0500 1/18/01, Dave Crocker wrote:
>At 06:04 PM 1/12/2001 -0500, Edward Lewis wrote:
>>I believe that this is the consensus on the meetings so far:
>
>What is the final plan?  If there is to be an interim meeting, people need
>to know the logistics.
>
>If the meeting is for Design Team work, then it is closed.  That is, it is
>by invitation only.  That is the nature of design teams.
>
>If the meeting is a full working group meeting, then there needs to be
>significant advance notice and an agenda, so people can determine what work
>will be done at the meeting.
>
>d/

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 18 Jan 2001 07:57:50 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: Ietf-Provreg <[email-masked]>
Sender: [email-masked]

At 06:04 PM 1/12/2001 -0500, Edward Lewis wrote:
>I believe that this is the consensus on the meetings so far:

What is the final plan?  If there is to be an interim meeting, people need 
to know the logistics.

If the meeting is for Design Team work, then it is closed.  That is, it is 
by invitation only.  That is the nature of design teams.

If the meeting is a full working group meeting, then there needs to be 
significant advance notice and an agenda, so people can determine what work 
will be done at the meeting.

d/

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: Moving ahead
Date: Thu, 18 Jan 2001 10:37:11 -0500
Importance: Normal
Sender: [email-masked]

Seems the group is very quiet. :-)

Scott, perhaps now is a good time to share the latest revision with the
mailing list so we can all say yea or nay??

Paul George
SARAF Software Solutions
(703)538-5666 x234

Date: Mon, 15 Jan 2001 17:26:04 +0100
From: Olivier Guillard / AFNIC <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Technical (was: security, authorization, definition, etc.)
Sender: [email-masked]

le 11 Jan, [email-masked] a écrit :

> This one entity could be the registry, could be a
> registrar, could be the registrant, what have you
> depending on the (busines) model.
> From the technical point of view, we don't really
> care. As long as we can make sure that only *one*
> entity can make changes, right.

I really do agree with you, that why "rrp" is *not*
the proper name for a protocole aimed to update the
DNS database.

DNS is a db, we know what information is required
to delegate a new domains (basically 2 ns) on the
net.

On the other hand, under some TLD, there might not
have have any registrars but a single entity (.mu),
under other their might not have any delegation
without a validation done by a third party that is
not a registrar nor the registry and so on.
In all case their should have an interface plugged
to the db to update it be it should not be formally
designated as a "registry-registrar protocol".

Regards,

-- 
Olivier Guillard
---
||    A.F.N.I.C.
|| http://www.nic.fr
|| mailto:[email-masked]

Date: Fri, 12 Jan 2001 23:20:17 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 06:04 PM 1/12/2001 -0500, Edward Lewis wrote:
>Do we have volunteers to host the European and Asia/Pacific meetings?

Having one interim IETF working group meeting is a big deal.  Having 
multiple, at around the same time, is probably unprecedented.

The fact that IETF working groups are inclusive forces the assumption that 
everyone can legitimately consider coming to an interim meeting.  Planning 
multiple meetings, for the same time, according to geography, runs counter 
to that.

My comments about Asia were based on noting that a number of people said 
they would already be in the area.  Hence the suggestion was to have the 
meeting near a already-planned event, rather than separately.

>I would also like to request that as part of these meetings, reports of the
>discussions be made available to the mailing list.  Because of the

As an official activity of the IETF, meeting notes are required to be 
submitted to the Secretariat.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Sun, 14 Jan 2001 16:32:20 -0500
To: Elisabeth Porteneuve <[email-masked]>, [email-masked]
From: Marc Blanchet <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: [email-masked]
Sender: [email-masked]

At/À 08:48 2001-01-13 +0100, Elisabeth Porteneuve you wrote/vous écriviez:

>For your information here is the known schedule for ccTLD meetings
>in January-February:
>
>       22 Jan: CENTR Technical Workshop in Amsterdam (attached to RIPE)
>    23-26 Jan: RIPE 38, Amsterdam,
>    30-31 Jan: MINC Workshop in Honolulu, Hawaii
>        1 Feb: ccTLD-ICANN meeting in Asia-Pac (see 19 Feb), Honolulu, Hawaii
>     2- 3 Feb: Study Session on ICANN in Zurich (some ccTLD involved)
>        5 Feb: CENTR Legal meeting (attached to Zurich)
>       19 Feb: ccTLD-ICANN meeting in Europe (see 1 Feb), Geneva, Switzerland
>       20 Feb: ccTLD-WIPO meeting in Geneva, Switzerland
>       21 Feb: meeting place reserved in Geneva, if ccTLD wants discuss more
>    22-23 Feb: CENTR GA meeting in Guernsay, British Channel Islands
>               (important meetings, ExCom re-election)
>March:
>        9 Mar: ccTLD meeting prior to ICANN Melbourne, in Melbourne, Australia
>    10-13 Mar: ICANN Melbourne
>    18-23 Mar: IETF Minnessota, USA
>
>Looks overloaded ...

- not necessarily the exact same set of people.
- maybe just-before-ietf can be something reasonable.

Regards, Marc.

>Elisabeth Porteneuve
>--
>
> > From [email-masked] Sat Jan 13 00:12 MET 2001
> > X-Sender: [email-masked]
> > Message-Id: <v0313030eb684e028a5fc@[10.33.10.145]>
> > Date: Fri, 12 Jan 2001 18:04:42 -0500
> > To: Ietf-Provreg <[email-masked]>
> > From: Edward Lewis <[email-masked]>
> > Subject: Why Interim Meetings?
> > Cc: [email-masked]
> >
> > I believe that this is the consensus on the meetings so far:
> >
> > 1) The requirements will largely be settled by then, so a requirements
> > discussion would NOT be on the agenda.
> >
> > 2) The discussion of the implementation of the protocol, starting from the
> > EPP proposal, is to be the primary item on the agenda.  Essentially, a
> > design meeting.
> >
> > 3) The desire is to get broad input.  A meeting is to be held in Washington
> > DC between Feb 19 and 22.  Meetings have been discussed in Europe for the
> > ccTLDs and in Asia/Pacific, possibly representing the ICANN gTLDs.
> >
> > 4) The meetings should be scheduled between Feburary and the March IETF.
> >
> > Do we have volunteers to host the European and Asia/Pacific meetings?
> >
> > I would also like to request that as part of these meetings, reports of the
> > discussions be made available to the mailing list.  Because of the
> > geographic extent of the meetings, many of the interested parties will not
> > be able to attend all of them.
> >
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Edward Lewis                                                NAI Labs
> > Phone: +1 443-259-2352                      Email: [email-masked]
> >
> > Dilbert is an optimist.
> >
> > Opinions expressed are property of my evil twin, not my employer.
> >
> >
> >

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

Date: Sat, 13 Jan 2001 08:48:52 +0100 (MET)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Why Interim Meetings?
Sender: [email-masked]

For your information here is the known schedule for ccTLD meetings
in January-February:

      22 Jan: CENTR Technical Workshop in Amsterdam (attached to RIPE)
   23-26 Jan: RIPE 38, Amsterdam, 
   30-31 Jan: MINC Workshop in Honolulu, Hawaii
       1 Feb: ccTLD-ICANN meeting in Asia-Pac (see 19 Feb), Honolulu, Hawaii
    2- 3 Feb: Study Session on ICANN in Zurich (some ccTLD involved)
       5 Feb: CENTR Legal meeting (attached to Zurich)
      19 Feb: ccTLD-ICANN meeting in Europe (see 1 Feb), Geneva, Switzerland
      20 Feb: ccTLD-WIPO meeting in Geneva, Switzerland
      21 Feb: meeting place reserved in Geneva, if ccTLD wants discuss more
   22-23 Feb: CENTR GA meeting in Guernsay, British Channel Islands
              (important meetings, ExCom re-election)
March:
       9 Mar: ccTLD meeting prior to ICANN Melbourne, in Melbourne, Australia
   10-13 Mar: ICANN Melbourne
   18-23 Mar: IETF Minnessota, USA

Looks overloaded ...
Elisabeth Porteneuve
--

> From [email-masked] Sat Jan 13 00:12 MET 2001
> X-Sender: [email-masked]
> Message-Id: <v0313030eb684e028a5fc@[10.33.10.145]>
> Date: Fri, 12 Jan 2001 18:04:42 -0500
> To: Ietf-Provreg <[email-masked]>
> From: Edward Lewis <[email-masked]>
> Subject: Why Interim Meetings?
> Cc: [email-masked]
> 
> I believe that this is the consensus on the meetings so far:
> 
> 1) The requirements will largely be settled by then, so a requirements
> discussion would NOT be on the agenda.
> 
> 2) The discussion of the implementation of the protocol, starting from the
> EPP proposal, is to be the primary item on the agenda.  Essentially, a
> design meeting.
> 
> 3) The desire is to get broad input.  A meeting is to be held in Washington
> DC between Feb 19 and 22.  Meetings have been discussed in Europe for the
> ccTLDs and in Asia/Pacific, possibly representing the ICANN gTLDs.
> 
> 4) The meetings should be scheduled between Feburary and the March IETF.
> 
> Do we have volunteers to host the European and Asia/Pacific meetings?
> 
> I would also like to request that as part of these meetings, reports of the
> discussions be made available to the mailing list.  Because of the
> geographic extent of the meetings, many of the interested parties will not
> be able to attend all of them.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> Dilbert is an optimist.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
> 
> 

Date: Fri, 12 Jan 2001 19:24:05 -0500
To: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
From: Marc Blanchet <[email-masked]>
Subject: Re: Why Interim Meetings?
Cc: [email-masked]
Sender: [email-masked]

At/À 18:04 2001-01-12 -0500, Edward Lewis you wrote/vous écriviez:
>I believe that this is the consensus on the meetings so far:
>
>1) The requirements will largely be settled by then, so a requirements
>discussion would NOT be on the agenda.
>
>2) The discussion of the implementation of the protocol, starting from the
>EPP proposal, is to be the primary item on the agenda.  Essentially, a
>design meeting.
>
>3) The desire is to get broad input.  A meeting is to be held in Washington
>DC between Feb 19 and 22.  Meetings have been discussed in Europe for the
>ccTLDs and in Asia/Pacific, possibly representing the ICANN gTLDs.
>
>4) The meetings should be scheduled between Feburary and the March IETF.

phone (or equivalent) bridge should be available, in order to get the best 
input from people that cannot attend.

Regards, Marc.

>Do we have volunteers to host the European and Asia/Pacific meetings?
>
>I would also like to request that as part of these meetings, reports of the
>discussions be made available to the mailing list.  Because of the
>geographic extent of the meetings, many of the interested parties will not
>be able to attend all of them.
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: +1 443-259-2352                      Email: [email-masked]
>
>Dilbert is an optimist.
>
>Opinions expressed are property of my evil twin, not my employer.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

Date: Fri, 12 Jan 2001 18:04:42 -0500
To: Ietf-Provreg <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Why Interim Meetings?
Cc: [email-masked]
Sender: [email-masked]

I believe that this is the consensus on the meetings so far:

1) The requirements will largely be settled by then, so a requirements
discussion would NOT be on the agenda.

2) The discussion of the implementation of the protocol, starting from the
EPP proposal, is to be the primary item on the agenda.  Essentially, a
design meeting.

3) The desire is to get broad input.  A meeting is to be held in Washington
DC between Feb 19 and 22.  Meetings have been discussed in Europe for the
ccTLDs and in Asia/Pacific, possibly representing the ICANN gTLDs.

4) The meetings should be scheduled between Feburary and the March IETF.

Do we have volunteers to host the European and Asia/Pacific meetings?

I would also like to request that as part of these meetings, reports of the
discussions be made available to the mailing list.  Because of the
geographic extent of the meetings, many of the interested parties will not
be able to attend all of them.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Some more comments on your grrp-reqs-05.txt (second try) 
Date: Fri, 12 Jan 2001 15:41:48 -0500
Sender: [email-masked]

Jaap,

I concur with all of your suggestions.  I'll change the lock state stuff to
a MAY to note that these are suggestions, and I'll leave the SHOULD in the
"human intervention" section (which was added some time ago at the request
of Olivier, I believe).  The Zulu stuff and format example (which again
looks more like _how_ than _what_) will be changed as well.

<Scott/> 

-----Original Message-----
From: Jaap Akkerhuis [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:49 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Some more comments on your grrp-reqs-05.txt (second try) 

Hi Scott,

Some comments over the last part of the draft.

	jaap

About 3.12 Lock status Indicators

At 3.12.[1] there is quite a list of indicators the MUST be
provided. It might well be possible that some of these states are
in fact mandated by the policies of the registry. Further more, it
is all concentrated on ``the domain''. Does this mean the domain
it self, the data associated with this or both?

We (.nl) do have
several types of lock states:

	a) domain holder might non-be changed but name server
	   changes are allowed and domain is published

	b) domain might not be transferred between registrars but other
	   changes are allowed

	c) domain is reserved by the registry (things like .co.nl,
	   .com.nl etc.)

	d) domain is blocked for registration (things like
	   killthequeen.nl etc.)

	e) more you don't want to know about

Maybe a MAY should be used in the second sentence.

8.2.[1] ... SHOULD operate without human intervention.

This going to be difficult for registries which have heavy policies.
Some registries might have policies that requires human intervention.
For instance, it might be necessary that information is needed
which cannot be serviced by the protocol. As an example, the registry
might need to check a Dun & Broadsheet document if only commercial
entities are aloud in .com.XX or a trademark ownership proof for
a .tm.XX. For these type of registries it will be difficult to do
that. But maybe the SHOULD here covers that.

8.4

I would leave out the Zulu stuff. That is way too much an American
culture thing. So drop it also from the time format. BTW, Isn't
there already an IETF standard how time formats are described (ntp
RFC)?

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Marcos Sanz/Denic'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RE: comments on your grrp-reqs-05.txt (second try)
Date: Fri, 12 Jan 2001 15:38:09 -0500
Sender: [email-masked]

True, but that's also why we have list archives!

Ed and I talked about this recently, and truth be told I can publish a new
version of the requirements draft that reflects agreed-to changes in very
short order.  Ed asked if the next version of the draft could include a name
change to reflect our move to WG status, and I agreed to proceed that way.
The WG doesn't yet exist, though, so I can't publish the draft with a WG
name quite yet.

I don't mind pushing out one more individual submission version before we
move it to a WG version if that would help.  Let me see how Ed and Jaap
would like to proceed.

<Scott/> 

-----Original Message-----
From: Marcos Sanz/Denic [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:58 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: RE: comments on your grrp-reqs-05.txt (second try)

On 10.01.01 14:37 "Hollenbeck, Scott" <[email-masked]> wrote:
> We earlier discussed bagging this requirement completely because it
> describes registry implementation detail.  I'd prefer to delete it than
> reword it.

It might be useful if a draft is posted with all agreed changes up to now,
before we start wasting time by looping over the same issues again and
again.

Marcos Sanz

Date: Fri, 12 Jan 2001 10:31:33 -0500
To: "Paul George" <[email-masked]>, "Ietf-Provreg" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: Interim meeting: was RE: Charter last call summary
Sender: [email-masked]

At 08:18 AM 1/12/2001 -0500, Paul George wrote:
>At first, I thought this was to be a "quickie" meeting to be held asap to
>finalize the RRP Requirements.  But more and more emails I see refer to this
>as a design meeting to be help as soon as the Reqs are done.  I am confused.

Generally I think we are close to consensus on Requirements.

>If the Reqs are so close to being completed, then I agree a meeting is not
>necessary and we should list all outstanding "issues" with the Reqs as they
>are right now and get to work on them and finish up.

A. Yes we should list all of the outstanding issues ..if there are any.

B. Beyond that there is a market not to mention a political ( ICANN proof 
of concept) problem here that needs to be solved ASAP..and a preliminary 
design meeting to flush out some thinking among the community IMHO is 
essential and I continue to support a off site meeting here in the DC area 
the week of Feb 19 -23... final date to be determined.

>If there are still lots of issues with the Reqs, then perhaps we should meet
>in the next week to finalize that first??
>
>Paul George
>SARAF Software Solutions
>(703)538-5666 x234
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Hollenbeck, Scott
>Sent: Friday, January 12, 2001 8:09 AM
>To: Ietf-Provreg
>Subject: RE: Interim meeting: was RE: Charter last call summary
>
>
>Are we looking to have an interim WG session or a design team session?

IMHO a design team...

>Location, participation, and productivity may all depend on what we want to
>do and how we approach it.  My own experience has been that design
>productivity tends to be inversely proportional to the number of
>participants involved;

Hummm...you have been thorough this process before  :-)

>we may need more time or multiple sessions if the
>desire is to not form a design team.
>
><Scott/>

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Subject: Re: RE: comments on your grrp-reqs-05.txt (second try)
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
From: "Marcos Sanz/Denic" <[email-masked]>
Date: Fri, 12 Jan 2001 15:57:48 +0100
Sender: [email-masked]

On 10.01.01 14:37 "Hollenbeck, Scott" <[email-masked]> wrote:
> We earlier discussed bagging this requirement completely because it
> describes registry implementation detail.  I'd prefer to delete it than
> reword it.

It might be useful if a draft is posted with all agreed changes up to now,
before we start wasting time by looping over the same issues again and
again.

Marcos Sanz

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: Some more comments on your grrp-reqs-05.txt (second try) 
Date: Fri, 12 Jan 2001 15:48:45 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Hi Scott,

Some comments over the last part of the draft.

	jaap

About 3.12 Lock status Indicators

At 3.12.[1] there is quite a list of indicators the MUST be
provided. It might well be possible that some of these states are
in fact mandated by the policies of the registry. Further more, it
is all concentrated on ``the domain''. Does this mean the domain
it self, the data associated with this or both?

We (.nl) do have
several types of lock states:

	a) domain holder might non-be changed but name server
	   changes are allowed and domain is published

	b) domain might not be transferred between registrars but other
	   changes are allowed

	c) domain is reserved by the registry (things like .co.nl,
	   .com.nl etc.)

	d) domain is blocked for registration (things like
	   killthequeen.nl etc.)

	e) more you don't want to know about

Maybe a MAY should be used in the second sentence.

8.2.[1] ... SHOULD operate without human intervention.

This going to be difficult for registries which have heavy policies.
Some registries might have policies that requires human intervention.
For instance, it might be necessary that information is needed
which cannot be serviced by the protocol. As an example, the registry
might need to check a Dun & Broadsheet document if only commercial
entities are aloud in .com.XX or a trademark ownership proof for
a .tm.XX. For these type of registries it will be difficult to do
that. But maybe the SHOULD here covers that.

8.4

I would leave out the Zulu stuff. That is way too much an American
culture thing. So drop it also from the time format. BTW, Isn't
there already an IETF standard how time formats are described (ntp
RFC)?

From: "Paul George" <[email-masked]>
To: "Ietf-Provreg" <[email-masked]>
Subject: RE: Interim meeting: was RE: Charter last call summary
Date: Fri, 12 Jan 2001 08:18:34 -0500
Importance: Normal
Sender: [email-masked]

At first, I thought this was to be a "quickie" meeting to be held asap to
finalize the RRP Requirements.  But more and more emails I see refer to this
as a design meeting to be help as soon as the Reqs are done.  I am confused.

If the Reqs are so close to being completed, then I agree a meeting is not
necessary and we should list all outstanding "issues" with the Reqs as they
are right now and get to work on them and finish up.

If there are still lots of issues with the Reqs, then perhaps we should meet
in the next week to finalize that first??

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hollenbeck, Scott
Sent: Friday, January 12, 2001 8:09 AM
To: Ietf-Provreg
Subject: RE: Interim meeting: was RE: Charter last call summary

Are we looking to have an interim WG session or a design team session?
Location, participation, and productivity may all depend on what we want to
do and how we approach it.  My own experience has been that design
productivity tends to be inversely proportional to the number of
participants involved; we may need more time or multiple sessions if the
desire is to not form a design team.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: Ietf-Provreg <[email-masked]>
Subject: RE: Interim meeting: was RE: Charter last call summary
Date: Fri, 12 Jan 2001 08:09:06 -0500
Sender: [email-masked]

Are we looking to have an interim WG session or a design team session?
Location, participation, and productivity may all depend on what we want to
do and how we approach it.  My own experience has been that design
productivity tends to be inversely proportional to the number of
participants involved; we may need more time or multiple sessions if the
desire is to not form a design team.

<Scott/>

Date: Thu, 11 Jan 2001 17:25:11 -0500
To: Dave Crocker <[email-masked]>
From: "J. William Semich" <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

The one I am somewhat familiar with is at JP-NIC, where they require
registration in both Latin/English and Japanese, as well as registering
both the English/Latin and Japanese versions of the domain name (this is
not related to IDN per se - it is a way to register the actual "Japanese
character" set for the domain name, as well as the legal ASCII domain name
that is entered into the root.) I'm sure someone from JP-NIC could add to
(or perhaps more likely subtract from/correct) my recollection. Whether
this might require a "different" set of requirements for a generic RRP, I
wouldn't venture to say.

Just "policy" issues perhaps?

Regards,

Bill

At 02:06 PM 1/11/01 -0800, Dave Crocker wrote:
>At 12:00 PM 1/11/2001 -0500, J. William Semich wrote:
>>many have a
>>completely different registration process and different registration
>>requirements from those being discussed here
>
>It would be helpful to hear a summary of those differences.
>
>d/
>
>
>=-=-=-=-=
>Dave Crocker  <[email-masked]>
>Brandenburg Consulting  <www.brandenburg.com>
>Tel: +1.408.246.8253,  Fax: +1.408.273.6464
>
>
Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

Date: Thu, 11 Jan 2001 19:06:38 -0800
To: Ietf-Provreg <[email-masked]>, [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Sender: [email-masked]

At 05:49 PM 1/11/2001 -0500, Jordyn A. Buchanan wrote:
>Maybe right after--that puts the meeting right between Apricot and 
>ICANN.  For those of us flying in from the U.S., that might get us out of 
>a trans-Pacific trip.

yup.

hmm.  halfway between KL and Melbourne...

Darwin AU or East Timor IN probably win geographically.

However I'd love to suggest Kota Kinabalu, Sabah, Malaysia on nortern 
Borneo.  I have some friends there, including a very Internet-savvy 
government official.  They love hosting hi-tech meetings.

KK also is a few miles from the island that hosted the Survivors TV 
event.  Staff and losers stayed at one of the 5-star hotels in KK.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Thu, 11 Jan 2001 19:57:40 -0500
To: Edward Lewis <[email-masked]>
From: Marc Blanchet <[email-masked]>
Subject: Re: Interim meeting
Cc: Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At/À 16:55 2001-01-11 -0500, Edward Lewis you wrote/vous écriviez:
>At 4:21 PM -0500 1/11/01, Jordyn A. Buchanan wrote:
> >At 04:10 PM 1/11/2001 -0500, Edward Lewis wrote:
> >
> >>I will be on vacation in Germany, flying into and out of Frankfort (a
> >>change from what I told others).  It is reasonable for me to schedule a
> >>meeting on March 14 (perhaps at DENIC), the day before I return home.
> >>Being vacation, my plans tend to be fluid.
> >
> >That's a really tough date given the ICANN meetings in Australia from Mar
> >10 - 13.  I'd guess that many people from this list will be travelling or
> >very jet lagged on the 14th.
>
>Just as well...what time frame is good?
>
>The IETF is March 18-23.  Before?  After?

After is not that useful IMHO.

Before is probably much better.

Before in my mind is as near as possible to sunday pm. ie.:
if one day meeting needed, then saturday pm to sunday noon.
if two days meeting needed, then start friday pm to sunday noon.

then location would be the IETF location (i.e. Minneapolis) and same hotel 
if possible.

my 2 cents

Marc.

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: +1 443-259-2352                      Email: [email-masked]
>
>Dilbert is an optimist.
>
>Opinions expressed are property of my evil twin, not my employer.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

Date: Thu, 11 Jan 2001 17:49:45 -0500
To: Dave Crocker <[email-masked]>, Edward Lewis <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: "J. William Semich" <[email-masked]>, Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:05 PM 1/11/2001 -0800, Dave Crocker wrote:
>At 04:10 PM 1/11/2001 -0500, Edward Lewis wrote:
>>I will be at APRICOT Feb 25-March 2.  I am not sure when I am committed to
>
>What about a meeting in Kuala Lumpur, right before or after 
>Apricot?  Looks like a number of us will be there.

Maybe right after--that puts the meeting right between Apricot and 
ICANN.  For those of us flying in from the U.S., that might get us out of a 
trans-Pacific trip.

Jordyn

Date: Thu, 11 Jan 2001 16:55:54 -0500
To: "Jordyn A. Buchanan" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: Edward Lewis <[email-masked]>, "J. William Semich" <[email-masked]>, Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 4:21 PM -0500 1/11/01, Jordyn A. Buchanan wrote:
>At 04:10 PM 1/11/2001 -0500, Edward Lewis wrote:
>
>>I will be on vacation in Germany, flying into and out of Frankfort (a
>>change from what I told others).  It is reasonable for me to schedule a
>>meeting on March 14 (perhaps at DENIC), the day before I return home.
>>Being vacation, my plans tend to be fluid.
>
>That's a really tough date given the ICANN meetings in Australia from Mar
>10 - 13.  I'd guess that many people from this list will be travelling or
>very jet lagged on the 14th.

Just as well...what time frame is good?

The IETF is March 18-23.  Before?  After?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 11 Jan 2001 14:06:17 -0800
To: "J. William Semich" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:00 PM 1/11/2001 -0500, J. William Semich wrote:
>many have a
>completely different registration process and different registration
>requirements from those being discussed here

It would be helpful to hear a summary of those differences.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Thu, 11 Jan 2001 14:05:21 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: "J. William Semich" <[email-masked]>, Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:10 PM 1/11/2001 -0500, Edward Lewis wrote:
>I will be at APRICOT Feb 25-March 2.  I am not sure when I am committed to

What about a meeting in Kuala Lumpur, right before or after Apricot?  Looks 
like a number of us will be there.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Thu, 11 Jan 2001 16:21:31 -0500
To: Edward Lewis <[email-masked]>, "J. William Semich" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:10 PM 1/11/2001 -0500, Edward Lewis wrote:

>I will be on vacation in Germany, flying into and out of Frankfort (a
>change from what I told others).  It is reasonable for me to schedule a
>meeting on March 14 (perhaps at DENIC), the day before I return home.
>Being vacation, my plans tend to be fluid.

That's a really tough date given the ICANN meetings in Australia from Mar 
10 - 13.  I'd guess that many people from this list will be travelling or 
very jet lagged on the 14th.

Jordyn

Date: Thu, 11 Jan 2001 16:10:20 -0500
To: "J. William Semich" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Sender: [email-masked]

I have a limited travel budget[1], but during February and March I will be
overseas (relative to the US) for other reasons.

At 12:00 PM -0500 1/11/01, J. William Semich wrote:
>At 10:09 PM 1/10/01 -0500, Richard Shockey wrote:
><snip>
>
>>I would also suggest {with the consent of our AD} that we schedule a series
>>of face to face meetings to expedite the process with results and minutes
>>reported to the list for comment and review. At some point we should
>>certainly consider a proper European venue in order to  meet face to face
>>with our CCTLD colleagues who have legitimate input into the process.

I will be on vacation in Germany, flying into and out of Frankfort (a
change from what I told others).  It is reasonable for me to schedule a
meeting on March 14 (perhaps at DENIC), the day before I return home.
Being vacation, my plans tend to be fluid.

>FYI, there are many ccTLDs not represented (or at least, not participating)
>on this list. Apart from Budi in Indonesia, no Asian ccTLDs have had input.
>I will try and drum up some interest, but the fact is, many have a
>completely different registration process and different registration
>requirements from those being discussed here, and I expect they would have
>quite a lot to offer once they get involved in the process of developing a
>generic registry-registrar protocol standard.

I will be at APRICOT Feb 25-March 2.  I am not sure when I am committed to
agenda items, but a half-day meeting, perhaps sometime on the 27th is
possible.

[1] My employer is not in the business of domain/address registration, ergo
I'm doing this on a very small budget.  I am doing this under the guise of
security research as an extension of work done in DNSSEC.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

To: "J. William Semich" <[email-masked]>
cc: Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>, [email-masked]
Subject: Re: Interim meeting: was RE: Charter last call summary 
Date: Thu, 11 Jan 2001 22:00:47 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Hi Bill,

    FYI, there are many ccTLDs not represented (or at least, not participating)
    on this list. Apart from Budi in Indonesia, no Asian ccTLDs have had input.
    I will try and drum up some interest,

There had been some discussions about this at some CENTR lists and
the cctld-discuss list I wouldn'nt be suprised if that is what
started Budi to participate. But yes, drum up some more interest
if you want.

	jaap

Date: Thu, 11 Jan 2001 12:25:16 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: [email-masked]
Subject: RE: Security vs. Authorization
Sender: [email-masked]

> What eludes me most is the reasoning that a registrar operating in a
> competitive system is more at risk of failure or of not complying with the
> registrar/registrant contract than a (single) registrar operating in a
> monopoly system.

Here's my reasoning on this and there are current examples to support
it.  In a monopoly system your registrar is the only one and hence any
problems will be picked up by the internet community at large and worked
on (eg if NSI went under or couldn't maintain itself while it was still
the only registrar there would have been broad government and corporate
intervention to fix the problem).  I'm not saying that they're have a
perfect service, but as the only service they must at least work.  In a
competative model registrars are smaller scale (I'm not sure how strict
the requirements are to be an accredited registrar, but from what I've
seen they don't require that much technical competence).  If one of them
should fail its merely a company going out its business -- a whole
industry won't be affected, merely its clients.  Besides in the single
registrar model all the data is centralized.  If the registrar goes under
it doesn't really matter who owns which domains.  In the multiple
registrar model the registrars are proxying or adding value added services
to the actual registration process, but, in the case of a "thin" registry,
they will hold all the relevant client information.  Hence, if the
registry all its registered domains would still continue to work (ie the
domain system would not collapse) but there would be a lot of angry
customers with no access to their domains.

By supporting examples I just meant that you can look at the current
accredited registrars -- I'm not going to name any, but I think there are
some which seem (from the technical expertise displayed on their
website) like very small and possible incapable organizations (often
offering very poor support).

I'm not trying to promote a monopolistic model in all of this but what I
think is an important point to make (and I would love to hear discussion
on it) is that the registry is consider a "canonical" source of domain
information (as the ICANN registered TLD owner they are responsible if a
user in their TLD is suddenly unable to access his domain).  Registrars
are merely entities that benefit from adding services or acting as a
proxy.  I'm not promoting the "fat" model here; what I'm saying is
essentially the registry is the legally responsible entity and should thus
have a record (in some unforgable format) of the final domain owner (the
registrant) for each domain.

Regards,
Sheer

Date: Thu, 11 Jan 2001 12:00:26 -0500
To: Richard Shockey <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>
From: "J. William Semich" <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Cc: [email-masked]
Sender: [email-masked]

At 10:09 PM 1/10/01 -0500, Richard Shockey wrote:
<snip>

>I would also suggest {with the consent of our AD} that we schedule a series 
>of face to face meetings to expedite the process with results and minutes 
>reported to the list for comment and review. At some point we should 
>certainly consider a proper European venue in order to  meet face to face 
>with our CCTLD colleagues who have legitimate input into the process.

FYI, there are many ccTLDs not represented (or at least, not participating)
on this list. Apart from Budi in Indonesia, no Asian ccTLDs have had input.
I will try and drum up some interest, but the fact is, many have a
completely different registration process and different registration
requirements from those being discussed here, and I expect they would have
quite a lot to offer once they get involved in the process of developing a
generic registry-registrar protocol standard.

Bill Semich
.NU Domain
and Vice-Chair, APTLD

Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: Ietf-Provreg <[email-masked]>
Subject: RE: Interim meeting: was RE: Charter last call summary
Date: Thu, 11 Jan 2001 06:59:15 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 10:10 PM
> To: Hollenbeck, Scott; Ietf-Provreg
> Subject: Re: Interim meeting: was RE: Charter last call summary
> 
> 
> At 11:02 AM 1/10/2001 -0500, Hollenbeck, Scott wrote:
> >I sent a hosting offer to the list a few minutes before Ed's 
> message was
> >sent.  My company's facility is near Washington Dulles 
> airport, has ample
> >conference room space, and I can provide a teleconference 
> bridge if needed.
> 
> 
> Scott this is a wonderful offer ..or we could do it in a 
> Herndon/Reston/Dulles VA hotel and NeuLevel [aka 
> NeuStar/Melbourne IT] 
> would be more that willing to split the costs etc...see if we 
> could get our 
> participants a conference room rate etc. A airport hotel 
> helps minimize the 
> travel burden .airport shuttle vs taxi etc.

That sounds OK, too.

<Scott/>

From: Bill Manning <[email-masked]>
Subject: Re: Security vs. Authorization
To: [email-masked] (Peter Mott)
Date: Wed, 10 Jan 2001 23:32:28 -0800 (PST)
Cc: [email-masked] (Dan Cohen), [email-masked]
Sender: [email-masked]

% Any system, particularly when inforced at a technical level that starts with
% a position of "registrars cant be trusted" will fail commercially.  Simply
% because registrars wont be able to differentiate themselves, and will
% ultimately be bound by the registry modus operandi.  The complexity will
% also erode benefit of a distributed service.

	Its not a question of trust, its a question of when
	any given registrar becomes "incapacitated". In a monopoly
	system, there is no alternative. In a competative market,
	there is a need to protect the integrity of the registered
	data.

% I am not advocating a system with no checks and balances.  All I say is,
% dont try to enforce compliance at a technical level.  Organise a third party
% with audit experience to run checks occasionally and require registrars to
% report to the TLD manager on a regular basis as part of retaining
% accreditation.

	Sure... thats one model. 
 
% In short, no more checking required than I would expect for a service
% provided by a single govt department.

	Hogwash. I want choice -AND- accountability.
	Its my data and I want to ensure that potential holders
	of my data have sound technical methods to ensure that 
	my data will remain intact regardless of their solvency.

% 
% Regards
% 
% Peter Mott
% Chief Enthusiast
% 2day.com
% -/-
% 
% 

-- 
--bill

From: Bill Manning <[email-masked]>
Subject: Re: Security vs. Authorization
To: [email-masked] (Hollenbeck, Scott)
Date: Wed, 10 Jan 2001 08:43:55 -0800 (PST)
Cc: [email-masked] ('Olivier Guillard'), [email-masked] (Ietf-Provreg)
Sender: [email-masked]

% > Are you sure that the registrar is the only one entitle do 
% > performe any
% > change?
% 
% There should be only one registrar authorized to change an object, but they
% should do so either on behalf of a registrant or pursuant to whatever legal
% arrangement exists between registrar and registrant.
% 
% <Scott/>

	I think that this might be problematic.  There should be a 
	method to allow "override" in the event the single authorized
	registrar is unwilling/unable to make the change.

--bill

From: Bill Manning <[email-masked]>
Subject: Re: Security vs. Authorization
To: [email-masked] (Hollenbeck, Scott)
Date: Wed, 10 Jan 2001 08:06:40 -0800 (PST)
Cc: [email-masked] ('Paul George'), [email-masked] (Ietf-Provreg)
Sender: [email-masked]

 Are there lessons to be learned from the RIPE registry/db experience?

% We've talked about authorization a bit in the context of transfers, but
% perhaps it also makes sense to consider an authorization requirement for
% other operations that can change the state of an object, such as renews,
% updates, and deletes.  Would anyone object to adding a requirement like this
% to sections 3.6 (Object Update), 3.8 (Object Renewal/Extension), and 3.10
% (Object Deletion):
% 
% [n] The protocol MUST provide services to confirm registrar authorization to
% [delete|renew|update|transfer] an object.
% 
% (This is a minor rewording of the transfer requirement change suggested by
% Jordyn.)
% 
% <Scott/>

-- 
--bill

From: "Peter Mott" <[email-masked]>
To: "Bill Manning" <[email-masked]>
Cc: "Dan Cohen" <[email-masked]>, <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Thu, 11 Jan 2001 22:02:00 +1300
Importance: Normal
Sender: [email-masked]

> 	Its not a question of trust, its a question of when
> 	any given registrar becomes "incapacitated". In a monopoly
> 	system, there is no alternative. In a competative market,
> 	there is a need to protect the integrity of the registered
> 	data.

The need to protect data exists whether the system is a monopoly or
competitive in nature.

> % In short, no more checking required than I would expect for a service
> % provided by a single govt department.
>
> 	Hogwash. I want choice -AND- accountability.
> 	Its my data and I want to ensure that potential holders
> 	of my data have sound technical methods to ensure that
> 	my data will remain intact regardless of their solvency.

Sounds like in your country govt departments have accountability and private
enterprise does not.  Not sure how your laws work, but down this way the
only folk who are above the law are generally the govt.  Everybody else is
expected to play the game fair and square.

I share your view that accountability is important. What I am suggesting is
a different means of obtaining it.  There are ways of dealing with (the
unlikely event of) insolvency other than through the technical
implementation.

What eludes me most is the reasoning that a registrar operating in a
competitive system is more at risk of failure or of not complying with the
registrar/registrant contract than a (single) registrar operating in a
monopoly system.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

Subject: Antwort: RE: Security vs. Authorization
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Thu, 11 Jan 2001 09:17:47 +0100
Sender: [email-masked]

> >
> > % > Are you sure that the registrar is the only one entitle do
> > % > performe any
> > % > change?
> > %
> > % There should be only one registrar authorized to change an
> > object, but they
> > % should do so either on behalf of a registrant or pursuant
> > to whatever legal
> > % arrangement exists between registrar and registrant.
> > %
> > % <Scott/>

Think a little bit to the future: Secure DNS.
I think there is a realy need that for example the registrant itself
"signs" his request of changing some Nameservers.
Not all registrars belong to the "good people" group, and may change
something.

I think there are two type of authorisation needed, one for to "login" in
the registry, and one for every object in the registry.

>From my point of view every Object in the registry has two parts:
1. the object itself
2. some kind of metadata

This metadata is a lot of the policy of the registry.
There you have the information about the registrant, Date/Time of
creating/update, and (most important) some kind of ACL.

Normaly the registrar is part of the ACL, but it is also possible to put
the customer also to the list.
This also makes live easier for the registrar.

Example: If i have a X.509 certificate from verisign ( ;-) ....) I want to
be able to change my contact data in the registry.
The registrar is then easily able to say "OK this realy seems to be my
customer" and forward this request to the registy.

Conclusion:
There is a requirement of authorisation objects inside the registry. These
objects may be username/password pairs , X.509 Certivicates, PGP-Keys or
whatever. It MUST be part of the GRRP protocoll and not part of the
transport protocoll.

Correct me if i am thinking to far......

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

Date: Wed, 10 Jan 2001 21:46:14 -0500
To: "Paul George" <[email-masked]>, "Ietf-Provreg" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: Charter last call summary
Sender: [email-masked]

At 10:17 AM 1/10/2001 -0500, Paul George wrote:
> > I suspected as much, but I feel we need to
> > get the IETF process moving along.
>
>As perviously mentioned, would it help to get
>as many people as possible together in person
>(& teleconference) to really get rolling?
>
>I vote for Washington, DC. ;-)
>
>Paul George
>SARAF Software Solutions
>(703)538-5666 x234

So do I.. :-)

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Wed, 10 Jan 2001 22:09:50 -0500
To: "Hollenbeck, Scott" <[email-masked]>, Ietf-Provreg <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Sender: [email-masked]

At 11:02 AM 1/10/2001 -0500, Hollenbeck, Scott wrote:
>I sent a hosting offer to the list a few minutes before Ed's message was
>sent.  My company's facility is near Washington Dulles airport, has ample
>conference room space, and I can provide a teleconference bridge if needed.
>
><Scott/>

Scott this is a wonderful offer ..or we could do it in a 
Herndon/Reston/Dulles VA hotel and NeuLevel [aka NeuStar/Melbourne IT] 
would be more that willing to split the costs etc...see if we could get our 
participants a conference room rate etc. A airport hotel helps minimize the 
travel burden .airport shuttle vs taxi etc.

IMHO once we have consensus on a requirements documents ( and it seems we 
are close) this plan makes a great deal of sense since I belive there is 
sufficient consensus on moving with all deliberate speed on defining what 
the protocol should be and your preliminary work is a excellent first step 
in that direction.

I would also suggest {with the consent of our AD} that we schedule a series 
of face to face meetings to expedite the process with results and minutes 
reported to the list for comment and review. At some point we should 
certainly consider a proper European venue in order to  meet face to face 
with our CCTLD colleagues who have legitimate input into the process.

I agree that a date the week of 19-23 is good for a first meeting.

> > -----Original Message-----
> > From: Edward Lewis [mailto:[email-masked]]
> > Sent: Wednesday, January 10, 2001 10:38 AM
>
>[snip]
>
> > The requirements document is on the charter for February, and we have
> > already been having lively threads on it.  I still need to review the
> > recent threads to see how they are converging, but I'll throw out as a
> > proposal an interim meeting sometime between February 19 and
> > February 22.
> > I would have liked a week later, but that's when I'll be at APRICOT.
> >
> > Does anyone want to volunteer a venue for a one day meeting then?
>
>[snip]

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Peter Mott" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Thu, 11 Jan 2001 12:10:43 +1300
Importance: Normal
Sender: [email-masked]

> As I (and others) mentioned earlier,
> if the authority (in a form of certificate, token, whatever
> authentication technology implemented) is in the registrant hand,
> this would not be a problem.

Having worked with customers using our automated services since 1996, I can
assure you that no matter how much care you take to ensure the registrant
has a key or similar, they WILL loose it or not have it when they need it.
You can usually also be sure that the entity requesting changes will not be
the registrant (who is not even slightly interested in this stuff) but their
agent.

Thats the real world.

> The registrant can remove/revoke the authority given to the
> registrar and delegate the authority to another registrar or
> even to the registry to make changes.

This is going to be a fun debate when we get to it :-)

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Peter Mott" <[email-masked]>
To: "Dan Cohen" <[email-masked]>, <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Thu, 11 Jan 2001 11:27:11 +1300
Importance: Normal
Sender: [email-masked]

> Even though I think we probably could come up with technical ways to
> protect registrants from registrar's bad behavior, I don't think we
> should.

I am sure we should not.  Registrar activity should be determined by
contract.  It never ceases to amaze me how people will trust a monopoly
registrar and as soon as you provide a choice of registrars, the new
entrants are not to be trusted and need to be checked.

The whole purpose of having a choice of registrar is so you can enter into a
contract that meets your needs and then TRUST that entity to live up to that
contract.

Any system, particularly when inforced at a technical level that starts with
a position of "registrars cant be trusted" will fail commercially.  Simply
because registrars wont be able to differentiate themselves, and will
ultimately be bound by the registry modus operandi.  The complexity will
also erode benefit of a distributed service.

In my view, the result will be no different to having a monopoly
registry/registrar entity.

I am not advocating a system with no checks and balances.  All I say is,
dont try to enforce compliance at a technical level.  Organise a third party
with audit experience to run checks occasionally and require registrars to
report to the TLD manager on a regular basis as part of retaining
accreditation.

In short, no more checking required than I would expect for a service
provided by a single govt department.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: [email-masked]
To: [email-masked]
Date: Thu, 11 Jan 2001 05:22:49 +0700
Subject: Technical (was: security, authorization, definition, etc.)
Sender: [email-masked]

What if we focus on one thing:

   Make sure the protocol only allows *one* entity to
   make changes in the database.

This one entity could be the registry, could be a
registrar, could be the registrant, what have you
depending on the (busines) model.
>From the technical point of view, we don't really
care. As long as we can make sure that only *one*
entity can make changes, right.

At this stage we don't really care how it is implemented.
Maybe in a form or certificate, token, password,
or whatever. As long as it's secure.

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: [email-masked]
To: [email-masked]
Date: Thu, 11 Jan 2001 05:18:03 +0700
Subject: RE: Security vs. Authorization
Sender: [email-masked]

> > 	I think that this might be problematic.  There should be a 
> > 	method to allow "override" in the event the single authorized
> > 	registrar is unwilling/unable to make the change.

As I (and others) mentioned earlier,
if the authority (in a form of certificate, token, whatever
authentication technology implemented) is in the registrant hand,
this would not be a problem.

The registrant can remove/revoke the authority given to the
registrar and delegate the authority to another registrar or
even to the registry to make changes.

This way, only *one* entity (whoever has the token/certificate)
can change the record and it is controlled by the registrant
(legal concern is technically addressed here).
Security and authentication are addressed in a *clean and ellegant*
manner. What more could you ask? ;-)

Implementation can be tricky, though.
But since we are not talking about implementation, we
can defer our concern at a later stage.

Of course, if we want more complicated implementation we
can have the registry holding key escrow :-)
(Although, I don't see the reason why such thing is needed
since the registry can change the content.)
Thus, the registry is responsible for the integrity of the
database.

Regards
-- budi
-- TLD-ID
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

Date: Wed, 10 Jan 2001 15:49:16 -0500
To: <[email-masked]>
From: Dan Cohen <[email-masked]>
Subject: RE: Security vs. Authorization
Sender: [email-masked]

At 03:04 PM 01/10/2001 -0500, Paul George wrote:
>I believe we should ensure data integrity so far as technology is concerned.
>But, does "data integrity" address the concern I brought up in the first
>place?  Which was:
>
>         "what role the protocol should play in protecting
>         the entities during each transaction."
>
>When I say "entities" I mean ALL entities, not just the Registrar and the
>Registry.

Even though I think we probably could come up with technical ways to 
protect registrants from registrar's bad behavior, I don't think we 
should.  The whole point of having gTLD registrars separate from the 
registry is that the registrars are responsible to the registrants, and the 
competition between registrars and the ability to transfer causes 
registrants to get better service.  I realize that most of the ccTLDs don't 
have this model, but that just means that ccTLD registries don't have to 
protect registrants from registrars.  The registrants enter into agreements 
with the registrars, and the registrars are legally responsible to provide 
the registrant with appropriate levels of service.  Also, registrars have 
agreements with ICANN (and probably with the registries as well) that 
require them to provide an appropriate level of service to the 
registrants.  These agreements, plus general business sense, should be 
enough to keep registrars (and their employees) in line.  Adding extra 
authentication that the registrant is responsible for will greatly 
inconvenience all of the "entities" involved, and really raise the cost for 
everyone (think of all the extra customer service interactions the 
registries would now have to handle if they had to assist registrants that 
lost their authenticating information).

Dan

Dan Cohen
Manager of Software Engineering
Register.Com, Inc.
212-798-9260

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Wed, 10 Jan 2001 15:04:44 -0500
Importance: Normal
Sender: [email-masked]

I believe we should ensure data integrity so far as technology is concerned.
But, does "data integrity" address the concern I brought up in the first
place?  Which was:

	"what role the protocol should play in protecting
	the entities during each transaction."

When I say "entities" I mean ALL entities, not just the Registrar and the
Registry.

For example: I am not associated in any way with example.com, yet I request
to the Registrar to change the contact information of example.com.  I MUST
not be allowed to do so, right?

Another example: I am registrar.com, I have registered example.com for
person X.  A disgruntled employee at registrar.com decides to remove all
contact information from the Registry for example.com without X's knowledge.
He/she MUST not be allowed to do so, right?

So the question is, do we rely solely on policy to protect against these
things?  Or are there technological means to ensure that I cannot do this?
I submit to the group that there are techological means to ensure this; and
furthermore, it should be addressed in the protocol.

Sections that address these concerns are (usually the last sentence) in:

3.6 [4]
3.7 [6] & [7]
3.8 [3]
3.10 [4]
3.11 [4]

Is it implied or assumed that these sentences apply to all parties involved?
Or do we need text acknowledging the "little guy", aka. the "registrant".

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hollenbeck, Scott
Sent: Wednesday, January 10, 2001 2:22 PM
To: [email-masked]
Subject: RE: Security vs. Authorization

Bill and I have exchanged some private messages about his thought.  I have
some concerns about how difficult it could be address the business and/or
legal aspects involved, and Bill believes that the technical considerations
on ensuring data integrity are fair game for provreg.  Does anyone have any
views of their own that they'd like to express?

<Scott/>

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 11:44 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Security vs. Authorization
>
>
> % > Are you sure that the registrar is the only one entitle do
> % > performe any
> % > change?
> %
> % There should be only one registrar authorized to change an
> object, but they
> % should do so either on behalf of a registrant or pursuant
> to whatever legal
> % arrangement exists between registrar and registrant.
> %
> % <Scott/>
>
> 	I think that this might be problematic.  There should be a
> 	method to allow "override" in the event the single authorized
> 	registrar is unwilling/unable to make the change.

Date: Wed, 10 Jan 2001 14:43:05 -0500
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: Security vs. Authorization
Sender: [email-masked]

At 02:21 PM 1/10/2001 -0500, Hollenbeck, Scott wrote:
>Bill and I have exchanged some private messages about his thought.  I have
>some concerns about how difficult it could be address the business and/or
>legal aspects involved, and Bill believes that the technical considerations
>on ensuring data integrity are fair game for provreg.  Does anyone have any
>views of their own that they'd like to express?

We have discussed of providing some authenticating factor to the registrant 
which would allow them to force a transfer between registrars.  This seems 
more than sufficient.  If a registrar isn't performing on behalf of the 
registrant, the domain can be transferred to another registrar who will.  A 
per-transaction override seems like a bit much.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Security vs. Authorization
Date: Wed, 10 Jan 2001 14:21:55 -0500
Sender: [email-masked]

Bill and I have exchanged some private messages about his thought.  I have
some concerns about how difficult it could be address the business and/or
legal aspects involved, and Bill believes that the technical considerations
on ensuring data integrity are fair game for provreg.  Does anyone have any
views of their own that they'd like to express?

<Scott/>

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 11:44 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Security vs. Authorization
> 
> 
> % > Are you sure that the registrar is the only one entitle do 
> % > performe any
> % > change?
> % 
> % There should be only one registrar authorized to change an 
> object, but they
> % should do so either on behalf of a registrant or pursuant 
> to whatever legal
> % arrangement exists between registrar and registrant.
> % 
> % <Scott/>
> 
> 	I think that this might be problematic.  There should be a 
> 	method to allow "override" in the event the single authorized
> 	registrar is unwilling/unable to make the change.

Date: Wed, 10 Jan 2001 18:39:39 +0100
From: Olivier Guillard <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
Cc: Olivier Guillard <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Paul George'" <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Security vs. Authorization
Sender: [email-masked]

le 10 Jan, Jordyn A. Buchanan a écrit :

> We're building a protocol by which registrars and similar 
> entitites can interact with registries

Doing so, you must assert what is a registry and what is a registrar
and what they are allowed to do on domain names. I really think this
is a political issue more than a technical one.

Regards,

-- 
Olivier

Date: Wed, 10 Jan 2001 18:35:29 +0100
From: Olivier Guillard <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "'Olivier Guillard'" <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Security vs. Authorization
Sender: [email-masked]

> > Are you sure that the registrar is the only one entitle do 
> > performe any
> > change?
> 
> There should be only one registrar authorized to change an object...

I don't think this is an issue for a technical protocol. It sounds like
more of a business or political issue.

> ... but they
> should do so either on behalf of a registrant or pursuant to whatever legal
> arrangement exists between registrar and registrant.

Regards,

-- 
Olivier

Date: Wed, 10 Jan 2001 12:27:07 -0500
To: Olivier Guillard <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Security vs. Authorization
Cc: "'Paul George'" <[email-masked]>, Ietf-Provreg <[email-masked]>
Sender: [email-masked]

At 06:02 PM 1/10/2001 +0100, Olivier Guillard wrote:
> > [n] The protocol MUST provide services to confirm registrar 
> authorization to
> > [delete|renew|update|transfer] an object.
>
>What happen if the registrant want to change something and the registrar
>doesn't want to do it?
>
>What happen if the registrar declare himself has the registrant?
>
>Are you sure that the registrar is the only one entitle do performe any
>change?

I really think this is an issue of policy more than one of 
technology.  We're building a protocol by which registrars and similar 
entitites can interact with registries, not a communications channel by 
which registrants can communicate directly with the registry.

If a registrar isn't doing what they're supposed to be doing for a 
registrant, the registrant can transfer the domain to a different 
registrar, or use whatever contracts or polices exist in order to bludgeon 
the registrar into taking appropriate action.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Olivier Guillard'" <[email-masked]>
Cc: Ietf-Provreg <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Wed, 10 Jan 2001 12:21:53 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Olivier Guillard [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 12:03 PM
> To: Hollenbeck, Scott
> Cc: 'Paul George'; Ietf-Provreg
> Subject: Re: Security vs. Authorization

> > [n] The protocol MUST provide services to confirm registrar 
> authorization to
> > [delete|renew|update|transfer] an object.
> 
> What happen if the registrant want to change something and 
> the registrar
> doesn't want to do it?

I don't think this is an issue for a protocol used between registry and
registrar.  It sounds like more of a business or contractual issue between
registrar and registrant.

> What happen if the registrar declare himself has the registrant?

Again, I don't think this is an issue for a protocol used between registry
and registrar and is instead a business or contractual issue between
registrar and registrant.

> Are you sure that the registrar is the only one entitle do 
> performe any
> change?

There should be only one registrar authorized to change an object, but they
should do so either on behalf of a registrant or pursuant to whatever legal
arrangement exists between registrar and registrant.

<Scott/>

Date: Wed, 10 Jan 2001 18:02:53 +0100
From: Olivier Guillard <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "'Paul George'" <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Security vs. Authorization
Sender: [email-masked]

> [n] The protocol MUST provide services to confirm registrar authorization to
> [delete|renew|update|transfer] an object.

What happen if the registrant want to change something and the registrar
doesn't want to do it?

What happen if the registrar declare himself has the registrant?

Are you sure that the registrar is the only one entitle do performe any
change?

-- 
Olivier

Date: Wed, 10 Jan 2001 17:49:41 +0100
From: Olivier Guillard <[email-masked]>
To: Peter Mott <[email-masked]>
Cc: Annie Renard <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Definition of Registry
Sender: [email-masked]

le 09 Jan, Peter Mott a écrit :
> The registry database or register is the central repository from which zone
> files are published. It is administered by the registry operator under
> contract from the TLD manager.

So, with the today's model, you speak only about DNS db, not whois doesn't it?

I don't think that whois db should be decentralized: heterogeneous format of
furnish for the zone, non pertinent information etc.

Example:

whois youngrussian.com -h whois.opensrs.net

Registrant:
 none
 N.J.
 N.J., N.J. 12345678
 US

 Domain Name: YOUNGRUSSIAN.COM
 
 Administrative Contact:
    Menas, John  [email-masked]
    N.J.
    N.J., N.J. 12345678
    US
    456-7895

 Technical Contact:
    Menas, John  [email-masked]
    N.J.
    N.J., N.J. 12345678
    US
    456-7895

 Billing Contact:
    Menas, John  [email-masked]
    N.J.
    N.J., N.J. 12345678
    US
    456-7895

> > The registrant consideration is surely an important issue, but it
> > might not be the only one, especially for a ccTLD zone.
>
> I agree.  It is important to have an independant entity to define what must
> be part of the registrar - registrant contract and what perhaps must not.

And define also which name can be delegated to who under which condition.

> Many folk think this a registry role.  I have come to the conclusion after
> studing the various roles and relationships that the TLD manager is the
> entity to set such requirements.

I suppose that this is really context dependent. Another (real) problem is
what guaranties has what you call "the TLD manager", I would call this "the
comunity boards representents" that the requirements he has set up will be
effectively applied? (please, don't tell by contract :)

> In most situations I would see the TLD manager as being a not for profit
> organisation owned by members who represent the community of interest for
> the namespace in question.

Agree.

> The registry operator can then focus on its core business, that of enabling
> registrars accredited by the TLD manager to enter into registration
> contracts with registrants, and record such contracts in the register.

Context dependent, in many case this does work only in theory, not in
practise.

> > The .fr registry is one of the first that has distinguished the databases
> > maintaining from the furniture of services linked to domainames! At that
> > time NSI was selling domainnames and maintaning the . , .com,
> > .net and .org
> > db :)
> 
> I would prefer to see the central register containing only those elements of
> data that are required to allow shared access by competing registrars.

You sugest a simple web or mail that directly update the zone file: I don't
think that this is wishable. There must have a validation stamp include
IN THE registration process. This validation should be performed by a party
that guaranty that the comunity boards representents decisions are applyed.

Otherwise, any charter can be written, it won't be applyed.

> Whilst it is possible (indeed likely) for the TLD manager to require
> additional attributes, as soon as you start adding them issues such as data
> ownership and commercial value come into play.  If you keep the value of the
> data in the shared registry as low as possible, this minimises opportunity
> for capture and also keeps cost of maintaining it down.

My grand father said: I don't have the means to pay low cost :) The question
is not only to keep the costs as low as possible, the problem is also to build
a communal project with as many concerned poeple as possible implied in. When
the question is about communication, my feeling is that many poeple should be
concerned to avoid ghettos.

> Sure, the TLD manager can set whatever requirements by way of contract with
> accredited registrars.  But remember for the TLD to be successful (have a
> good selection of registrars for registrants to choose from) then the
> requirements have to be acceptable to the registrar community as well as the
> registrant community.

As I said, we know that such contracts work only in theory.
About finding an acceptable concensus, I agree, this is the question.

> > We don't try to prescribe to anyone what he has to do, we just think that
> > the .fr internet zone should grow with the respect of a "charter".
> 
> I endorse such an approach.  As long as the charter is an accurate
> reflection of the community of interest rather than a top level view of what
> one or two folk think the community needs :-)

Yep, that's why AFNIC is a non for profit organisation with users, governemental
and registrar members represented in the board. They have inputs coming from users
and professional working groups.

Best regard,

-- 
Olivier

From: "Hollenbeck, Scott" <[email-masked]>
To: Ietf-Provreg <[email-masked]>
Subject: Re: Interim meeting: was RE: Charter last call summary
Date: Wed, 10 Jan 2001 11:02:38 -0500
Sender: [email-masked]

I sent a hosting offer to the list a few minutes before Ed's message was
sent.  My company's facility is near Washington Dulles airport, has ample
conference room space, and I can provide a teleconference bridge if needed.

<Scott/>

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 10:38 AM

[snip]

> The requirements document is on the charter for February, and we have
> already been having lively threads on it.  I still need to review the
> recent threads to see how they are converging, but I'll throw out as a
> proposal an interim meeting sometime between February 19 and 
> February 22.
> I would have liked a week later, but that's when I'll be at APRICOT.
> 
> Does anyone want to volunteer a venue for a one day meeting then?

[snip]

To: Edward Lewis <[email-masked]>
cc: "Paul George" <[email-masked]>, [email-masked]
Subject: Re: Charter last call summary 
Date: Wed, 10 Jan 2001 17:05:10 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Wednesday, 10 Jan 2001, Edward Lewis writes:
> At 4:04 AM -0500 1/10/01, Marcel Schneider wrote:
>>As Peter said: this is common ICANN/gTLD usage. We are well
>>aware of it :).

> Others have used the terminology too.  (It is certainly what I am familiar
> with, and I haven't been woking with ICANN.)  I would think that any
> entity/agent that is entering data into a registry could be said to be
> acting as a registrar, even if the entity isn't otherwise known as one.

A registrar is tied to a) a dumb registry system and 
b) a thin registry data base. The registrar is performing policy 
checking.

Unfortunately all of this does not apply to how most ccTLD's
operate now. So imagine a registrar applying for domain
names in both gTLD and ccTLD registries. If we apply the
same nomenclature the registrar will be sure everything is
identical.

> Recall too that this protocol is designed for the case that the (entity
> acting like a) registry and the (entity acting like a) registrar are
> separated by a network.

I am aware of this. I see no reason why it should be used for
a single 'monotlithic' registry-registrar organization. 

>  If there is no separation, this protocol may not
> apply to the situation.

Sure.

>  There will be no mandate from the IETF that this
> protocol be used in registration.  Such a mandate may come from a registrar
> accrediting organization, but the IETF process can't be contingent on that.

The registry-registrar protocol we are designing now will IMO
become a de facto standard. We (SWITCH) have an XML interface 
which is designed for that purpose but I'm personally already 
convinced that we will have to resort to the new rrp asap.
http://www.nic.ch/batch/ for those interested.

>>Sorry for not answering quicker but we had a night in between
>>in Switzerland :).

> I suspected as much, but I feel we need to get the IETF process moving along.

Right. Please move on.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]

> Dilbert is an optimist.

> Opinions expressed are property of my evil twin, not my employer.

Marcel

Date: Wed, 10 Jan 2001 16:51:09 +0100
From: Olivier Guillard <[email-masked]>
To: Peter Mott <[email-masked]>
Cc: Olivier Guillard <[email-masked]>, Annie Renard <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Definition of Registry
Sender: [email-masked]

Thanks for those inputs, I try to compile (as far as my
english allow it).

> Thanks for your questions, hope I have answered a few :-)

Yep, and also reminded me some english lessons with the
plural and singular in latin language with "criterium",
"criteria" :)

Olivier

le 09 Jan, Peter Mott a écrit :
> > > > We have different views of the world.  Through my eyes I see
> > domain name
> > > > registration  being the execution of a legal contract between
> > the registrar
> > > > and the registrant.  The public record of that contract is
> > the insertion of
> > > > the name into the registry database.
> >
> >
> > To clarify the issues, could you please precise what you call "registry
> > database"?
> 
> The registry database or register is the central repository from which zone
> files are published. It is administered by the registry operator under
> contract from the TLD manager.
> 
> > The registrant consideration is surely an important issue, but it
> > might not
> > be the only one, especially for a ccTLD zone.
> 
> I agree.  It is important to have an independant entity to define what must
> be part of the registrar - registrant contract and what perhaps must not.
> Many folk think this a registry role.  I have come to the conclusion after
> studing the various roles and relationships that the TLD manager is the
> entity to set such requirements.
> 
> In most situations I would see the TLD manager as being a not for profit
> organisation owned by members who represent the community of interest for
> the namespace in question.
> 
> The registry operator can then focus on its core business, that of enabling
> registrars accredited by the TLD manager to enter into registration
> contracts with registrants, and record such contracts in the register.
> 
> > The .fr registry is one of the first that has distinguished the databases
> > maintaining from the furniture of services linked to domainames! At that
> > time NSI was selling domainnames and maintaning the . , .com,
> > .net and .org
> > db :)
> 
> I would prefer to see the central register containing only those elements of
> data that are required to allow shared access by competing registrars.
> Whilst it is possible (indeed likely) for the TLD manager to require
> additional attributes, as soon as you start adding them issues such as data
> ownership and commercial value come into play.  If you keep the value of the
> data in the shared registry as low as possible, this minimises opportunity
> for capture and also keeps cost of maintaining it down.
> 
> > The .fr zone is a ressource that is aimed to serve and promote a
> > particular
> > comunity designated by those two letters. It's essential for us
> > to distinguish
> > the commercial function (domain name sale) from the political one (charter
> > and usage referential writting).
> 
> Sure, the TLD manager can set whatever requirements by way of contract with
> accredited registrars.  But remember for the TLD to be successful (have a
> good selection of registrars for registrants to choose from) then the
> requirements have to be acceptable to the registrar community as well as the
> registrant community.
> 
> > What do you mean exactly by "accreditated entity". On which criteriums,
> > defined by who and by which process do you feel the accreditation should
> > happen?
> 
> The TLD manager would determine the requirements for becoming a registrar.
> The accreditation criteria should address the needs of the community of
> interest the TLD serves.
> 
> > We don't try to prescribe to anyone what he has to do, we just think that
> > the .fr internet zone should grow with the respect of a "charter".
> 
> I endorse such an approach.  As long as the charter is an accurate
> reflection of the community of interest rather than a top level view of what
> one or two folk think the community needs :-)
> 
> > ".mu" has been delegated for the maurician island, have you ever
> > been their? go to http://www.mu,
> 
> I am fairly sure IANA/Jon Postel did not have this approach in mind for a
> TLD. Such business models are possible because RFC1591 has not evolved to
> address issues that have appeared as commercial players get involved in the
> Internet.
> 
> Thanks for your questions, hope I have answered a few :-)
> 
> Regards
> 
> Peter Mott
> Chief Enthusiast
> 2day.com
> -/-
> 

-- 
Olivier

Date: Wed, 10 Jan 2001 10:38:00 -0500
To: "Jordyn A. Buchanan" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Interim meeting: was RE: Charter last call summary
Cc: "Paul George" <[email-masked]>, "Ietf-Provreg" <[email-masked]>
Sender: [email-masked]

I was waiting for two things before starting this, both are done (charter
set onwards and whether I'd be at APRICOT the first week of March).

The requirements document is on the charter for February, and we have
already been having lively threads on it.  I still need to review the
recent threads to see how they are converging, but I'll throw out as a
proposal an interim meeting sometime between February 19 and February 22.
I would have liked a week later, but that's when I'll be at APRICOT.

Does anyone want to volunteer a venue for a one day meeting then?

The main agenda for the meeting will be a discussion of the protocol
specification, based on Scott's epp draft.  I don't want to take time to
discuss requirements in the meeting, so continue to send comments to the
mailing list.

At 10:19 AM -0500 1/10/01, Jordyn A. Buchanan wrote:
>At 10:17 AM 1/10/2001 -0500, Paul George wrote:
>>I vote for Washington, DC. ;-)
>And D.C. sounds fine to me.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: Ietf-Provreg <[email-masked]>
Subject: RE: Charter last call summary
Date: Wed, 10 Jan 2001 10:23:57 -0500
Sender: [email-masked]

FWIW my company is willing to host such a session, and we are only a few
miles from Washington Dulles airport for anyone who has to travel by air.

<Scott/>

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 10:20 AM
> To: Paul George; Ietf-Provreg
> Subject: RE: Charter last call summary
> 
> 
> At 10:17 AM 1/10/2001 -0500, Paul George wrote:
> > > I suspected as much, but I feel we need to
> > > get the IETF process moving along.
> >
> >As perviously mentioned, would it help to get
> >as many people as possible together in person
> >(& teleconference) to really get rolling?
> >
> >I vote for Washington, DC. ;-)
> 
> I agree that this would be a very useful step once the requirements 
> document has been finalized.  It sounds like there's enough 
> interest to 
> make such a meeting useful and this effort might help us meet 
> the WG's 
> aggressive timelines.
> 
> And D.C. sounds fine to me.
> 
> Jordyn
> 

Date: Wed, 10 Jan 2001 10:19:45 -0500
To: "Paul George" <[email-masked]>, "Ietf-Provreg" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: Charter last call summary
Sender: [email-masked]

At 10:17 AM 1/10/2001 -0500, Paul George wrote:
> > I suspected as much, but I feel we need to
> > get the IETF process moving along.
>
>As perviously mentioned, would it help to get
>as many people as possible together in person
>(& teleconference) to really get rolling?
>
>I vote for Washington, DC. ;-)

I agree that this would be a very useful step once the requirements 
document has been finalized.  It sounds like there's enough interest to 
make such a meeting useful and this effort might help us meet the WG's 
aggressive timelines.

And D.C. sounds fine to me.

Jordyn

From: "Paul George" <[email-masked]>
To: "Ietf-Provreg" <[email-masked]>
Subject: RE: Charter last call summary
Date: Wed, 10 Jan 2001 10:17:22 -0500
Importance: Normal
Sender: [email-masked]

> I suspected as much, but I feel we need to
> get the IETF process moving along.

As perviously mentioned, would it help to get
as many people as possible together in person
(& teleconference) to really get rolling?

I vote for Washington, DC. ;-)

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 9:35 AM
To: Marcel Schneider
Cc: Edward Lewis; Paul George; [email-masked]
Subject: Re: Charter last call summary

At 4:04 AM -0500 1/10/01, Marcel Schneider wrote:
>As Peter said: this is common ICANN/gTLD usage. We are well
>aware of it :).

Others have used the terminology too.  (It is certainly what I am familiar
with, and I haven't been woking with ICANN.)  I would think that any
entity/agent that is entering data into a registry could be said to be
acting as a registrar, even if the entity isn't otherwise known as one.

Recall too that this protocol is designed for the case that the (entity
acting like a) registry and the (entity acting like a) registrar are
separated by a network.  If there is no separation, this protocol may not
apply to the situation.  There will be no mandate from the IETF that this
protocol be used in registration.  Such a mandate may come from a registrar
accrediting organization, but the IETF process can't be contingent on that.

>Sorry for not answering quicker but we had a night in between
>in Switzerland :).

I suspected as much, but I feel we need to get the IETF process moving
along.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Paul George" <[email-masked]>
To: "Ietf-Provreg" <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Wed, 10 Jan 2001 10:14:27 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C07AEE.1D055DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> [n] The protocol MUST provide services to confirm 
> registrar authorization to [delete|renew|update|transfer]
> an object.

This sounds fine.  Thanks.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 8:58 AM
To: 'Paul George'; Ietf-Provreg
Subject: RE: Security vs. Authorization

We've talked about authorization a bit in the context of transfers, but
perhaps it also makes sense to consider an authorization requirement for
other operations that can change the state of an object, such as renews,
updates, and deletes.  Would anyone object to adding a requirement like this
to sections 3.6 (Object Update), 3.8 (Object Renewal/Extension), and 3.10
(Object Deletion):

[n] The protocol MUST provide services to confirm registrar authorization to
[delete|renew|update|transfer] an object.

(This is a minor rewording of the transfer requirement change suggested by
Jordyn.)

<Scott/>

>  -----Original Message-----
> From: 	Paul George [mailto:[email-masked]] 
> Sent:	Tuesday, January 09, 2001 3:04 PM
> To:	Ietf-Provreg
> Subject:	Security vs. Authorization
> 
> I would like to bring up a point about the difference between the security
aspects (which should NOT be a part) of the RRP and the authorization (and
consequently protection) of each "entity" during transaction processing.
> 
> While I agree that we should not dictate security protocols and such, I
think it is important that we discuss what role the protocol should play in
protecting the entities during each transaction.
> 
> For instance, should the protocol recognize the fact that, while we are
defining interactions between only two parties (registry - registrar), there
are actually (at least) three parties in almost every conceivable form of
real world implmentation?  For example, I think the protection of the third
party (the registrant) is important and needs to be considered when defining
the protocol.  Even if it is something as simple as saying that the protocol
SHOULD allow for some means of authorizing some or all of the RRP
transactions.
> 
> I don't want to ruffle feathers if this has been rehashed too often, but I
would like other people's thoughts on this matter.  Thanks a bunch!
> 
> Paul George
> SARAF Software Solutions

------=_NextPart_000_0000_01C07AEE.1D055DF0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0000_01C07AEE.1D055DF0--

Date: Wed, 10 Jan 2001 09:35:17 -0500
To: Marcel Schneider <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Charter last call summary
Cc: Edward Lewis <[email-masked]>, "Paul George" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 4:04 AM -0500 1/10/01, Marcel Schneider wrote:
>As Peter said: this is common ICANN/gTLD usage. We are well
>aware of it :).

Others have used the terminology too.  (It is certainly what I am familiar
with, and I haven't been woking with ICANN.)  I would think that any
entity/agent that is entering data into a registry could be said to be
acting as a registrar, even if the entity isn't otherwise known as one.

Recall too that this protocol is designed for the case that the (entity
acting like a) registry and the (entity acting like a) registrar are
separated by a network.  If there is no separation, this protocol may not
apply to the situation.  There will be no mandate from the IETF that this
protocol be used in registration.  Such a mandate may come from a registrar
accrediting organization, but the IETF process can't be contingent on that.

>Sorry for not answering quicker but we had a night in between
>in Switzerland :).

I suspected as much, but I feel we need to get the IETF process moving along.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul George'" <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: RE: Security vs. Authorization
Date: Wed, 10 Jan 2001 08:57:44 -0500
Sender: [email-masked]

We've talked about authorization a bit in the context of transfers, but
perhaps it also makes sense to consider an authorization requirement for
other operations that can change the state of an object, such as renews,
updates, and deletes.  Would anyone object to adding a requirement like this
to sections 3.6 (Object Update), 3.8 (Object Renewal/Extension), and 3.10
(Object Deletion):

[n] The protocol MUST provide services to confirm registrar authorization to
[delete|renew|update|transfer] an object.

(This is a minor rewording of the transfer requirement change suggested by
Jordyn.)

<Scott/>

>  -----Original Message-----
> From: 	Paul George [mailto:[email-masked]] 
> Sent:	Tuesday, January 09, 2001 3:04 PM
> To:	Ietf-Provreg
> Subject:	Security vs. Authorization
> 
> I would like to bring up a point about the difference between the security
aspects (which should NOT be a part) of the RRP and the authorization (and
consequently protection) of each "entity" during transaction processing.
> 
> While I agree that we should not dictate security protocols and such, I
think it is important that we discuss what role the protocol should play in
protecting the entities during each transaction.
> 
> For instance, should the protocol recognize the fact that, while we are
defining interactions between only two parties (registry - registrar), there
are actually (at least) three parties in almost every conceivable form of
real world implmentation?  For example, I think the protection of the third
party (the registrant) is important and needs to be considered when defining
the protocol.  Even if it is something as simple as saying that the protocol
SHOULD allow for some means of authorizing some or all of the RRP
transactions.
> 
> I don't want to ruffle feathers if this has been rehashed too often, but I
would like other people's thoughts on this matter.  Thanks a bunch!
> 
> Paul George
> SARAF Software Solutions

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>, "'Jaap Akkerhuis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: comments on your grrp-reqs-05.txt (second try)
Date: Wed, 10 Jan 2001 08:37:17 -0500
Sender: [email-masked]

Thanks for the comments, Jordyn.  Based on earlier comments regarding
transaction identifiers I agree that we need to change the requirements
somewhat, but in a way that's slightly different than what you've proposed.
I'll explain below.

<Scott/>

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 1:03 PM
> To: Hollenbeck, Scott; 'Jaap Akkerhuis'
> Cc: [email-masked]
> Subject: RE: comments on your grrp-reqs-05.txt (second try)
> 
> 
> I'm going to make some comments and at the end of this 
> message I'll suggest 
> specific language to address the issues I raise.
> 
> At 09:46 AM 1/8/2001 -0500, Hollenbeck, Scott wrote:
> 
> >The idea here is that there needs to be a registry-unique 
> "key" that can be
> >used to unambiguously identify every transaction performed 
> by the server on
> >behalf of a client.  Both client and server know the "key", 
> so both have
> >information that can be used to reconcile client-server 
> activity.  No client
> >knows the "keys" associated with the transactions of any 
> other client.
> >
> >This uniqueness plays into my motivation for using these 
> identifiers in the
> >transfer process.  While a thick registry may have 
> end-customer information
> >that can be used to authenticate transfer requests, a thin 
> registry may not.
> >The protocol has to provide a transfer mechanism that works 
> equally well in
> >both environments.
> >
> >The transaction identifier is known to the sponsoring client 
> and the server.
> >If the client (registrar) also provides the identifier to 
> the registrant,
> >the registrant can take the identifier to a second registrar 
> (who won't know
> >the identifier by any other means) to facilitate a transfer.  If the
> >protocol requires this identifier to process transfer 
> actions, transfer
> >mistakes or unauthorized transfers should be minimized.
> 
> This sounds clumsy to me.  If these identifiers are going to 
> be unique and 
> not easily guessable, they're probably not particularly 
> user-friendly.  This isn't a big deal when we're talking about 
> registry/registrar protocol interaction, but I can't imagine 
> that these 
> transaction IDs are the kind of things that reigstrars are 
> going to want to 
> hand out to domain holders every time they register or modify 
> a domain 
> name.  Even if it did become routine for registrars to pass this 
> information down to domain holders, I think we're expecting a 
> lot if we 
> think that users are going to hold onto these identifiers for 
> an indefinite 
> length of time.  This parallels your own objection to using digital 
> signatures for transfers--the technology works, but the user 
> probably won't 
> put it to good use.

I don't think "user-friendly" is an issue because they'll be needed by users
_only_ when they wish to transfer a domain.  If they happen to lose track of
the identifier it should be very easy to recover it from both registry and
registrar on demand.

> More generally, I think specific mechanisms for 
> authenticating the transfer 
> of objects between registrars is a matter of registry policy 
> that will vary 
> widely.  The section on transfers should include a 
> requirement that the 
> protocol allow the registrar requesting the transfer to pass 
> in information 
> to authenticate the transfer, but not get into specifics 
> about what that 
> information should be.  (It could be a transaction ID, or a digitial 
> certificate, or something as mundane as a password.)

I agree from the requirements perspective; we can save the debate on how
this should work for the protocol discussion.

> As a final note on this topic, I think that requiring the 
> transaction ID to 
> approve or cancel the transfer is unnecessary.  The protocol 
> should be able 
> to validate whether or not a request comes from an 
> appropriate registrar 
> without this information.  (Basically, the registrar has already 
> authenticated themselves--we should be able to determine that 
> the "cancel 
> that transfer" comamnd comes from the right place in the same 
> way that we 
> determine that the "delete that domain" command does.)

Thinking ahead to protocol I think it's simpler and cleaner if transfer
command syntax remains consistent, but since this does get into the
mechanics of _how_ transfers operate I think we can strike the text that
describes this as a requirement.

> Staying on the topic of transaction IDs, but moving on to a 
> new issue, I 
> think that in many circumstances it is not necessary for the 
> registrar to 
> pass a transaction ID to the registry.  This should be 
> optional:  if a 
> registrar passes in a transaction ID, the registry should use 
> it, but if 
> the registrar does not, the registry will generate a unique 
> ID and return 
> it once the transaction is complete.  (I'll even concede that 
> I can see 
> circumstances when we'd want the transaction ID to be 
> required, but I can 
> also see circumstances when the registrar can simply wait and 
> use whatever 
> the registry gives them.)

I believe this topic would be more appropriate to tackle when we talk
protocol.  For now, I think it better if we use words like this to identify
the need for transaction identifiers (this came up in an earlier discussion
regarding section 3.3):

"[1] Registry operations that create, update, or delete objects MUST be
associated with a registry-unique identifier.  The protocol MUST allow each
transaction to be identified in a permanent and globally unique manner."

This describes _what_ the protocol has to do without making any statements
about _how_ it should be done.

[snip]
 
> > > 3.4.[6] contact information
> > >
> > > I have the feeling that the required contact information might be
> > > too detailed in certain cases. If the registry/registrar relation
> > > is very thin it is possible that just information over 
> the registrar
> > > might be sufficient. (But then one can argues thses also have a
> > > name, address etc. so it won't hurt.
> >
> >True, but the protocol has to support both thick and thin 
> models.  It's
> >important to distinguish between what the protocol has to do 
> to support
> >multiple models, and how each registry may use the protocol. 
>  Section 2.4
> >says that an underlying assumption is that a registry may choose to
> >implement a subset of the required protocol features, and 
> this is one area
> >where I think registries will choose to do things 
> differently based on local
> >policies.
> 
> While I agree with Scott's statement above, I think that 
> right now the 
> requirements are too strict.  Different registries may have different 
> notions about what information is required for a contact and what is 
> optional.  I suggest we require the protocol handle all of 
> the various bits 
> of information, but not require which ones need to be filled out.

OK, this could be as simple as changing a MUST to a MAY in 3.4-[6] as you
noted.

[snip]
 
> Okay, that's it for now.  Specific changes to language are below.
> 
> ---
> 
> 3.3 [1] Registry operations that create, update, or delete 
> objects MUST be 
> associated with a registry-unique transaction identifier.  
> This identifier 
> MAY be provided by the registrar, in which case the same 
> identifier MUST be 
> returned by the registry.  In the event that the registrar 
> does not provide 
> the identifier, the registry MUST generate and return a new 
> transaction 
> identifier.
> 
> 3.4 [3] A request to register an object MAY include a transaction 
> identifier. If the registrar includes a transaction 
> identifier with the 
> request, this identifier MUST be returned to the registrar.  If the 
> registrar does not include the identifier, the registry must 
> generate and 
> return a new transaction identifier upon the successful 
> registration of the 
> object.

Both of these requirements have already been changed to remove any mention
of _how_ the identifier should be created or used.
 
> 3.4 [6] The protocol MUST provide services to register 
> contact information 
> describing human and organizational entities. Contact 
> registration MUST NOT 
> be limited to a specific period of time. Contact registration 
> MAY include a 
> name (individual name, organization name, or both), address 
> (including 
> street address, city, state or province (if applicable), 
> postal code, and 
> country), telephone number, facsimile telephone number, and 
> e-mail address.

Got it.

> 3.7 [4] The protocol MUST provide services that allows the registrar 
> initiating the transfer to pass information which authenticates the 
> transfer to the registry.
> 
> 3.7 [6] The protocol MUST provide services that allow the requesting 
> registrar to cancel a requested object transfer before the 
> request has been 
> approved or rejected by the original sponsoring registrar. 
> Requests to 
> cancel the transfer of registered objects MUST be limited to 
> the registrar 
> that requested transfer of the registered object.  
> Unauthorized attempts to 
> cancel the transfer of a registered object MUST be explicitly 
> rejected.
> 
> 3.7 [7] The protocol MUST provide services that allow the original 
> sponsoring registrar to approve or reject a requested object 
> transfer. 
> Requests to approve or reject the transfer of registered 
> objects MUST be 
> limited to the registrar that currently sponsors the 
> registered object. 
> Unauthorized attempts to approve or reject the transfer of a 
> registered 
> object MUST be explicitly rejected.

I'm OK with these changes, too.

> 3.7 [9] The protocol MUST support a configurable period 
> during which time a 
> request to transfer the registration of an object MAY be approved, 
> rejected, or cancelled.

We earlier discussed bagging this requirement completely because it
describes registry implementation detail.  I'd prefer to delete it than
reword it.

From: "Peter Mott" <[email-masked]>
To: "Marcel Schneider" <[email-masked]>, "Paul George" <[email-masked]>
Cc: "Ietf-Provreg" <[email-masked]>
Subject: RE: Charter last call summary 
Date: Wed, 10 Jan 2001 23:30:48 +1300
Importance: Normal
Sender: [email-masked]

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

Legal definition will probably determine that the entity exerting control
over the register is the party the registrant has a contract with.  In most
ccTLD cases this entity acts as both registry and registrar.

So even in a ccTLD where both registry and registrar services are performed
by the same entity, the registrant contract is still with the registrar :-)

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

If we can agree that your ccTLD has the same entity performing registry and
registrar services, then I think gTLD thinkers will understand :-)

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

If you can see that you are in fact the (monopoly) registrar (and
coincidently the registry operator) for your ccTLD, then you should see no
problem with this.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

To: Edward Lewis <[email-masked]>
cc: "Paul George" <[email-masked]>, [email-masked]
Subject: Re: Charter last call summary 
Date: Wed, 10 Jan 2001 10:04:40 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Tuesday, 9 Jan 2001, Edward Lewis writes:

Hello Ed

> Keep in mind that this is "just" the charter.  This sets the scope of work
> of the group.  Omitting the detail that one entity may be both a registrar
> and registry (or any other pair or triple) is acceptable.

The point is that instead of a registrar an agent could show up ;-).

> As far as terms used in the charter, e.g., registrar, it is acceptable to
> think of the words as they are used in common usage.

As Peter said: this is common ICANN/gTLD usage. We are well
aware of it :).

>  The terminology
> thread may dive deeper into the details of the meanings but such detail
> will likely have no impact on the charter.

> Given that all the other comments are positive, I plan to send the charter
> on within the next 2-3 hours (end of my business day).

Sorry for not answering quicker but we had a night in between
in Switzerland :).

> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]

> Dilbert is an optimist.

> Opinions expressed are property of my evil twin, not my employer.

Marcel

To: "Paul George" <[email-masked]>
cc: "Ietf-Provreg" <[email-masked]>
Subject: Re: Charter last call summary 
Date: Wed, 10 Jan 2001 09:55:58 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marcel Schneider
> Sent: Tuesday, January 09, 2001 1:39 PM
> To: Paul George
> Cc: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]On
>> Behalf Of Marcel Schneider
>> Sent: Tuesday, January 09, 2001 11:50 AM
>> Cc: [email-masked]
>> 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 <[email-masked]>
>>>          Jaap Akkerhius <[email-masked]>

>>>   APPLICATIONS AREA DIRECTOR(S):
>>>          Patrik Fältström <[email-masked]>
>>>          Ned Freed <[email-masked]>

>>>   AREA ADVISOR:
>>>          Patrik Fältström <[email-masked]>

>>>   MAILING LISTS:
>>>   General Discussion: [email-masked]
>>>   To Subscribe: [email-masked]
>>>     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: [email-masked]

>>> Dilbert is an optimist.

>>> Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 9 Jan 2001 22:12:57 +0100 (MET)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Charter last call summary
Sender: [email-masked]

Peter Mott wrote:
| 
| > 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.
| 
| The above role definitions are certainly the ICANN/gTLD view.
| 
| As we move to an Internet guided more by legal contract than technical
| specification, I think you will see some modification to this view.  I see
| the act of registration being the execution of a legal binding contract
| between registrar and registrant.  Part of that contract requires the
| registrar to insert a record into the register (administered by the registry
| operator) for publication onto the public Internet.
| 
| The scenario above clearly places the registry in the business of providing
| registrars with a public database.  From a contract perspective, quite
| different to having registrars asking a registry to register a name.
| 

I like very much your approach, it stress out the responsabilities.

Kind regards,
Elisabeth Porteneuve

Date: Tue, 09 Jan 2001 15:35:02 -0500
From: Neeran Saraf <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: Charter last call summary
Sender: [email-masked]

Edward Lewis wrote:

> This is the charter I am preparing to send "upwards" real soon now.  This
> incorporates the comments I have seen on the list.
> ============================================================================

This looks fine.

--
Neeran A. Saraf ([email-masked])
President and CEO
SARAF Software Solutions, Inc.
http://www.SARAF.com

Tel: 703-538-5666 ext.225
Pager: 1-800-381-2039
Fax: 703-538-1006

103 W. Broad St., Suite 600
Falls Church, VA 22046
USA

Date: Tue, 9 Jan 2001 14:52:50 -0500
To: Marcel Schneider <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Charter last call summary
Cc: "Paul George" <[email-masked]>, [email-masked]
Sender: [email-masked]

Marcel,

Keep in mind that this is "just" the charter.  This sets the scope of work
of the group.  Omitting the detail that one entity may be both a registrar
and registry (or any other pair or triple) is acceptable.

As far as terms used in the charter, e.g., registrar, it is acceptable to
think of the words as they are used in common usage.  The terminology
thread may dive deeper into the details of the meanings but such detail
will likely have no impact on the charter.

Given that all the other comments are positive, I plan to send the charter
on within the next 2-3 hours (end of my business day).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Peter Mott" <[email-masked]>
To: "Paul George" <[email-masked]>, "Ietf-Provreg" <[email-masked]>
Subject: RE: Charter last call summary 
Date: Wed, 10 Jan 2001 09:17:22 +1300
Importance: Normal
Sender: [email-masked]

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

The above role definitions are certainly the ICANN/gTLD view.

As we move to an Internet guided more by legal contract than technical
specification, I think you will see some modification to this view.  I see
the act of registration being the execution of a legal binding contract
between registrar and registrant.  Part of that contract requires the
registrar to insert a record into the register (administered by the registry
operator) for publication onto the public Internet.

The scenario above clearly places the registry in the business of providing
registrars with a public database.  From a contract perspective, quite
different to having registrars asking a registry to register a name.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Paul George" <[email-masked]>
To: "Ietf-Provreg" <[email-masked]>
Subject: Security vs. Authorization
Date: Tue, 9 Jan 2001 15:03:58 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C07A4D.64DC17F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I would like to bring up a point about the difference between the security
aspects (which should NOT be a part) of the RRP and the authorization (and
consequently protection) of each "entity" during transaction processing.

While I agree that we should not dictate security protocols and such, I
think it is important that we discuss what role the protocol should play in
protecting the entities during each transaction.

For instance, should the protocol recognize the fact that, while we are
defining interactions between only two parties (registry - registrar), there
are actually (at least) three parties in almost every conceivable form of
real world implmentation?  For example, I think the protection of the third
party (the registrant) is important and needs to be considered when defining
the protocol.  Even if it is something as simple as saying that the protocol
SHOULD allow for some means of authorizing some or all of the RRP
transactions.

I don't want to ruffle feathers if this has been rehashed too often, but I
would like other people's thoughts on this matter.  Thanks a bunch!

Paul George
SARAF Software Solutions

------=_NextPart_000_0024_01C07A4D.64DC17F0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0024_01C07A4D.64DC17F0--

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Charter last call summary
Date: Tue, 9 Jan 2001 14:45:09 -0500
Importance: Normal
Sender: [email-masked]

I agree with the charter.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Edward Lewis
Sent: Tuesday, January 09, 2001 11:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: Charter last call summary

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 <[email-masked]>
         Jaap Akkerhius <[email-masked]>

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström <[email-masked]>
         Ned Freed <[email-masked]>

  AREA ADVISOR:
         Patrik Fältström <[email-masked]>

  MAILING LISTS:
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
    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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Paul George" <[email-masked]>
To: "Ietf-Provreg" <[email-masked]>
Subject: RE: Charter last call summary 
Date: Tue, 9 Jan 2001 14:19:23 -0500
Importance: Normal
Sender: [email-masked]

Hi Marcel,

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

This being the case, your "agent" entity COULD then fall into a "reseller"
definition.  I think it all boils down to symantics.

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

Paul George
Saraf Software Solutions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Marcel Schneider
Sent: Tuesday, January 09, 2001 1:39 PM
To: Paul George
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marcel Schneider
> Sent: Tuesday, January 09, 2001 11:50 AM
> Cc: [email-masked]
> 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 <[email-masked]>
>>          Jaap Akkerhius <[email-masked]>

>>   APPLICATIONS AREA DIRECTOR(S):
>>          Patrik Fältström <[email-masked]>
>>          Ned Freed <[email-masked]>

>>   AREA ADVISOR:
>>          Patrik Fältström <[email-masked]>

>>   MAILING LISTS:
>>   General Discussion: [email-masked]
>>   To Subscribe: [email-masked]
>>     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: [email-masked]

>> Dilbert is an optimist.

>> Opinions expressed are property of my evil twin, not my employer.

From: "Peter Mott" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, <[email-masked]>
Subject: RE: Charter last call summary
Date: Wed, 10 Jan 2001 08:10:54 +1300
Importance: Normal
Sender: [email-masked]

> This is the charter I am preparing to send "upwards" real soon now.  This
> incorporates the comments I have seen on the list.

Its close enough to get my support.  Lets move on!

Regards

Peter Mott
Chief Enthusiast
2day.com
-/- 

From: "Peter Mott" <[email-masked]>
To: "Marcel Schneider" <[email-masked]>, "Paul George" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Charter last call summary 
Date: Wed, 10 Jan 2001 08:00:25 +1300
Importance: Normal
Sender: [email-masked]

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

Every TLD that has the same entity performing registry and registrar roles
should consider using this protocol.  If you ever want to move to a
competitive registration model, you will need to give other registrars
access to the registry as well as yourself.  It would make such a
transistion much cleaner and save you considerable development time.

If you are sure the TLD will always offer a monopoly registrar service, then
I guess using the rrp is less compelling.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

Date: Tue, 09 Jan 2001 12:03:28 -0500
To: Dave Crocker <[email-masked]>, Edward Lewis <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Charter last call summary
Cc: [email-masked]
Sender: [email-masked]

At 08:33 AM 1/9/2001 -0800, Dave Crocker wrote:
>At 11:00 AM 1/9/2001 -0500, Edward Lewis wrote:
>>This is the charter I am preparing to send "upwards" real soon now.  This
>>incorporates the comments I have seen on the list.
>
>
>looks fine.

I agree..

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

To: "Paul George" <[email-masked]>
cc: [email-masked]
Subject: Re: Charter last call summary 
Date: Tue, 09 Jan 2001 19:38:45 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marcel Schneider
> Sent: Tuesday, January 09, 2001 11:50 AM
> Cc: [email-masked]
> 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 <[email-masked]>
>>          Jaap Akkerhius <[email-masked]>

>>   APPLICATIONS AREA DIRECTOR(S):
>>          Patrik Fältström <[email-masked]>
>>          Ned Freed <[email-masked]>

>>   AREA ADVISOR:
>>          Patrik Fältström <[email-masked]>

>>   MAILING LISTS:
>>   General Discussion: [email-masked]
>>   To Subscribe: [email-masked]
>>     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: [email-masked]

>> Dilbert is an optimist.

>> Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 09 Jan 2001 13:02:41 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Jaap Akkerhuis'" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: comments on your grrp-reqs-05.txt (second try)
Cc: [email-masked]
Sender: [email-masked]

I'm going to make some comments and at the end of this message I'll suggest 
specific language to address the issues I raise.

At 09:46 AM 1/8/2001 -0500, Hollenbeck, Scott wrote:

>The idea here is that there needs to be a registry-unique "key" that can be
>used to unambiguously identify every transaction performed by the server on
>behalf of a client.  Both client and server know the "key", so both have
>information that can be used to reconcile client-server activity.  No client
>knows the "keys" associated with the transactions of any other client.
>
>This uniqueness plays into my motivation for using these identifiers in the
>transfer process.  While a thick registry may have end-customer information
>that can be used to authenticate transfer requests, a thin registry may not.
>The protocol has to provide a transfer mechanism that works equally well in
>both environments.
>
>The transaction identifier is known to the sponsoring client and the server.
>If the client (registrar) also provides the identifier to the registrant,
>the registrant can take the identifier to a second registrar (who won't know
>the identifier by any other means) to facilitate a transfer.  If the
>protocol requires this identifier to process transfer actions, transfer
>mistakes or unauthorized transfers should be minimized.

This sounds clumsy to me.  If these identifiers are going to be unique and 
not easily guessable, they're probably not particularly 
user-friendly.  This isn't a big deal when we're talking about 
registry/registrar protocol interaction, but I can't imagine that these 
transaction IDs are the kind of things that reigstrars are going to want to 
hand out to domain holders every time they register or modify a domain 
name.  Even if it did become routine for registrars to pass this 
information down to domain holders, I think we're expecting a lot if we 
think that users are going to hold onto these identifiers for an indefinite 
length of time.  This parallels your own objection to using digital 
signatures for transfers--the technology works, but the user probably won't 
put it to good use.

More generally, I think specific mechanisms for authenticating the transfer 
of objects between registrars is a matter of registry policy that will vary 
widely.  The section on transfers should include a requirement that the 
protocol allow the registrar requesting the transfer to pass in information 
to authenticate the transfer, but not get into specifics about what that 
information should be.  (It could be a transaction ID, or a digitial 
certificate, or something as mundane as a password.)

As a final note on this topic, I think that requiring the transaction ID to 
approve or cancel the transfer is unnecessary.  The protocol should be able 
to validate whether or not a request comes from an appropriate registrar 
without this information.  (Basically, the registrar has already 
authenticated themselves--we should be able to determine that the "cancel 
that transfer" comamnd comes from the right place in the same way that we 
determine that the "delete that domain" command does.)

Staying on the topic of transaction IDs, but moving on to a new issue, I 
think that in many circumstances it is not necessary for the registrar to 
pass a transaction ID to the registry.  This should be optional:  if a 
registrar passes in a transaction ID, the registry should use it, but if 
the registrar does not, the registry will generate a unique ID and return 
it once the transaction is complete.  (I'll even concede that I can see 
circumstances when we'd want the transaction ID to be required, but I can 
also see circumstances when the registrar can simply wait and use whatever 
the registry gives them.)

> > 3.4.[3]
> >
> >       ``A request  Must have a transaction identifier ... ''
> >
> > If it is a request for a new domain, should the registrar generate
> > this? It looks like a bootstrapping problem to me, I'm confused
> > but might just not understand. Also
>
>I think I need to reword this text to make it clear that an identifier MUST
>be associated with the transaction, but how it happens is up to the protocol
>designers.

I agree with this.  The text here is actually not problematic (except that 
it requires the registrar to pass in the ID, which I think is unnecessary), 
but 3.3 [1] could probably be re-worked to add the clarity you describe.

> >       ``The transaction identifier MUST be returned to the
> > registrant ...''
> >
> > This sounds as a requirement to how the registrar operates and is
> > outside the scope the registry/registrar protocol. At least, I
> > haven't seen how the protocol can enforce this.
>
>If the identifier is needed to authorize a transfer (which I believe is a
>Good Thing), the identifier has to get to the client (new registrar) who
>issues a transfer request.  The protocol can enforce this by not processing
>a transfer action without the identifier, but perhaps this requirement
>should be changed to not touch on registrar-registrant interaction.

See my comments above on this.  I don't think this should be a requirement; 
we could make it optional, but if that's the case, it really is about the 
relationship between the registrar and registrant and out of scope.

> > 3.4.[6] contact information
> >
> > I have the feeling that the required contact information might be
> > too detailed in certain cases. If the registry/registrar relation
> > is very thin it is possible that just information over the registrar
> > might be sufficient. (But then one can argues thses also have a
> > name, address etc. so it won't hurt.
>
>True, but the protocol has to support both thick and thin models.  It's
>important to distinguish between what the protocol has to do to support
>multiple models, and how each registry may use the protocol.  Section 2.4
>says that an underlying assumption is that a registry may choose to
>implement a subset of the required protocol features, and this is one area
>where I think registries will choose to do things differently based on local
>policies.

While I agree with Scott's statement above, I think that right now the 
requirements are too strict.  Different registries may have different 
notions about what information is required for a contact and what is 
optional.  I suggest we require the protocol handle all of the various bits 
of information, but not require which ones need to be filled out.

> > 3.4.[8] identifiers
> >
> > The mention of ``contact identifier'' remembers me of NIC-handles.
> > I'm also not so sure that all the mentioned identifiers are actually
> > necessary in an actual protocol. Maybe the MUST should become a
> > MAY?
>
>I think there has to be some kind of unique key associated with every
>object.

This is certainly useful at a protocol level, even though many registries 
and/or registrars may not choose to make such extensive use of the 
NIC-handle concept as we may be used to in the .com/.net/.org world.

> > Sections 3.7.[1] - 3.7.[7] describe the basics of the transfer of
> > the objects between registrars. Apart from that, it does something
> > else in the mean time. It actually defines policy matter: The
> > original sponsoring registrar is able to block the transfer. Either
> > (implicitly) by never releasing the current transaction identifier
> > or directly by using 3.7.[7].
> >
> > Whether or not a registrar is able to block such a transfer is a
> > policy matter. Currently it is not allowed in the .nl registry (and
> > as far as I know in .den either). Some time ago it was possible to
> > do this in .nl, but on request of various registrars and given the
> > experience gained, this is no longer the case. It turned out that
> > when there were conflicts between registrant A and registrar X and
> > A wanted to switched to registrar Y, X basically could take the
> > domain from A hostage. Often the registry was dragged into the
> > conflict to decide whether of not the domain was correctly taken
> > ``hostage'', often was forced to take a side in the conflict. The
> > conflicts can be arbitrary. Non-payment by A for services provided
> > by X, non-delivery of services by X paid for by X, or just petty
> > complaints, the dog of A has bitten the cat of X. You name it, we
> > seem it all.
> >
> > The task for a registry is to registry names. Even for conflicts
> > whether or not someone has the right on a certain domain name is,
> > for most registries not part of their job. For that are dispute
> > arbitration thingies or courts of law. So to be dragged into
> > arbitrary conflicts is even worse. Therefore we abolished this
> > blocking. Other registries might have a different policies.
> >
> > Anyway, I tried to reformulate 3.7.[1] and further in a policy
> > neutral fashion, but failed miserably. But I do hope we can come
> > up with something.
>
>This feature has to be in the protocol (it's 100% required in the ICANN gTLD
>world), but it sounds like transfer request blocking by the old registrar
>should be an optional feature.

Yes.  The protocol has to have the capability to allow this, but it 
shouldn't be required for all transfers.

Okay, that's it for now.  Specific changes to language are below.

---

3.3 [1] Registry operations that create, update, or delete objects MUST be 
associated with a registry-unique transaction identifier.  This identifier 
MAY be provided by the registrar, in which case the same identifier MUST be 
returned by the registry.  In the event that the registrar does not provide 
the identifier, the registry MUST generate and return a new transaction 
identifier.

3.4 [3] A request to register an object MAY include a transaction 
identifier. If the registrar includes a transaction identifier with the 
request, this identifier MUST be returned to the registrar.  If the 
registrar does not include the identifier, the registry must generate and 
return a new transaction identifier upon the successful registration of the 
object.

3.4 [6] The protocol MUST provide services to register contact information 
describing human and organizational entities. Contact registration MUST NOT 
be limited to a specific period of time. Contact registration MAY include a 
name (individual name, organization name, or both), address (including 
street address, city, state or province (if applicable), postal code, and 
country), telephone number, facsimile telephone number, and e-mail address.

3.7 [4] The protocol MUST provide services that allows the registrar 
initiating the transfer to pass information which authenticates the 
transfer to the registry.

3.7 [6] The protocol MUST provide services that allow the requesting 
registrar to cancel a requested object transfer before the request has been 
approved or rejected by the original sponsoring registrar. Requests to 
cancel the transfer of registered objects MUST be limited to the registrar 
that requested transfer of the registered object.  Unauthorized attempts to 
cancel the transfer of a registered object MUST be explicitly rejected.

3.7 [7] The protocol MUST provide services that allow the original 
sponsoring registrar to approve or reject a requested object transfer. 
Requests to approve or reject the transfer of registered objects MUST be 
limited to the registrar that currently sponsors the registered object. 
Unauthorized attempts to approve or reject the transfer of a registered 
object MUST be explicitly rejected.

3.7 [9] The protocol MUST support a configurable period during which time a 
request to transfer the registration of an object MAY be approved, 
rejected, or cancelled.

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Charter last call summary 
Date: Tue, 9 Jan 2001 12:17:41 -0500
Importance: Normal
Sender: [email-masked]

Marcel,

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

Paul George
Saraf Software Solutions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Marcel Schneider
Sent: Tuesday, January 09, 2001 11:50 AM
Cc: [email-masked]
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 <[email-masked]>
>          Jaap Akkerhius <[email-masked]>

>   APPLICATIONS AREA DIRECTOR(S):
>          Patrik Fältström <[email-masked]>
>          Ned Freed <[email-masked]>

>   AREA ADVISOR:
>          Patrik Fältström <[email-masked]>

>   MAILING LISTS:
>   General Discussion: [email-masked]
>   To Subscribe: [email-masked]
>     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: [email-masked]

> Dilbert is an optimist.

> Opinions expressed are property of my evil twin, not my employer.

To: [email-masked]
Subject: Re: Charter last call summary 
Date: Tue, 09 Jan 2001 17:55:06 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Tuesday, 9 Jan 2001, Edward Lewis writes:

I also 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 <[email-masked]>
>          Jaap Akkerhius <[email-masked]>

>   APPLICATIONS AREA DIRECTOR(S):
>          Patrik Fältström <[email-masked]>
>          Ned Freed <[email-masked]>

>   AREA ADVISOR:
>          Patrik Fältström <[email-masked]>

>   MAILING LISTS:
>   General Discussion: [email-masked]
>   To Subscribe: [email-masked]
>     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.
...

cc: [email-masked]
Subject: Re: Charter last call summary 
Date: Tue, 09 Jan 2001 17:50:05 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
>          Jaap Akkerhius <[email-masked]>

>   APPLICATIONS AREA DIRECTOR(S):
>          Patrik Fältström <[email-masked]>
>          Ned Freed <[email-masked]>

>   AREA ADVISOR:
>          Patrik Fältström <[email-masked]>

>   MAILING LISTS:
>   General Discussion: [email-masked]
>   To Subscribe: [email-masked]
>     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: [email-masked]

> Dilbert is an optimist.

> Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 09 Jan 2001 08:33:31 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Charter last call summary
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:00 AM 1/9/2001 -0500, Edward Lewis wrote:
>This is the charter I am preparing to send "upwards" real soon now.  This
>incorporates the comments I have seen on the list.

looks fine.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 9 Jan 2001 11:00:56 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Charter last call summary
Cc: [email-masked]
Sender: [email-masked]

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 <[email-masked]>
         Jaap Akkerhius <[email-masked]>

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström <[email-masked]>
         Ned Freed <[email-masked]>

  AREA ADVISOR:
         Patrik Fältström <[email-masked]>

  MAILING LISTS:
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
    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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Peter Mott" <[email-masked]>
To: "Olivier Guillard" <[email-masked]>
Cc: "Annie Renard" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Definition of Registry
Date: Tue, 9 Jan 2001 09:25:51 +1300
Importance: Normal
Sender: [email-masked]

> > > We have different views of the world.  Through my eyes I see
> domain name
> > > registration  being the execution of a legal contract between
> the registrar
> > > and the registrant.  The public record of that contract is
> the insertion of
> > > the name into the registry database.
>
>
> To clarify the issues, could you please precise what you call "registry
> database"?

The registry database or register is the central repository from which zone
files are published. It is administered by the registry operator under
contract from the TLD manager.

> The registrant consideration is surely an important issue, but it
> might not
> be the only one, especially for a ccTLD zone.

I agree.  It is important to have an independant entity to define what must
be part of the registrar - registrant contract and what perhaps must not.
Many folk think this a registry role.  I have come to the conclusion after
studing the various roles and relationships that the TLD manager is the
entity to set such requirements.

In most situations I would see the TLD manager as being a not for profit
organisation owned by members who represent the community of interest for
the namespace in question.

The registry operator can then focus on its core business, that of enabling
registrars accredited by the TLD manager to enter into registration
contracts with registrants, and record such contracts in the register.

> The .fr registry is one of the first that has distinguished the databases
> maintaining from the furniture of services linked to domainames! At that
> time NSI was selling domainnames and maintaning the . , .com,
> .net and .org
> db :)

I would prefer to see the central register containing only those elements of
data that are required to allow shared access by competing registrars.
Whilst it is possible (indeed likely) for the TLD manager to require
additional attributes, as soon as you start adding them issues such as data
ownership and commercial value come into play.  If you keep the value of the
data in the shared registry as low as possible, this minimises opportunity
for capture and also keeps cost of maintaining it down.

> The .fr zone is a ressource that is aimed to serve and promote a
> particular
> comunity designated by those two letters. It's essential for us
> to distinguish
> the commercial function (domain name sale) from the political one (charter
> and usage referential writting).

Sure, the TLD manager can set whatever requirements by way of contract with
accredited registrars.  But remember for the TLD to be successful (have a
good selection of registrars for registrants to choose from) then the
requirements have to be acceptable to the registrar community as well as the
registrant community.

> What do you mean exactly by "accreditated entity". On which criteriums,
> defined by who and by which process do you feel the accreditation should
> happen?

The TLD manager would determine the requirements for becoming a registrar.
The accreditation criteria should address the needs of the community of
interest the TLD serves.

> We don't try to prescribe to anyone what he has to do, we just think that
> the .fr internet zone should grow with the respect of a "charter".

I endorse such an approach.  As long as the charter is an accurate
reflection of the community of interest rather than a top level view of what
one or two folk think the community needs :-)

> ".mu" has been delegated for the maurician island, have you ever
> been their? go to http://www.mu,

I am fairly sure IANA/Jon Postel did not have this approach in mind for a
TLD. Such business models are possible because RFC1591 has not evolved to
address issues that have appeared as commercial players get involved in the
Internet.

Thanks for your questions, hope I have answered a few :-)

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: comments on your grrp-reqs-05.txt (second try)
Date: Mon, 8 Jan 2001 09:46:15 -0500 
Sender: [email-masked]

Thanks, Jaap.  I'll answer your questions etc. below.

<Scott/>

> -----Original Message-----
> From: Jaap Akkerhuis [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 7:34 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: comments on your grrp-reqs-05.txt (second try)
> 
> 
> 
> 
> Scott,
> 
> Here are promised comments on the draft. I'm afraid it is not
> complete, it goes up to page 13 (section 3.9). I do have some
> comments about the rest but they are still sketchy and not really
> worked out.  But I believe that for now there are enough things
> which need attention.
> 
> I'm aware that some have already been discussed and are maybe a
> repeat. Others might be more questions about (mine) improper
> interpretation. For some I will try to formulate some replacement.
> text, but, not being an American native speaker, they might not be
> as precise as desired. Therefore I will add the motivation in the
> hope that the meaning my remarks become clear.
> 
> Regards,
> 
> 	jaap
> 
> About 2.2 System Functions
> 
> This section describes also whois is services that the registry
> might provide. I would suggest to some text in the style of:
> 
> 	Details about the functionality of this whois functions
> 	are is not covered in this document.

Agreed, I'll add such text.

> 
> About 3.1 Session Management
> 
> Since is a high level description it might be wise to make some
> statement about what happens when the session is premature aborted.
> Something in the line of:
> 
> 	[7] The protocol MUST have a way to deal with premature
> 	aborted sessions. For example, roll back of the current
> 	transaction.

Agreed, I'll add such text.

> About 3.3 Transaction identification
> 
> I'm worried about the role that this has in the protocol. It might
> be that it is just my view, but I consider that the registration
> of a domain name, the change of a nameserver, the transfer of a
> name to another registrar, etc, each separate transactions. And to
> have some kind of idea per transaction is not bad (For example,
> when the session is interrupted during the transaction).
> 
> However, the way it is used (See 3.7, Object Transfer) it seems to
> me that this ID is actually an encoding for a domainname-registrar
> pair. It only changes when this relation ship changes. Correct me
> if I'm wrong and please explain the role in the protocol.

The idea here is that there needs to be a registry-unique "key" that can be
used to unambiguously identify every transaction performed by the server on
behalf of a client.  Both client and server know the "key", so both have
information that can be used to reconcile client-server activity.  No client
knows the "keys" associated with the transactions of any other client.

This uniqueness plays into my motivation for using these identifiers in the
transfer process.  While a thick registry may have end-customer information
that can be used to authenticate transfer requests, a thin registry may not.
The protocol has to provide a transfer mechanism that works equally well in
both environments.

The transaction identifier is known to the sponsoring client and the server.
If the client (registrar) also provides the identifier to the registrant,
the registrant can take the identifier to a second registrar (who won't know
the identifier by any other means) to facilitate a transfer.  If the
protocol requires this identifier to process transfer actions, transfer
mistakes or unauthorized transfers should be minimized.

> 3.4.[2]
> 
> This has been discussed before. I just want to add that in .nl (and
> as far as I now in .de land) there is no expiration date. For
> nl.domains is a maintenance fee (quarterly, .de monthly I believe).
> Of course if that payment is stopped, the domainname expires
> automatically. So that is a form of expiration, but I find it
> difficult to put it in wording.

Yes, the next version of the draft will clearly note that domains do not
necessarily have an explicit expiration date.  I don't want to get anywhere
near trying to explain in this document how expiration might happen due to
billing issues, and I think everyone will agree that it's out of scope.

> 3.4.[3]
> 
> 	``A request  Must have a transaction identifier ... ''
> 
> If it is a request for a new domain, should the registrar generate
> this? It looks like a bootstrapping problem to me, I'm confused
> but might just not understand. Also

I think I need to reword this text to make it clear that an identifier MUST
be associated with the transaction, but how it happens is up to the protocol
designers.

> 	``The transaction identifier MUST be returned to the 
> registrant ...''
> 
> This sounds as a requirement to how the registrar operates and is
> outside the scope the registry/registrar protocol. At least, I
> haven't seen how the protocol can enforce this.

If the identifier is needed to authorize a transfer (which I believe is a
Good Thing), the identifier has to get to the client (new registrar) who
issues a transfer request.  The protocol can enforce this by not processing
a transfer action without the identifier, but perhaps this requirement
should be changed to not touch on registrar-registrant interaction.

> 3.4.[4] & 3.4.[5] Name servers & Glue records
> 
> Yes, I do agree that the protocol MUST be able to use nameservers
> with out-of-zone nameservers (example.com might have 
> ns1.nameserver.net
> as nameserver). But the fact that one should not have glue records
> for is actually not part of the protocol requirements. It is more
> part of how to run a proper nameserver. Maybe, instead of the
> wording about the glue records, we should have a reference to one
> or more of the current RFCs which  deal with the care and feeding
> of nameserver? Something like:
> 
> 	Glue records for out of zone nameservers MUST not be in the
> 	zonefile, according to RFC XXXX.
> 
> might probably be enough.

I need to defer to Patrik here since the original text was added at his
request.  One of my original instructions from the IESG was to stay away
from describing _how_ the protocol should do anything in this document, and
instead describe _what_ the protocol needs to do, leaving the "how" to the
protocol design documents.  I could generalize this requirement a bit to say
something like "Glue records for out of zone nameservers MUST be managed
according to current DNS standards" (which says _what_ must happen, but not
_how_ it happens), but I think Patrik had some specific reasons for wanting
this text more explicit.  Patrik?

> 3.4.[6] contact information
> 
> I have the feeling that the required contact information might be
> too detailed in certain cases. If the registry/registrar relation
> is very thin it is possible that just information over the registrar
> might be sufficient. (But then one can argues thses also have a
> name, address etc. so it won't hurt.

True, but the protocol has to support both thick and thin models.  It's
important to distinguish between what the protocol has to do to support
multiple models, and how each registry may use the protocol.  Section 2.4
says that an underlying assumption is that a registry may choose to
implement a subset of the required protocol features, and this is one area
where I think registries will choose to do things differently based on local
policies.

> 3.4.[7] telephone numbers must conform to international standards
> 
> ``The good thing about standards is that there are so many to choose
> from'' (Andy Tanenbaum). Maybe we should have a reference to a
> specific standard. (The ENUM RFC uses I-TU E.164 if not mistaken).

Agreed, but this gets into "how" vs. "what".  I'd prefer to keep this
requirement as-is, leaving the specific reference to the protocol documents.

> 3.4.[8] identifiers
> 
> The mention of ``contact identifier'' remembers me of NIC-handles.
> I'm also not so sure that all the mentioned identifiers are actually
> necessary in an actual protocol. Maybe the MUST should become a
> MAY?

I think there has to be some kind of unique key associated with every
object.

> 3.4.[9]  grace period
> S
> This requirement borders on policy issues. Some policies for updating
> certain objects might not allow for a grace period (but then, I
> realize, you can always set the period to 0).

Agreed, this requirement will not be in the next version.

> 3.4.[10]
> 
> I looked at this form various points to try to get the 
> meaning of this.
> I'm afraid I don't get it. The first sentence is fine:
> 
> 	``All registrars MUST be authorized to register 
> S
> and seems obvious to me (Wasn't this the gaol of the protocol?).
> But the bit about nameservers registration is unclear to me.  Does
> this say that registrar X, Y and Z are not a low to share a nameserver
> (possible hosted by registrar A?). I'm probably just confused.

No, this text shouldn't be interpreted as not allowing "sharing" of a name
server once it has been registered.  That's perfectly OK.  The intention is
to describe which registrar can register and manage name servers within a
registered domain.

> 3.5.[1]
> 
> Remark to 2nd sentence: Some registry require minimal two nameserver
> (but that is policy).

Agreed, and that's why there's nothing in the document to describes minimums
or maximums.

> 3.5.[2]
> 
> The last two sentence, state more a fact then that it is a 
> requirement.
> They might just as easily be dropped.

I think they need to be here to ensure that the protocol provides features
to allow this kind of behavior, which is supported by the DNS.

> BTW, it is the policy of the .nl registry that, to avoid clutter
> and unnecessary glue records in the zone file, that one should not
> have the same nameserver under multiple names. I also believe that
> this is the strongly advised to do so in one of the ``how to run
> nameservers'' RFC. Maybe a reference should be supplied?

This is one of those areas of distinction between what the protocol needs to
do to support multiple models and how a registry might implement the
protocol.  I'd prefer to see a "how" reference in the protocol documents.

> 3.5.[4]
> 
> (Especially the last sentence of) This item actually deals more
> with how to run nameservices then with the Registry/registrar
> relations.  I'm not sure whether this should actually be in this
> document.

This requirement is the one that says that the protocol must allow
registrars to reference name servers registered by other registrars.

> 3.6.[4]
> 
> Seems for me stating the obvious. But maybe is het necessary for
> legal reasons or has it to deal with 3.4.[10] which I didn't get?

Obvious, yes, but we can't forget obvious requirements.

> 3.7 Object Transfer
> 
> I have serious problems with this section. It seems to me to
> concentrate on transfer between registrars. However, it doesn't seem
> to deal with transfer of objects between registrant (domain name
> holders). Or maybe I'm too much focused on the word ``transfer''.
> One might actually say that the last case (transfer between
> registrants) is actually an update of an object. Is that the case?
> Actually one can draw a matrix the way things might be transferred:
> 
>           registrant A      registrant B
>         ---------------------------------
> 	|                |               | registrar X
>         ----------------------------------
>         |                |               | registrar Y
>         ----------------------------------
> 
> So I guess what is meant transfer is in a vertical direction, while
> transfer in horizontal direction is actually covered by update.
> Maybe some form of introduction it this style is needed somewhere
> in the document.

Nothing in this document addresses registrant-registry or
registrant-registrar behavior, except the mention of transaction identifier
management (which I can change).  I believe these interactions are out of
scope.

> Sections 3.7.[1] - 3.7.[7] describe the basics of the transfer of
> the objects between registrars. Apart from that, it does something
> else in the mean time. It actually defines policy matter: The
> original sponsoring registrar is able to block the transfer. Either
> (implicitly) by never releasing the current transaction identifier
> or directly by using 3.7.[7].
> 
> Whether or not a registrar is able to block such a transfer is a
> policy matter. Currently it is not allowed in the .nl registry (and
> as far as I know in .den either). Some time ago it was possible to
> do this in .nl, but on request of various registrars and given the
> experience gained, this is no longer the case. It turned out that
> when there were conflicts between registrant A and registrar X and
> A wanted to switched to registrar Y, X basically could take the
> domain from A hostage. Often the registry was dragged into the
> conflict to decide whether of not the domain was correctly taken
> ``hostage'', often was forced to take a side in the conflict. The
> conflicts can be arbitrary. Non-payment by A for services provided
> by X, non-delivery of services by X paid for by X, or just petty
> complaints, the dog of A has bitten the cat of X. You name it, we
> seem it all.
> 
> The task for a registry is to registry names. Even for conflicts
> whether or not someone has the right on a certain domain name is,
> for most registries not part of their job. For that are dispute
> arbitration thingies or courts of law. So to be dragged into
> arbitrary conflicts is even worse. Therefore we abolished this
> blocking. Other registries might have a different policies.
> 
> Anyway, I tried to reformulate 3.7.[1] and further in a policy
> neutral fashion, but failed miserably. But I do hope we can come
> up with something.

This feature has to be in the protocol (it's 100% required in the ICANN gTLD
world), but it sounds like transfer request blocking by the old registrar
should be an optional feature.

> 3.8. Renewal/Extensions
> 
> As said by 3.4.[2], some registry policies have automatic extensions,
> so this need some rethinking.

Yes, agreed, and the next version will put both sections in synch.

> Section 3.9 and 3.11 seems to handle the same type of subjects:
> Queries to the registry. Maybe they should either lumped together
> or at least change the order of 3.10 and 3.9.
> 
> As a general remark, there is some danger that with these queries
> too much information are leaked out of the registry and that it
> might be abused as an alternative for a whois service. These queries
> should be used just in the registration process. A registrar must
> be discouraged using these queries to, for example, search for
> potential customers which are actually served (``sponsored'' is
> the term used in the draft) by competing registrars.

I think the query types need to be separate, but perhaps switching the order
and adding text to better explain the difference would be a good idea.
We've seen a real need in the gTLD world for a very fast "is this object
registered" query that any registrar can perform, and then a potentially
more restricted query to obtain information about a registered object.  I
agree that query abuse is something we need to be aware of, especially in a
thick registry environment where contact information may be maintained.

Date: Mon, 8 Jan 2001 14:27:19 +0100
From: Olivier Guillard <[email-masked]>
To: Peter Mott <[email-masked]>
Cc: Annie Renard <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Definition of Registry
Sender: [email-masked]

Hello Peter,

le 05 Jan, Peter Mott a écrit :
> 
> > > it's the practice for the .fr registry
> > > update of the database are requested by the registrant, through
> > > the registrar.
> > 
> > We have different views of the world.  Through my eyes I see domain name
> > registration  being the execution of a legal contract between the registrar
> > and the registrant.  The public record of that contract is the insertion of
> > the name into the registry database.

To clarify the issues, could you please precise what you call "registry
database"?

> > 
> > To determine the registrar, I simply ask the question "with whom does the
> > registrant have a contract for the domain name registration?"  Whoever that
> > entity is - is always the registrar.
> 

The registrant consideration is surely an important issue, but it might not
be the only one, especially for a ccTLD zone. Under .fr, for example, we
try to also serve a local user comunity, by furnishing a "trust zone":

- Stable and properly configured delegated DNS
- Pertinent, coherent and verifyed Whois informations
- Fair and multilingual search directory

> > Not sure how .fr works, but I suspect the contract is in fact between the
> > registrant and your organisation.  The party you refer to as registrar is
> > probably acting as an agent for the registrant.  Your organisation is in
> > fact the registrar.

The .fr registry is one of the first that has distinguished the databases
maintaining from the furniture of services linked to domainames! At that
time NSI was selling domainnames and maintaning the . , .com, .net and .org
db :)

> > This may all seem to be splitting hairs, but its important stuff in my view.
> > Understanding relationships and roles is required before developing system
> > to support it, and protocol to enable system

The .fr zone is a ressource that is aimed to serve and promote a particular
comunity designated by those two letters. It's essential for us to distinguish
the commercial function (domain name sale) from the political one (charter
and usage referential writting). For me, this last function is the buisness
of the users. They must have the means and tools to be able to say what they
want and also know that their choices can be apply.

> > > registrar is a provider of added value (services) for the user
> > > connectivity.
> > 
> > My definition of registrar is simply an entity accredited to enter into
> > domain name registration contracts with registrants.  This entity may have
> > domain name registration as a core or supporting business activity.  It is
> > not relevant.

What do you mean exactly by "accreditated entity". On which criteriums,
defined by who and by which process do you feel the accreditation should
happen?

> > > In France, registry is a monopoly model (public service, not
> > > registrar itself),
> > > registrars are in the competitive sector.
> > 
> > I think you will see from above that I dont agree with you.  What you likely
> > have is a monopoly registrar (your organisation) with agents all offering
> > the same registration contract (your TLD policy combined with business
> > rules).
> > 
> > Such a model does not support competition in the business of domain name
> > registration.  Although I concede that agents can wrap your service in
> > different ways to differentiate themselves.  I suspect however the major
> > differentiation occurs between core service elements for the agent rather
> > than the service of name registration.
> > 
> > Please dont think I am a supporter of any particular model or have fixed
> > views.  I have been studying this stuff in depth since 1996, own an
> > accredited ICANN registrar (although not operational as yet) and admin for
> > .tk .aq as well as registry operator for .pn
> > 
> > What I have been trying to highlight is that it is the identification of the
> > players and their relationships that is important, not so much where the
> > data is.  If this wg proceeds with the relationship model in the draft,
> > thats ok with me.  I just wanted to make sure people had the opportunity of
> > considering alternatives.

We don't try to prescribe to anyone what he has to do, we just think that
the .fr internet zone should grow with the respect of a "charter". There
are many stackholders that are really concerned by the naming policies under
the .fr (it is a country code!). We have the responsability to take in
account their point of view, that's why this "charter" is written implying
them. ".mu" has been delegated for the maurician island, have you ever
been their? go to http://www.mu, I personnally don't recognize the local
maurician community. No doubt that the relation ship beetwen the regitrar
and the registry for this zone is very automated (and close from GRRP).

> > Regards
> > 
> > Peter Mott
> > Chief Enthusiast
> > 2day.com
> > - -/-
> > 
> > 
> > 

Very best regards,

-- 
Olivier Guillard

---
||    A.F.N.I.C.
|| http://www.nic.fr
|| mailto:[email-masked]

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: comments on your grrp-reqs-05.txt (second try)
Date: Mon, 08 Jan 2001 13:33:36 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Scott,

Here are promised comments on the draft. I'm afraid it is not
complete, it goes up to page 13 (section 3.9). I do have some
comments about the rest but they are still sketchy and not really
worked out.  But I believe that for now there are enough things
which need attention.

I'm aware that some have already been discussed and are maybe a
repeat. Others might be more questions about (mine) improper
interpretation. For some I will try to formulate some replacement.
text, but, not being an American native speaker, they might not be
as precise as desired. Therefore I will add the motivation in the
hope that the meaning my remarks become clear.

Regards,

	jaap

About 2.2 System Functions

This section describes also whois is services that the registry
might provide. I would suggest to some text in the style of:

	Details about the functionality of this whois functions
	are is not covered in this document.

About 3.1 Session Management

Since is a high level description it might be wise to make some
statement about what happens when the session is premature aborted.
Something in the line of:

	[7] The protocol MUST have a way to deal with premature
	aborted sessions. For example, roll back of the current
	transaction.

About 3.3 Transaction identification

I'm worried about the role that this has in the protocol. It might
be that it is just my view, but I consider that the registration
of a domain name, the change of a nameserver, the transfer of a
name to another registrar, etc, each separate transactions. And to
have some kind of idea per transaction is not bad (For example,
when the session is interrupted during the transaction).

However, the way it is used (See 3.7, Object Transfer) it seems to
me that this ID is actually an encoding for a domainname-registrar
pair. It only changes when this relation ship changes. Correct me
if I'm wrong and please explain the role in the protocol.

3.4.[2]

This has been discussed before. I just want to add that in .nl (and
as far as I now in .de land) there is no expiration date. For
nl.domains is a maintenance fee (quarterly, .de monthly I believe).
Of course if that payment is stopped, the domainname expires
automatically. So that is a form of expiration, but I find it
difficult to put it in wording.

3.4.[3]

	``A request  Must have a transaction identifier ... ''

If it is a request for a new domain, should the registrar generate
this? It looks like a bootstrapping problem to me, I'm confused
but might just not understand. Also

	``The transaction identifier MUST be returned to the registrant ...''

This sounds as a requirement to how the registrar operates and is
outside the scope the registry/registrar protocol. At least, I
haven't seen how the protocol can enforce this.

3.4.[4] & 3.4.[5] Name servers & Glue records

Yes, I do agree that the protocol MUST be able to use nameservers
with out-of-zone nameservers (example.com might have ns1.nameserver.net
as nameserver). But the fact that one should not have glue records
for is actually not part of the protocol requirements. It is more
part of how to run a proper nameserver. Maybe, instead of the
wording about the glue records, we should have a reference to one
or more of the current RFCs which  deal with the care and feeding
of nameserver? Something like:

	Glue records for out of zone nameservers MUST not be in the
	zonefile, according to RFC XXXX.

might probably be enough.

3.4.[6] contact information

I have the feeling that the required contact information might be
too detailed in certain cases. If the registry/registrar relation
is very thin it is possible that just information over the registrar
might be sufficient. (But then one can argues thses also have a
name, address etc. so it won't hurt.

3.4.[7] telephone numbers must conform to international standards

``The good thing about standards is that there are so many to choose
from'' (Andy Tanenbaum). Maybe we should have a reference to a
specific standard. (The ENUM RFC uses I-TU E.164 if not mistaken).

3.4.[8] identifiers

The mention of ``contact identifier'' remembers me of NIC-handles.
I'm also not so sure that all the mentioned identifiers are actually
necessary in an actual protocol. Maybe the MUST should become a
MAY?

3.4.[9]  grace period
S
This requirement borders on policy issues. Some policies for updating
certain objects might not allow for a grace period (but then, I
realize, you can always set the period to 0).

3.4.[10]

I looked at this form various points to try to get the meaning of this.
I'm afraid I don't get it. The first sentence is fine:

	``All registrars MUST be authorized to register 
S
and seems obvious to me (Wasn't this the gaol of the protocol?).
But the bit about nameservers registration is unclear to me.  Does
this say that registrar X, Y and Z are not a low to share a nameserver
(possible hosted by registrar A?). I'm probably just confused.

3.5.[1]

Remark to 2nd sentence: Some registry require minimal two nameserver
(but that is policy).

3.5.[2]

The last two sentence, state more a fact then that it is a requirement.
They might just as easily be dropped.

BTW, it is the policy of the .nl registry that, to avoid clutter
and unnecessary glue records in the zone file, that one should not
have the same nameserver under multiple names. I also believe that
this is the strongly advised to do so in one of the ``how to run
nameservers'' RFC. Maybe a reference should be supplied?

3.5.[4]

(Especially the last sentence of) This item actually deals more
with how to run nameservices then with the Registry/registrar
relations.  I'm not sure whether this should actually be in this
document.

3.6.[4]

Seems for me stating the obvious. But maybe is het necessary for
legal reasons or has it to deal with 3.4.[10] which I didn't get?

3.7 Object Transfer

I have serious problems with this section. It seems to me to
concentrate on transfer between registrars. However, it doesn't seem
to deal with transfer of objects between registrant (domain name
holders). Or maybe I'm too much focused on the word ``transfer''.
One might actually say that the last case (transfer between
registrants) is actually an update of an object. Is that the case?
Actually one can draw a matrix the way things might be transferred:

          registrant A      registrant B
        ---------------------------------
	|                |               | registrar X
        ----------------------------------
        |                |               | registrar Y
        ----------------------------------

So I guess what is meant transfer is in a vertical direction, while
transfer in horizontal direction is actually covered by update.
Maybe some form of introduction it this style is needed somewhere
in the document.

Sections 3.7.[1] - 3.7.[7] describe the basics of the transfer of
the objects between registrars. Apart from that, it does something
else in the mean time. It actually defines policy matter: The
original sponsoring registrar is able to block the transfer. Either
(implicitly) by never releasing the current transaction identifier
or directly by using 3.7.[7].

Whether or not a registrar is able to block such a transfer is a
policy matter. Currently it is not allowed in the .nl registry (and
as far as I know in .den either). Some time ago it was possible to
do this in .nl, but on request of various registrars and given the
experience gained, this is no longer the case. It turned out that
when there were conflicts between registrant A and registrar X and
A wanted to switched to registrar Y, X basically could take the
domain from A hostage. Often the registry was dragged into the
conflict to decide whether of not the domain was correctly taken
``hostage'', often was forced to take a side in the conflict. The
conflicts can be arbitrary. Non-payment by A for services provided
by X, non-delivery of services by X paid for by X, or just petty
complaints, the dog of A has bitten the cat of X. You name it, we
seem it all.

The task for a registry is to registry names. Even for conflicts
whether or not someone has the right on a certain domain name is,
for most registries not part of their job. For that are dispute
arbitration thingies or courts of law. So to be dragged into
arbitrary conflicts is even worse. Therefore we abolished this
blocking. Other registries might have a different policies.

Anyway, I tried to reformulate 3.7.[1] and further in a policy
neutral fashion, but failed miserably. But I do hope we can come
up with something.

3.8. Renewal/Extensions

As said by 3.4.[2], some registry policies have automatic extensions,
so this need some rethinking.

Section 3.9 and 3.11 seems to handle the same type of subjects:
Queries to the registry. Maybe they should either lumped together
or at least change the order of 3.10 and 3.9.

As a general remark, there is some danger that with these queries
too much information are leaked out of the registry and that it
might be abused as an alternative for a whois service. These queries
should be used just in the registration process. A registrar must
be discouraged using these queries to, for example, search for
potential customers which are actually served (``sponsored'' is
the term used in the draft) by competing registrars.

Date: Mon, 08 Jan 2001 09:19:15 +0100
From: Klaus Malorny <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Ok. let's move on (was: RE: Definition of Registry)
Sender: [email-masked]

[email-masked] wrote:
> 
> On 6 Jan 01, at 22:32, Peter Mott wrote:
> 
> ...
> > Anyway, I suspect this thread is now off topic.  Most people here want to
> > build a protocol based on a technical view, not one that takes into account
> > business relationships and legal contracts.
> ...
> 
> Let's move on. I just want to make sure that the definition
> in the document and the protocol that we're building
> are flexible enough to support different views/usage.
> 
> Come to think of it, business relationships *may* affect
> technical design. eg. we may have to use somekind of
> certificate to allow record modification, chain of trust,
> somekind of certificate authority,
> direct access to the database by a large (huge? millions) number
> of users (if registrant is allow to access her own record),
> ... argh that's too complicated. :-(
> 
> Well, I'll let you guys deal with this :-)
> 

Yes, indeed this discussion will have little influence in the design of the
base protocol. But maybe we are able to define an upper layer protocol/common
requirements for registries or similar, and therefore I think it is important
to discuss such things and keep them in mind.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: [email-masked]
To: <[email-masked]>
Date: Sun, 7 Jan 2001 05:35:40 +0700
Subject: Ok. let's move on (was: RE: Definition of Registry)
Sender: [email-masked]

On 6 Jan 01, at 22:32, Peter Mott wrote:

...
> Anyway, I suspect this thread is now off topic.  Most people here want to
> build a protocol based on a technical view, not one that takes into account
> business relationships and legal contracts.
...

Let's move on. I just want to make sure that the definition
in the document and the protocol that we're building
are flexible enough to support different views/usage.

Come to think of it, business relationships *may* affect
technical design. eg. we may have to use somekind of
certificate to allow record modification, chain of trust,
somekind of certificate authority,
direct access to the database by a large (huge? millions) number
of users (if registrant is allow to access her own record),
... argh that's too complicated. :-(

Well, I'll let you guys deal with this :-)

[back to my corner and work on this huge tcpdump trace again...
this silly tcpslice doesn't work :-(
got any tools to slice huge tcpdump trace?]

-- budi
-- TLD-ID
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: "Peter Mott" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Definition of Registry
Date: Sat, 6 Jan 2001 22:32:11 +1300
Importance: Normal
Sender: [email-masked]

> Peter,
> I still think that the user/registrant/registered entity
> is the one that has the power to change the data in
> the registry. (Through some kind of certificate.)
>
> However, she can delegate the right to a registrar.
> ie. a registrar can change the data, on behalf of her.
> It is easy to transfer authority/delegation from one
> registrar to another registrar if she wishes.
> Just revoke the certifiate and issue an new one.
>
> Maybe something like this?
>
>           Registry
>               |
>      +--------+-----------+ ...
>      |        |           |
>    User/    registrar  registrar
> Registrant    |           |
>            +--+---+
>            |      |
>          User/
>        Registrant

Above is based on a technical/data management perspective.  It does not
address business relationship, contract or liability issues.  For example,
if the registry sells domain name registration services directly to
registrants, then it is competing with its registrar customers.  It also
means the registry has to charge a domain name registration fee of some sort
to the registrant directly, potentially managing thousands of accounts and
all the time taking its focus away from its core business - that of
providing a register that records domain name registration contracts
executed by registrars.

There are several others that make it less than desirable as well, but I
wont go into them here.

My preferred model sees the registry charging each accredited registrar a
monthly fee that represents their share of the cost of providing the
registry service.  The registry should not charge registrars fees that
relate to specific domain names.  This is where I think the ICANN gTLD model
and the NSIregistry modus operandi could be improved to reduce complexity
and cost.

Anyway, I suspect this thread is now off topic.  Most people here want to
build a protocol based on a technical view, not one that takes into account
business relationships and legal contracts.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Herbert Vitzthum" <[email-masked]>
To: "Klaus Malorny" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: AW: Definition of Registry
Date: Sat, 6 Jan 2001 09:42:15 +0100
Importance: Normal
Sender: [email-masked]

Thats the perfect picture

Herbert

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Klaus Malorny
> Gesendet: Samstag, 06. Janner 2001 00:42
> An: [email-masked]
> Cc: [email-masked]
> Betreff: Re: Definition of Registry
>
>
>
>
> [email-masked] wrote:
> >
> > On 5 Jan 01, at 14:06, Peter Mott wrote:
> >
> > > Perhaps I was not so clear.  I am talking about the entity
> with power to
> > > change the data in the registry, not the entity that claims
> an intellectual
> > > property right to the data.
> >
> > Peter,
> > I still think that the user/registrant/registered entity
> > is the one that has the power to change the data in
> > the registry. (Through some kind of certificate.)
> >
> > However, she can delegate the right to a registrar.
> > ie. a registrar can change the data, on behalf of her.
> > It is easy to transfer authority/delegation from one
> > registrar to another registrar if she wishes.
> > Just revoke the certifiate and issue an new one.
> >
> > Maybe something like this?
> >
> >           Registry
> >               |
> >      +--------+-----------+ ...
> >      |        |           |
> >    User/    registrar  registrar
> > Registrant    |           |
> >            +--+---+
> >            |      |
> >          User/
> >        Registrant
> >
>
>
> Budi,
>
> to our experience, registrars often have resellers, and, in some
> cases, they
> also have resellers. So, to use your diagram, it could look like
>
>            Registry
>                |
>       +--------+-----------+ ...
>       |        |           |
>     User/    registrar  registrar
>  Registrant    |           |
>             +--+---+     reseller
>             |      |       |
>           User/       +----+---+
>         Registrant    |        |
>                     User/     reseller
>                   Registrant   |
>                                .
>                                .
>                              User/
>                            Registrant
>
> So the question is whether one should introduce a generalized concept of a
> "chain of delegation", similar to the chain of authorities in digital
> certificates.
>
> regards,
>
> Klaus Malorny
>
> __________________________________________________________________
> _________
>      |       |
>      | knipp |                   Knipp  Medien und Kommunikation GmbH
>       -------                           Technologiepark
>                                         Martin-Schmeisser-Weg 9
>      Dipl. Inf. Klaus Malorny           44227 Dortmund
>      [email-masked]             Tel. +49 231 9703 0

Date: Sat, 06 Jan 2001 00:42:06 +0100
From: Klaus Malorny <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Definition of Registry
Sender: [email-masked]

[email-masked] wrote:
> 
> On 5 Jan 01, at 14:06, Peter Mott wrote:
> 
> > Perhaps I was not so clear.  I am talking about the entity with power to
> > change the data in the registry, not the entity that claims an intellectual
> > property right to the data.
> 
> Peter,
> I still think that the user/registrant/registered entity
> is the one that has the power to change the data in
> the registry. (Through some kind of certificate.)
> 
> However, she can delegate the right to a registrar.
> ie. a registrar can change the data, on behalf of her.
> It is easy to transfer authority/delegation from one
> registrar to another registrar if she wishes.
> Just revoke the certifiate and issue an new one.
> 
> Maybe something like this?
> 
>           Registry
>               |
>      +--------+-----------+ ...
>      |        |           |
>    User/    registrar  registrar
> Registrant    |           |
>            +--+---+
>            |      |
>          User/
>        Registrant
> 

Budi,

to our experience, registrars often have resellers, and, in some cases, they
also have resellers. So, to use your diagram, it could look like

           Registry
               |
      +--------+-----------+ ...
      |        |           |
    User/    registrar  registrar
 Registrant    |           |
            +--+---+     reseller
            |      |       |
          User/       +----+---+
        Registrant    |        |
                    User/     reseller
                  Registrant   |
                               .
                               .
                             User/
                           Registrant

So the question is whether one should introduce a generalized concept of a
"chain of delegation", similar to the chain of authorities in digital
certificates.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: [email-masked]
To: <[email-masked]>
Date: Sat, 6 Jan 2001 05:07:58 +0700
Subject: RE: Definition of Registry
Sender: [email-masked]

On 5 Jan 01, at 14:06, Peter Mott wrote:

> Perhaps I was not so clear.  I am talking about the entity with power to
> change the data in the registry, not the entity that claims an intellectual
> property right to the data. 

Peter,
I still think that the user/registrant/registered entity
is the one that has the power to change the data in
the registry. (Through some kind of certificate.)

However, she can delegate the right to a registrar.
ie. a registrar can change the data, on behalf of her.
It is easy to transfer authority/delegation from one
registrar to another registrar if she wishes.
Just revoke the certifiate and issue an new one.

Maybe something like this?

          Registry
              |
     +--------+-----------+ ...
     |        |           |
   User/    registrar  registrar
Registrant    |           |
           +--+---+
           |      |
         User/
       Registrant

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: [email-masked]
To: <[email-masked]>
Date: Sat, 6 Jan 2001 05:06:08 +0700
Subject: RE: Definition of Registry
Sender: [email-masked]

On 5 Jan 01, at 14:06, Peter Mott wrote:

> Perhaps I was not so clear.  I am talking about the entity with power to
> change the data in the registry, not the entity that claims an intellectual
> property right to the data. 

Peter,
I still think that the user/registrant/registered entity
is the one that has the power to change the data in
the registry.
However, she can delegate the right to a registrar.
ie. a registrar can change the data, on behalf of the user.

Registry can deal with registrar *AND* user/registrant.

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

To: [email-masked]
cc: "Hollenbeck, Scott" <[email-masked]>
Subject: Oh shit
Date: Fri, 05 Jan 2001 22:21:51 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Oops, I just mailed an incomplete version of my comments on the draft.
It was not meant to go out. I'll have a better version with more
comments ready later this weekend. It is probably better to discard it
for now, I'll repost.

Please, accept my apologies for this.

	jaap

To: [email-masked]
cc: "Hollenbeck, Scott" <[email-masked]>
Subject: comments on grrp-05
Date: Fri, 05 Jan 2001 22:15:54 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Scott,

Here are some comments on the draft. I'm aware that some have already
been discussed and are maybe a repeat. Others might be more questions
about (mine) improper interpretation. For some I will try to formulate
some replacement. text, but, not an american native speaker, they might
not be as precise as desired. Therefore I will add the motivation in
the hope that the meaning is clear.

About 2.2 System Functions

This section describes also whois is services that the registry might
provide. I would suggest to some text in the style of:

	Details about the functionality of this whois functions
	are is not covered in this document.

About 3.1 Session Management

Since is a high level description it might be wise to make some
statement about what happens when the session is premature aborted.
Something in the line of:

	[7] The protocol MUST have a way to deal with premature
	aborted sessions. For example, roll back of the current
	transaction.

About 3.3 Transaction identification

I'm worried about the role that this has in the protocol. It might be
that it is just my view, but I consider that the registration of a
domain name, the change of a nameserver, the transfer of a name to
another registrar, etc, each separate transactions. And to have some
kind of idea per transaction is not bad (For example, when the session
is interrupted during the transaction).

However, the way it is used (See 3.7, Object Transfer) it seems to me
that this ID is actually an encoding for a domainname-registar pair. It
only changes when this relation ship changes. Correct me if I'm wrong
and please explain the role in the protocol.

3.4.[2]

This has been discussed before. I just want to add that in .nl (and as
far as I now in .de land) there is no expiration date. For nl.domains is
a maintanance fee (quarterly, .de monthly I believe). Of course if that
payment is stopped, the domainname expires automatically. So that is a
form of experation, but I find it difficult to put it in wording.

3.4.[3]

	``A request  Must have a transaction identifier ... ''

If it is a request for a new domain, should the registrar generate this?
It looks like a bootstrapping problem to me, I'm confused but might just
not understand. Also

	``The transaction identifier MUST be returned to the registrant ...''

This sounds as a requirement to how the registrar operates and is 
outside the scope the registry/registar protocol.

Date: Fri, 5 Jan 2001 12:33:36 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: "Ross Wm. Rader" <[email-masked]>
cc: "Ietf-Provreg@Cafax. Se" <[email-masked]>
Subject: Re: Domain Name/Whois Data Element and Related Definitions 
Sender: [email-masked]

For purposes of privacy filtering it is my sense that for each set of
information that pertains to an identifiable person that we need at least
a clearly tagged item that indicates the country in which that person
resides.  That will make it a lot easier to build privacy filters.

Similarly, the entire collection of data ought to be tagged with an item
that indicates the country in which the database from which the report is
being made can be found.

		--karl--

From: "Herbert Vitzthum" <[email-masked]>
To: "Ross Wm. Rader" <[email-masked]>, "Ietf-Provreg@Cafax. Se" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: AW: Domain Name/Whois Data Element and Related Definitions
Date: Fri, 5 Jan 2001 21:15:03 +0100
Importance: Normal
Sender: [email-masked]

Dear Ross

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Ross Wm. Rader
> Gesendet: Freitag, 05. Jänner 2001 15:12
> An: Ietf-Provreg@Cafax. Se; Patrik Fältström
> Betreff: Re: Domain Name/Whois Data Element and Related Definitions
>
>
> > Using the term SLD is difficult as sometimes what is registered is
> > not an second level domain, but instead a third level domain.
>
> True. ICANN made a small mistake when they put their various operating
> agreements with DOC/NSI/Registrars in place. Prior to that,
> "domain holder"
> and "registrant" were used somewhat interchangeably to describe the entity
> that held the domain. When ICANN started producing contracts,
> they defined a
> new term "SLD Holder" to mean the same thing. The problem was that people
> stopped using "domain holder" and started using the unwieldly newer terms.
> As such, the more understood and universally used term "domain holder" has
> largely been dropped from the vocabulary of domains. I think it's
> time that
> we bring it back ;)

I agree with you.
It is not important on whtich Label. The Domain Holder is the Organisation
or Person who is the Owner/User of the Name. XXXX.de, XXXX.CO.UK, the Domain
Holder uses XXXX under .co.uk and XXXX under .de nothing else.

>
> I'll annotate the next version to include a variant of the above.
> If anyone
> has any suggestions as to what the def'n of a "domain holder"
> should be, or
> rather, where the definition may be materially different from that of SLD
> Holder, please drop me a line. I'll start wordsmithing in the meantime...
>
> -rwr

This is the definition from the nic.at Terms and Conditions

1.3 Domain-holder

Domain-holder means such authorized party (natural person or legal entity)
as is solely entitled to claim use of the domain vis-à-vis nic.at. In the
application form, the holder shall be designated by its full and correct
name and address. By filing the application, the applicant represents that
he is of age and has legal capacity.

http://www.nic.at/english/agbs.html

Best Regards

Herbert

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Definition of Registry 
Date: Fri, 5 Jan 2001 14:14:29 -0500
Importance: Normal
Sender: [email-masked]

(This ended up beinging kinda long, sorry in advance)

Hello, just joined the mailing list yesterday and just finished reading the
archive- phweeeuu!  Forgive me during this learning curve, I am new to this
whole thing.

I have a comment on the sticking point between gTLD-oriented people and
ccTLD-oriented people regarding the "competitive model".

In many cases in life it is common for the same "entity" to take on
different roles.  If a registry provides domain name restration services
(like NSI) then it could be viewed that the registry is acting as a
registrar during those activities.

Our company has been thinking about the different roles related to domain
name registration and at the highest level we have so far:

3:User - Individual contact/agent - Authorized to act on behalf of (2).

2:Customer - Individual, company, org, gov't, etc. - "Owner" of the "thing"
that each "transaction" concerns.  (could I be any more ambiguous? ;-)

NOTE: (3) and (2) could be one and the same person.

1:Registrar - Organization responsible for gathering the required
information and transmitting said information to (0). Might want to store
information on (1) & (2) on a local DB.  Will probably want to enforce some
set of business rules (policy) on (2) - like charge money, etc.

0:Registry - Organization responsible for processing requests from (1),
storing them in a database and publishing zone files.  Will probably want to
enforce some set of business rules on (1) - like expected data fields, etc.

NOTE: (1) and (0) could be one and the same "entity".

The below discussion might be a matter of symantics.  When someone says:

 >     "Registry: An entity that provides back-end domain name registration
 >     services to registrars....

It tells me that there exists the capability for a registrar to connect to
the registry's system and request an action.  It DOES NOT tell me that a
registry initiates a request for any of those actions.  Which I think is the
way it should be.

If an entity (company, gov't, etc.) initiates a request to it's own registry
for a domain name service, then at that moment that entity is acting in the
role of a regsitrar.  When it processes its own request it switches back to
being a registry.

I think the below discussion tends to limit every entity (company, gov't,
etc.) to only one role - which would not allow a regstry to "have any
interest in the business of domain name registration."  Which would be a
limited view of reality.

It is said that it is better to remain silent and thought a fool then to
speak and remove all doubt.  Well, I guess I spoke..... :-)

Paul George
Saraf Software Solutions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Herbert Vitzthum
Sent: Friday, January 05, 2001 3:35 AM
To: Peter Mott; Jaap Akkerhuis; Hollenbeck, Scott
Cc: [email-masked]; [email-masked]
Subject: AW: Definition of Registry

Peter,

if the RRP is only for NSI or maybe some new gTLDs fine. If not understand
and accept ccTLD Voice and nearly common way of doeing.

Best Regards

Herbert

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Peter Mott
> Gesendet: Donnerstag, 04. Jänner 2001 22:15
> An: Jaap Akkerhuis; Hollenbeck, Scott
> Cc: [email-masked]; [email-masked]
> Betreff: RE: Definition of Registry
>
>
> >     OK, how about changing the definition from this:
> >
> >     "Registry: An entity that provides back-end domain name registration
> >     services to registrars, managing a central repository of
> > information
>
> Whats broke here is the notion that a registry provides a domain name
> registration service.  In a competitive model, the registry should only do
> these things:-
>
> *	Provide registrars with access to a shared database
> *	Publish zone files
>
> At no time does the registry register names.  Registration is a task
> completed by the registrar as part of executing a contract it has with the
> registrant.
>
> The registry should not have any interest in the business of domain name
> registration.  Just the business of ensuring accredited registrars can.
>
> My thinking is that the registry exists to complete the tasks
> which cant be
> shared due to the hierarchical nature of the system.  But those
> tasks alone.
>
> The moment you have the registry taking on other tasks, you introduce
> compexity and duplication of responsibility.
>
> Regards
>
> Peter Mott
> Chief Enthusiast
> 2day.com
> -/-

To: [email-masked]
cc: [email-masked]
Subject: Re: Definition of Registry 
Date: Thu, 04 Jan 2001 17:16:30 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Who is responsible for the content if the Registry is not? Will each
    Registrar instead be responsible for his part of the database?

The registrar should provide the correct data to the registry. If
this change (change of address, phone number or whatever), it should
update the data accordingly.

    What then if a customer moves from one Registrar to another?

There should be a way to enable this transfer, and, the requirements
doc actually specifies this.

Of course, if the registrar is not providing the proper data there
should be ways to force correction of the behavior of the registrar.
Kick him out of the system, whatever.

But it all boils down to the policy of the registry.

Experience learns that it is difficult to fully check the correctness
of all of the data the registrar provides. This might be done by
having directly contacting the registrant for some of the information.
This is something what a ``thick'' registry might do and I believe
that the UK registry does something like that. A very ``thin''
(ultra slim) registry sit on the other end of the spectrum.

Therefore, we should be careful not saying too much about this
which might easily interpret as policy issues.

Sincerely,

	jaap

Date: Wed, 03 Jan 2001 17:39:53 -0500
To: <[email-masked]>, <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: Definition of Registry
Sender: [email-masked]

At 04:48 PM 1/3/2001 -0500, Ross Wm. Rader wrote:
>RickW and I had a conversation about the role of definitions in this process
>and other domain name related efforts in San Diego last month. We both
>agreed that a common base of definitions will play an important role in
>ensuring that whatever work this group and others accomplish is done in the
>most efficient manner. As such, I took it upon myself to pen a draft (which
>may or may not conform to IETF draft submission standards ;) that was
>intended to act as a strawman towards defining a common set of definitions.
>
>If it would be useful, I could clean it up and pass it back to this list in
>short order. I do have a concern that this might be distracting to the
>larger goal of this particular group. Perhaps if the definitions are
>valuable yet the process of definition distractive, a separate effort on a
>separate list geared towards hashing them out might be more efficient.
>
>-rwr

Please do I think this would be most helpful... just post it as text here...

To: "Ietf-Provreg@Cafax. Se" <[email-masked]>
Subject: Re: Domain Name/Whois Data Element and Related Definitions 
Date: Fri, 05 Jan 2001 16:03:43 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Friday, 5 Jan 2001, "Ross Wm. Rader" writes:
>> Using the term SLD is difficult as sometimes what is registered is
>> not an second level domain, but instead a third level domain.

> True. ICANN made a small mistake when they put their various operating
> agreements with DOC/NSI/Registrars in place. Prior to that, "domain holder"
> and "registrant" were used somewhat interchangeably to describe the entity
> that held the domain. When ICANN started producing contracts, they defined a
> new term "SLD Holder" to mean the same thing. The problem was that people
> stopped using "domain holder" and started using the unwieldly newer terms.
> As such, the more understood and universally used term "domain holder" has
> largely been dropped from the vocabulary of domains. I think it's time that
> we bring it back ;)

> I'll annotate the next version to include a variant of the above. If anyone
> has any suggestions as to what the def'n of a "domain holder" should be, or
> rather, where the definition may be materially different from that of SLD
> Holder, please drop me a line. I'll start wordsmithing in the meantime...

We have long ago dropped the term 'administrative contact' because
it is ambiguous. We since then use domain name holder, see (with
a whois client whois.nic.ch or the search engine on 
http://www.nic.ch/search/).

The holder is the legally valid contact for the domain name.
Or more precise: the holder contact contains the legally valid
address information of a natural or legal person to which the
domain name has been assigned.

Native english speakers will find a better formula :). Hope
you know what is intended. Suggest not to use additional 
hierachical definitions, like SLD. A holder is a holder is
a holder :) and not an owner, btw. 

Marcel

From: "Ross Wm. Rader" <[email-masked]>
To: "Herbert Vitzthum" <[email-masked]>, "Ietf-Provreg@Cafax. Se" <[email-masked]>
Subject: Re: Domain Name/Whois Data Element and Related Definitions 
Date: Fri, 5 Jan 2001 09:14:11 -0500
Sender: [email-masked]

From: Herbert Vitzthum <[email-masked]>
To: <[email-masked]>; Ietf-Provreg@Cafax. Se <[email-masked]>
Sent: Friday, January 05, 2001 4:48 AM
Subject: AW: Domain Name/Whois Data Element and Related Definitions

> Dear Ross,
>
> thank you very much for preparing this excellent document. I do not say
that
> I can agree with the content, but it is a very good starting point for a
> long discussion. But maybe this discussion should take place in a
separated
> list - don't know, but seams to be a different level as the RRP.

Agreed, but the language is substantially important to the efforts here.

>
> We should ask for what reason we ask to get a Admin-C or a Tech-C, maybe
in
> some cases this is necessary because the domain holder is not in the
> position to answer questions about his/her domain.
>
> But in most cases to ask the admin-C about a domain it is like to ask a
wall
> also the tech-C. The really important information's needed for a domain
are
> the Information about the Domain-Holder und about the Registrar.

We can only define what the field labels mean, or rather should mean. We
can't prescribe the intelligence or capability labels of the people that
presume the responsibility.

>
> The Billing Information only belongs to the registry and must not be
public
> available.
>

That's a policy issue that should be determined by the Registry.

> The first Question must be "what data is necessary for what reasons"?
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] [mailto:[email-masked]]Im
> > Auftrag von Ross Wm. Rader
> > Gesendet: Donnerstag, 04. Jänner 2001 23:59
> > An: Ietf-Provreg@Cafax. Se
> > Betreff: Domain Name/Whois Data Element and Related Definitions
> >
> >
> > All,
> >
> > As a result of the positive on and off-list responses generated
> > by my offer
> > posted yesterday, the following is my attempt at putting a stake in the
> > ground surrounding the various definitions etc. that we will need to
deal
> > with through this, and other processes. I trust that the format etc.,
will
> > be acceptable for the intended purposes. Keep in mind that in no way do
I
> > view this as the definitive or authoritative list of related
definitions,
> > but rather, as a starting point that will hopefully speed our efforts.
If
> > there is sufficient demand, I will continue to update this
> > document based on
> > the feedback of this group and other parties.
> >
> > -rwr
> >
> >
> >
> > Internet Draft                                                 R. Rader
> > Document: draft-rader-dnwhois-defn-00.txt                   Tucows Inc.
> > Category: Informational                                  November, 2000
> >
> >
> >
> >          Domain Name/Whois Data Element and Related Definitions
> >
> >
> > Status of this Memo
> >
> >    This document is an Internet-Draft and is in full conformance with
> >    all provisions of Section 10 of RFC 2026 [1].
> >
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF), its areas, and its working groups. Note that
> >    other groups may also distribute working documents as Internet-
> >    Drafts. Internet-Drafts are draft documents valid for a maximum of
> >    six months and may be updated, replaced, or obsoleted by other
> >    documents at any time. It is inappropriate to use Internet- Drafts
> >    as reference material or to cite them other than as "work in
> >    progress."
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> > 1. Abstract
> >
> >    Efforts are currently being undertaken to review the role of Whois
> >    (as defined in RFC 954 [2]) and formalize registry/registrar
> >    communications protocols in light of the current and evolving scope
> >    and utility of DNS, domain name registries and related entities. In
> >    order for this work to be truly effective and broadly applicable, it
> >    is important that accepted definitions act as the foundation. This
> >    document is an attempt to create a starting point for the requisite
> >    dialogue that will ultimately foster the determination and
> >    acceptance of these definitions.
> >
> >
> > 2. Conventions used in this document
> >
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
> >    this document are to be interpreted as described in RFC 2119 [3].
> >
> >
> > 3. Definitions
> >
> >    Contact: Contacts are individuals or entities associated with domain
> >    name records. Typically, third parties with specific inquiries or
> >    concerns will use contact records to determine who should act upon
> >    specific issues related to a domain name record. There are typically
> >
> > >                      Domain Name & Related Def'n        November, 2000
> >
> >    three of these contact types associated with a domain name record,
> >    the Administrative contact, the Billing contact and the Technical
> >    contact.
> >
> >         Administrative Contact: The administrative contact is an
> >         individual, role or organization authorized to interact with
> >         the registry or registrar on behalf of the SLD Holder. The
> >         administrative contact should be able to answer non-technical
> >         questions about the domain name's registration and the SLD
> >         Holder. In all cases, the Administrative Contact is viewed as
> >         the authoritative point of contact for the domain name, second
> >         only to the Registrant.
> >
> >         Billing Contact: The billing contact is the individual, role or
> >         organization designated to receive the invoice for domain name
> >         registration and re-registration fees.
> >
> >         Technical Contact: The technical contact is the individual,
> >         role or organization who is responsible for the technical
> >         operations of the delegated zone. This contact likely maintains
> >         the domain name server(s) for the domain. The technical contact
> >         should be able to answer technical questions about the domain
> >         name, the delegated zone and work with technically oriented
> >         people in other zones to solve technical problems that affect
> >         the domain name and/or zone.
> >
> >    Data Escrow:
> >
> >    NIC: Network Information Center.
> >
> >         InterNIC: The InterNIC, a registered service mark of the U.S.
> >         Department of Commerce, is a concept for an integrated network
> >         information center that was developed by several companies,
> >         including Network Solutions, in cooperation with the U.S.
> >         Government. Currently, the term InterNIC is being used in
> >         conjunction with a neutral, stand alone web page (located at
> >         http://www.internic.net) that has been established to provide
> >         the public with information regarding Internet domain name
> >         registration. The InterNIC was originally created by NSF to
> >         provide specific Internet services; directory & database
> >         services (by AT&T), registration services (by Network
> >         Solutions) and information services (by General
> >         Atomics/CERFnet). [4]
> >
> >         NIC Handle: A NIC Handle is an identifier in use by some
> >         registrars and registries that is assigned to various records
> >         in the domain name database. Globally, they do not have a
> >         common format or application. Further, they are not globally
> >         unique.
> >
> >    Registrant: See SLD Holder
> >
> >
> >
> > >                      Domain Name & Related Def'n        November, 2000
> >
> >    Registrar: A person or entity that contracts with SLD holders and a
> >    registry, collecting registration data about the SLD holders and
> >    submitting zone file information for entry in the registry database.
> >
> >    Registry: A Registry is the person(s) or entity(ies) responsible for
> >    providing registry services. Registry services include customer
> >    database administration, zone file publication, DNS operation,
> >    marketing and policy determination in accordance with the general
> >    principles outlined in RFC 1591 [5]. A Registry may outsource some,
> >    all, or none of these services.
> >
> >    Registry Operator: Usually synonymous with the term Registry,
> >    however a Registry Operator may also be an organization or
> >    individual acting operating the Registry under an outsourced
> >    technical services management contract.
> >
> >    SLD: An "SLD" is a second-level domain of the DNS
> >
> >         SLD Holder: The individual or organization that registers a
> >         specific domain name. This individual or organization holds the
> >         right to use that specific domain name for a specified period
> >         of time, provided certain conditions are met and the
> >         registration fees are paid. This person or organization is the
> >         "legal entity" bound by the terms of the relevant service
> >         agreement
> >
> >         SLD Sponsor: The Registrar responsible for the submission of
> >         the domain name to the Registry.
> >
> >    Whois: a TCP transaction based query/response server, that providing
> >    netwide directory service to network users. Originally defined in
> >    RFC 954, the earlier implementations were centralized systems run
> >    first by SRC-NIC and then later InterNIC/Network Solutions. The SRI-
> >    NIC and InterNIC implementations are more formally referred to as
> >    "NICNAME/Whois" services. Whois is not purely a domain name or IP
> >    address directory service, but has been deployed for a wide variety
> >    of uses, both public and private. Other variants of this service
> >    include RWhois and the newer Verisign Referral LDAP Whois service.
> >
> >         Bulk Whois:
> >
> >         Command line Whois:
> >
> >         Referral Whois:
> >
> >         Registrar Whois:
> >
> >         Registry Whois:
> >
> >         Web based Whois:
> >
> >         Whois Record:
> >
> >
> > >                      Domain Name & Related Def'n        November, 2000
> >
> > 4. Security Considerations
> >
> >    This memo provides definitions for administrative terms related to
> >    DNS and does not raise or address security issues.
> >
> > 5. References
> >
> >    [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
> >       BCP 9, RFC 2026, October 1996.
> >
> >    [2]  Harrenstein, Stahl & Feinler, "NICName/Whois", RFC 954, October
> >       1985.
> >
> >    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
> >       Levels", BCP 14, RFC 2119, March 1997
> >
> >    [4]  Kristula, D., "History of the Internet",
> >       http://davesite.com/webstation/net-history.shtml, 1996.
> >
> >    [5]  Postel, J., "Domain Name System Structure and Delegation", RFC
> >       1591, March, 1994.
> >
> >
> > 6. Acknowledgments
> >
> >    This document is the result of input and motivation from a wide
> >    variety of individuals and entities. Rick Wesson, Scott Allan and
> >    Tim Jung provided the primary motivators with ICANN, IANA and
> >    Network Solutions providing the history and context. Additionally,
> >    the various terms and conditions, operating contracts and frequently
> >    asked questions documents produced by various Registries and
> >    Registrars were instrumental in the production of this document.
> >    Where appropriate, these contributions will be specifically
> >    acknowledged in the References portion of future iterations of this
> >    draft.
> >
> > 7. Author's Address
> >
> >    Ross Wm. Rader
> >    Tucows Inc.
> >    96 Mowat Avenue
> >    Toronto, Ontario
> >    M9C 3M1
> >    t. 416.538.5492
> >    f. 416.531.2516
> >    e. [email-masked]
> >
> >
> >
> >
> >
> >
> >
> >
> > >                      Domain Name & Related Def'n        November, 2000
> >
> >
> >
> > Full Copyright Statement
> >
> >    "Copyright (C) The Internet Society 2001. All Rights Reserved. This
> >    document and translations of it may be copied and furnished to
> >    others, and derivative works that comment on or otherwise explain it
> >    or assist in its implmentation may be prepared, copied, published
> >    and distributed, in whole or in part, without restriction of any
> >    kind, provided that the above copyright notice and this paragraph
> >    are included on all such copies and derivative works. However, this
> >    document itself may not be modified in any way, such as by removing
> >    the copyright notice or references to the Internet Society or other
> >    Internet organizations, except as needed for the purpose of
> >    developing Internet standards in which case the procedures for
> >    copyrights defined in the Internet Standards process must be
> >    followed, or as required to translate it into languages other than
> >    English.
> >
> >    The limited permissions granted above are perpetual and will not be
> >    revoked by the Internet Society or its successors or assigns.
> >
> >    This document and the information contained herein is provided on an
> >    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> >    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> >    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
>

From: "Ross Wm. Rader" <[email-masked]>
To: "Ietf-Provreg@Cafax. Se" <[email-masked]>, =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>
Subject: Re: Domain Name/Whois Data Element and Related Definitions
Date: Fri, 5 Jan 2001 09:11:38 -0500
Sender: [email-masked]

> Using the term SLD is difficult as sometimes what is registered is
> not an second level domain, but instead a third level domain.

True. ICANN made a small mistake when they put their various operating
agreements with DOC/NSI/Registrars in place. Prior to that, "domain holder"
and "registrant" were used somewhat interchangeably to describe the entity
that held the domain. When ICANN started producing contracts, they defined a
new term "SLD Holder" to mean the same thing. The problem was that people
stopped using "domain holder" and started using the unwieldly newer terms.
As such, the more understood and universally used term "domain holder" has
largely been dropped from the vocabulary of domains. I think it's time that
we bring it back ;)

I'll annotate the next version to include a variant of the above. If anyone
has any suggestions as to what the def'n of a "domain holder" should be, or
rather, where the definition may be materially different from that of SLD
Holder, please drop me a line. I'll start wordsmithing in the meantime...

-rwr

To: [email-masked]
Subject: Re: Definition of Registry 
Date: Fri, 05 Jan 2001 14:19:42 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Friday, 5 Jan 2001, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= writes:
> At 11.38 +0100 01-01-05, Marcel Schneider wrote:
>>On Friday, 5 Jan 2001, "Peter Mott" writes:
>>
>>I completely agree with Peter's analysis blow. But the
>>important fact for this group is: there are two models
>>for registries/registrars/agents. The 'lightweight'
>>registry model (just DB and connectivity) is mostly
>>used in gTLD's and will continue to be (one of the
>>reasons is that it has not the registry as a bottelneck).
>>
>>The 'policy-setting' registry is more common in ccTLD's and
>>will continue to be.

> Isn't it the case that we actually have two orthogonal things we talk about?

Think so too.

>                | no-policy   |    policy   |
> --------------+-------------+-------------+
> thin registry |             |             |
> --------------+-------------+-------------+
> fat registry  |             |             |
> --------------+-------------+-------------+

> I.e. the question on thin or fat is just about where information of 
> domain name holder is (at registry or registrar) while policy can 
> still exist or not, regardless of this fact.

Maybe we could put it in different wordings:

A 'smart' registry checks policy.
A 'dumb' registry does not check policy.

A 'fat' registry registry contains a most complete set of
   domain name information.
A 'thin' registry contains only a minimal set of domain
   name information, usually the domain name - registrar
   tuple and creation/modification data.

This means we do not have to care about smart or dumb 
registries because this is policy issues only.

We also do not have to care what is published by
registrars/agents/registries because this is privacy
stuff.

The rrp should be designed that it could carry a full set
of registry data as required by a 'fat' registry: all
contacts, name servers, billing info, ceation and mod
dates (maybe more, we will have to determine this) and
all of the control information. The interaction of 
registrars with 'thin' registries will just be a 
subset of the above (hopefully ;-)).

> Yes, most domains _with_ policy are also fat registries, but that is 
> a statistical fact, and not something built into the definitions.

Right.

> Also, you can have a registry for non-TLD's aswell, aswell as for 
> "other things than domains" as Karl said. If the consensus on this 
> list were to do something for domains, and not too generic, even 
> though it is good if it can be used for other things, I still think 
> we should talk about a registry being the responsible registry for a 
> domain, and not just TLD.

Also my opinion. If Karl could supply reasons for a different
approach (a more generic) we'd be glad to reconsider.

Marcel

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: hello and some initial comments
Date: Fri, 5 Jan 2001 07:33:59 -0500 
Sender: [email-masked]

Abstract discussion is OK since it helps provide focus, but we do have two
immediate tasks at hand:

1. Completion of the charter (which has been "last called" by Ed), and
2. Completion of the requirements.

We haven't really started talking about EPP or any other protocol specifics
yet, and that's fine -- without agreed-to requirements it doesn't make much
sense to start looking at protocol proposals.

<Scott/>

-----Original Message-----
From: Klaus Malorny [mailto:[email-masked]]
Sent: Friday, January 05, 2001 7:28 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: hello and some initial comments

"Hollenbeck, Scott" wrote:
> 
> Klaus,
> 
> Thanks for the comments.  If you believe they reflect something that you'd
> like to see changed in the requirements draft, would you please identify
the
> section of the draft that you think needs to be changed and the change
that
> you'd like to see made?
> 
> <Scott/>
> 

I got the impression that the discussion is still on a more abstract level
than your requirements document or your EPP documents, so I didn't do that.
But I can take a look at it once again.

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeißer-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Herbert Vitzthum'" <[email-masked]>, [email-masked]
Subject: RE: Object Registration
Date: Fri, 5 Jan 2001 07:28:32 -0500 
Sender: [email-masked]

I think we've already covered changes to the draft to deal with expiration
date (or no expiration date), but I disagree completely that requirements
3.4-[4] - 3.4-[10] are policy focused.  I don't think we can get away from
requiring the protocol to support name server and contact provisioning,
though 3.4-[9] will be removed in the next revision.  The name server
requirements in particular exist because of DNS-driven considerations.  If
you disagree with some of the specific text that's in those requirements,
please suggest alternative wording.

</Scott>

>  -----Original Message-----
> From: 	Herbert Vitzthum [mailto:[email-masked]] 
> Sent:	Friday, January 05, 2001 7:17 AM
> To:	[email-masked]
> Subject:	Object Registration
> 
> Dear All,
> 
> in the draft 3.4 Object Registration:
> 
> [1] must also be endless as some ccTLDs have not an enddate in the
contract.
> 
> [4] to [10] This is policy and must no be considered in a technical
protocol. The rfc for smtp also does not consider the content of an email.
> 
> Best Regards
> 
> Herbert

Date: Fri, 05 Jan 2001 13:27:51 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: hello and some initial comments
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> Klaus,
> 
> Thanks for the comments.  If you believe they reflect something that you'd
> like to see changed in the requirements draft, would you please identify the
> section of the draft that you think needs to be changed and the change that
> you'd like to see made?
> 
> <Scott/>
> 

I got the impression that the discussion is still on a more abstract level than your requirements document or your EPP documents, so I didn't do that. But I can take a look at it once again.

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeißer-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Herbert Vitzthum" <[email-masked]>
To: <[email-masked]>
Subject: Object Registration
Date: Fri, 5 Jan 2001 13:17:15 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C07719.D29A28E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dear All,

in the draft 3.4 Object Registration:

[1] must also be endless as some ccTLDs have not an enddate in the contract.

[4] to [10] This is policy and must no be considered in a technical
protocol. The rfc for smtp also does not consider the content of an email.

Best Regards

Herbert

------=_NextPart_000_0000_01C07719.D29A28E0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0000_01C07719.D29A28E0--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: hello and some initial comments
Date: Fri, 5 Jan 2001 07:11:24 -0500 
Sender: [email-masked]

Klaus,

Thanks for the comments.  If you believe they reflect something that you'd
like to see changed in the requirements draft, would you please identify the
section of the draft that you think needs to be changed and the change that
you'd like to see made?

<Scott/>

-----Original Message-----
From: Klaus Malorny [mailto:[email-masked]]
Sent: Friday, January 05, 2001 3:47 AM
To: [email-masked]
Subject: hello and some initial comments

Hello,

first of all, I want to say hello and to introduce myself briefly. I am
working
as a software developer for Knipp Medien und Kommunikation GmbH, which is
(beside others) in the domain name registration business. Having the
imagination
of a simple but versatile domain registration protocol which is adopted by
most
domain registries around the world and which eases the registration
business, I
joined the list in the hope to contribute a little bit to reach this goal.

I saw that the discussion is already active for about two weeks;
unfortunately,
I had no time to read all postings in the archive. I promise that I will do
it,
but for now, I would like to make some general comments I prepared some days
ago, 
based on Scott Hollenbeck's drafts and my own thoughts. Please excuse if 
I mention topics which have already been addressed or are currently in
discussion.

Low Level Protocol Issues
-------------------------

I saw some discussions about the underlying communication protocol. I
support
the idea of using one of the existing/emerging protocols, like BXXP instead
of
re-inventing one.

High Level Protocol Issues
--------------------------

As I understand, the client/registrar and the server/registry interact by a
request/response model. In this context, I think it is very important to
have
some kind of server initiated interaction (even if done by a polling
mechanism).
In some cases, e.g. the transfer of domains between registrars, the
client/registrar needs to be informed asynchronously. In current
registration
systems, this is mostly done outside of the core protocol, e.g. by sending
e-mails. This should be integrated into the protocol, both for
simplification
and to benefit from other protocol features, like transaction management,
encryption.

Transaction Management
----------------------

The protocol must be able to deal with errornous states, like interruption
of
the communication between the two endpoints. So the protocol should
incorporate
a transaction management. It should be separated from the design of the
requests, in contrast to the way the problem was solved in the RRP: Here the
commands were designed in a way to allow the client to repeat any command
which
it thinks the server might not have executed. Eventually, this may limit the
possibilities of the commands. For example, the "renew" command had to be
extended beyond to its straight forward design to avoid an unwanted
extension of
the registration period in the case of a command repetition.

Internationalization/Localization
---------------------------------

Although the protocol must of course support internationalized data, e.g.
Unicode domain names or contact data, it is IMHO not required for the
protocol
to support multiple languages itself, e.g. to generate error messages in
different languages. It is more important to make them machine
understandable
;-), e.g. to list related information separately and identifiable. It is the
registrar's duty to generate a message suitable for human beings in whatever
language
out of it, if the registrar feels the need to (see also below)

Modularisation - Object Model
-----------------------------

To have a modular concept may be an advantage -- it may be useful for
registries
which require additional data or policies. If we introduce a concept of
abstract
objects, with different concrete object types varying from application to
application,

- we need an object model which describes what properties an object can have
and
how an object can interact with other objects

- the protocol must enable the client to get information about the existing
object types and the effect of operations on them (meta information)

- the protocol must not only enable the client to get the information about
a
single object, but also the relation of it to other objects.

To give two examples: a query of a domain object should not only report the
contacts and name servers used by the domain, but also dependencies which
are
hidden in current systems, e.g. name servers which lie in zone of the domain
or
domains which use a certain contact.

If a registrar attempts to transfer a (domain) object, it needs to know
whether
it also gets the name servers lying in the domain's zone and which they are.

Object Ownership
----------------

It must be defined how objects appear in a multi-registrar/-client
environment.
Are objects owned by one client visible to others, can they be used by
others?
What happens on ownership transfers, esp. with related objects? Are they
cloned?

Modularisation - Error Reporting
--------------------------------

In case of a modular concept, the error reporting mechanism must have some
kind
of flexibility, as operations on different object types may produce
different
errors. In general, I propose some kind of classification system, at least
in
the following classes

- protocol violations (e.g. bad commands, missing parameters)

- integrity violations (e.g. trying to delete a name server object which
still
in use by a domain object)

- policy violations (the command is technically correct, but violates a
registry
policy, e.g. modify a domain which is on-hold)

Renewal
-------

Models different to NSI/Verisign model should be supported, esp. shorter
periods
and auto-renewal.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Herbert Vitzthum" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: AW: Domain Name/Whois Data Element and Related Definitions
Date: Fri, 5 Jan 2001 12:13:39 +0100
Importance: Normal
Sender: [email-masked]

No isnt right. Some ar allowing (.co.at, .or.at .at) some ar not (.de) the
RRP should make both posibile

Best Regards

Herbert

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von [email-masked]
> Gesendet: Freitag, 05. Jänner 2001 12:02
> An: [email-masked]
> Betreff: Re: Domain Name/Whois Data Element and Related Definitions
>
>
> On 5 Jan 01, at 9:41, Patrik Fältström wrote:
>
> > At 17.59 -0500 01-01-04, Ross Wm. Rader wrote:
> > >    SLD: An "SLD" is a second-level domain of the DNS
> > >
> > >         SLD Holder: The individual or organization that registers a
> > >         specific domain name. This individual or organization
> holds the
> > >         right to use that specific domain name for a specified period
> > >         of time, provided certain conditions are met and the
> > >         registration fees are paid. This person or organization is the
> > >         "legal entity" bound by the terms of the relevant service
> > >         agreement
> > >
> > >         SLD Sponsor: The Registrar responsible for the submission of
> > >         the domain name to the Registry.
> >
> > Using the term SLD is difficult as sometimes what is registered is
> > not an second level domain, but instead a third level domain.
>
> Correct. Many (most?) ccTLD do not allow users to register SLD.
> Users register a third level domain, eg: domain-name.co.id or
> domain-name.net.id, and so on.
> How about just Domain Name Holder?
>
> Regards
> -- budi
> -- TLD-ID
> --
> Homepage: <http://budi.insan.co.id>
> my presentation materials, papers, scrapbook, ... and more
> What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: "Herbert Vitzthum" <[email-masked]>
To: "Marcel Schneider" <[email-masked]>, <[email-masked]>
Subject: AW: Definition of Registry 
Date: Fri, 5 Jan 2001 12:12:10 +0100
Importance: Normal
Sender: [email-masked]

Dear Marcel,

very clear view, thank you very much.

Herbert

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Marcel Schneider
> Gesendet: Freitag, 05. Janner 2001 11:38
> An: [email-masked]
> Betreff: Re: Definition of Registry
>
>
> On Friday, 5 Jan 2001, "Peter Mott" writes:
>
> I completely agree with Peter's analysis blow. But the
> important fact for this group is: there are two models
> for registries/registrars/agents. The 'lightweight'
> registry model (just DB and connectivity) is mostly
> used in gTLD's and will continue to be (one of the
> reasons is that it has not the registry as a bottelneck).
>
> The 'policy-setting' registry is more common in ccTLD's and
> will continue to be.
>
> The RRP needs to support both models. We should discuss
> the reasons why it couldn't.
>
>
> Marcel
>
>
>
>
> >> it's the practice for the .fr registry
> >> update of the database are requested by the registrant, through
> >> the registrar.
>
> > We have different views of the world.  Through my eyes I see domain name
> > registration  being the execution of a legal contract between
> the registrar
> > and the registrant.  The public record of that contract is the
> insertion of
> > the name into the registry database.
>
> > To determine the registrar, I simply ask the question "with
> whom does the
> > registrant have a contract for the domain name registration?"
> Whoever that
> > entity is - is always the registrar.
>
> > Not sure how .fr works, but I suspect the contract is in fact
> between the
> > registrant and your organisation.  The party you refer to as
> registrar is
> > probably acting as an agent for the registrant.  Your organisation is in
> > fact the registrar.
>
> > This may all seem to be splitting hairs, but its important
> stuff in my view.
> > Understanding relationships and roles is required before
> developing system
> > to support it, and protocol to enable system
>
> >> registrar is a provider of added value (services) for the user
> >> connectivity.
>
> > My definition of registrar is simply an entity accredited to enter into
> > domain name registration contracts with registrants.  This
> entity may have
> > domain name registration as a core or supporting business
> activity.  It is
> > not relevant.
>
> >> In France, registry is a monopoly model (public service, not
> >> registrar itself),
> >> registrars are in the competitive sector.
>
> > I think you will see from above that I dont agree with you.
> What you likely
> > have is a monopoly registrar (your organisation) with agents
> all offering
> > the same registration contract (your TLD policy combined with business
> > rules).
>
> > Such a model does not support competition in the business of domain name
> > registration.  Although I concede that agents can wrap your service in
> > different ways to differentiate themselves.  I suspect however the major
> > differentiation occurs between core service elements for the
> agent rather
> > than the service of name registration.
>
> > Please dont think I am a supporter of any particular model or have fixed
> > views.  I have been studying this stuff in depth since 1996, own an
> > accredited ICANN registrar (although not operational as yet)
> and admin for
> > .tk .aq as well as registry operator for .pn
>
> > What I have been trying to highlight is that it is the
> identification of the
> > players and their relationships that is important, not so much where the
> > data is.  If this wg proceeds with the relationship model in the draft,
> > thats ok with me.  I just wanted to make sure people had the
> opportunity of
> > considering alternatives.
>
> > Regards
>
> > Peter Mott
> > Chief Enthusiast
> > 2day.com
> > -/-
>
>

Date: Fri, 5 Jan 2001 12:07:33 +0100
To: Marcel Schneider <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Definition of Registry
Sender: [email-masked]

At 11.38 +0100 01-01-05, Marcel Schneider wrote:
>On Friday, 5 Jan 2001, "Peter Mott" writes:
>
>I completely agree with Peter's analysis blow. But the
>important fact for this group is: there are two models
>for registries/registrars/agents. The 'lightweight'
>registry model (just DB and connectivity) is mostly
>used in gTLD's and will continue to be (one of the
>reasons is that it has not the registry as a bottelneck).
>
>The 'policy-setting' registry is more common in ccTLD's and
>will continue to be.

Isn't it the case that we actually have two orthogonal things we talk about?

               | no-policy   |    policy   |
--------------+-------------+-------------+
thin registry |             |             |
--------------+-------------+-------------+
fat registry  |             |             |
--------------+-------------+-------------+

I.e. the question on thin or fat is just about where information of 
domain name holder is (at registry or registrar) while policy can 
still exist or not, regardless of this fact.

Yes, most domains _with_ policy are also fat registries, but that is 
a statistical fact, and not something built into the definitions.

Also, you can have a registry for non-TLD's aswell, aswell as for 
"other things than domains" as Karl said. If the consensus on this 
list were to do something for domains, and not too generic, even 
though it is good if it can be used for other things, I still think 
we should talk about a registry being the responsible registry for a 
domain, and not just TLD.

    paf

From: [email-masked]
To: <[email-masked]>
Date: Fri, 5 Jan 2001 18:02:05 +0700
Subject: Re: Domain Name/Whois Data Element and Related Definitions
Sender: [email-masked]

On 5 Jan 01, at 9:41, Patrik Fältström wrote:

> At 17.59 -0500 01-01-04, Ross Wm. Rader wrote:
> >    SLD: An "SLD" is a second-level domain of the DNS
> >
> >         SLD Holder: The individual or organization that registers a
> >         specific domain name. This individual or organization holds the
> >         right to use that specific domain name for a specified period
> >         of time, provided certain conditions are met and the
> >         registration fees are paid. This person or organization is the
> >         "legal entity" bound by the terms of the relevant service
> >         agreement
> >
> >         SLD Sponsor: The Registrar responsible for the submission of
> >         the domain name to the Registry.
> 
> Using the term SLD is difficult as sometimes what is registered is 
> not an second level domain, but instead a third level domain.

Correct. Many (most?) ccTLD do not allow users to register SLD.
Users register a third level domain, eg: domain-name.co.id or
domain-name.net.id, and so on.
How about just Domain Name Holder?

Regards
-- budi
-- TLD-ID
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

To: [email-masked]
Subject: Re: Definition of Registry 
Date: Fri, 05 Jan 2001 11:38:25 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Friday, 5 Jan 2001, "Peter Mott" writes:

I completely agree with Peter's analysis blow. But the
important fact for this group is: there are two models
for registries/registrars/agents. The 'lightweight'
registry model (just DB and connectivity) is mostly
used in gTLD's and will continue to be (one of the
reasons is that it has not the registry as a bottelneck).

The 'policy-setting' registry is more common in ccTLD's and
will continue to be.

The RRP needs to support both models. We should discuss
the reasons why it couldn't.

Marcel

>> it's the practice for the .fr registry
>> update of the database are requested by the registrant, through
>> the registrar.

> We have different views of the world.  Through my eyes I see domain name
> registration  being the execution of a legal contract between the registrar
> and the registrant.  The public record of that contract is the insertion of
> the name into the registry database.

> To determine the registrar, I simply ask the question "with whom does the
> registrant have a contract for the domain name registration?"  Whoever that
> entity is - is always the registrar.

> Not sure how .fr works, but I suspect the contract is in fact between the
> registrant and your organisation.  The party you refer to as registrar is
> probably acting as an agent for the registrant.  Your organisation is in
> fact the registrar.

> This may all seem to be splitting hairs, but its important stuff in my view.
> Understanding relationships and roles is required before developing system
> to support it, and protocol to enable system

>> registrar is a provider of added value (services) for the user
>> connectivity.

> My definition of registrar is simply an entity accredited to enter into
> domain name registration contracts with registrants.  This entity may have
> domain name registration as a core or supporting business activity.  It is
> not relevant.

>> In France, registry is a monopoly model (public service, not
>> registrar itself),
>> registrars are in the competitive sector.

> I think you will see from above that I dont agree with you.  What you likely
> have is a monopoly registrar (your organisation) with agents all offering
> the same registration contract (your TLD policy combined with business
> rules).

> Such a model does not support competition in the business of domain name
> registration.  Although I concede that agents can wrap your service in
> different ways to differentiate themselves.  I suspect however the major
> differentiation occurs between core service elements for the agent rather
> than the service of name registration.

> Please dont think I am a supporter of any particular model or have fixed
> views.  I have been studying this stuff in depth since 1996, own an
> accredited ICANN registrar (although not operational as yet) and admin for
> .tk .aq as well as registry operator for .pn

> What I have been trying to highlight is that it is the identification of the
> players and their relationships that is important, not so much where the
> data is.  If this wg proceeds with the relationship model in the draft,
> thats ok with me.  I just wanted to make sure people had the opportunity of
> considering alternatives.

> Regards

> Peter Mott
> Chief Enthusiast
> 2day.com
> -/-

From: "Peter Mott" <[email-masked]>
To: "Annie Renard" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Definition of Registry 
Date: Fri, 5 Jan 2001 23:15:10 +1300
Importance: Normal
Sender: [email-masked]

> it's the practice for the .fr registry
> update of the database are requested by the registrant, through
> the registrar.

We have different views of the world.  Through my eyes I see domain name
registration  being the execution of a legal contract between the registrar
and the registrant.  The public record of that contract is the insertion of
the name into the registry database.

To determine the registrar, I simply ask the question "with whom does the
registrant have a contract for the domain name registration?"  Whoever that
entity is - is always the registrar.

Not sure how .fr works, but I suspect the contract is in fact between the
registrant and your organisation.  The party you refer to as registrar is
probably acting as an agent for the registrant.  Your organisation is in
fact the registrar.

This may all seem to be splitting hairs, but its important stuff in my view.
Understanding relationships and roles is required before developing system
to support it, and protocol to enable system

> registrar is a provider of added value (services) for the user
> connectivity.

My definition of registrar is simply an entity accredited to enter into
domain name registration contracts with registrants.  This entity may have
domain name registration as a core or supporting business activity.  It is
not relevant.

> In France, registry is a monopoly model (public service, not
> registrar itself),
> registrars are in the competitive sector.

I think you will see from above that I dont agree with you.  What you likely
have is a monopoly registrar (your organisation) with agents all offering
the same registration contract (your TLD policy combined with business
rules).

Such a model does not support competition in the business of domain name
registration.  Although I concede that agents can wrap your service in
different ways to differentiate themselves.  I suspect however the major
differentiation occurs between core service elements for the agent rather
than the service of name registration.

Please dont think I am a supporter of any particular model or have fixed
views.  I have been studying this stuff in depth since 1996, own an
accredited ICANN registrar (although not operational as yet) and admin for
.tk .aq as well as registry operator for .pn

What I have been trying to highlight is that it is the identification of the
players and their relationships that is important, not so much where the
data is.  If this wg proceeds with the relationship model in the draft,
thats ok with me.  I just wanted to make sure people had the opportunity of
considering alternatives.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Herbert Vitzthum" <[email-masked]>
To: <[email-masked]>, "Ietf-Provreg@Cafax. Se" <[email-masked]>
Subject: AW: Domain Name/Whois Data Element and Related Definitions 
Date: Fri, 5 Jan 2001 10:48:52 +0100
Importance: Normal
Sender: [email-masked]

Dear Ross,

thank you very much for preparing this excellent document. I do not say that
I can agree with the content, but it is a very good starting point for a
long discussion. But maybe this discussion should take place in a separated
list - don't know, but seams to be a different level as the RRP.

We should ask for what reason we ask to get a Admin-C or a Tech-C, maybe in
some cases this is necessary because the domain holder is not in the
position to answer questions about his/her domain.

But in most cases to ask the admin-C about a domain it is like to ask a wall
also the tech-C. The really important information’s needed for a domain are
the Information about the Domain-Holder und about the Registrar.

The Billing Information only belongs to the registry and must not be public
available.

The first Question must be “what data is necessary for what reasons”?

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Ross Wm. Rader
> Gesendet: Donnerstag, 04. Jänner 2001 23:59
> An: Ietf-Provreg@Cafax. Se
> Betreff: Domain Name/Whois Data Element and Related Definitions
>
>
> All,
>
> As a result of the positive on and off-list responses generated
> by my offer
> posted yesterday, the following is my attempt at putting a stake in the
> ground surrounding the various definitions etc. that we will need to deal
> with through this, and other processes. I trust that the format etc., will
> be acceptable for the intended purposes. Keep in mind that in no way do I
> view this as the definitive or authoritative list of related definitions,
> but rather, as a starting point that will hopefully speed our efforts. If
> there is sufficient demand, I will continue to update this
> document based on
> the feedback of this group and other parties.
>
> -rwr
>
>
>
> Internet Draft                                                 R. Rader
> Document: draft-rader-dnwhois-defn-00.txt                   Tucows Inc.
> Category: Informational                                  November, 2000
>
>
>
>          Domain Name/Whois Data Element and Related Definitions
>
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC 2026 [1].
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts. Internet-Drafts are draft documents valid for a maximum of
>    six months and may be updated, replaced, or obsoleted by other
>    documents at any time. It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> 1. Abstract
>
>    Efforts are currently being undertaken to review the role of Whois
>    (as defined in RFC 954 [2]) and formalize registry/registrar
>    communications protocols in light of the current and evolving scope
>    and utility of DNS, domain name registries and related entities. In
>    order for this work to be truly effective and broadly applicable, it
>    is important that accepted definitions act as the foundation. This
>    document is an attempt to create a starting point for the requisite
>    dialogue that will ultimately foster the determination and
>    acceptance of these definitions.
>
>
> 2. Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC 2119 [3].
>
>
> 3. Definitions
>
>    Contact: Contacts are individuals or entities associated with domain
>    name records. Typically, third parties with specific inquiries or
>    concerns will use contact records to determine who should act upon
>    specific issues related to a domain name record. There are typically
>
> >                      Domain Name & Related Def'n        November, 2000
>
>    three of these contact types associated with a domain name record,
>    the Administrative contact, the Billing contact and the Technical
>    contact.
>
>         Administrative Contact: The administrative contact is an
>         individual, role or organization authorized to interact with
>         the registry or registrar on behalf of the SLD Holder. The
>         administrative contact should be able to answer non-technical
>         questions about the domain name's registration and the SLD
>         Holder. In all cases, the Administrative Contact is viewed as
>         the authoritative point of contact for the domain name, second
>         only to the Registrant.
>
>         Billing Contact: The billing contact is the individual, role or
>         organization designated to receive the invoice for domain name
>         registration and re-registration fees.
>
>         Technical Contact: The technical contact is the individual,
>         role or organization who is responsible for the technical
>         operations of the delegated zone. This contact likely maintains
>         the domain name server(s) for the domain. The technical contact
>         should be able to answer technical questions about the domain
>         name, the delegated zone and work with technically oriented
>         people in other zones to solve technical problems that affect
>         the domain name and/or zone.
>
>    Data Escrow:
>
>    NIC: Network Information Center.
>
>         InterNIC: The InterNIC, a registered service mark of the U.S.
>         Department of Commerce, is a concept for an integrated network
>         information center that was developed by several companies,
>         including Network Solutions, in cooperation with the U.S.
>         Government. Currently, the term InterNIC is being used in
>         conjunction with a neutral, stand alone web page (located at
>         http://www.internic.net) that has been established to provide
>         the public with information regarding Internet domain name
>         registration. The InterNIC was originally created by NSF to
>         provide specific Internet services; directory & database
>         services (by AT&T), registration services (by Network
>         Solutions) and information services (by General
>         Atomics/CERFnet). [4]
>
>         NIC Handle: A NIC Handle is an identifier in use by some
>         registrars and registries that is assigned to various records
>         in the domain name database. Globally, they do not have a
>         common format or application. Further, they are not globally
>         unique.
>
>    Registrant: See SLD Holder
>
>
>
> >                      Domain Name & Related Def'n        November, 2000
>
>    Registrar: A person or entity that contracts with SLD holders and a
>    registry, collecting registration data about the SLD holders and
>    submitting zone file information for entry in the registry database.
>
>    Registry: A Registry is the person(s) or entity(ies) responsible for
>    providing registry services. Registry services include customer
>    database administration, zone file publication, DNS operation,
>    marketing and policy determination in accordance with the general
>    principles outlined in RFC 1591 [5]. A Registry may outsource some,
>    all, or none of these services.
>
>    Registry Operator: Usually synonymous with the term Registry,
>    however a Registry Operator may also be an organization or
>    individual acting operating the Registry under an outsourced
>    technical services management contract.
>
>    SLD: An "SLD" is a second-level domain of the DNS
>
>         SLD Holder: The individual or organization that registers a
>         specific domain name. This individual or organization holds the
>         right to use that specific domain name for a specified period
>         of time, provided certain conditions are met and the
>         registration fees are paid. This person or organization is the
>         "legal entity" bound by the terms of the relevant service
>         agreement
>
>         SLD Sponsor: The Registrar responsible for the submission of
>         the domain name to the Registry.
>
>    Whois: a TCP transaction based query/response server, that providing
>    netwide directory service to network users. Originally defined in
>    RFC 954, the earlier implementations were centralized systems run
>    first by SRC-NIC and then later InterNIC/Network Solutions. The SRI-
>    NIC and InterNIC implementations are more formally referred to as
>    "NICNAME/Whois" services. Whois is not purely a domain name or IP
>    address directory service, but has been deployed for a wide variety
>    of uses, both public and private. Other variants of this service
>    include RWhois and the newer Verisign Referral LDAP Whois service.
>
>         Bulk Whois:
>
>         Command line Whois:
>
>         Referral Whois:
>
>         Registrar Whois:
>
>         Registry Whois:
>
>         Web based Whois:
>
>         Whois Record:
>
>
> >                      Domain Name & Related Def'n        November, 2000
>
> 4. Security Considerations
>
>    This memo provides definitions for administrative terms related to
>    DNS and does not raise or address security issues.
>
> 5. References
>
>    [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
>       BCP 9, RFC 2026, October 1996.
>
>    [2]  Harrenstein, Stahl & Feinler, "NICName/Whois", RFC 954, October
>       1985.
>
>    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", BCP 14, RFC 2119, March 1997
>
>    [4]  Kristula, D., "History of the Internet",
>       http://davesite.com/webstation/net-history.shtml, 1996.
>
>    [5]  Postel, J., "Domain Name System Structure and Delegation", RFC
>       1591, March, 1994.
>
>
> 6. Acknowledgments
>
>    This document is the result of input and motivation from a wide
>    variety of individuals and entities. Rick Wesson, Scott Allan and
>    Tim Jung provided the primary motivators with ICANN, IANA and
>    Network Solutions providing the history and context. Additionally,
>    the various terms and conditions, operating contracts and frequently
>    asked questions documents produced by various Registries and
>    Registrars were instrumental in the production of this document.
>    Where appropriate, these contributions will be specifically
>    acknowledged in the References portion of future iterations of this
>    draft.
>
> 7. Author's Address
>
>    Ross Wm. Rader
>    Tucows Inc.
>    96 Mowat Avenue
>    Toronto, Ontario
>    M9C 3M1
>    t. 416.538.5492
>    f. 416.531.2516
>    e. [email-masked]
>
>
>
>
>
>
>
>
> >                      Domain Name & Related Def'n        November, 2000
>
>
>
> Full Copyright Statement
>
>    "Copyright (C) The Internet Society 2001. All Rights Reserved. This
>    document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implmentation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
>
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >

From: Annie Renard <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Definition of Registry 
Date: Fri, 05 Jan 2001 10:37:22 +0100
Sender: [email-masked]

 In your previous mail you wrote:

	 On 5 Jan 01, at 10:05, Peter Mott wrote:
	 
	 > > Who is responsible for the content if the Registry is not? Will each
	 > > Registrar instead be responsible for his part of the database?
	 > >
	 > > What then if a customer moves from one Registrar to another?
	 > 
	 > Answer: The registry record is then maintained by the new registrar.
	 > 
	 > The role of database integrity belongs to the registry.
	 > The role of content management belongs to the registar.
	 
	 Hmm... I would think that the record belongs to the user
	 (the owner of the record, registered entity, registrant?). 
	 Let's do this one right(?).

I fully agree, only the registrant hold the record, not the registrar

	 She can delegate access to the registrar she chooses. 
	 Thus, when she changes registrar she can revoke delegation 
	 to the previous registrar and delegate access to the new registrar.
	 (Perhaps through some kind of ticket, certificate, or 
	 what have you. We can hash technical details latter on.)
	 This way, transfer access from one registrar to another
	 is clean.
	 Othwerwise, registrar who registered her record may deny
	 transfer to another (usually competing) registrar.
	 Then, the user/registred entity is stuck.
	 
	 But all of this means that access to the database must 
	 go through a registrar. ie. user cannot modify her own record.
	 Is this a good thing? Is this common practice?
	 I don't know.

it's the practice for the .fr registry
update of the database are requested by the registrant, through the registrar.
Then, only the registry can perform this update.

	 Or maybe in certain implementation, a user can be considered
	 a registrar?
	 Come to think of it, by adding the user in the equation
	 it is more complex :-(
	 
	 Inconsitencies (spell?) of the content is the responsibility
	 of the user (registered entity/registrant).
	 The registry is "responsible" for database integrity.

	 Although, we should define what is "responsible".
	 If I were (currnetly am) a registry, then I don't want
	 to get sued. But I do make sure that integrity is one
	 of the top priorities.
	 
right	 

	 So, what's the role a registrar? Beats me ;-)
	 Interface between registered entity (user) and registry?
	 
registrar is a provider of added value (services) for the user connectivity.
it's interface between the registrant and the registry only for the
domain names management.
In France, registry is a monopoly model (public service, not registrar itself),
registrars are in the competitive sector.

	 > In some applications, the two roles are administered by the same entity.
	 > Thats a monopoly model.  OK for a closed/restricted namespace like .mil but
	 > not useful for open gTLD's.
	 
	 Some ccTLDs operate like this. Ours (.ID) is an example.
	 Although, we plan to change it into an open model by the
	 end of 2002. I would think many will stay like this
	 for a longer period of time.

Best regards,

---
        Annie Renard    [[email-masked]]
        AFNIC/NIC France
	c/o INRIA domaine de Voluceau BP105, 78153 Le Chesnay CEDEX, France
	http://www.nic.fr/
	Personal Email: [email-masked]

Date: Fri, 5 Jan 2001 09:41:59 +0100
To: "Ross Wm. Rader" <[email-masked]>, "Ietf-Provreg@Cafax. Se" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Domain Name/Whois Data Element and Related Definitions
Sender: [email-masked]

At 17.59 -0500 01-01-04, Ross Wm. Rader wrote:
>    SLD: An "SLD" is a second-level domain of the DNS
>
>         SLD Holder: The individual or organization that registers a
>         specific domain name. This individual or organization holds the
>         right to use that specific domain name for a specified period
>         of time, provided certain conditions are met and the
>         registration fees are paid. This person or organization is the
>         "legal entity" bound by the terms of the relevant service
>         agreement
>
>         SLD Sponsor: The Registrar responsible for the submission of
>         the domain name to the Registry.

Using the term SLD is difficult as sometimes what is registered is 
not an second level domain, but instead a third level domain.

    paf

Date: Fri, 05 Jan 2001 09:47:23 +0100
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: hello and some initial comments
Sender: [email-masked]

Hello,

first of all, I want to say hello and to introduce myself briefly. I am working
as a software developer for Knipp Medien und Kommunikation GmbH, which is
(beside others) in the domain name registration business. Having the imagination
of a simple but versatile domain registration protocol which is adopted by most
domain registries around the world and which eases the registration business, I
joined the list in the hope to contribute a little bit to reach this goal.

I saw that the discussion is already active for about two weeks; unfortunately,
I had no time to read all postings in the archive. I promise that I will do it,
but for now, I would like to make some general comments I prepared some days ago, 
based on Scott Hollenbeck's drafts and my own thoughts. Please excuse if 
I mention topics which have already been addressed or are currently in discussion.

Low Level Protocol Issues
-------------------------

I saw some discussions about the underlying communication protocol. I support
the idea of using one of the existing/emerging protocols, like BXXP instead of
re-inventing one.

High Level Protocol Issues
--------------------------

As I understand, the client/registrar and the server/registry interact by a
request/response model. In this context, I think it is very important to have
some kind of server initiated interaction (even if done by a polling mechanism).
In some cases, e.g. the transfer of domains between registrars, the
client/registrar needs to be informed asynchronously. In current registration
systems, this is mostly done outside of the core protocol, e.g. by sending
e-mails. This should be integrated into the protocol, both for simplification
and to benefit from other protocol features, like transaction management,
encryption.

Transaction Management
----------------------

The protocol must be able to deal with errornous states, like interruption of
the communication between the two endpoints. So the protocol should incorporate
a transaction management. It should be separated from the design of the
requests, in contrast to the way the problem was solved in the RRP: Here the
commands were designed in a way to allow the client to repeat any command which
it thinks the server might not have executed. Eventually, this may limit the
possibilities of the commands. For example, the "renew" command had to be
extended beyond to its straight forward design to avoid an unwanted extension of
the registration period in the case of a command repetition.

Internationalization/Localization
---------------------------------

Although the protocol must of course support internationalized data, e.g.
Unicode domain names or contact data, it is IMHO not required for the protocol
to support multiple languages itself, e.g. to generate error messages in
different languages. It is more important to make them machine understandable
;-), e.g. to list related information separately and identifiable. It is the
registrar's duty to generate a message suitable for human beings in whatever language
out of it, if the registrar feels the need to (see also below)

Modularisation - Object Model
-----------------------------

To have a modular concept may be an advantage -- it may be useful for registries
which require additional data or policies. If we introduce a concept of abstract
objects, with different concrete object types varying from application to
application,

- we need an object model which describes what properties an object can have and
how an object can interact with other objects

- the protocol must enable the client to get information about the existing
object types and the effect of operations on them (meta information)

- the protocol must not only enable the client to get the information about a
single object, but also the relation of it to other objects.

To give two examples: a query of a domain object should not only report the
contacts and name servers used by the domain, but also dependencies which are
hidden in current systems, e.g. name servers which lie in zone of the domain or
domains which use a certain contact.

If a registrar attempts to transfer a (domain) object, it needs to know whether
it also gets the name servers lying in the domain's zone and which they are.

Object Ownership
----------------

It must be defined how objects appear in a multi-registrar/-client environment.
Are objects owned by one client visible to others, can they be used by others?
What happens on ownership transfers, esp. with related objects? Are they cloned?

Modularisation - Error Reporting
--------------------------------

In case of a modular concept, the error reporting mechanism must have some kind
of flexibility, as operations on different object types may produce different
errors. In general, I propose some kind of classification system, at least in
the following classes

- protocol violations (e.g. bad commands, missing parameters)

- integrity violations (e.g. trying to delete a name server object which still
in use by a domain object)

- policy violations (the command is technically correct, but violates a registry
policy, e.g. modify a domain which is on-hold)

Renewal
-------

Models different to NSI/Verisign model should be supported, esp. shorter periods
and auto-renewal.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Herbert Vitzthum" <[email-masked]>
To: "Peter Mott" <[email-masked]>, "Jaap Akkerhuis" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: AW: Definition of Registry 
Date: Fri, 5 Jan 2001 09:35:17 +0100
Importance: Normal
Sender: [email-masked]

Peter,

if the RRP is only for NSI or maybe some new gTLDs fine. If not understand
and accept ccTLD Voice and nearly common way of doeing.

Best Regards

Herbert

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Peter Mott
> Gesendet: Donnerstag, 04. Jänner 2001 22:15
> An: Jaap Akkerhuis; Hollenbeck, Scott
> Cc: [email-masked]; [email-masked]
> Betreff: RE: Definition of Registry
>
>
> >     OK, how about changing the definition from this:
> >
> >     "Registry: An entity that provides back-end domain name registration
> >     services to registrars, managing a central repository of
> > information
>
> Whats broke here is the notion that a registry provides a domain name
> registration service.  In a competitive model, the registry should only do
> these things:-
>
> *	Provide registrars with access to a shared database
> *	Publish zone files
>
> At no time does the registry register names.  Registration is a task
> completed by the registrar as part of executing a contract it has with the
> registrant.
>
> The registry should not have any interest in the business of domain name
> registration.  Just the business of ensuring accredited registrars can.
>
> My thinking is that the registry exists to complete the tasks
> which cant be
> shared due to the hierarchical nature of the system.  But those
> tasks alone.
>
> The moment you have the registry taking on other tasks, you introduce
> compexity and duplication of responsibility.
>
> Regards
>
> Peter Mott
> Chief Enthusiast
> 2day.com
> -/-

From: "Herbert Vitzthum" <[email-masked]>
To: "Peter Mott" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: AW: Definition of Registry
Date: Fri, 5 Jan 2001 09:33:32 +0100
Importance: Normal
Sender: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Peter Mott
> Gesendet: Donnerstag, 04. Jänner 2001 22:06
> An: [email-masked]; [email-masked]
> Betreff: RE: Definition of Registry
>
>
> > Who is responsible for the content if the Registry is not? Will each
> > Registrar instead be responsible for his part of the database?
> >
> > What then if a customer moves from one Registrar to another?
>
> Answer: The registry record is then maintained by the new registrar.
>
> The role of database integrity belongs to the registry.
> The role of content management belongs to the registar.

More in the gTLD World as in the ccTLD World

>
> In some applications, the two roles are administered by the same entity.
> Thats a monopoly model.  OK for a closed/restricted namespace
> like .mil but
> not useful for open gTLD's.
>
> A competitive registration model requires competing registrars to have
> access to a shared database operated by an independent registry operator.
> The entire reason for having a registrar is to have them maintain the
> content.  If some other entity (registry) wants to do this as
> well, then the
> registrar is redundant.

"competitive registration model" is very .com centric view, ccTLD may see
this different and for good reasons not use this model at all, but
supporting their kind of Registrarmodell

>
> The moment you have the registry operator taking the slightest interest in
> database content, the model is broken, complexity and costs go through the
> roof.  The present gTLD implementation is an example of what can go wrong
> :-)

As in the most ccTLDs will be a direct contract between Registry and
Registrant, the Registry has to take care of the correctness of the data.
Registrants are making millions of Euros profit by using their domains for
the business, e-commerce WEB Site. If the Registry is making a bad job the
registrant is able to simple sue the registry.

>
> Regards
>
> Peter Mott
> Chief Enthusiast
> 2day.com
> -/-
>
>
>

From: "Peter Mott" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Definition of Registry
Date: Fri, 5 Jan 2001 14:06:37 +1300
Importance: Normal
Sender: [email-masked]

> > Answer: The registry record is then maintained by the new registrar.
> >
> > The role of database integrity belongs to the registry.
> > The role of content management belongs to the registar.
>
> Hmm... I would think that the record belongs to the user
> (the owner of the record, registered entity, registrant?).
> Let's do this one right(?).

Perhaps I was not so clear.  I am talking about the entity with power to
change the data in the registry, not the entity that claims an intellectual
property right to the data.  Except when a registrar wants to register their
own domain names, I would always expect these entities to be different.

... but thats another mine field altogether!

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: [email-masked]
To: <[email-masked]>
Date: Fri, 5 Jan 2001 06:47:42 +0700
Subject: RE: Definition of Registry
Sender: [email-masked]

On 5 Jan 01, at 10:05, Peter Mott wrote:

> > Who is responsible for the content if the Registry is not? Will each
> > Registrar instead be responsible for his part of the database?
> >
> > What then if a customer moves from one Registrar to another?
> 
> Answer: The registry record is then maintained by the new registrar.
> 
> The role of database integrity belongs to the registry.
> The role of content management belongs to the registar.

Hmm... I would think that the record belongs to the user
(the owner of the record, registered entity, registrant?). 
Let's do this one right(?).

She can delegate access to the registrar she chooses. 
Thus, when she changes registrar she can revoke delegation 
to the previous registrar and delegate access to the new registrar.
(Perhaps through some kind of ticket, certificate, or 
what have you. We can hash technical details latter on.)
This way, transfer access from one registrar to another
is clean.
Othwerwise, registrar who registered her record may deny
transfer to another (usually competing) registrar.
Then, the user/registred entity is stuck.

But all of this means that access to the database must 
go through a registrar. ie. user cannot modify her own record.
Is this a good thing? Is this common practice?
I don't know.
Or maybe in certain implementation, a user can be considered
a registrar?
Come to think of it, by adding the user in the equation
it is more complex :-(

Inconsitencies (spell?) of the content is the responsibility
of the user (registered entity/registrant).
The registry is "responsible" for database integrity.
Although, we should define what is "responsible".
If I were (currnetly am) a registry, then I don't want
to get sued. But I do make sure that integrity is one
of the top priorities.

So, what's the role a registrar? Beats me ;-)
Interface between registered entity (user) and registry?

> In some applications, the two roles are administered by the same entity.
> Thats a monopoly model.  OK for a closed/restricted namespace like .mil but
> not useful for open gTLD's.

Some ccTLDs operate like this. Ours (.ID) is an example.
Although, we plan to change it into an open model by the
end of 2002. I would think many will stay like this
for a longer period of time.

Regards
-- budi
-- TLD-ID
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Ietf-Provreg@Cafax. Se" <[email-masked]>
Subject:  Domain Name/Whois Data Element and Related Definitions 
Date: Thu, 4 Jan 2001 17:59:19 -0500
Importance: Normal
Sender: [email-masked]

All,

As a result of the positive on and off-list responses generated by my offer
posted yesterday, the following is my attempt at putting a stake in the
ground surrounding the various definitions etc. that we will need to deal
with through this, and other processes. I trust that the format etc., will
be acceptable for the intended purposes. Keep in mind that in no way do I
view this as the definitive or authoritative list of related definitions,
but rather, as a starting point that will hopefully speed our efforts. If
there is sufficient demand, I will continue to update this document based on
the feedback of this group and other parties.

-rwr

Internet Draft                                                 R. Rader
Document: draft-rader-dnwhois-defn-00.txt                   Tucows Inc.
Category: Informational                                  November, 2000

         Domain Name/Whois Data Element and Related Definitions

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   Efforts are currently being undertaken to review the role of Whois
   (as defined in RFC 954 [2]) and formalize registry/registrar
   communications protocols in light of the current and evolving scope
   and utility of DNS, domain name registries and related entities. In
   order for this work to be truly effective and broadly applicable, it
   is important that accepted definitions act as the foundation. This
   document is an attempt to create a starting point for the requisite
   dialogue that will ultimately foster the determination and
   acceptance of these definitions.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

3. Definitions

   Contact: Contacts are individuals or entities associated with domain
   name records. Typically, third parties with specific inquiries or
   concerns will use contact records to determine who should act upon
   specific issues related to a domain name record. There are typically

                     Domain Name & Related Def'n        November, 2000

   three of these contact types associated with a domain name record,
   the Administrative contact, the Billing contact and the Technical
   contact.

        Administrative Contact: The administrative contact is an
        individual, role or organization authorized to interact with
        the registry or registrar on behalf of the SLD Holder. The
        administrative contact should be able to answer non-technical
        questions about the domain name's registration and the SLD
        Holder. In all cases, the Administrative Contact is viewed as
        the authoritative point of contact for the domain name, second
        only to the Registrant.

        Billing Contact: The billing contact is the individual, role or
        organization designated to receive the invoice for domain name
        registration and re-registration fees.

        Technical Contact: The technical contact is the individual,
        role or organization who is responsible for the technical
        operations of the delegated zone. This contact likely maintains
        the domain name server(s) for the domain. The technical contact
        should be able to answer technical questions about the domain
        name, the delegated zone and work with technically oriented
        people in other zones to solve technical problems that affect
        the domain name and/or zone.

   Data Escrow:

   NIC: Network Information Center.

        InterNIC: The InterNIC, a registered service mark of the U.S.
        Department of Commerce, is a concept for an integrated network
        information center that was developed by several companies,
        including Network Solutions, in cooperation with the U.S.
        Government. Currently, the term InterNIC is being used in
        conjunction with a neutral, stand alone web page (located at
        http://www.internic.net) that has been established to provide
        the public with information regarding Internet domain name
        registration. The InterNIC was originally created by NSF to
        provide specific Internet services; directory & database
        services (by AT&T), registration services (by Network
        Solutions) and information services (by General
        Atomics/CERFnet). [4]

        NIC Handle: A NIC Handle is an identifier in use by some
        registrars and registries that is assigned to various records
        in the domain name database. Globally, they do not have a
        common format or application. Further, they are not globally
        unique.

   Registrant: See SLD Holder

                     Domain Name & Related Def'n        November, 2000

   Registrar: A person or entity that contracts with SLD holders and a
   registry, collecting registration data about the SLD holders and
   submitting zone file information for entry in the registry database.

   Registry: A Registry is the person(s) or entity(ies) responsible for
   providing registry services. Registry services include customer
   database administration, zone file publication, DNS operation,
   marketing and policy determination in accordance with the general
   principles outlined in RFC 1591 [5]. A Registry may outsource some,
   all, or none of these services.

   Registry Operator: Usually synonymous with the term Registry,
   however a Registry Operator may also be an organization or
   individual acting operating the Registry under an outsourced
   technical services management contract.

   SLD: An "SLD" is a second-level domain of the DNS

        SLD Holder: The individual or organization that registers a
        specific domain name. This individual or organization holds the
        right to use that specific domain name for a specified period
        of time, provided certain conditions are met and the
        registration fees are paid. This person or organization is the
        "legal entity" bound by the terms of the relevant service
        agreement

        SLD Sponsor: The Registrar responsible for the submission of
        the domain name to the Registry.

   Whois: a TCP transaction based query/response server, that providing
   netwide directory service to network users. Originally defined in
   RFC 954, the earlier implementations were centralized systems run
   first by SRC-NIC and then later InterNIC/Network Solutions. The SRI-
   NIC and InterNIC implementations are more formally referred to as
   "NICNAME/Whois" services. Whois is not purely a domain name or IP
   address directory service, but has been deployed for a wide variety
   of uses, both public and private. Other variants of this service
   include RWhois and the newer Verisign Referral LDAP Whois service.

        Bulk Whois:

        Command line Whois:

        Referral Whois:

        Registrar Whois:

        Registry Whois:

        Web based Whois:

        Whois Record:

                     Domain Name & Related Def'n        November, 2000

4. Security Considerations

   This memo provides definitions for administrative terms related to
   DNS and does not raise or address security issues.

5. References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.

   [2]  Harrenstein, Stahl & Feinler, "NICName/Whois", RFC 954, October
      1985.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   [4]  Kristula, D., "History of the Internet",
      http://davesite.com/webstation/net-history.shtml, 1996.

   [5]  Postel, J., "Domain Name System Structure and Delegation", RFC
      1591, March, 1994.

6. Acknowledgments

   This document is the result of input and motivation from a wide
   variety of individuals and entities. Rick Wesson, Scott Allan and
   Tim Jung provided the primary motivators with ICANN, IANA and
   Network Solutions providing the history and context. Additionally,
   the various terms and conditions, operating contracts and frequently
   asked questions documents produced by various Registries and
   Registrars were instrumental in the production of this document.
   Where appropriate, these contributions will be specifically
   acknowledged in the References portion of future iterations of this
   draft.

7. Author's Address

   Ross Wm. Rader
   Tucows Inc.
   96 Mowat Avenue
   Toronto, Ontario
   M9C 3M1
   t. 416.538.5492
   f. 416.531.2516
   e. [email-masked]

                     Domain Name & Related Def'n        November, 2000

Full Copyright Statement

   "Copyright (C) The Internet Society 2001. All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



From: "Peter Mott" <[email-masked]>
To: "Mike Lampson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Definition of Registry
Date: Fri, 5 Jan 2001 11:14:05 +1300
Importance: Normal
Sender: [email-masked]

> (draft-hollenbeck-grrp-reqs-05.txt).  Everyone should review this document
> and look at the requirements related to both "thin" and "thick" registry
> models.

I was talking more about roles and relationships between players rather than
where the data is stored. It appears the author of the draft has reasonably
chosen the current gTLD relationship model as the basis for the protocol
design.

This may be a reasonable thing to do.  From a ccTLD perspective, I favour a
different approach.

> As for content management, I believe it should be beyond the scope of this
> working group to determine the validity of the data.  Policies
> made by each
> Registry are going to determine who checks the data and even how much
> checking is done.

This is clearly the case in the model being proposed.  If it were me, I
would not have the registry even thinking about such things!

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

Date: Thu, 04 Jan 2001 16:55:22 -0500
From: Mike Lampson <[email-masked]>
Subject: Re: Definition of Registry
To: [email-masked]
Cc: Peter Mott <[email-masked]>, [email-masked]
Sender: [email-masked]

I'm not sure that everyone on this Working Group list is aware that there
are 2 Registry models defined in the original gRRP spec
(draft-hollenbeck-grrp-reqs-05.txt).  Everyone should review this document
and look at the requirements related to both "thin" and "thick" registry
models.  I believe that the protocol we are developing in this group should
support both registry models.

As for content management, I believe it should be beyond the scope of this
working group to determine the validity of the data.  Policies made by each
Registry are going to determine who checks the data and even how much
checking is done.

Regards,

_Mike
--
Mike Lampson
The Registry at Info Avenue, LLC
 (Really just a Registrar, not a Registry)
(803) 802-6584

From: "Peter Mott" <[email-masked]>
To: "Jaap Akkerhuis" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Definition of Registry 
Date: Fri, 5 Jan 2001 10:15:28 +1300
Importance: Normal
Sender: [email-masked]

>     OK, how about changing the definition from this:
>
>     "Registry: An entity that provides back-end domain name registration
>     services to registrars, managing a central repository of
> information

Whats broke here is the notion that a registry provides a domain name
registration service.  In a competitive model, the registry should only do
these things:-

*	Provide registrars with access to a shared database
*	Publish zone files

At no time does the registry register names.  Registration is a task
completed by the registrar as part of executing a contract it has with the
registrant.

The registry should not have any interest in the business of domain name
registration.  Just the business of ensuring accredited registrars can.

My thinking is that the registry exists to complete the tasks which cant be
shared due to the hierarchical nature of the system.  But those tasks alone.

The moment you have the registry taking on other tasks, you introduce
compexity and duplication of responsibility.

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

From: "Peter Mott" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Definition of Registry
Date: Fri, 5 Jan 2001 10:05:57 +1300
Importance: Normal
Sender: [email-masked]

> Who is responsible for the content if the Registry is not? Will each
> Registrar instead be responsible for his part of the database?
>
> What then if a customer moves from one Registrar to another?

Answer: The registry record is then maintained by the new registrar.

The role of database integrity belongs to the registry.
The role of content management belongs to the registar.

In some applications, the two roles are administered by the same entity.
Thats a monopoly model.  OK for a closed/restricted namespace like .mil but
not useful for open gTLD's.

A competitive registration model requires competing registrars to have
access to a shared database operated by an independent registry operator.
The entire reason for having a registrar is to have them maintain the
content.  If some other entity (registry) wants to do this as well, then the
registrar is redundant.

The moment you have the registry operator taking the slightest interest in
database content, the model is broken, complexity and costs go through the
roof.  The present gTLD implementation is an example of what can go wrong
:-)

Regards

Peter Mott
Chief Enthusiast
2day.com
-/-

Reply-To: <[email-masked]>
From: "Alf Hansen" <[email-masked]>
To: <[email-masked]>
Subject: Re: Definition of Registry
Date: Thu, 4 Jan 2001 16:12:08 +0100
Importance: Normal
Sender: [email-masked]

Hi,

Who is responsible for the content if the Registry is not? Will each
Registrar instead be responsible for his part of the database?

What then if a customer moves from one Registrar to another?

Best regards,
Alf H
.NO

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marcos Sanz/Denic
> Sent: 4. januar 2001 15:24
> To: Jaap Akkerhuis
> Cc: [email-masked]
> Subject: Re: Re: Defenition of Registry
>
>
> On 04.01.01 14:19 Jaap Akkerhuis <[email-masked]> wrote:
> > I would leave it the way it was. This ``maintaining the intergrity
> > of repository content'' is way too strong. How can the registry be
> > resposible if the registrat is given wrong data? Are they still
> > resposible? This will give lawyers new business opportunities.
>
> Agree with Jaap. It depends upon what does here "integrity" mean.
> I can guarantee they satisfy "integrity" but you bet I will not make any
> assertion about its "veracity".
>
> Marcos Sanz (.de registry)

To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: Draft provreg charter (v01) 
Date: Thu, 04 Jan 2001 15:41:03 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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" sales and support services by
    registrars who interact with registrants and with the registry.

I would prefer not to use the word ``sale'', why not just:

    ..., versus "front-end" regsitry adn support services ...

As others have remarked, the milestones schedule is quite aggresive
and might need some adaptation as we go on.

	jaap

Subject: Re: Re: Defenition of Registry
To: Jaap Akkerhuis <[email-masked]>
Cc: [email-masked]
From: "Marcos Sanz/Denic" <[email-masked]>
Date: Thu, 4 Jan 2001 15:23:40 +0100
Sender: [email-masked]

On 04.01.01 14:19 Jaap Akkerhuis <[email-masked]> wrote:
> I would leave it the way it was. This ``maintaining the intergrity
> of repository content'' is way too strong. How can the registry be
> resposible if the registrat is given wrong data? Are they still
> resposible? This will give lawyers new business opportunities.

Agree with Jaap. It depends upon what does here "integrity" mean.
I can guarantee they satisfy "integrity" but you bet I will not make any
assertion about its "veracity".

Marcos Sanz (.de registry)

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Defenition of Registry 
Date: Thu, 04 Jan 2001 14:19:16 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    OK, how about changing the definition from this:
    
    "Registry: An entity that provides back-end domain name registration
    services to registrars, managing a central repository of information for a
    given TLD.  A registry is typically responsible for publication and
    distribution of TLD zone files used by the Domain Name System."
    
    to this:
    
    "Registry: An entity that provides back-end domain name registration
    services to registrars, managing a central repository of information for a
    given TLD.  A registry is responsible for maintaining the integrity of
    repository content.  A registry is also typically responsible for
    publication and distribution of TLD zone files used by the Domain Name
    System."

I would leave it the way it was. This ``maintaining the intergrity
of repository content'' is way too strong. How can the registry be
resposible if the registrat is given wrong data? Are they still
resposible? This will give lawyers new business opportunities.

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Defenition of Registry
Date: Thu, 4 Jan 2001 07:58:14 -0500 
Sender: [email-masked]

OK, how about changing the definition from this:

"Registry: An entity that provides back-end domain name registration
services to registrars, managing a central repository of information for a
given TLD.  A registry is typically responsible for publication and
distribution of TLD zone files used by the Domain Name System."

to this:

"Registry: An entity that provides back-end domain name registration
services to registrars, managing a central repository of information for a
given TLD.  A registry is responsible for maintaining the integrity of
repository content.  A registry is also typically responsible for
publication and distribution of TLD zone files used by the Domain Name
System."

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Alf Hansen [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 4:22 PM
To: Hollenbeck, Scott; [email-masked]
Subject: RE: Defenition of Registry

Scott,

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: 3. januar 2001 15:59
> To: [email-masked]'; [email-masked]
> Subject: RE: Defenition of Registry
>
>
> Alf,
>
> Could you clarify what you mean by "/responsible/ for the content in the
> repository"?  I agree that a registry should be responsible for database
> integrity etc., but are you suggesting that a registry should be
> responsible
> for maintaining (creates, updates, deletes, etc.) registrar-provided data
> without direct authorization from a registrar (or acting as a registrar
> itself) as well?

No. The registry should be responsible for the content. The registrars will
collect the data based on an agreement (contract) with the registry, and the
registry should provide the registrars with the tools needed to maintain the
database i a secure way: Proper authentication of the registrars, limitation
of consequences after registrar-misbehaviour, logs enabling investigation of
incidents, etc.

There will be a variety of "naming policies" for different TLDs. The
protocol must allow such flexibility in naming policies. The registry is
responsible for the content, and must therefore make sure that the
registrars also follow the rules (the actual naming policy) when they
maintain the database (on behalf of the registry). The protocol must be a
technical tool both for the registrars and the registry, assisting them to
provide cost effective, high quality registration services to the
registrants (customers).

The protocol is not policy, but a technical tool.

To: [email-masked]
Subject: Re: Defenition of Registry 
Date: Thu, 04 Jan 2001 10:42:11 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Wednesday, 3 Jan 2001, "Alf Hansen" writes:

>> Could you clarify what you mean by "/responsible/ for the content in the
>> repository"?  I agree that a registry should be responsible for database
>> integrity etc., but are you suggesting that a registry should be
>> responsible
>> for maintaining (creates, updates, deletes, etc.) registrar-provided data
>> without direct authorization from a registrar (or acting as a registrar
>> itself) as well?

> No. The registry should be responsible for the content.

But there is no need for that. The responsiblity for the 
content can be waived by the registry and put upon the
registrars. There are different 'schools' of thinking
in this respect.

But an efficient registry cannot be responsible for content, 
simply because it will not be able to handle large workloads
and there are other reasons:

* it will be required to run cheap, because registrars want
  low prices and/or high margins
* duplication of policy checking should be avoided
* any policy checking can be performed by the front
  end, speak regisrars/agents (they may need some
  software for that) and this will result in better
  performance (*) and smoother handling (what happens if
  the registry does not allow an application ? How
  much time will the agent have to wait ? What does he
  say to the applicant ? What happens to invoices ?

(*) If registrars perform according to the contract with
the registry !

> The registrars will
> collect the data based on an agreement (contract) with the registry, and the
> registry should provide the registrars with the tools needed to maintain the
> database i a secure way: Proper authentication of the registrars, limitation
> of consequences after registrar-misbehaviour, logs enabling investigation of
> incidents, etc.

> There will be a variety of "naming policies" for different TLDs. The
> protocol must allow such flexibility in naming policies. The registry is
> responsible for the content, and must therefore make sure that the
> registrars also follow the rules (the actual naming policy) when they
> maintain the database (on behalf of the registry). The protocol must be a
> technical tool both for the registrars and the registry, assisting them to
> provide cost effective, high quality registration services to the
> registrants (customers).

> The protocol is not policy, but a technical tool.

I think you already are in line with what I try to outline
above ...

Marcel

Date: Wed, 03 Jan 2001 17:39:53 -0500
To: <[email-masked]>, <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: Definition of Registry
Sender: [email-masked]

At 04:48 PM 1/3/2001 -0500, Ross Wm. Rader wrote:
>RickW and I had a conversation about the role of definitions in this process
>and other domain name related efforts in San Diego last month. We both
>agreed that a common base of definitions will play an important role in
>ensuring that whatever work this group and others accomplish is done in the
>most efficient manner. As such, I took it upon myself to pen a draft (which
>may or may not conform to IETF draft submission standards ;) that was
>intended to act as a strawman towards defining a common set of definitions.
>
>If it would be useful, I could clean it up and pass it back to this list in
>short order. I do have a concern that this might be distracting to the
>larger goal of this particular group. Perhaps if the definitions are
>valuable yet the process of definition distractive, a separate effort on a
>separate list geared towards hashing them out might be more efficient.
>
>-rwr

Please do I think this would be most helpful... just post it as text here...

Date: Wed, 3 Jan 2001 20:24:11 -0500
To: Karl Auerbach <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: belated response to Re: Comments on overall direction
Cc: <[email-masked]>
Sender: [email-masked]

At 3:29 PM -0500 12/26/00, Karl Auerbach wrote:
>1. A nit: I'd like to get rid of this horrid "registrar", "registry",
>"registrant" terminology.

I think that changing this would be hard.  I haven't heard any other
comments on this, my observation is that the consensus would be to let the
terminology stand.

>3. I am very wary of continuing the current notion of agent-to-agent
>transfers.  To my mind any transfer should be accomplished via the
>customer, i.e. that some signed certificate must be handed by the
>relinquishing agent to the customer for the customer to hand over to the
>acquiring agent.

My concern would be an unresponsive relinquishing agent, perhaps a
registrar who has gone out of business, lost the ability to apply a trusted
digital signature, etc.  It seems reasonable that an organization might
have a domain registered for 2 years and not change it, only to find at
renewal time that the registrar who did the work as moved on.  The fact
that a registrar does not have (to have) face-to-face contact with the
customer makes it more likely that some "weaker" registrars may fade.  (The
analogy with the OS and capabilities - if I interpret it correctly doesn't
seem to hold - a process would die when the OS dies.)

>4. I'm nervous about the inclusion of fancy negotion protocols - such as

I am too, but on the other hand, I've had experience with protocols that
did no negotiation with too little feedback.  There was an event scheduling
protocol that wouldn't allow events that overlapped, not even by a second.
If a rejected request would have satisfied if delayed by just 1 second, you
wouldn't know.  (This was not an internet protocol.)

Just a comment...

>5. The issue of privacy and security seems to be being glossed over - we
>are talking about databases that will be among the worlds larger bodies of
>personally identifiable information - with both strong privacy
>characteristics and high value to marketing/sales folks.

While at this time I can neither dispute nor support the claim of a
"glossing over" of privacy and security, those issues will be something I
plan to watch.  In this working group we are confining ourselves to the
protocol, so the questions I will be looking to see answered are "can the
protocol support (appropriate) privacy and security?" and "will the
protocol hinder privacy and security?"

Of course, this is in addition to the regular questions such as "will the
protocol work?", etc.

I thought I might add that "confining ourselves to the protocol" does not
mean that documents will ignore other aspects (such as definitions of
terminology).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>
Subject: RE: Definition of Registry
Date: Wed, 3 Jan 2001 16:48:46 -0500
Importance: Normal
Sender: [email-masked]

RickW and I had a conversation about the role of definitions in this process
and other domain name related efforts in San Diego last month. We both
agreed that a common base of definitions will play an important role in
ensuring that whatever work this group and others accomplish is done in the
most efficient manner. As such, I took it upon myself to pen a draft (which
may or may not conform to IETF draft submission standards ;) that was
intended to act as a strawman towards defining a common set of definitions.

If it would be useful, I could clean it up and pass it back to this list in
short order. I do have a concern that this might be distracting to the
larger goal of this particular group. Perhaps if the definitions are
valuable yet the process of definition distractive, a separate effort on a
separate list geared towards hashing them out might be more efficient.

-rwr

<  -----Original Message-----
<  From: [email-masked] [mailto:[email-masked]]On
<  Behalf Of Alf Hansen
<  Sent: Wednesday, January 03, 2001 4:22 PM
<  To: Hollenbeck, Scott; [email-masked]
<  Subject: RE: Defenition of Registry
<
<
<  Scott,
<
<  > -----Original Message-----
<  > From: Hollenbeck, Scott [mailto:[email-masked]]
<  > Sent: 3. januar 2001 15:59
<  > To: [email-masked]'; [email-masked]
<  > Subject: RE: Defenition of Registry
<  >
<  >
<  > Alf,
<  >
<  > Could you clarify what you mean by "/responsible/ for the
<  content in the
<  > repository"?  I agree that a registry should be responsible
<  for database
<  > integrity etc., but are you suggesting that a registry should be
<  > responsible
<  > for maintaining (creates, updates, deletes, etc.)
<  registrar-provided data
<  > without direct authorization from a registrar (or acting as a registrar
<  > itself) as well?
<
<  No. The registry should be responsible for the content. The
<  registrars will
<  collect the data based on an agreement (contract) with the
<  registry, and the
<  registry should provide the registrars with the tools needed to
<  maintain the
<  database i a secure way: Proper authentication of the
<  registrars, limitation
<  of consequences after registrar-misbehaviour, logs enabling
<  investigation of
<  incidents, etc.
<
<  There will be a variety of "naming policies" for different TLDs. The
<  protocol must allow such flexibility in naming policies. The registry is
<  responsible for the content, and must therefore make sure that the
<  registrars also follow the rules (the actual naming policy) when they
<  maintain the database (on behalf of the registry). The protocol must be a
<  technical tool both for the registrars and the registry,
<  assisting them to
<  provide cost effective, high quality registration services to the
<  registrants (customers).
<
<  The protocol is not policy, but a technical tool.
<
<  >
<  > Scott Hollenbeck
<  > VeriSign Global Registry Services
<  >
<
<  Best regards,
<  Alf H
<  .NO
<

Reply-To: <[email-masked]>
From: "Alf Hansen" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: RE: Defenition of Registry
Date: Wed, 3 Jan 2001 22:21:35 +0100
Importance: Normal
Sender: [email-masked]

Scott,

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: 3. januar 2001 15:59
> To: [email-masked]'; [email-masked]
> Subject: RE: Defenition of Registry
>
>
> Alf,
>
> Could you clarify what you mean by "/responsible/ for the content in the
> repository"?  I agree that a registry should be responsible for database
> integrity etc., but are you suggesting that a registry should be
> responsible
> for maintaining (creates, updates, deletes, etc.) registrar-provided data
> without direct authorization from a registrar (or acting as a registrar
> itself) as well?

No. The registry should be responsible for the content. The registrars will
collect the data based on an agreement (contract) with the registry, and the
registry should provide the registrars with the tools needed to maintain the
database i a secure way: Proper authentication of the registrars, limitation
of consequences after registrar-misbehaviour, logs enabling investigation of
incidents, etc.

There will be a variety of "naming policies" for different TLDs. The
protocol must allow such flexibility in naming policies. The registry is
responsible for the content, and must therefore make sure that the
registrars also follow the rules (the actual naming policy) when they
maintain the database (on behalf of the registry). The protocol must be a
technical tool both for the registrars and the registry, assisting them to
provide cost effective, high quality registration services to the
registrants (customers).

The protocol is not policy, but a technical tool.

>
> Scott Hollenbeck
> VeriSign Global Registry Services
>

Best regards,
Alf H
.NO

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Karl Auerbach'" <[email-masked]>
Cc: Edward Lewis <[email-masked]>, [email-masked]
Subject: RE: provreg mailing list LAST CALL: charter
Date: Wed, 3 Jan 2001 15:41:12 -0500 
Sender: [email-masked]

OK, in that case I think we have it covered because support for IPv6 name
server addressing is covered in sections 1.1 and 3.4 of the requirements
draft.  The next version of the draft will modify section 3.4 a tad to
explicitly mention both IPv4 and IPv6 instead of depending on the definition
of "IP Address" from section 1.1.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Karl Auerbach [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 3:10 PM
To: Hollenbeck, Scott
Cc: Edward Lewis; [email-masked]
Subject: RE: provreg mailing list LAST CALL: charter

> Would adding an explicit reference in the charter to the requirements
> document (which includes requirements for supporting both IPv4 and IPv6)
as
> Ed suggested cover your concern?

It really doesn't matter to me where it goes as long as we remember to
make sure we can handle customer/client/registrants who happen to want to
have some IPv6 based name servers for their domain name.

		--karl--

Date: Wed, 3 Jan 2001 12:10:20 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>
Subject: RE: provreg mailing list LAST CALL: charter
Sender: [email-masked]

> Would adding an explicit reference in the charter to the requirements
> document (which includes requirements for supporting both IPv4 and IPv6) as
> Ed suggested cover your concern?

It really doesn't matter to me where it goes as long as we remember to
make sure we can handle customer/client/registrants who happen to want to
have some IPv6 based name servers for their domain name.

		--karl--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Karl Auerbach'" <[email-masked]>, Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: RE: provreg mailing list LAST CALL: charter
Date: Wed, 3 Jan 2001 13:40:59 -0500 
Sender: [email-masked]

Karl,

Would adding an explicit reference in the charter to the requirements
document (which includes requirements for supporting both IPv4 and IPv6) as
Ed suggested cover your concern?

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Karl Auerbach [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 1:29 PM
To: Edward Lewis
Cc: [email-masked]
Subject: Re: provreg mailing list LAST CALL: charter

> I am issuing a last call for comments on the charter, which Dave Crocker
> most recently submitted on Tue, 02 Jan 2001 09:31:03 -0800.  The last call
> expires at 9am (-0500) Tueday, January 9.

Should the charter mention IPv6, in particular the need to carry IPv6
addresses in addition to IPv4 ones as name server data in the protocol
payloads?

		--karl--

Date: Wed, 3 Jan 2001 10:29:16 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>
Subject: Re: provreg mailing list LAST CALL: charter
Sender: [email-masked]

> I am issuing a last call for comments on the charter, which Dave Crocker
> most recently submitted on Tue, 02 Jan 2001 09:31:03 -0800.  The last call
> expires at 9am (-0500) Tueday, January 9.

Should the charter mention IPv6, in particular the need to carry IPv6
addresses in addition to IPv4 ones as name server data in the protocol
payloads?

		--karl--

Date: Tue, 02 Jan 2001 12:46:29 -0500
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: RE: One additional requirement...
Sender: [email-masked]

At 08:44 AM 1/2/2001 -0500, Hollenbeck, Scott wrote:
>Section 6.1 of the requirements draft addresses standards compliance.  How
>about if I change 6.1-[1] from this:
>
>"[1] A generic registry-registrar protocol MUST conform to current IETF
>standards.  Standards for domain and host name syntax, IP address syntax,
>and security are particularly relevant.  Emerging standards for the Domain
>Name System MUST be considered as they approach maturity."
>
>to this:
>
>"[1] A generic registry-registrar protocol MUST conform to current IETF
>standards.  Standards for domain and host name syntax, IP address syntax,
>security, and transport are particularly relevant.  Emerging standards for
>the Domain Name System MUST be considered as they approach maturity."
>
>Scott Hollenbeck
>VeriSign Global Registry Services

Thats fine .... we dont need to flog the the issue.

>-----Original Message-----
>From: Richard Shockey [mailto:[email-masked]]
>Sent: Friday, December 22, 2000 1:02 PM
>To: [email-masked]
>Subject: One additional requirement...
>
>
>
>IMHO we should be explicit in our requirements document that we invent no
>new transport protocols.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Marshall T. Rose" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Cc: "Marshall Rose" <[email-masked]>
Subject: Re: State of Provreg
Date: Tue, 2 Jan 2001 07:52:19 -0800
Sender: [email-masked]

> I'm curious about the need for a co-chair
> ...

i agree. chairs aren't supposed to be advocates...they're supposed to
facilitate process.

/mtr

Date: Tue, 02 Jan 2001 11:24:37 -0500
From: Jordan Glogau <[email-masked]>
To: [email-masked]
Subject: SUBSCRIBE
Sender: [email-masked]

SUBSCRIBE

From: "Marshall T. Rose" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Cc: "Marshall Rose" <[email-masked]>
Subject: Re: State of Provreg
Date: Tue, 2 Jan 2001 07:52:19 -0800
Sender: [email-masked]

> I'm curious about the need for a co-chair
> ...

i agree. chairs aren't supposed to be advocates...they're supposed to
facilitate process.

/mtr

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Defenition of Registry
Date: Wed, 3 Jan 2001 09:58:46 -0500 
Sender: [email-masked]

Alf,

Could you clarify what you mean by "/responsible/ for the content in the
repository"?  I agree that a registry should be responsible for database
integrity etc., but are you suggesting that a registry should be responsible
for maintaining (creates, updates, deletes, etc.) registrar-provided data
without direct authorization from a registrar (or acting as a registrar
itself) as well?

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Alf Hansen [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 8:04 AM
To: [email-masked]
Subject: Defenition of Registry

Hi all,

I just joined the list, and I saw from

  http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-05.txt :

  "Registry: An entity that provides back-end domain name registration
  services to registrars, managing a central repository of information
  for a given TLD.  A registry is typically responsible for publication
  and distribution of TLD zone files used by the Domain Name System."

Perhaps this is obvious, but I think it should be added somewhere that the
Registry is also /responsible/ for the content in the repository. This means
that the protocol we will be developing must allow the Registry to manage
and be responsible for the content, even if a large number of Registrars
simultainously are allowed to access and update the database.

It is a challange, but it is possible.

Best regards,
Alf H
.NO

Date: Wed, 3 Jan 2001 09:24:31 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: provreg mailing list LAST CALL: charter
Cc: [email-masked]
Sender: [email-masked]

I am issuing a last call for comments on the charter, which Dave Crocker
most recently submitted on Tue, 02 Jan 2001 09:31:03 -0800.  The last call
expires at 9am (-0500) Tueday, January 9.

To start the last call, I am submitting the following comments:

> As there is a need to speed the definition of the protocol, I would like
>to have Jaap Akkerhuis named as a second chair.  I have a tendency to be
>on travel, which sometimes disrupts my schedule (but not for lengthy
>times).

> I would like to have a reference to the requirements draft (grrp-05)
>along with the reference to the epp-00 draft.  (As in: "The working group
>will use as input...")

> I would prefer that it be made explicitly known that we will be focusing
>the early efforts emphasizing the management of domain name information
>first while maintaining extensibility and other provisioning information
>(addresses, contacts) after the first round.

Comments on David's draft charter and these comments are welcome.  The
resulting charter (based on consensus) will submitted to the IETF next week.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Requirements for object existence queries
Date: Wed, 3 Jan 2001 09:09:59 -0500 
Sender: [email-masked]

I tend to agree with budi, though I contend that the positive response (the
object exists) points to additional information being available.  I believe
it preferable to completely separate the existence query from the "give me
attribute info about the object" query.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 8:08 AM
To: [email-masked]
Subject: Re: Requirements for object existence queries

Dan Cohen wrote:

> In section 3.9 [4] of the requirements draft,  it says:
> 
> A query to determine if an object exists in the registry MUST return only
a 
> positive or negative response so that server software
> that responds to this query can be optimized for speed.

Pardon my ignorance (just joined a few days ago
and still in ROM mode), but where can I get the
complete draft?

> In think that MUST should change to MAY.  If a registry can implement a 
> highly optimized query that returns more information (maybe the
> registrar who "owns" the object), so much the better.  That information 
> would probably be quite helpful to registrars.

Can't we put this under a postive response?
Perhaps with a code (eg. ala FTP) that says more information
is available. Then, it is up to the client to get this additional
information. Perhaps it just wants to know whether such
object exists or not.

[snip]

Reply-To: <[email-masked]>
From: "Alf Hansen" <[email-masked]>
To: <[email-masked]>
Subject: Defenition of Registry
Date: Wed, 3 Jan 2001 14:04:20 +0100
Importance: Normal
Sender: [email-masked]

Hi all,

I just joined the list, and I saw from

  http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-05.txt :

  "Registry: An entity that provides back-end domain name registration
  services to registrars, managing a central repository of information
  for a given TLD.  A registry is typically responsible for publication
  and distribution of TLD zone files used by the Domain Name System."

Perhaps this is obvious, but I think it should be added somewhere that the
Registry is also /responsible/ for the content in the repository. This means
that the protocol we will be developing must allow the Registry to manage
and be responsible for the content, even if a large number of Registrars
simultainously are allowed to access and update the database.

It is a challange, but it is possible.

Best regards,
Alf H
.NO

From: [email-masked]
To: [email-masked]
Date: Wed, 3 Jan 2001 20:08:21 +0700
Subject: Re: Requirements for object existence queries
Sender: [email-masked]

Dan Cohen wrote:

> In section 3.9 [4] of the requirements draft,  it says:
> 
> A query to determine if an object exists in the registry MUST return only a 
> positive or negative response so that server software
> that responds to this query can be optimized for speed.

Pardon my ignorance (just joined a few days ago
and still in ROM mode), but where can I get the
complete draft?

> In think that MUST should change to MAY.  If a registry can implement a 
> highly optimized query that returns more information (maybe the
> registrar who "owns" the object), so much the better.  That information 
> would probably be quite helpful to registrars.

Can't we put this under a postive response?
Perhaps with a code (eg. ala FTP) that says more information
is available. Then, it is up to the client to get this additional
information. Perhaps it just wants to know whether such
object exists or not.
(Since I have not read the requirements draft,
I don't know how the state diagram of the protocol looks like.)

> And while we are on the topic of optimizing for speed, have people 
> considered that an XML based protocol might not be the ideal choice for this?
> XML based protocols are almost universally more verbose than non-XML 
> alternatives, and while the CPU overhead for parsing the XML may be
> negligible, when you consider added CPU time for encryption, plus extra 
> network bandwidth, you wind up which a much less performance
> friendly protocol.

I, too, am not too keen on XML-based protocols :-)

Regards
-- budi
-- .ID admin
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Martin Oldfield'" <[email-masked]>, [email-masked]
Subject: RE: Where is the requirements draft ?
Date: Wed, 3 Jan 2001 06:50:45 -0500 
Sender: [email-masked]

http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-05.txt

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Martin Oldfield [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 4:55 AM
To: [email-masked]
Subject: Where is the requirements draft ?

Sorry if this is obvious to the congoscenti, but where can I find a
copy of the requirements draft ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Wed,  3 Jan 2001 09:55:17 +0000 (GMT)
To: [email-masked]
Subject: Where is the requirements draft ?
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

Sorry if this is obvious to the congoscenti, but where can I find a
copy of the requirements draft ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Tue, 02 Jan 2001 17:16:00 -0500
To: [email-masked]
From: Dan Cohen <[email-masked]>
Subject: Requirements for object existence queries
Sender: [email-masked]

In section 3.9 [4] of the requirements draft,  it says:

A query to determine if an object exists in the registry MUST return only a 
positive or negative response so that server software
that responds to this query can be optimized for speed.

In think that MUST should change to MAY.  If a registry can implement a 
highly optimized query that returns more information (maybe the
registrar who "owns" the object), so much the better.  That information 
would probably be quite helpful to registrars.

And while we are on the topic of optimizing for speed, have people 
considered that an XML based protocol might not be the ideal choice for this?
XML based protocols are almost universally more verbose than non-XML 
alternatives, and while the CPU overhead for parsing the XML may be
negligible, when you consider added CPU time for encryption, plus extra 
network bandwidth, you wind up which a much less performance
friendly protocol.

My humble 2 cents.

Dan

Dan Cohen
Manager of Software Engineering
Register.Com, Inc.
212-798-9260

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Dave Crocker'" <[email-masked]>, [email-masked]
Subject: RE: Draft provreg charter (v01)
Date: Tue, 2 Jan 2001 15:58:53 -0500 
Sender: [email-masked]

We have mailing list and archive information, described below.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 12:31 PM
To: [email-masked]
Subject: Draft provreg charter (v01)

[snip]

MAILING LISTS:
General Discussion: [email-masked]
To Subscribe: [email-masked]
  In Body: subscribe ietf-provreg
Archive: http://www.cafax.se/ietf-provreg/maillist/

[snip]

To: [email-masked]
Subject: Re: Draft provreg charter (v01) 
Date: Tue, 02 Jan 2001 19:10:35 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Tuesday, 2 Jan 2001, Dave Crocker writes:

> Provisioning Registry Protocol (ProvReg)
...
> 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" sales and support services by
 
> registrars who interact with registrants and with the registry.

Would suggest to omit the word sale -
* a name could then be seen as a property (some doubt it is)
* some registries do not charge
* some registries charge maintenance fees
* we should not imply that registrars need to sell names
- and replace it by something like 'customer suport services'.

>  Especially 
> for various Top-Level Domains, the desire is to permit multiple registrars 
> to share access to the database.  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 the data base service
 
> running a domain name service registry repository.

'the data base service running a domain name service registry repository'
??? Could someone tell a simple mind like me what that means ;-)?

The expressions thin and thick sould probably be explained
if they will stay. Thick: 'full data base services provided
by registry' or something similar.

Marcel

cc: [email-masked]
Subject: Re: Draft provreg charter (v01) 
Date: Tue, 02 Jan 2001 19:08:43 +0100
From: Marcel Schneider <[email-masked]>
Sender: [email-masked]

On Tuesday, 2 Jan 2001, Dave Crocker writes:

> Provisioning Registry Protocol (ProvReg)
...
> 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" sales and support services by 
> registrars who interact with registrants and with the registry.

Would suggest to omit the word sale -
* a name could then be seen as a property (some doubt it is)
* some registries do not charge
* some registries charge maintenance fees
* we should not imply that registrars need to sell names
- and replace it by something like 'customer suport services'.

>  Especially 
> for various Top-Level Domains, the desire is to permit multiple registrars 
> to share access to the database.  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 the data base service 
> running a domain name service registry repository.

'the data base service running a domain name service registry repository'
??? Could someone tell a simple mind like me what that means ;-)?

The expressions thin and thick sould probably be explained
if they will stay. Thick: 'full data base services provided
by registry' or something similar.

Marcel

Date: Tue, 02 Jan 2001 09:31:03 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Draft provreg charter (v01)
Sender: [email-masked]

Provisioning Registry Protocol (ProvReg)

-------------------------------

  CHAIR(S):
Edward Lewis <[email-masked]>

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström <[email-masked]>
Ned Freed <[email-masked]>

  AREA ADVISOR:
         Patrik Fältström

  MAILING LISTS:
General Discussion:
To Subscribe:
    In Body:             subscribe
    Alternate:
Archive:

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" sales and 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.  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 the data base service 
running a domain name service registry repository.

The 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 (eg: thin, thick, ...).
The working group will use as input 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

Jan, 2001       Working group agreement on functional requirements for protocol

Mar, 2001       Initial specification of provreg protocol

Jun, 2001       Second draft specification

Sep, 2001       Submit draft for standards track

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 02 Jan 2001 09:21:22 -0800
To: "Christopher Ambler" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Draft provreg charter
Cc: <[email-masked]>
Sender: [email-masked]

At 11:40 PM 12/28/00 -0800, Christopher Ambler wrote:
>Less than a month to go from a functional req to an initial spec? Are you 
>being
>optimistic, or presuming that the initial spec won't stray much from the
>existing one, hence a shorter timeframe?

the latter.

it is the only way to make an aggressive schedule.  however if the 
consensus of the working group is that major changes are necessary, then 
major changes will be made, as always.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 02 Jan 2001 12:02:22 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
From: Marc Blanchet <[email-masked]>
Subject: RE: State of Provreg
Sender: [email-masked]

my 2 cents on my own experience on co-chairing:
- if one co-chair is busy because of work/personal/... (it happens to me 
with a new baby last february), then the other one can continue on and the 
end result is that the wg do not suffer from lack of time from the chair.
- co-chairs can separate their work inside the wg (ie. content, ietf 
management, etc...), so their respective workload is less.
- co-chairs can separate their intervention when perception of politics 
arise: i.e. when a co-chair is business involved in an touchy issue of the 
wg, then the other co-chair can take that ball. (Really useful for the 
co-chairing I've done since  a year now...)
- co-chairs can separate the travel when they are asked to provide reports 
to various organisations, conferences, etc... Especially useful, since it 
happens that the travel schedule of the co-chairs is different and 
complementary so the probability is higher that these requests will be 
handled easily
- there is also some drawbacks (more time for discussing the hot issues 
between the co-chairs, etc.), but my own experience is that co-chairing is 
much more useful than the possible drawbacks.

All these arguments can be relevant or not to this working group. My 
current wg co-chairing is probably a bit political... ;-)))

Well, this is just food of thoughts. I'm not saying that the wg should have 
co-chairs.

Regards, Marc.

At/À 10:41 2001-01-02 -0500, Hollenbeck, Scott you wrote/vous écriviez:
>I'm curious about the need for a co-chair.  I've seen only two list messages
>that touch on the topic: one from Geva in which he suggested the idea, and
>one from myself suggesting that if the need is for "balance" we already
>appear to be progressing towards a balanced WG.  Is a co-chair needed due to
>projected work load or some "behind the scenes" concerns that haven't been
>raised on the list?
>
>Scott Hollenbeck
>VeriSign Global Registry Services
>
>-----Original Message-----
>From: Edward Lewis [mailto:[email-masked]]
>Sent: Tuesday, January 02, 2001 10:04 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: State of Provreg
>
>
>Currently "provreg" has not yet become a WG.  We need to have a charter in
>place and a second co-chair.
>
>Jaap Akkerhuis, a member of Stichting Internet Domeinregistratie Nederland,
>has volunteered to be a co-chair.  (In addition to myself.)
>
>Dave Crocker has been preparing the charter.  Dave, I would like to request
>a reposting of the charter incorporating recent comments provided.  I ask
>the mailing list members to comment on this so it can be submitted to the
>IETF.  Solidifying the charter is the most important work item on our list
>right now.
>
>As soon as Dave puts the current charter on the list, I'll issue a mailing
>list last call.  The last call will be just *one* week.
>
>Once the WG is formalized, we will adopt two drafts to begin ("continue")
>discussion.  One is the protocol requirements document and the other is a
>proposed protocol specification.  Each of these are edited by Scott
>Hollenbeck, and both appear under his name (as we have to WG standing yet).
>
>The current documents, as presented in San Diego are:
>      draft-hollenbeck-grrp-reqs-05.txt
>      draft-hollenbeck-epp-00.txt
>
>There are other epp-*-00.txt's that will be adopted as needed.
>
>When making comments on the documents, keep in mind:
>
>The charter is our roadmap.  We want to set the scope for the work,
>expressing the desired outcome and the schedule.  From what I've gleaned,
>our desire is to specifiy a policy-neutral registrar-registry protocol.
>The protocol should suitable for any registrar to contact any registry,
>regardless of differences in the registries' business models.  *One* reason
>for doing this quickly is have the protocol in place so it can be used in
>the ICANN-gTLD process.
>
>The requirements document specifies what a candidate protocol must do and
>what it should do.  The requirements are not levied on either registry nor
>registrar operations.  I.e., the document does not (and can not) require
>compliance by parties to use the protocol nor to use it exclusively.
>
>We trust that the protocol, when specified, will be good enough and
>desirable enough that registries and their registrars will want to use it.
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: +1 443-259-2352                      Email: [email-masked]
>
>"It takes years of training to know when to do nothing" - Dogbert
>
>Opinions expressed are property of my evil twin, not my employer.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

Date: Tue, 02 Jan 2001 08:42:18 -0800
To: Rick H Wesson <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: State of Provreg
Cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 08:19 AM 1/2/01 -0800, Rick H Wesson wrote:
>I propose that we just keep Ed as chair and not have a co-chair. Not that
>I have anything against Jaap, I don't. I think Ed will be fair and make
>sure all sides get represented.

I am quite fond of having co-chairs... in some circumstances.  In 
particular, co-chairs can be quite helpful when the content area involves 
lots of people with little or no IETF experience.  Hence one chair is a 
content expert and one is a process expert.

This group already has a number of very experienced IETF participants, so 
there is no need to worry about the group having sufficient knowledge in 
that regard.

As to "neutrality" that is never possible to achieve completely.  Hence it 
is worth attending to it only for extreme cases.  Also note that the same 
concern about a neutral chair could be raised about a neutral editor.  (As 
has been often noted, editor is actually a more powerful job than chair...)

Let me suggest that this group has a broad enough, and active enough, range 
of participants to greatly reduce concerns about biased process and biased 
content.

One chair ought to be just fine.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 02 Jan 2001 08:24:12 -0800
To: "Paul M. Kane" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Draft provreg charter
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:36 PM 1/1/01 +0000, Paul M. Kane wrote:
>As with much in this world ...technology is not the main issue but the 
>political
>environment in which technology may be employed....

For IETF work, that statement is not correct.

The IETF seeks very diligently to focus on technical issues, to the 
exclusion of political ones.  To date it has succeeded in that focus quite 
well.

>So may I suggest inorder to progress the RRP
>protocol, the obligation for Registrars/Registries to adopt the "standard" RRP
>(resulting from this process) is not to the exclusion of other "less 
>regulated"
>technologies/requirements.

The IETF has dealt with the problem of national variations before, not 
surprisingly  also in the realm of security/privacy.  As noted above, the 
issue was resolved by focusing on technical issues rather than political.

Countries are free to adopt technically inferior solutions.  The IETF is not.

That said, it is usually true that IETF work provides layered solutions, 
such having security and functional mechanisms that work independently.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 2 Jan 2001 08:19:27 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Subject: RE: State of Provreg
Sender: [email-masked]

I propose that we just keep Ed as chair and not have a co-chair. Not that
I have anything against Jaap, I don't. I think Ed will be fair and make
sure all sides get represented.

-rick

On Tue, 2 Jan 2001, Hollenbeck, Scott wrote:

> I'm curious about the need for a co-chair.  I've seen only two list messages
> that touch on the topic: one from Geva in which he suggested the idea, and
> one from myself suggesting that if the need is for "balance" we already
> appear to be progressing towards a balanced WG.  Is a co-chair needed due to
> projected work load or some "behind the scenes" concerns that haven't been
> raised on the list?
>

Date: Tue, 02 Jan 2001 08:13:08 -0800
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Draft provreg charter
Cc: [email-masked]
Sender: [email-masked]

At 11:16 AM 1/1/01 -0500, Hollenbeck, Scott wrote:
>believe that the best solution is a simple protocol with other protocol
>layers that address the needs (such as transport or security) of different
>operating environments.

Exactly correct.

At 08:38 AM 1/2/01 -0500, Hollenbeck, Scott wrote:
>We could adopt a charter with "longer" deadlines, and then work hard to beat
>them through the work of a design team.  I would be willing to organize and
>host such an effort if needed.

In order to meet an aggressive schedule, one must be set.

Set longer milestones and the effort will take longer.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: State of Provreg
Date: Tue, 2 Jan 2001 10:41:01 -0500 
Sender: [email-masked]

I'm curious about the need for a co-chair.  I've seen only two list messages
that touch on the topic: one from Geva in which he suggested the idea, and
one from myself suggesting that if the need is for "balance" we already
appear to be progressing towards a balanced WG.  Is a co-chair needed due to
projected work load or some "behind the scenes" concerns that haven't been
raised on the list?

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 10:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: State of Provreg

Currently "provreg" has not yet become a WG.  We need to have a charter in
place and a second co-chair.

Jaap Akkerhuis, a member of Stichting Internet Domeinregistratie Nederland,
has volunteered to be a co-chair.  (In addition to myself.)

Dave Crocker has been preparing the charter.  Dave, I would like to request
a reposting of the charter incorporating recent comments provided.  I ask
the mailing list members to comment on this so it can be submitted to the
IETF.  Solidifying the charter is the most important work item on our list
right now.

As soon as Dave puts the current charter on the list, I'll issue a mailing
list last call.  The last call will be just *one* week.

Once the WG is formalized, we will adopt two drafts to begin ("continue")
discussion.  One is the protocol requirements document and the other is a
proposed protocol specification.  Each of these are edited by Scott
Hollenbeck, and both appear under his name (as we have to WG standing yet).

The current documents, as presented in San Diego are:
     draft-hollenbeck-grrp-reqs-05.txt
     draft-hollenbeck-epp-00.txt

There are other epp-*-00.txt's that will be adopted as needed.

When making comments on the documents, keep in mind:

The charter is our roadmap.  We want to set the scope for the work,
expressing the desired outcome and the schedule.  From what I've gleaned,
our desire is to specifiy a policy-neutral registrar-registry protocol.
The protocol should suitable for any registrar to contact any registry,
regardless of differences in the registries' business models.  *One* reason
for doing this quickly is have the protocol in place so it can be used in
the ICANN-gTLD process.

The requirements document specifies what a candidate protocol must do and
what it should do.  The requirements are not levied on either registry nor
registrar operations.  I.e., the document does not (and can not) require
compliance by parties to use the protocol nor to use it exclusively.

We trust that the protocol, when specified, will be good enough and
desirable enough that registries and their registrars will want to use it.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 2 Jan 2001 10:04:18 -0500
To: <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: State of Provreg
Cc: [email-masked]
Sender: [email-masked]

Currently "provreg" has not yet become a WG.  We need to have a charter in
place and a second co-chair.

Jaap Akkerhuis, a member of Stichting Internet Domeinregistratie Nederland,
has volunteered to be a co-chair.  (In addition to myself.)

Dave Crocker has been preparing the charter.  Dave, I would like to request
a reposting of the charter incorporating recent comments provided.  I ask
the mailing list members to comment on this so it can be submitted to the
IETF.  Solidifying the charter is the most important work item on our list
right now.

As soon as Dave puts the current charter on the list, I'll issue a mailing
list last call.  The last call will be just *one* week.

Once the WG is formalized, we will adopt two drafts to begin ("continue")
discussion.  One is the protocol requirements document and the other is a
proposed protocol specification.  Each of these are edited by Scott
Hollenbeck, and both appear under his name (as we have to WG standing yet).

The current documents, as presented in San Diego are:
     draft-hollenbeck-grrp-reqs-05.txt
     draft-hollenbeck-epp-00.txt

There are other epp-*-00.txt's that will be adopted as needed.

When making comments on the documents, keep in mind:

The charter is our roadmap.  We want to set the scope for the work,
expressing the desired outcome and the schedule.  From what I've gleaned,
our desire is to specifiy a policy-neutral registrar-registry protocol.
The protocol should suitable for any registrar to contact any registry,
regardless of differences in the registries' business models.  *One* reason
for doing this quickly is have the protocol in place so it can be used in
the ICANN-gTLD process.

The requirements document specifies what a candidate protocol must do and
what it should do.  The requirements are not levied on either registry nor
registrar operations.  I.e., the document does not (and can not) require
compliance by parties to use the protocol nor to use it exclusively.

We trust that the protocol, when specified, will be good enough and
desirable enough that registries and their registrars will want to use it.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Richard Shockey'" <[email-masked]>, [email-masked]
Subject: RE: One additional requirement...
Date: Tue, 2 Jan 2001 08:44:43 -0500 
Sender: [email-masked]

Section 6.1 of the requirements draft addresses standards compliance.  How
about if I change 6.1-[1] from this:

"[1] A generic registry-registrar protocol MUST conform to current IETF
standards.  Standards for domain and host name syntax, IP address syntax,
and security are particularly relevant.  Emerging standards for the Domain
Name System MUST be considered as they approach maturity."

to this:

"[1] A generic registry-registrar protocol MUST conform to current IETF
standards.  Standards for domain and host name syntax, IP address syntax,
security, and transport are particularly relevant.  Emerging standards for
the Domain Name System MUST be considered as they approach maturity."

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Friday, December 22, 2000 1:02 PM
To: [email-masked]
Subject: One additional requirement...

IMHO we should be explicit in our requirements document that we invent no 
new transport protocols.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Draft provreg charter
Date: Tue, 2 Jan 2001 08:38:34 -0500 
Sender: [email-masked]

I think both Ed and Richard have valid points.  We need a charter with
deadlines that don't force us towards suboptimal results, but we also need
to be aware of the practical realities that keep each of us interested in
this process.

We could adopt a charter with "longer" deadlines, and then work hard to beat
them through the work of a design team.  I would be willing to organize and
host such an effort if needed.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Saturday, December 30, 2000 11:34 AM
To: Edward Lewis; Christopher Ambler
Cc: [email-masked]; [email-masked]
Subject: Re: Draft provreg charter

At 04:39 PM 12/29/2000 -0500, Edward Lewis wrote:
>The effort to define a generic registrar registry protocol has been
>underway for some time now, seeking input from various groups.  Little or
>no interest has been expressed until now, hence the compressed schedule
>presented in the charter.  Interest and attendence at the BOF meeting in
>San Diego was much greater than anticipated.

Well IMHO it was totally expected... what possible interest would there be 
in a generic RRP if there were no new TLD's issued?  The progressive 
members ccTLD community has been waiting for this as well ..timing is 
everything and the critical mass now exists.

>Although the hope is that the existing documents are in good shape, the
>desire is to generate a protocol that is beneficial to all involved and in
>a timely manner.  Although we would like to have quick results, arriving at
>a solid protocol is more important than the schedule.

Well I'm not sure I agree here.. there is a genuine dilemma here caused by 
ICANN process <suprise>. Whereas it is clear that there was no critical 
mass for a XRRP until new TLD's were issued but now there is a serious 
problem of time to market among the new registry entrants and the desire of 
the registrar community NOT to have competing standards out there.

That is just as important as a solid protocol...and the business of our 
registrars will be seriously impaired if we have multiple proposals out 
there or we stall and delay.

>  Bare in mind that
>delays in achieving the protocol specification may have an impact on the
>registry to registrar business model for some time.

Well I don't know about your business model but that is unacceptable to 
mine. I cant speak for my TUCOWS friends but I cant imagine they want this 
process dragged out.

  We cant have any delays here for any number of reasons including the 
public expatiation that these new TLD's have been created and need to be 
put in place and the need to prove to ICANN  that the "proof of concept" 
will work.

>With this in mind, what is the feeling about:
>Apr, 2001       WG agreement on functional requirements for protocol
>May, 2001       Initial specification of provreg protocol

I would accelerate this to Requirements by Feb , by April have the 
specification ready and by IETF 50 we think about wraping things up.

>This allows for a face to face meeting at the next IETF (providing the WG
>is formed) before the deadline for the two documents.  But, please,
>continue to provide comments on the existing documents in a timely fashion.

Well I'm going to propose that we discuss with our Area Director Patrik the 
possibility of some off-site meetings to accelerate the requirements and 
design process. This is standard procedure within the  IETF when a 
consensus within the WG exists that such meetings are necessary. The list 
is always the central focus of the WG but such off sites have the advantage 
of focusing attention on the problem among a highly motivated group of 
participants. These meetings have worked with great success in the past and 
given the unique situation here and the market pressures for new registries 
to be up and running is a short period of time I believe this is a good
idea.

The reason I'm suggesting this is my belief that there is already rough 
consensus on what this protocol looks like (transport a XML something) and 
the core problems are defining the schemas , preparing them for an IANA 
registration procedure ( see  draft-mealling-iana-xmlns-registry-00.txt) , 
and deciding on a transport and security model ( I favor BEEP) since I'm 
sure no one wants to invent a new transport or security model for this.

Extensibility in this model is achieved by the abstraction of the XML 
objects from the transport layer and the detailed description of the 
business rules associated with the XML objects. Clearly the business rules 
for TLD registration would be different from IP address requests, telephone 
numbers or teachers accessing a registry of student records etc.

Indeed there may be different business rules between TLD registries. Our 
colleagues at .DE have been correct to point out that what is required for 
a gTLD is not necessarily what is needed by a ccTLD.  European privacy 
rules being what they are. Indeed the requirements for .COM registration 
might change over time as new gTLD are issued and Verisign looks to "add 
value" in new ways. Such value adds would eventually be reflected in the 
"extensible" registration procedure.

So .. even though the WG has not been approved and we are still debating 
charter and requirements issues ..is there interest in some structured 
off-site meetings?   Washington DC perhaps :-)

Date: Tue, 2 Jan 2001 11:29:10 +0100
To: Lars-Johan Liman <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Provreg list administratrivia.
Sender: [email-masked]

At 10.38 +0100 01-01-02, Lars-Johan Liman wrote:
>Please note that the mail server for the <[email-masked]>
>maillist has mild spamfilters installed, and that it permits only list
>members to send messages to the list.

For an IETF wg mailing list, the messages which are rejected must be 
sent to a human which then can make a decision manually whether the 
message should be accepted or not.

The requirements for a wg mailing list in the IETF include the following:

  - Subscribing to the list should be simple, and one should not have to
    give away other information than the email address. Being forced to
    do so violates the laws in some countries in the world, including
    but not limited to, Sweden.
  - An email archive must exist which anyone on the Internet can access
    via FTP and/or HTTP without giving away any information at all.
  - Sending messages to the list must be possible for all users on the
    Internet, including non-subscribed users. I.e. cross posting between
    mailing lists must be possible.
  - It is ok to have a manual filter (a user allowing messages but not
    spam through) for non-subscribed members, but never an automatic
    rejection mechanism.
  - Any time a message is rejected, the sender of the message should be
    informed why, and a copy of the communication between the person
    running the filter and the person sending the rejected message
    should be archived.
  - The user <wgacronym>[email-masked] must be subscribed to
    the mailing list.

      paf

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

To: [email-masked]
Subject: Provreg list administratrivia.
From: Lars-Johan Liman <[email-masked]>
Date: Tue, 02 Jan 2001 10:38:38 +0100
Lines: 16
Sender: [email-masked]

Folks,

Please note that the mail server for the <[email-masked]>
maillist has mild spamfilters installed, and that it permits only list
members to send messages to the list. Thus, you have to send your
messages using "From:" equal to your subscribed list, else the message
will bounce. Sending from "my home address", or "my alternative
employer" will usually NOT work without tweaking the address.

				Best regards,
				  /Liman
				   Mail list admin
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Autonomica AB, Stockholm 	! HTTP  : //www.autonomica.se/
#----------------------------------------------------------------------

Date: Mon, 01 Jan 2001 14:36:19 +0000
From: "Paul M. Kane" <[email-masked]>
Organization: REACTO.com
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Draft provreg charter
Sender: [email-masked]

Hi Scott and all

As with much in this world ...technology is not the main issue but the political
environment in which technology may be employed....
Putting on my Registrars NC Rep's "hat" the desire to have a standard interface
to gTLDs is well overdue and most welcome. We need to ensure that the proposed
new TLDs can be introduces in a stable and efficient manner (as quickly as
possible). One issue I have is the scope and ramifications of adopting certain
technologies which certain governments are keen to control... cryptography,
international personal data exchange... etc. Thus it is a registrars legal
ability to adopt certain technologies that could confine/restrict their business
activity as registrars and .... So may I suggest inorder to progress the RRP
protocol, the obligation for Registrars/Registries to adopt the "standard" RRP
(resulting from this process) is not to the exclusion of other "less regulated"
technologies/requirements.

Continuing that theme (and putting on a ccTLD "hat") may I suggest that your
work should not impinge upon the right/ability of a ccTLD
registry to best serve the local internet community, and if that means using
email templates as the best means of communicating with a ccTLD registry ...so
it should be without any pressures to adopt more "real-time" registry/registrar
protocols..... i.e. soften the "ccTLD" registry approach to avoid "push-back".
In some of the ccTLD registry systems we administer, the use of x509
certificates are not allowed in certain jurisdictions, so we use either secure
tunnel (for real-time interface) or PGP encrypted email.

I am on vacation at the moment and thus not able to particiapte/respond to
emails etc,

Happy New Year to all.....

Paul

Date: Fri, 22 Dec 2000 13:01:46 -0500
To: [email-masked]
From: Richard Shockey <[email-masked]>
Subject: One additional requirement...
Sender: [email-masked]

IMHO we should be explicit in our requirements document that we invent no 
new transport protocols.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Fri, 22 Dec 2000 12:52:34 -0500
To: "Jordyn A. Buchanan" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Sender: [email-masked]

At 12:34 PM 12/21/2000 -0500, Jordyn A. Buchanan wrote:
>At 12:05 PM 12/21/2000 -0500, Hollenbeck, Scott wrote:
>>Rather than try to enumerate all of the possible object types that might be
>>registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
>>Geva (which I think would then be inconsistent with other specific object
>>requirements in 3.4), I'd really prefer to add a requirement to section 7.5
>>if people believe that 7.5-[1] talks more to protocol extensibility than
>>object extensibility:
>
>Just for clarity, I suggest we enumerate the types of objects we might 
>like to register for sanity's sake, and not for inclusion into the 
>requirements doc.  Then we can make sure that the requirements match.
>
>Scott's suggestion that we add a statement at the global level about 
>extensibility rather than making the object requirements overly generic is 
>a good one, and I think the language he proposes is much more clear and 
>understandable than a more generic discussion about alphanumeric strings 
>with certain qualities.

Works for me...

>Jordyn

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Fri, 22 Dec 2000 12:51:41 -0500
To: "J. William Semich" <[email-masked]>, "'provreg List'" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Scope [was Re: Expiration times]
Sender: [email-masked]

>
> >
> >This is a valid point.  At the same time, I think it's important to avoid
> >too much scope creep here too.
><snip>

Please

>Verisign has launched a testbed registry for ENUM type identifiers
>(www.enumworld.com). Scott, would the above proposed provision for a
>"broader range of identifiers" be one way to accommodate ENUM registry
>activity, or would 7.5-[1] be adequate?

Speaking as IETF ENUM Chair I think it would be a bad idea for PROVREG to 
look at this ENUM provisioning ..at this time. What is important for this 
protocol is extensibility.

We do need to stay focused on the task at hand with is domain name 
registration and the needs of customers and some of us new registries to be 
ready in a timely manner.

If we keep extensibility in mind then I think we will have no problems 
..ENUM registrations would be only a "profile" of provreg.

That would indicate that we want to add "application tags" to the XML 
schemas to indicate what application is involved ..obviously IP phone 
number registrations will require an entirely different set data based on a 
entirely different set of business rules

>Bill Semich
>
>.NU Domain

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul M. Kane'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Draft provreg charter
Date: Mon, 1 Jan 2001 11:16:57 -0500 
Sender: [email-masked]

Paul,

I'm certainly not advocating any particular solution that (to use your
example) requires X.509 certificates.  As I've said on this list before, I
believe that the best solution is a simple protocol with other protocol
layers that address the needs (such as transport or security) of different
operating environments.

Scott Hollenbeck
VeriSign Global Registry Services 

-----Original Message-----
From: Paul M. Kane [mailto:[email-masked]]
Sent: Monday, January 01, 2001 9:36 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: Draft provreg charter

Hi Scott and all

As with much in this world ...technology is not the main issue but the
political
environment in which technology may be employed....
Putting on my Registrars NC Rep's "hat" the desire to have a standard
interface
to gTLDs is well overdue and most welcome. We need to ensure that the
proposed
new TLDs can be introduces in a stable and efficient manner (as quickly as
possible). One issue I have is the scope and ramifications of adopting
certain
technologies which certain governments are keen to control... cryptography,
international personal data exchange... etc. Thus it is a registrars legal
ability to adopt certain technologies that could confine/restrict their
business
activity as registrars and .... So may I suggest inorder to progress the RRP
protocol, the obligation for Registrars/Registries to adopt the "standard"
RRP
(resulting from this process) is not to the exclusion of other "less
regulated"
technologies/requirements.

Continuing that theme (and putting on a ccTLD "hat") may I suggest that your
work should not impinge upon the right/ability of a ccTLD
registry to best serve the local internet community, and if that means using
email templates as the best means of communicating with a ccTLD registry
...so
it should be without any pressures to adopt more "real-time"
registry/registrar
protocols..... i.e. soften the "ccTLD" registry approach to avoid
"push-back".
In some of the ccTLD registry systems we administer, the use of x509
certificates are not allowed in certain jurisdictions, so we use either
secure
tunnel (for real-time interface) or PGP encrypted email.

I am on vacation at the moment and thus not able to particiapte/respond to
emails etc,

Happy New Year to all.....

Paul