Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0VKPfQ09659 for ietf-provreg-outgoing; Wed, 31 Jan 2001 21:25:41 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VKPdA09654 for ; Wed, 31 Jan 2001 21:25:40 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id UAA06131; Wed, 31 Jan 2001 20:21:46 GMT From: "Brian W. Spolarich" To: , Subject: RE: Merging RRP and Whois Date: Wed, 31 Jan 2001 15:26:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200101302258.QAA21440@alliance.globalnetlink.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk | 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. :-) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0VIeOg08630 for ietf-provreg-outgoing; Wed, 31 Jan 2001 19:40:24 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VIeMA08625 for ; Wed, 31 Jan 2001 19:40:22 +0100 (MET) Received: by sentry.gw.tislabs.com; id NAA26748; Wed, 31 Jan 2001 13:43:38 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xmaa26739; Wed, 31 Jan 01 13:43:02 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jan 2001 13:28:34 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: Interim Meeting Reminder Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 ietf-provreg@cafax.se or send mail to lewis@tislabs.com 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0VC1If04583 for ietf-provreg-outgoing; Wed, 31 Jan 2001 13:01:18 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VC1GA04578 for ; Wed, 31 Jan 2001 13:01:16 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA23301; Wed, 31 Jan 2001 07:01:12 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jan 2001 06:56:17 -0500 Message-ID: From: "Hollenbeck, Scott" To: =?windows-1252?Q?=27J=F6rg_Bauer/Denic=27?= , ietf-provreg@cafax.se Subject: RE: Interim Meeting Date: Wed, 31 Jan 2001 06:56:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f0VC1HA04579 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Meeting details were sent to this list on Monday 22 January: http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00188.html > -----Original Message----- > From: Jörg Bauer/Denic [mailto:bauer@denic.de] > Sent: Wednesday, January 31, 2001 4:01 AM > To: ietf-provreg@cafax.se > Subject: Interim Meeting > > > > Are we having a interim Meeting at 20.Feb. ??? > > Could anybody post exact Place/Date ???? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0V936303214 for ietf-provreg-outgoing; Wed, 31 Jan 2001 10:03:06 +0100 (MET) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0V936A03209 for ; Wed, 31 Jan 2001 10:03:06 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14Nt9g-0006Vk-00; Wed, 31 Jan 2001 10:02:21 +0100 Subject: Interim Meeting To: ietf-provreg@cafax.se X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Wed, 31 Jan 2001 10:00:45 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 31.01.2001 10:02:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Are we having a interim Meeting at 20.Feb. ??? Could anybody post exact Place/Date ???? -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0V91kD03188 for ietf-provreg-outgoing; Wed, 31 Jan 2001 10:01:46 +0100 (MET) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0V91jA03183 for ; Wed, 31 Jan 2001 10:01:45 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14Nt8W-0006PV-00; Wed, 31 Jan 2001 10:01:09 +0100 Subject: Antwort: Unique "Handles"? To: Bill Manning Cc: budi@alliance.globalnetlink.com, ietf-provreg@cafax.se, ietf-whois@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Wed, 31 Jan 2001 09:59:21 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 31.01.2001 10:01:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 31.01.2001 00:42 Bill Manning 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 : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0V83WM02811 for ietf-provreg-outgoing; Wed, 31 Jan 2001 09:03:32 +0100 (MET) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0V83TA02806 for ; Wed, 31 Jan 2001 09:03:29 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0V82i400368 for ietf-provreg@cafax.se; Wed, 31 Jan 2001 09:02:44 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UNhXA28532 for ; Wed, 31 Jan 2001 00:43:33 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0UNhUU07537; Tue, 30 Jan 2001 15:43:30 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0UNg8426756; Tue, 30 Jan 2001 15:42:08 -0800 Message-Id: <200101302342.f0UNg8426756@zed.isi.edu> Subject: Unique "Handles"? To: budi@alliance.globalnetlink.com Date: Tue, 30 Jan 2001 15:42:08 -0800 (PST) Cc: ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <200101302258.QAA21440@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Jan 31, 2001 05:19:35 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UMGOJ27453 for ietf-provreg-outgoing; Tue, 30 Jan 2001 23:16:24 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UMGNA27448 for ; Tue, 30 Jan 2001 23:16:23 +0100 (MET) Received: from pentium3 (ppp8d.dialin.elga.net.id [202.173.64.136]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA21440; Tue, 30 Jan 2001 16:58:30 -0600 Message-Id: <200101302258.QAA21440@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Wed, 31 Jan 2001 05:19:35 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Merging RRP and Whois CC: ietf-whois@imc.org References: <002401c087f7$ed394840$140a0a0a@ambler.net> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0ULQFc26697 for ietf-provreg-outgoing; Tue, 30 Jan 2001 22:26:15 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0ULQAA26692 for ; Tue, 30 Jan 2001 22:26:10 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0ULPON01184 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 22:25:24 +0100 (MET) Received: from fulcrum ([204.70.128.22]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UKFnA26003 for ; Tue, 30 Jan 2001 21:15:50 +0100 (MET) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Z00G01SA1NG@cw.net> for ietf-provreg@cafax.se; Tue, 30 Jan 2001 15:15:37 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Z00G3NSA1FG@cw.net>; Tue, 30 Jan 2001 15:15:37 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 15:15:55 -0500 Content-return: allowed Date: Tue, 30 Jan 2001 15:25:31 -0500 From: "Lu, Ping" Subject: RE: Sorry -- Re: Merging RRP and Whois To: "'Shane Kerr'" , "Lu, Ping" Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: plu@cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Tuesday, January 30, 2001 1:17 PM > To: Lu, Ping > Cc: ietf-provreg@cafax.se; ietf-whois@imc.org > 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 > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UKJHO26058 for ietf-provreg-outgoing; Tue, 30 Jan 2001 21:19:17 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UKJCA26050 for ; Tue, 30 Jan 2001 21:19:12 +0100 (MET) Received: by sentry.gw.tislabs.com; id PAA13236; Tue, 30 Jan 2001 15:22:23 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma013225; Tue, 30 Jan 01 15:21:51 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Jan 2001 15:15:37 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Mail thread clean up Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: , was 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UJu1e25807 for ietf-provreg-outgoing; Tue, 30 Jan 2001 20:56:01 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UJtuA25800 for ; Tue, 30 Jan 2001 20:55:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0UJtCh00597 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 20:55:12 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UIIjA24879 for ; Tue, 30 Jan 2001 19:18:45 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id TAA01081; Tue, 30 Jan 2001 19:17:12 +0100 (CET) Date: Tue, 30 Jan 2001 19:17:12 +0100 (CET) From: Shane Kerr To: "Lu, Ping" cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: RE: Sorry -- Re: Merging RRP and Whois In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UJtdG25798 for ietf-provreg-outgoing; Tue, 30 Jan 2001 20:55:39 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UJtVA25793 for ; Tue, 30 Jan 2001 20:55:31 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0UJskx00581 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 20:54:46 +0100 (MET) Received: from fulcrum ([204.70.128.22]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UHPVA24308 for ; Tue, 30 Jan 2001 18:25:32 +0100 (MET) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Z00901KDZ6X@cw.net> for ietf-provreg@cafax.se; Tue, 30 Jan 2001 12:25:11 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Z007NQKDYJI@cw.net>; Tue, 30 Jan 2001 12:25:10 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 12:25:29 -0500 Content-return: allowed Date: Tue, 30 Jan 2001 12:35:02 -0500 From: "Lu, Ping" Subject: RE: Sorry -- Re: Merging RRP and Whois To: "'Sheer El-Showk'" , ietf-provreg@cafax.se, ietf-whois@imc.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: plu@cw.net > -----Original Message----- > From: Sheer El-Showk [mailto:sheer@laudanum.saraf.com] > Sent: Tuesday, January 30, 2001 8:55 AM > To: ietf-provreg@cafax.se; ietf-whois@imc.org > 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 > > > > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UDxrW21650 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:59:53 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UDxqA21645 for ; Tue, 30 Jan 2001 14:59:52 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0UDskN27542; Tue, 30 Jan 2001 08:54:46 -0500 Date: Tue, 30 Jan 2001 08:54:46 -0500 (EST) From: Sheer El-Showk To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Sorry -- Re: Merging RRP and Whois In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD8Tk20914 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:08:29 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UD8SA20909 for ; Tue, 30 Jan 2001 14:08:28 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD7h000800 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 14:07:43 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0TGCuA08246 for ; Mon, 29 Jan 2001 17:12:56 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA13082; Mon, 29 Jan 2001 17:12:24 +0100 (CET) Date: Mon, 29 Jan 2001 17:12:24 +0100 (CET) From: Shane Kerr To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010129103932.A735@register.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD6PQ20798 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:06:25 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UD6OA20793 for ; Tue, 30 Jan 2001 14:06:24 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD5e800691 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 14:05:40 +0100 (MET) Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0SDvtA24461 for ; Sun, 28 Jan 2001 14:57:56 +0100 (MET) Received: from 04-180.068.popsite.net (sheer@04-180.068.popsite.net [64.24.81.180]) by uclink4.berkeley.edu (8.10.1/8.10.1) with ESMTP id f0SDvoG13899; Sun, 28 Jan 2001 05:57:50 -0800 (PST) Date: Sun, 28 Jan 2001 06:49:19 +0000 (WET) From: Sheer El-Showk X-Sender: sheer@graymalkin.teranix.net To: Bill Manning cc: George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101261737.f0QHb3h12444@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD6KJ20782 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:06:20 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UD6JA20777 for ; Tue, 30 Jan 2001 14:06:19 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD5Y300683 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 14:05:34 +0100 (MET) Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0SDTYA24313 for ; Sun, 28 Jan 2001 14:29:34 +0100 (MET) Received: from 12-173.068.popsite.net (sheer@12-173.068.popsite.net [64.24.83.173]) by uclink4.berkeley.edu (8.10.1/8.10.1) with ESMTP id f0SDTUG13540 for ; Sun, 28 Jan 2001 05:29:31 -0800 (PST) Date: Sun, 28 Jan 2001 06:20:54 +0000 (WET) From: Sheer El-Showk X-Sender: sheer@graymalkin.teranix.net To: ietf-provreg@cafax.se Subject: Re: Exentisibility in the requirements In-Reply-To: <20010124134616.N24903@register.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > > > > Dilbert is an optimist. > > > > Opinions expressed are property of my evil twin, not my employer. > > > > > > -- > ----------------------------- > George Belotsky > Senior Software Architect > Register.com, inc. > george@register.com > 212-798-9127 (phone) > 212-798-9876 (fax) > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD2Jl20690 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:02:19 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UD2EA20685 for ; Tue, 30 Jan 2001 14:02:14 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD1Te00555 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 14:01:29 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0RH1wA16020 for ; Sat, 27 Jan 2001 18:01:58 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA13199; Sat, 27 Jan 2001 18:01:56 +0100 (CET) Date: Sat, 27 Jan 2001 18:01:56 +0100 (CET) From: Shane Kerr To: Christopher Ambler cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <002401c087f7$ed394840$140a0a0a@ambler.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 ~~ Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD29220672 for ietf-provreg-outgoing; Tue, 30 Jan 2001 14:02:09 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UD28A20667 for ; Tue, 30 Jan 2001 14:02:08 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UD1Ol00547 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 14:01:24 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0RGgbA15845 for ; Sat, 27 Jan 2001 17:42:37 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA11253; Sat, 27 Jan 2001 17:41:59 +0100 (CET) Date: Sat, 27 Jan 2001 17:41:59 +0100 (CET) From: Shane Kerr To: Bill Manning cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101262118.f0QLIT312712@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0UCvbZ20571 for ietf-provreg-outgoing; Tue, 30 Jan 2001 13:57:37 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0UCvQA20566 for ; Tue, 30 Jan 2001 13:57:26 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0UCufL00411 for ietf-provreg@cafax.se; Tue, 30 Jan 2001 13:56:41 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QLJsA07972 for ; Fri, 26 Jan 2001 22:19:54 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0QLJqU07751; Fri, 26 Jan 2001 13:19:52 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0QLIT312712; Fri, 26 Jan 2001 13:18:29 -0800 Message-Id: <200101262118.f0QLIT312712@zed.isi.edu> Subject: Re: Merging RRP and Whois To: george@register.com (George Belotsky) Date: Fri, 26 Jan 2001 13:18:29 -0800 (PST) Cc: shane@ripe.net (Shane Kerr), ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <20010126145636.B7740@register.com> from "George Belotsky" at Jan 26, 2001 02:56:36 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % % 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0U0Td213100 for ietf-provreg-outgoing; Tue, 30 Jan 2001 01:29:39 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0U0TcA13095 for ; Tue, 30 Jan 2001 01:29:38 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA20513 for ; Mon, 29 Jan 2001 19:29:37 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jan 2001 19:24:44 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: FW: WG Review: Provisioning Registry Protocol (provreg) Date: Mon, 29 Jan 2001 19:24:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk FYI -- our WG proposal has finally hit the wires. -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Monday, January 29, 2001 1:54 PM To: IETF-Announce; IETF-Announce; @loki.ietf.org Cc: new-work@ietf.org 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:ietf-provreg@cafax.se To Subscribe: ietf-provreg-request@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ Description of Working Group: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models. This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn). The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. Documentation from the working group will: * Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants * Describe appropriate mechanisms for security during registrar access * List useful examples of registrar access transactions Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0TG6lk08162 for ietf-provreg-outgoing; Mon, 29 Jan 2001 17:06:47 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0TG6kA08157 for ; Mon, 29 Jan 2001 17:06:47 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0TG1W925122; Mon, 29 Jan 2001 11:01:33 -0500 Date: Mon, 29 Jan 2001 11:01:32 -0500 (EST) From: Sheer El-Showk To: George Belotsky cc: Bill Manning , Shane Kerr , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010129103932.A735@register.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > % 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0TFdjf07762 for ietf-provreg-outgoing; Mon, 29 Jan 2001 16:39:45 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0TFdgA07757 for ; Mon, 29 Jan 2001 16:39:44 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14NGOy-0005UP-00; Mon, 29 Jan 2001 10:39:32 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 29 Jan 2001 10:39:32 -0500 Date: Mon, 29 Jan 2001 10:39:32 -0500 From: George Belotsky To: Bill Manning Cc: Shane Kerr , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010129103932.A735@register.com> References: <20010126145636.B7740@register.com> <200101262118.f0QLIT312712@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101262118.f0QLIT312712@zed.isi.edu>; from bmanning@ISI.EDU on Fri, Jan 26, 2001 at 01:18:29PM -0800 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0T7fIM02046 for ietf-provreg-outgoing; Mon, 29 Jan 2001 08:41:18 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0T7fHA02041 for ; Mon, 29 Jan 2001 08:41:17 +0100 (MET) Received: from pbue.switch.ch ([130.59.4.112]) by central.switch.ch with esmtp (Exim 3.15 #3) id 14N8w7-0001Id-00 for ietf-provreg@cafax.se; Mon, 29 Jan 2001 08:41:16 +0100 Date: Sun, 28 Jan 2001 20:19:06 +0100 From: Urs Eppenberger To: ietf-provreg@cafax.se Subject: Unique NIC handles (was: Merging RRP and Whois) Message-ID: <799322.980713146@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0SEEA424578 for ietf-provreg-outgoing; Sun, 28 Jan 2001 15:14:10 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0SEE9A24573 for ; Sun, 28 Jan 2001 15:14:09 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0SE9CG23670; Sun, 28 Jan 2001 09:09:12 -0500 Date: Sun, 28 Jan 2001 09:09:12 -0500 (EST) From: Sheer El-Showk To: bmanning@ISI.EDU cc: george@register.com, ietf-provreg@cafax.se Subject: Re: Merging RRP and Whois (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0SE4Bc24520 for ietf-provreg-outgoing; Sun, 28 Jan 2001 15:04:11 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0SE4AA24515 for ; Sun, 28 Jan 2001 15:04:10 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0SDxIa23653 for ; Sun, 28 Jan 2001 08:59:18 -0500 Date: Sun, 28 Jan 2001 08:59:18 -0500 (EST) From: Sheer El-Showk To: ietf-provreg@cafax.se Subject: Re: Exentisibility in the requirements (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > > > > Dilbert is an optimist. > > > > Opinions expressed are property of my evil twin, not my employer. > > > > > > -- > ----------------------------- > George Belotsky > Senior Software Architect > Register.com, inc. > george@register.com > 212-798-9127 (phone) > 212-798-9876 (fax) > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0S7ZqN22322 for ietf-provreg-outgoing; Sun, 28 Jan 2001 08:35:52 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0S7ZoA22317 for ; Sun, 28 Jan 2001 08:35:51 +0100 (MET) Received: from jamessonyvaio (1Cust223.tnt2.honolulu2.hi.da.uu.net [63.39.141.223]) by mail.i-dns.net (Postfix) with SMTP id F278FFFC03; Sun, 28 Jan 2001 15:35:33 +0800 (SGT) Message-ID: <002a01c088fc$bacb84d0$df8d273f@jamessonyvaio> From: "James Seng/Personal" To: "Bill Manning" , "George Belotsky" Cc: "Shane Kerr" , , References: <200101262118.f0QLIT312712@zed.isi.edu> Subject: Re: Merging RRP and Whois Date: Sun, 28 Jan 2001 09:02:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0S4ZFw21336 for ietf-provreg-outgoing; Sun, 28 Jan 2001 05:35:15 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0S4ZEA21331 for ; Sun, 28 Jan 2001 05:35:14 +0100 (MET) Received: from 207-172-149-91.s28.as5.anp.md.dialup.rcn.com ([207.172.149.91]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14MjYM-0004h4-00 ; Sat, 27 Jan 2001 23:35:02 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200101280429.f0S4T8n23559@nic-naa.net> References: Your message of "Thu, 25 Jan 2001 09:25:18 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jan 2001 23:32:37 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0S4Tvq21292 for ietf-provreg-outgoing; Sun, 28 Jan 2001 05:29:57 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0S4TuA21287 for ; Sun, 28 Jan 2001 05:29:56 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0S4T8n23559; Sat, 27 Jan 2001 23:29:08 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101280429.f0S4T8n23559@nic-naa.net> To: Edward Lewis cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Thu, 25 Jan 2001 09:25:18 EST." Date: Sat, 27 Jan 2001 23:29:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk >> 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? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0R0SEO09660 for ietf-provreg-outgoing; Sat, 27 Jan 2001 01:28:14 +0100 (MET) Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0R0SDA09655 for ; Sat, 27 Jan 2001 01:28:13 +0100 (MET) Received: from vulcan (1Cust144.tnt7.redmond.wa.da.uu.net [63.23.205.144]) by falcon.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA14585; Fri, 26 Jan 2001 16:28:09 -0800 (PST) Message-ID: <002401c087f7$ed394840$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: , References: <200101261737.f0QHb3h12444@zed.isi.edu> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 16:27:25 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f0R0SEA09656 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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, foo@bar.com information is handled by NSI. foo@bar.newtld 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 chris@the.web Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKTCB07149 for ietf-provreg-outgoing; Fri, 26 Jan 2001 21:29:12 +0100 (MET) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QKTBA07144 for ; Fri, 26 Jan 2001 21:29:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKSW000564 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 21:28:32 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QHqnA05395 for ; Fri, 26 Jan 2001 18:52:49 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA00939; Fri, 26 Jan 2001 18:52:44 +0100 (CET) Date: Fri, 26 Jan 2001 18:52:43 +0100 (CET) From: Shane Kerr To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010126120738.B4948@register.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? 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 Database Software Engineer RIPE NCC +31 20 535 4427 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKT5307133 for ietf-provreg-outgoing; Fri, 26 Jan 2001 21:29:05 +0100 (MET) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QKT3A07128 for ; Fri, 26 Jan 2001 21:29:03 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKSO700552 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 21:28:24 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QHcRA05261 for ; Fri, 26 Jan 2001 18:38:28 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0QHcQU29106; Fri, 26 Jan 2001 09:38:26 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0QHb3h12444; Fri, 26 Jan 2001 09:37:03 -0800 Message-Id: <200101261737.f0QHb3h12444@zed.isi.edu> Subject: Re: Merging RRP and Whois To: george@register.com (George Belotsky) Date: Fri, 26 Jan 2001 09:37:03 -0800 (PST) Cc: ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <20010126120738.B4948@register.com> from "George Belotsky" at Jan 26, 2001 12:07:38 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKSjk07112 for ietf-provreg-outgoing; Fri, 26 Jan 2001 21:28:45 +0100 (MET) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QKSdA07095 for ; Fri, 26 Jan 2001 21:28:39 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKS0B00520 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 21:28:00 +0100 (MET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QFCkA03703 for ; Fri, 26 Jan 2001 16:12:46 +0100 (MET) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id QAA29363; Fri, 26 Jan 2001 16:11:02 +0100 (CET) Date: Fri, 26 Jan 2001 16:11:02 +0100 (CET) From: Shane Kerr To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101232157.f0NLv1n06510@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Database Software Engineer RIPE NCC +31 20 535 4427 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKShp07100 for ietf-provreg-outgoing; Fri, 26 Jan 2001 21:28:43 +0100 (MET) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QKSVA07093 for ; Fri, 26 Jan 2001 21:28:31 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QKRpk00508 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 21:27:51 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QDbSA02761 for ; Fri, 26 Jan 2001 14:37:28 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0QDaMn14835; Fri, 26 Jan 2001 08:36:22 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101261336.f0QDaMn14835@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Fri, 26 Jan 2001 15:11:14 +0800." <008301c08767$2d55c1b0$4d272dd4@jamessonyvaio> Date: Fri, 26 Jan 2001 08:36:22 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QJudZ06735 for ietf-provreg-outgoing; Fri, 26 Jan 2001 20:56:39 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QJucA06730 for ; Fri, 26 Jan 2001 20:56:39 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14MEz6-0005n5-00; Fri, 26 Jan 2001 14:56:36 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 26 Jan 2001 14:56:36 -0500 Date: Fri, 26 Jan 2001 14:56:36 -0500 From: George Belotsky To: Shane Kerr Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010126145636.B7740@register.com> References: <20010126120738.B4948@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shane@ripe.net on Fri, Jan 26, 2001 at 06:52:43PM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? > > 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 > Database Software Engineer > RIPE NCC > +31 20 535 4427 > > > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QH7fX04967 for ietf-provreg-outgoing; Fri, 26 Jan 2001 18:07:41 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QH7eA04962 for ; Fri, 26 Jan 2001 18:07:40 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14MCLa-0005L1-00; Fri, 26 Jan 2001 12:07:38 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 26 Jan 2001 12:07:38 -0500 Date: Fri, 26 Jan 2001 12:07:38 -0500 From: George Belotsky To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010126120738.B4948@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAKIb00483 for ietf-provreg-outgoing; Fri, 26 Jan 2001 11:20:18 +0100 (MET) Received: from naptop.autonomica.se (dhcp221.ripemtg.ripe.net [193.0.4.221]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QAKGA00478 for ; Fri, 26 Jan 2001 11:20:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAJaV00592 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 11:19:36 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0Q7CkA29190 for ; Fri, 26 Jan 2001 08:12:47 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.77]) by mail.i-dns.net (Postfix) with SMTP id C06D5FFC04; Fri, 26 Jan 2001 15:12:32 +0800 (SGT) Message-ID: <008301c08767$2d55c1b0$4d272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , References: <200101260158.f0Q1wSn13418@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 15:11:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAJFj00459 for ietf-provreg-outgoing; Fri, 26 Jan 2001 11:19:15 +0100 (MET) Received: from naptop.autonomica.se (dhcp221.ripemtg.ripe.net [193.0.4.221]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QAJEA00454 for ; Fri, 26 Jan 2001 11:19:14 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAIZn00555 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 11:18:35 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0Q1xPA27111 for ; Fri, 26 Jan 2001 02:59:25 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0Q1wSn13418; Thu, 25 Jan 2001 20:58:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101260158.f0Q1wSn13418@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Fri, 26 Jan 2001 06:54:49 +0800." <02c701c08721$d4c1e000$32272dd4@jamessonyvaio> Date: Thu, 25 Jan 2001 20:58:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAIf700440 for ietf-provreg-outgoing; Fri, 26 Jan 2001 11:18:41 +0100 (MET) Received: from naptop.autonomica.se (dhcp221.ripemtg.ripe.net [193.0.4.221]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0QAIZA00435 for ; Fri, 26 Jan 2001 11:18:35 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0QAHtO00531 for ietf-provreg@cafax.se; Fri, 26 Jan 2001 11:17:55 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PJEoA23962 for ; Thu, 25 Jan 2001 20:14:50 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0PJDpn12632; Thu, 25 Jan 2001 14:13:51 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101251913.f0PJDpn12632@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Fri, 26 Jan 2001 01:43:02 +0800." <003701c086f6$46260ef0$32272dd4@jamessonyvaio> Date: Thu, 25 Jan 2001 14:13:51 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > If you are having a private conversation with Patrik then please do it > offline. See Message-Id: > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PNJhr26234 for ietf-provreg-outgoing; Fri, 26 Jan 2001 00:19:43 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PNJgA26229 for ; Fri, 26 Jan 2001 00:19:42 +0100 (MET) Received: from pentium3 (ppp24d.dialin.elga.net.id [202.173.64.152]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id SAA20445; Thu, 25 Jan 2001 18:00:20 -0600 Message-Id: <200101260000.SAA20445@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Fri, 26 Jan 2001 06:22:39 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Merging RRP and Whois CC: In-reply-to: <003701c086f6$46260ef0$32272dd4@jamessonyvaio> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PMuNb25942 for ietf-provreg-outgoing; Thu, 25 Jan 2001 23:56:23 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PMuLA25937 for ; Thu, 25 Jan 2001 23:56:22 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.40.32]) by mail.i-dns.net (Postfix) with SMTP id CB5F2FFC04; Fri, 26 Jan 2001 06:56:08 +0800 (SGT) Message-ID: <02c701c08721$d4c1e000$32272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: , References: <200101251913.f0PJDpn12632@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 06:54:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PHioH22706 for ietf-provreg-outgoing; Thu, 25 Jan 2001 18:44:50 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PHicA22701 for ; Thu, 25 Jan 2001 18:44:45 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.50]) by mail.i-dns.net (Postfix) with SMTP id B2605FFC04; Fri, 26 Jan 2001 01:44:21 +0800 (SGT) Message-ID: <003701c086f6$46260ef0$32272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: , References: <200101251453.f0PErbn12099@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 01:43:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PFgTS20488 for ietf-provreg-outgoing; Thu, 25 Jan 2001 16:42:29 +0100 (MET) Received: from naptop.pilsnet.sunet.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PFgCA20479 for ; Thu, 25 Jan 2001 16:42:13 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0PFfXM02209 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 16:41:33 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PEt6A19437 for ; Thu, 25 Jan 2001 15:55:06 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0PErbn12099; Thu, 25 Jan 2001 09:53:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101251453.f0PErbn12099@nic-naa.net> To: "James Seng" cc: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Eric Brunner-Williams in Portland Maine" , "George Belotsky" , "Paul George" , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Thu, 25 Jan 2001 13:10:52 +0800." <0b2401c0868d$33fe04d0$06272dd4@jamessonyvaio> Date: Thu, 25 Jan 2001 09:53:37 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PEYRo19010 for ietf-provreg-outgoing; Thu, 25 Jan 2001 15:34:27 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PEYPA19001 for ; Thu, 25 Jan 2001 15:34:26 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA02307; Thu, 25 Jan 2001 09:37:39 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma002303; Thu, 25 Jan 01 09:37:33 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200101240243.f0O2h2n07024@nic-naa.net> References: Your message of "Wed, 24 Jan 2001 06:54:47 +0800." <04cf01c0858f$7eed1ca0$06272dd4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 25 Jan 2001 09:25:18 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: ietf-provreg@cafax.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f0PEYQA19003 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Jaap Akkerhuis APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: Patrik Fältström MAILING LISTS: General Discussion: ietf-provreg@cafax.se To Subscribe: majordomo@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ DESCRIPTION OF WORKING GROUP: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models. This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0PBNtg14998 for ietf-provreg-outgoing; Thu, 25 Jan 2001 12:23:55 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0PBNsA14993 for ; Thu, 25 Jan 2001 12:23:54 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA09126; Thu, 25 Jan 2001 12:23:53 +0100 Date: Thu, 25 Jan 2001 12:23:53 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: open RRP implementations Message-ID: <20010125122353.B8709@nohope.patoche.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from ross@tucows.com on Wed, Jan 24, 2001 at 02:56:14PM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P9AXO11545 for ietf-provreg-outgoing; Thu, 25 Jan 2001 10:10:33 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P9AVA11540 for ; Thu, 25 Jan 2001 10:10:32 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P99ok01237 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 10:09:50 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P5CQA08839 for ; Thu, 25 Jan 2001 06:12:26 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.146]) by mail.i-dns.net (Postfix) with SMTP id 85026FFC09; Thu, 25 Jan 2001 13:12:12 +0800 (SGT) Message-ID: <0b2401c0868d$33fe04d0$06272dd4@jamessonyvaio> From: "James Seng" To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Eric Brunner-Williams in Portland Maine" Cc: "George Belotsky" , "Paul George" , , , References: <200101242020.f0OKK1n09745@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 13:10:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P98gG11499 for ietf-provreg-outgoing; Thu, 25 Jan 2001 10:08:42 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P98gA11494 for ; Thu, 25 Jan 2001 10:08:42 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P984K01201 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 10:08:04 +0100 (MET) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OKuQA04023 for ; Wed, 24 Jan 2001 21:56:26 +0100 (MET) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LWxp-0002xO-00; Wed, 24 Jan 2001 21:56:21 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Paul George" Cc: , Subject: RE: Merging RRP and Whois References: Message-Id: Date: Wed, 24 Jan 2001 21:56:21 +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P98Yq11480 for ietf-provreg-outgoing; Thu, 25 Jan 2001 10:08:34 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P98XA11475 for ; Thu, 25 Jan 2001 10:08:33 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P97t401189 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 10:07:55 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OKLKA03631 for ; Wed, 24 Jan 2001 21:21:20 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0OKK1n09745; Wed, 24 Jan 2001 15:20:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101242020.f0OKK1n09745@nic-naa.net> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: George Belotsky , Paul George , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Wed, 24 Jan 2001 19:25:11 +0100." Date: Wed, 24 Jan 2001 15:20:01 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P92AQ11417 for ietf-provreg-outgoing; Thu, 25 Jan 2001 10:02:10 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P924A11410 for ; Thu, 25 Jan 2001 10:02:04 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P91M601053 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 10:01:22 +0100 (MET) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OGV4A00762 for ; Wed, 24 Jan 2001 17:31:04 +0100 (MET) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LSoy-0002u0-00; Wed, 24 Jan 2001 17:30:56 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Paul George" Cc: , Subject: RE: Merging RRP and Whois References: <20010124111158.J24903@register.com> Message-Id: Date: Wed, 24 Jan 2001 17:30:56 +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8ZDO10982 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:35:13 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8ZBA10977 for ; Thu, 25 Jan 2001 09:35:11 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8YYl00583 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:34:34 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0O2iBA23561 for ; Wed, 24 Jan 2001 03:44:12 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0O2h2n07024; Tue, 23 Jan 2001 21:43:02 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101240243.f0O2h2n07024@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Wed, 24 Jan 2001 06:54:47 +0800." <04cf01c0858f$7eed1ca0$06272dd4@jamessonyvaio> Date: Tue, 23 Jan 2001 21:43:02 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8YRY10929 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:34:27 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8YQA10922 for ; Thu, 25 Jan 2001 09:34:26 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8XmO00539 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:33:48 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NLwCA19913 for ; Tue, 23 Jan 2001 22:58:12 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NLv1n06510; Tue, 23 Jan 2001 16:57:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232157.f0NLv1n06510@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: Karl Auerbach , George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 16:00:02 EST." <200101232100.f0NL02n06389@nic-naa.net> Date: Tue, 23 Jan 2001 16:57:01 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8YPw10913 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:34:25 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8YJA10908 for ; Thu, 25 Jan 2001 09:34:19 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8XgR00523 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:33:42 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NLHJA19475 for ; Tue, 23 Jan 2001 22:17:20 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id 936CDFFC01; Wed, 24 Jan 2001 05:17:07 +0800 (SGT) Message-ID: <028601c08581$a9baa230$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Karl Auerbach" , "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "George Belotsky" , , References: <200101232100.f0NL02n06389@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 05:15:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8YBH10897 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:34:11 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8Y9A10892 for ; Thu, 25 Jan 2001 09:34:10 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8XWs00515 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:33:32 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NL1BA19259 for ; Tue, 23 Jan 2001 22:01:11 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NL02n06389; Tue, 23 Jan 2001 16:00:02 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232100.f0NL02n06389@nic-naa.net> To: Karl Auerbach cc: Eric Brunner-Williams in Portland Maine , George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 12:38:50 PST." Date: Tue, 23 Jan 2001 16:00:02 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8Y5O10881 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:34:05 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8Y5A10876 for ; Thu, 25 Jan 2001 09:34:05 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8XRf00507 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:33:27 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NKVYA18840 for ; Tue, 23 Jan 2001 21:31:34 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NKUSn06310; Tue, 23 Jan 2001 15:30:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101232030.f0NKUSn06310@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 13:18:55 EST." <20010123131855.E24903@register.com> Date: Tue, 23 Jan 2001 15:30:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8Xlc10855 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:33:47 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8XgA10841 for ; Thu, 25 Jan 2001 09:33:42 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8X4b00465 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:33:04 +0100 (MET) Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NIEGA17417 for ; Tue, 23 Jan 2001 19:14:17 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id TAA26661 ; Tue, 23 Jan 2001 19:13:34 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0NIDEL17283; Tue, 23 Jan 2001 19:13:14 +0100 Date: Tue, 23 Jan 2001 19:13:14 +0100 From: Olivier Guillard / AFNIC To: George Belotsky Cc: ietf-provreg@cafax.se Subject: Re: Merging RRP and Whois Message-ID: <20010123191314.A17128@james.nic.fr> References: <20010122141511.C24633@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010122141511.C24633@register.com>; from george@register.com on Mon, Jan 22, 2001 at 02:15:11PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > george@register.com > 212-798-9127 (phone) > 212-798-9876 (fax) -- Olivier Guillard --- || A.F.N.I.C. || http://www.nic.fr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8XY110839 for ietf-provreg-outgoing; Thu, 25 Jan 2001 09:33:34 +0100 (MET) Received: from naptop.autonomica.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P8XSA10834 for ; Thu, 25 Jan 2001 09:33:28 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0P8Wot00453 for ietf-provreg@cafax.se; Thu, 25 Jan 2001 09:32:50 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NHgbA17028 for ; Tue, 23 Jan 2001 18:42:37 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0NHfUn05975; Tue, 23 Jan 2001 12:41:30 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101231741.f0NHfUn05975@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Tue, 23 Jan 2001 11:32:09 EST." <20010123113209.C24903@register.com> Date: Tue, 23 Jan 2001 12:41:30 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0P51XH08714 for ietf-provreg-outgoing; Thu, 25 Jan 2001 06:01:33 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0P51VA08709 for ; Thu, 25 Jan 2001 06:01:32 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.146]) by mail.i-dns.net (Postfix) with SMTP id 2781BFFC01; Thu, 25 Jan 2001 13:01:18 +0800 (SGT) Message-ID: <0afa01c0868b$ad5aa970$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Jaap Akkerhuis" Cc: "George Belotsky" , "Paul George" , , References: <200101242013.VAA69987@bartok.sidn.nl> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 12:59:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OLxhD04658 for ietf-provreg-outgoing; Wed, 24 Jan 2001 22:59:43 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OLxfA04653 for ; Wed, 24 Jan 2001 22:59:42 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA11344; Wed, 24 Jan 2001 16:59:39 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 16:54:56 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Edward Lewis'" , "'ietf-provreg@cafax.se'" Subject: RE: Exentisibility in the requirements Date: Wed, 24 Jan 2001 16:54:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk FWIW there _is_ a section in the draft (section 7.5) describing extensibility requirements. -----Original Message----- From: Edward Lewis [mailto:lewis@tislabs.com] Sent: Wednesday, January 24, 2001 12:55 PM To: ietf-provreg@cafax.se Cc: lewis@tislabs.com 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OKE5I03508 for ietf-provreg-outgoing; Wed, 24 Jan 2001 21:14:05 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaamjurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OKE5A03503 for ; Wed, 24 Jan 2001 21:14:05 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA24063; Wed, 24 Jan 2001 21:14:01 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA69987; Wed, 24 Jan 2001 21:13:56 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101242013.VAA69987@bartok.sidn.nl> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: George Belotsky , Paul George , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of Wed, 24 Jan 2001 19:25:11 +0100. Date: Wed, 24 Jan 2001 21:13:56 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OJtN403258 for ietf-provreg-outgoing; Wed, 24 Jan 2001 20:55:23 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OJtMA03253 for ; Wed, 24 Jan 2001 20:55:23 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14LVzv-00041R-00; Wed, 24 Jan 2001 14:54:27 -0500 Reply-To: From: "Ross Wm. Rader" To: , "George Belotsky" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul George" Cc: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 14:56:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of Ross Wm. Rader < Sent: Wednesday, January 24, 2001 2:50 PM < To: George Belotsky; Patrik Fältström; Paul George < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < 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: owner-ietf-whois@mail.imc.org < < [mailto:owner-ietf-whois@mail.imc.org]On Behalf Of George Belotsky < < Sent: Wednesday, January 24, 2001 2:00 PM < < To: Patrik Fältström; Paul George < < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < < 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 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. < george@register.com < 212-798-9127 (phone) < 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OJncE03168 for ietf-provreg-outgoing; Wed, 24 Jan 2001 20:49:38 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OJnbA03163 for ; Wed, 24 Jan 2001 20:49:37 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14LVuH-0003lb-00; Wed, 24 Jan 2001 14:48:37 -0500 Reply-To: From: "Ross Wm. Rader" To: "George Belotsky" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul George" Cc: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 14:50:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010124135935.O24903@register.com> Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-whois@mail.imc.org < [mailto:owner-ietf-whois@mail.imc.org]On Behalf Of George Belotsky < Sent: Wednesday, January 24, 2001 2:00 PM < To: Patrik Fältström; Paul George < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < 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 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. < george@register.com < 212-798-9127 (phone) < 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OIxfn02720 for ietf-provreg-outgoing; Wed, 24 Jan 2001 19:59:41 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OIxeA02715 for ; Wed, 24 Jan 2001 19:59:40 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LV8p-0002mf-00; Wed, 24 Jan 2001 13:59:35 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 13:59:35 -0500 Date: Wed, 24 Jan 2001 13:59:35 -0500 From: George Belotsky To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul George Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124135935.O24903@register.com> References: <20010124123722.L24903@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from paf@cisco.com on Wed, Jan 24, 2001 at 07:25:11PM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OIkIg02531 for ietf-provreg-outgoing; Wed, 24 Jan 2001 19:46:18 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OIkHA02526 for ; Wed, 24 Jan 2001 19:46:18 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LUvx-0006Ni-00; Wed, 24 Jan 2001 13:46:17 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 13:46:16 -0500 Date: Wed, 24 Jan 2001 13:46:16 -0500 From: George Belotsky To: Edward Lewis Cc: ietf-provreg@cafax.se Subject: Re: Exentisibility in the requirements Message-ID: <20010124134616.N24903@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Wed, Jan 24, 2001 at 12:55:09PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OIcIA02396 for ietf-provreg-outgoing; Wed, 24 Jan 2001 19:38:18 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OIcHA02391 for ; Wed, 24 Jan 2001 19:38:17 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LUlj-0003EF-00; Wed, 24 Jan 2001 13:35:43 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 13:35:42 -0500 Date: Wed, 24 Jan 2001 13:35:42 -0500 From: George Belotsky To: Martin Oldfield Cc: Patrik Fdltstrvm , Edward Lewis , James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124133542.M24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> <20010124121938.K24903@register.com> <14959.4087.191697.458539@joanna.william.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14959.4087.191697.458539@joanna.william.org>; from m@mail.tc on Wed, Jan 24, 2001 at 05:35:10PM +0000 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OIWcS02307 for ietf-provreg-outgoing; Wed, 24 Jan 2001 19:32:38 +0100 (MET) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OIWbA02302 for ; Wed, 24 Jan 2001 19:32:37 +0100 (MET) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA02945; Wed, 24 Jan 2001 10:32:28 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0OIWO405755; Wed, 24 Jan 2001 10:32:24 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA25772; Wed, 24 Jan 2001 10:32:12 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010124123722.L24903@register.com> References: <20010124123722.L24903@register.com> Date: Wed, 24 Jan 2001 19:25:11 +0100 To: George Belotsky , Paul George From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Merging RRP and Whois Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OHwGL01884 for ietf-provreg-outgoing; Wed, 24 Jan 2001 18:58:16 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OHwGA01879 for ; Wed, 24 Jan 2001 18:58:16 +0100 (MET) Received: by sentry.gw.tislabs.com; id NAA18981; Wed, 24 Jan 2001 13:01:29 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xmab18969; Wed, 24 Jan 01 13:01:03 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jan 2001 12:55:09 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Exentisibility in the requirements Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OHbTp01664 for ietf-provreg-outgoing; Wed, 24 Jan 2001 18:37:29 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OHbSA01659 for ; Wed, 24 Jan 2001 18:37:29 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LTrG-00065N-00; Wed, 24 Jan 2001 12:37:22 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 12:37:22 -0500 Date: Wed, 24 Jan 2001 12:37:22 -0500 From: George Belotsky To: Paul George Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124123722.L24903@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pgeorge@saraf.com on Wed, Jan 24, 2001 at 11:39:16AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:randy@psg.com] > Sent: Wednesday, January 24, 2001 11:31 AM > To: Paul George > Cc: ietf-provreg@cafax.se; ietf-whois@imc.org > 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OHafK01633 for ietf-provreg-outgoing; Wed, 24 Jan 2001 18:36:41 +0100 (MET) Received: from joanna.william.org (joanna.william.org [195.153.6.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OHacA01628 for ; Wed, 24 Jan 2001 18:36:39 +0100 (MET) Received: from mjo by joanna.william.org with local (Exim 3.16 #1) id 14LTp8-0007YE-00 (Debian); Wed, 24 Jan 2001 17:35:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Jan 2001 17:35:10 +0000 (GMT) To: George Belotsky Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Edward Lewis , James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010124121938.K24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> <20010124121938.K24903@register.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14959.4087.191697.458539@joanna.william.org> From: Martin Oldfield Sender: owner-ietf-provreg@cafax.se Precedence: bulk >>>>> "George" == George Belotsky 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OHKiq01401 for ietf-provreg-outgoing; Wed, 24 Jan 2001 18:20:44 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OHKhA01396 for ; Wed, 24 Jan 2001 18:20:43 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LTa6-0003qz-00; Wed, 24 Jan 2001 12:19:38 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 12:19:38 -0500 Date: Wed, 24 Jan 2001 12:19:38 -0500 From: George Belotsky To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Edward Lewis , James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124121938.K24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from paf@cisco.com on Wed, Jan 24, 2001 at 05:18:53PM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OGdK600881 for ietf-provreg-outgoing; Wed, 24 Jan 2001 17:39:20 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0OGdJA00876 for ; Wed, 24 Jan 2001 17:39:19 +0100 (MET) Received: (qmail 23612 invoked from network); 24 Jan 2001 16:42:07 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 24 Jan 2001 16:42:07 -0000 From: "Paul George" To: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 11:39:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:randy@psg.com] Sent: Wednesday, January 24, 2001 11:31 AM To: Paul George Cc: ietf-provreg@cafax.se; ietf-whois@imc.org 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OGMex00677 for ietf-provreg-outgoing; Wed, 24 Jan 2001 17:22:40 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0OGMdA00672 for ; Wed, 24 Jan 2001 17:22:39 +0100 (MET) Received: (qmail 23244 invoked from network); 24 Jan 2001 16:25:27 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 24 Jan 2001 16:25:27 -0000 From: "Paul George" To: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 11:22:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010124111158.J24903@register.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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; ietf-provreg@cafax.se; ietf-whois@imc.org 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: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OGJvh00607 for ietf-provreg-outgoing; Wed, 24 Jan 2001 17:19:57 +0100 (MET) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OGJuA00602 for ; Wed, 24 Jan 2001 17:19:56 +0100 (MET) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08711; Wed, 24 Jan 2001 08:19:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0OGJAI02136; Wed, 24 Jan 2001 08:19:10 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA21546; Wed, 24 Jan 2001 08:18:57 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010124111158.J24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> Date: Wed, 24 Jan 2001 17:18:53 +0100 To: George Belotsky , Edward Lewis From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Merging RRP and Whois Cc: James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OGChW00505 for ietf-provreg-outgoing; Wed, 24 Jan 2001 17:12:43 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OGCgA00499 for ; Wed, 24 Jan 2001 17:12:43 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LSWd-00057p-00; Wed, 24 Jan 2001 11:11:59 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 11:11:58 -0500 Date: Wed, 24 Jan 2001 11:11:58 -0500 From: George Belotsky To: Edward Lewis Cc: James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124111158.J24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Wed, Jan 24, 2001 at 09:34:32AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0OEg7029238 for ietf-provreg-outgoing; Wed, 24 Jan 2001 15:42:07 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0OEg3A29233 for ; Wed, 24 Jan 2001 15:42:03 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA15669; Wed, 24 Jan 2001 09:45:08 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma015659; Wed, 24 Jan 01 09:44:44 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> References: <200101240243.f0O2h2n07024@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jan 2001 09:34:32 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , , Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0O4b0T24406 for ietf-provreg-outgoing; Wed, 24 Jan 2001 05:37:00 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0O4awA24399 for ; Wed, 24 Jan 2001 05:36:58 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.225]) by mail.i-dns.net (Postfix) with SMTP id 65316FFC0D; Wed, 24 Jan 2001 12:36:44 +0800 (SGT) Message-ID: <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: "Eric Brunner-Williams in Portland Maine" , "Karl Auerbach" , "George Belotsky" , , References: <200101240243.f0O2h2n07024@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 12:35:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NMuVX20604 for ietf-provreg-outgoing; Tue, 23 Jan 2001 23:56:31 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NMuSA20599 for ; Tue, 23 Jan 2001 23:56:29 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id BEC99FFC07; Wed, 24 Jan 2001 06:56:08 +0800 (SGT) Message-ID: <04cf01c0858f$7eed1ca0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: "Karl Auerbach" , "George Belotsky" , , , References: <200101232157.f0NLv1n06510@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 06:54:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NKdEJ18939 for ietf-provreg-outgoing; Tue, 23 Jan 2001 21:39:14 +0100 (MET) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NKdDA18934 for ; Tue, 23 Jan 2001 21:39:13 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f0NKco803021; Tue, 23 Jan 2001 12:38:50 -0800 Date: Tue, 23 Jan 2001 12:38:50 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Eric Brunner-Williams in Portland Maine cc: George Belotsky , , Subject: Re: Merging RRP and Whois In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NK1tV18576 for ietf-provreg-outgoing; Tue, 23 Jan 2001 21:01:55 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NK1sA18571 for ; Tue, 23 Jan 2001 21:01:54 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA18032; Tue, 23 Jan 2001 21:01:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id VAA65853; Tue, 23 Jan 2001 21:01:39 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101232001.VAA65853@bartok.sidn.nl> To: Edward Lewis cc: George Belotsky , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of Tue, 23 Jan 2001 11:49:13 -0500. Date: Tue, 23 Jan 2001 21:01:39 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NIaE417723 for ietf-provreg-outgoing; Tue, 23 Jan 2001 19:36:14 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NIaDA17718 for ; Tue, 23 Jan 2001 19:36:13 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14L8I9-0006fO-00; Tue, 23 Jan 2001 13:35:41 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 13:35:40 -0500 Date: Tue, 23 Jan 2001 13:35:40 -0500 From: George Belotsky To: Olivier Guillard / AFNIC Cc: ietf-provreg@cafax.se Subject: Re: Merging RRP and Whois Message-ID: <20010123133540.F24903@register.com> References: <20010122141511.C24633@register.com> <20010123191314.A17128@james.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010123191314.A17128@james.nic.fr>; from guillard@nic.fr on Tue, Jan 23, 2001 at 07:13:14PM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > > george@register.com > > 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NIJ4W17474 for ietf-provreg-outgoing; Tue, 23 Jan 2001 19:19:04 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NIJ3A17469 for ; Tue, 23 Jan 2001 19:19:03 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14L81v-0003Cp-00; Tue, 23 Jan 2001 13:18:55 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 13:18:55 -0500 Date: Tue, 23 Jan 2001 13:18:55 -0500 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123131855.E24903@register.com> References: <20010123113209.C24903@register.com> <200101231741.f0NHfUn05975@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101231741.f0NHfUn05975@nic-naa.net>; from brunner@nic-naa.net on Tue, Jan 23, 2001 at 12:41:30PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NGsnb04754 for ietf-provreg-outgoing; Tue, 23 Jan 2001 17:54:49 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NGslA04749 for ; Tue, 23 Jan 2001 17:54:47 +0100 (MET) Received: from jamessonyvaio (unknown [212.45.39.209]) by mail.i-dns.net (Postfix) with SMTP id 3344FFFC09; Wed, 24 Jan 2001 00:54:35 +0800 (SGT) Message-ID: <016401c0855c$fb401420$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "George Belotsky" , "Eric Brunner-Williams in Portland Maine" Cc: , References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> <20010123113209.C24903@register.com> Subject: Re: Merging RRP and Whois Date: Wed, 24 Jan 2001 00:53:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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" To: "Eric Brunner-Williams in Portland Maine" Cc: ; 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. > george@register.com > 212-798-9127 (phone) > 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NGqNg04709 for ietf-provreg-outgoing; Tue, 23 Jan 2001 17:52:23 +0100 (MET) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NGqMA04704 for ; Tue, 23 Jan 2001 17:52:22 +0100 (MET) Received: from 207-172-150-201.s10.as11.anp.md.dialup.rcn.com ([207.172.150.201] helo=[207.172.148.194]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14L6fu-0005zY-00 ; Tue, 23 Jan 2001 11:52:07 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: <20010123113209.C24903@register.com> References: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jan 2001 11:49:13 -0500 To: George Belotsky From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, ietf-whois@imc.org Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NGWJa04416 for ietf-provreg-outgoing; Tue, 23 Jan 2001 17:32:19 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NGWIA04411 for ; Tue, 23 Jan 2001 17:32:18 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14L6Mc-0001eI-00; Tue, 23 Jan 2001 11:32:10 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Tue, 23 Jan 2001 11:32:09 -0500 Date: Tue, 23 Jan 2001 11:32:09 -0500 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123113209.C24903@register.com> References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0NAKV200279 for ietf-provreg-outgoing; Tue, 23 Jan 2001 11:20:31 +0100 (MET) Received: from naptop.pilsnet.sunet.se (dhcp71.ripemtg.ripe.net [193.0.4.71]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0NAJCA00266 for ; Tue, 23 Jan 2001 11:19:12 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f0N9VbX01726 for ietf-provreg@cafax.se; Tue, 23 Jan 2001 10:31:37 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0MNCki23724 for ; Tue, 23 Jan 2001 00:12:49 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f0MNBZn03650; Mon, 22 Jan 2001 18:11:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101222311.f0MNBZn03650@nic-naa.net> To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Mon, 22 Jan 2001 14:15:11 EST." <20010122141511.C24633@register.com> Date: Mon, 22 Jan 2001 18:11:34 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0N6bLT27717 for ietf-provreg-outgoing; Tue, 23 Jan 2001 07:37:21 +0100 (MET) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0N6bLi27712 for ; Tue, 23 Jan 2001 07:37:21 +0100 (MET) Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.11.1/8.11.1) with ESMTP id f0N6bDU10926; Tue, 23 Jan 2001 07:37:13 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id f0N6ZsN20357; Tue, 23 Jan 2001 07:35:54 +0100 Date: Tue, 23 Jan 2001 07:35:53 +0100 From: Stig Venaas To: Eric Brunner-Williams in Portland Maine Cc: George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010123073553.A20344@sverresborg.uninett.no> References: <20010122141511.C24633@register.com> <200101222311.f0MNBZn03650@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200101222311.f0MNBZn03650@nic-naa.net>; from brunner@nic-naa.net on Mon, Jan 22, 2001 at 06:11:34PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0MK11c21736 for ietf-provreg-outgoing; Mon, 22 Jan 2001 21:01:01 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0MK10i21730 for ; Mon, 22 Jan 2001 21:01:00 +0100 (MET) Received: from 207-172-151-17.s17.as12.anp.md.dialup.rcn.com ([207.172.151.17]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Kn97-0007al-00 ; Mon, 22 Jan 2001 15:00:58 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: <20010122141511.C24633@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jan 2001 14:58:14 -0500 To: George Belotsky From: Edward Lewis Subject: Re: Merging RRP and Whois Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0MJFDK21234 for ietf-provreg-outgoing; Mon, 22 Jan 2001 20:15:13 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0MJFCi21229 for ; Mon, 22 Jan 2001 20:15:12 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14KmQp-0004GF-00 for ietf-provreg@cafax.se; Mon, 22 Jan 2001 14:15:11 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 22 Jan 2001 14:15:11 -0500 Date: Mon, 22 Jan 2001 14:15:11 -0500 From: George Belotsky To: ietf-provreg@cafax.se Subject: Merging RRP and Whois Message-ID: <20010122141511.C24633@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0MG5V419126 for ietf-provreg-outgoing; Mon, 22 Jan 2001 17:05:31 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0MG5Ui19121 for ; Mon, 22 Jan 2001 17:05:30 +0100 (MET) Received: from 207-172-148-156.s29.as2.anp.md.dialup.rcn.com ([207.172.148.156]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14KjTD-0005R0-00 ; Mon, 22 Jan 2001 11:05:27 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jan 2001 10:59:50 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: Meeting notice and other proto-WG items Cc: "'ietf-provreg@cafax.se'" , lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0MCDBm16693 for ietf-provreg-outgoing; Mon, 22 Jan 2001 13:13:11 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0MCD9i16688 for ; Mon, 22 Jan 2001 13:13:10 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA03669 for ; Mon, 22 Jan 2001 07:13:08 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 07:08:30 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: New Requirements Draft Available Date: Mon, 22 Jan 2001 07:08:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0M0emV10628 for ietf-provreg-outgoing; Mon, 22 Jan 2001 01:40:48 +0100 (MET) Received: from europe.std.com (europe.std.com [199.172.62.20]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0M0eli10623 for ; Mon, 22 Jan 2001 01:40:47 +0100 (MET) Received: from world.std.com (brunner@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id TAA12235; Sun, 21 Jan 2001 19:40:44 -0500 (EST) Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id TAA23151; Sun, 21 Jan 2001 19:40:41 -0500 (EST) Message-Id: <200101220040.TAA23151@world.std.com> X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol To: Edward Lewis cc: "'ietf-provreg@cafax.se'" , brunner@world.std.com Subject: Re: Meeting notice and other proto-WG items In-reply-to: Your message of "Sun, 21 Jan 2001 16:35:35 EST." Date: Sun, 21 Jan 2001 19:40:41 -0500 From: Eric Brunner Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0LMQ1B09762 for ietf-provreg-outgoing; Sun, 21 Jan 2001 23:26:01 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0LMQ0i09756 for ; Sun, 21 Jan 2001 23:26:00 +0100 (MET) Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id OAA16357; Sun, 21 Jan 2001 14:25:53 -0800 (PST) Date: Sun, 21 Jan 2001 14:25:53 -0800 (PST) From: Rick H Wesson To: Edward Lewis cc: "'ietf-provreg@cafax.se'" Subject: Re: Meeting notice and other proto-WG items In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0LLgbg09424 for ietf-provreg-outgoing; Sun, 21 Jan 2001 22:42:37 +0100 (MET) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0LLgZi09419 for ; Sun, 21 Jan 2001 22:42:36 +0100 (MET) Received: from 207-172-185-61.s61.as18.anp.md.dialup.rcn.com ([207.172.185.61]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14KSFs-00023V-00 ; Sun, 21 Jan 2001 16:42:32 -0500 X-Sender: lewis@192.94.214.100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 21 Jan 2001 16:35:35 -0500 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: Meeting notice and other proto-WG items Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JFtMu17322 for ietf-provreg-outgoing; Fri, 19 Jan 2001 16:55:22 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JFtLi17317 for ; Fri, 19 Jan 2001 16:55:21 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA00805 for ; Fri, 19 Jan 2001 10:45:24 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jan 2001 10:50:45 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Updated Requirements Draft Date: Fri, 19 Jan 2001 10:50:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JE8k816126 for ietf-provreg-outgoing; Fri, 19 Jan 2001 15:08:46 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JE8ji16121 for ; Fri, 19 Jan 2001 15:08:45 +0100 (MET) Received: from [172.16.1.10] (clemente [172.16.1.10]) by total.confusion.net (Postfix) with ESMTP id A6AB07AAC; Fri, 19 Jan 2001 09:08:43 -0500 (EST) Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <200101191322.OAA44525@bartok.sidn.nl> References: <200101191322.OAA44525@bartok.sidn.nl> Date: Fri, 19 Jan 2001 09:08:38 -0500 To: Jaap Akkerhuis , "Hollenbeck, Scott" From: "Jordyn A. Buchanan" Subject: Re: Why Interim Meetings? Cc: Dave Crocker , Edward Lewis , Ietf-Provreg Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JDqQn15950 for ietf-provreg-outgoing; Fri, 19 Jan 2001 14:52:26 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JDqQi15945 for ; Fri, 19 Jan 2001 14:52:26 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA07903; Fri, 19 Jan 2001 14:50:41 +0100 Date: Fri, 19 Jan 2001 14:50:41 +0100 From: Patrick To: Jaap Akkerhuis Cc: "Hollenbeck, Scott" , Dave Crocker , Edward Lewis , Ietf-Provreg Subject: Registries in need of new protocols... Message-ID: <20010119145041.G5954@nohope.patoche.org> References: <200101191322.OAA44525@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101191322.OAA44525@bartok.sidn.nl>; from jaap@sidn.nl on Fri, Jan 19, 2001 at 02:22:03PM +0100 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JDM6x15665 for ietf-provreg-outgoing; Fri, 19 Jan 2001 14:22:06 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JDM5i15659 for ; Fri, 19 Jan 2001 14:22:05 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id OAA94846; Fri, 19 Jan 2001 14:22:04 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id OAA44525; Fri, 19 Jan 2001 14:22:04 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101191322.OAA44525@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: Dave Crocker , Edward Lewis , Ietf-Provreg Subject: Re: Why Interim Meetings? In-reply-to: Your message of Fri, 19 Jan 2001 06:57:24 -0500. Date: Fri, 19 Jan 2001 14:22:03 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JC4NZ14945 for ietf-provreg-outgoing; Fri, 19 Jan 2001 13:04:23 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JC4Mi14940 for ; Fri, 19 Jan 2001 13:04:22 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA00086; Fri, 19 Jan 2001 06:54:26 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jan 2001 06:59:48 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Edward Lewis'" Cc: ietf-provreg@cafax.se Subject: RE: Moving ahead Date: Fri, 19 Jan 2001 06:59:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'll have an individual submission update sent to the I-D administrator later today. > -----Original Message----- > From: Edward Lewis [mailto:lewis@tislabs.com] > Sent: Thursday, January 18, 2001 8:25 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > 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. > > > > > > > >-----Original Message----- > >From: Paul George [mailto:pgeorge@saraf.com] > >Sent: Thursday, January 18, 2001 10:37 AM > >To: ietf-provreg@cafax.se > >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: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JC3GD14921 for ietf-provreg-outgoing; Fri, 19 Jan 2001 13:03:16 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JC3Fi14916 for ; Fri, 19 Jan 2001 13:03:15 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA00082; Fri, 19 Jan 2001 06:52:06 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jan 2001 06:57:28 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" , Dave Crocker Cc: Edward Lewis , Ietf-Provreg Subject: RE: Why Interim Meetings? Date: Fri, 19 Jan 2001 06:57:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > -----Original Message----- > From: Jaap Akkerhuis [mailto:jaap@sidn.nl] > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JALqg14268 for ietf-provreg-outgoing; Fri, 19 Jan 2001 11:21:52 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaamjurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JALqi14263 for ; Fri, 19 Jan 2001 11:21:52 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA93846; Fri, 19 Jan 2001 11:21:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA43654; Fri, 19 Jan 2001 11:21:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101191021.LAA43654@bartok.sidn.nl> To: Dave Crocker cc: Edward Lewis , Ietf-Provreg Subject: Re: Why Interim Meetings? In-reply-to: Your message of Thu, 18 Jan 2001 09:03:57 -0800. <5.1.0.4.2.20010118085048.01efac50@brandenburg.com> Date: Fri, 19 Jan 2001 11:21:51 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0JAEI214185 for ietf-provreg-outgoing; Fri, 19 Jan 2001 11:14:18 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0JAEGi14180 for ; Fri, 19 Jan 2001 11:14:17 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA93797; Fri, 19 Jan 2001 11:14:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA43605; Fri, 19 Jan 2001 11:14:15 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101191014.LAA43605@bartok.sidn.nl> To: Dave Crocker cc: Edward Lewis , Ietf-Provreg Subject: Re: Why Interim Meetings? In-reply-to: Your message of Thu, 18 Jan 2001 07:57:50 -0800. <5.1.0.4.2.20010118075550.06550730@brandenburg.com> Date: Fri, 19 Jan 2001 11:14:15 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0J1lh710074 for ietf-provreg-outgoing; Fri, 19 Jan 2001 02:47:43 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0J1lgi10069 for ; Fri, 19 Jan 2001 02:47:42 +0100 (MET) Received: by sentry.gw.tislabs.com; id UAA10560; Thu, 18 Jan 2001 20:50:54 -0500 (EST) Received: from dhcp32.gw.tislabs.com(192.94.214.132) by sentry.gw.tislabs.com via smap (V5.5) id xma010555; Thu, 18 Jan 01 20:50:19 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jan 2001 20:44:32 -0500 To: Edward Lewis From: Edward Lewis Subject: RE: Moving ahead Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0J1ReS09863 for ietf-provreg-outgoing; Fri, 19 Jan 2001 02:27:40 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0J1Rdi09858 for ; Fri, 19 Jan 2001 02:27:39 +0100 (MET) Received: by sentry.gw.tislabs.com; id UAA10248; Thu, 18 Jan 2001 20:30:51 -0500 (EST) Received: from dhcp32.gw.tislabs.com(192.94.214.132) by sentry.gw.tislabs.com via smap (V5.5) id xma010244; Thu, 18 Jan 01 20:30:25 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jan 2001 20:24:57 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: Moving ahead Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > > > >-----Original Message----- >From: Paul George [mailto:pgeorge@saraf.com] >Sent: Thursday, January 18, 2001 10:37 AM >To: ietf-provreg@cafax.se >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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0IImpI05407 for ietf-provreg-outgoing; Thu, 18 Jan 2001 19:48:51 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0IImoi05402 for ; Thu, 18 Jan 2001 19:48:50 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA28975 for ; Thu, 18 Jan 2001 13:38:56 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jan 2001 13:44:17 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Moving ahead Date: Thu, 18 Jan 2001 13:44:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. -----Original Message----- From: Paul George [mailto:pgeorge@saraf.com] Sent: Thursday, January 18, 2001 10:37 AM To: ietf-provreg@cafax.se 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0IH46x04225 for ietf-provreg-outgoing; Thu, 18 Jan 2001 18:04:06 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0IH45i04218 for ; Thu, 18 Jan 2001 18:04:05 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id JAA00429; Thu, 18 Jan 2001 09:03:40 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.4.2.20010118085048.01efac50@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Thu, 18 Jan 2001 09:03:57 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Why Interim Meetings? Cc: Edward Lewis , Ietf-Provreg In-Reply-To: References: <5.1.0.4.2.20010118075550.06550730@brandenburg.com> <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0IGifN03999 for ietf-provreg-outgoing; Thu, 18 Jan 2001 17:44:41 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0IGidi03994 for ; Thu, 18 Jan 2001 17:44:40 +0100 (MET) Received: by sentry.gw.tislabs.com; id LAA02249; Thu, 18 Jan 2001 11:47:51 -0500 (EST) Received: from dhcp26.gw.tislabs.com(192.94.214.126) by sentry.gw.tislabs.com via smap (V5.5) id xma002228; Thu, 18 Jan 01 11:46:52 -0500 X-Sender: lewis@192.94.214.100 Message-Id: In-Reply-To: <5.1.0.4.2.20010118075550.06550730@brandenburg.com> References: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jan 2001 11:41:17 -0500 To: Dave Crocker From: Edward Lewis Subject: Re: Why Interim Meetings? Cc: Edward Lewis , Ietf-Provreg Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0IGHHW03686 for ietf-provreg-outgoing; Thu, 18 Jan 2001 17:17:17 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0IGHGi03681 for ; Thu, 18 Jan 2001 17:17:16 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id IAA31851; Thu, 18 Jan 2001 08:17:13 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.4.2.20010118075550.06550730@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Thu, 18 Jan 2001 07:57:50 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Why Interim Meetings? Cc: Ietf-Provreg In-Reply-To: References: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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/ Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0IFbJM03306 for ietf-provreg-outgoing; Thu, 18 Jan 2001 16:37:19 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0IFbHi03301 for ; Thu, 18 Jan 2001 16:37:19 +0100 (MET) Received: (qmail 7835 invoked from network); 18 Jan 2001 15:39:41 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 18 Jan 2001 15:39:41 -0000 From: "Paul George" To: Subject: Moving ahead Date: Thu, 18 Jan 2001 10:37:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0FGR4B16752 for ietf-provreg-outgoing; Mon, 15 Jan 2001 17:27:04 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0FGQti16747 for ; Mon, 15 Jan 2001 17:26:55 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id RAA30633 ; Mon, 15 Jan 2001 17:26:36 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0FGQ4R28752; Mon, 15 Jan 2001 17:26:04 +0100 Date: Mon, 15 Jan 2001 17:26:04 +0100 From: Olivier Guillard / AFNIC To: ietf-provreg@cafax.se, budi@alliance.globalnetlink.com Subject: Re: Technical (was: security, authorization, definition, etc.) Message-ID: <20010115172604.B20143@james.nic.fr> References: ; <20010110174941.E19336@james.nic.fr> <200101102255.QAA23118@alliance.globalnetlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200101102255.QAA23118@alliance.globalnetlink.com>; from budi@alliance.globalnetlink.com on Thu, Jan 11, 2001 at 05:22:49AM +0700 Sender: owner-ietf-provreg@cafax.se Precedence: bulk le 11 Jan, budi@alliance.globalnetlink.com 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:guillard@nic.fr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0F8bKm12417 for ietf-provreg-outgoing; Mon, 15 Jan 2001 09:37:20 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0F8bCi12412 for ; Mon, 15 Jan 2001 09:37:12 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0F8anO00452 for ietf-provreg@cafax.se; Mon, 15 Jan 2001 09:36:49 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0D7Kgi24703 for ; Sat, 13 Jan 2001 08:20:43 +0100 (MET) Received: from DCROCKER.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA27168; Fri, 12 Jan 2001 23:20:39 -0800 Message-Id: <5.1.0.4.2.20010112231702.01ec84c8@brandenburg.songbird.com> X-Sender: dcrocker@brandenburg.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Fri, 12 Jan 2001 23:20:17 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Why Interim Meetings? Cc: Ietf-Provreg , lewis@tislabs.com In-Reply-To: References: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0EMdM708211 for ietf-provreg-outgoing; Sun, 14 Jan 2001 23:39:22 +0100 (MET) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0EMdIi08206 for ; Sun, 14 Jan 2001 23:39:18 +0100 (MET) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f0EMl9d73977; Sun, 14 Jan 2001 17:47:09 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010114163142.03ca9cc0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 14 Jan 2001 16:32:20 -0500 To: Elisabeth Porteneuve , ietf-provreg@cafax.se From: Marc Blanchet Subject: Re: Why Interim Meetings? Cc: lewis@tislabs.com In-Reply-To: <200101130748.IAA19391@balsa.cetp.ipsl.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 owner-ietf-provreg@cafax.se Sat Jan 13 00:12 MET 2001 > > X-Sender: lewis@pop.gw.tislabs.com > > Message-Id: > > Date: Fri, 12 Jan 2001 18:04:42 -0500 > > To: Ietf-Provreg > > From: Edward Lewis > > Subject: Why Interim Meetings? > > Cc: lewis@tislabs.com > > > > 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: lewis@tislabs.com > > > > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0D7mtw24837 for ietf-provreg-outgoing; Sat, 13 Jan 2001 08:48:55 +0100 (MET) Received: from balsa.cetp.ipsl.fr (balsa.cetp.ipsl.fr [193.52.172.32]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0D7msi24832 for ; Sat, 13 Jan 2001 08:48:54 +0100 (MET) Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id IAA19391; Sat, 13 Jan 2001 08:48:52 +0100 (MET) Date: Sat, 13 Jan 2001 08:48:52 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200101130748.IAA19391@balsa.cetp.ipsl.fr> To: ietf-provreg@cafax.se Cc: lewis@tislabs.com Subject: Re: Why Interim Meetings? Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 owner-ietf-provreg@cafax.se Sat Jan 13 00:12 MET 2001 > X-Sender: lewis@pop.gw.tislabs.com > Message-Id: > Date: Fri, 12 Jan 2001 18:04:42 -0500 > To: Ietf-Provreg > From: Edward Lewis > Subject: Why Interim Meetings? > Cc: lewis@tislabs.com > > 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: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0D0NI721561 for ietf-provreg-outgoing; Sat, 13 Jan 2001 01:23:18 +0100 (MET) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0D0NGi21556 for ; Sat, 13 Jan 2001 01:23:17 +0100 (MET) Received: from CLASSIC.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f0D0Utd52332; Fri, 12 Jan 2001 19:30:56 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010112192248.03b09d48@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 19:24:05 -0500 To: Edward Lewis , Ietf-Provreg From: Marc Blanchet Subject: Re: Why Interim Meetings? Cc: lewis@tislabs.com In-Reply-To: References: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > >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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CN86R20961 for ietf-provreg-outgoing; Sat, 13 Jan 2001 00:08:06 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CN85i20956 for ; Sat, 13 Jan 2001 00:08:05 +0100 (MET) Received: by sentry.gw.tislabs.com; id SAA00248; Fri, 12 Jan 2001 18:11:13 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma000246; Fri, 12 Jan 01 18:10:20 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> References: <5.0.2.1.0.20010111174840.018c2340@mail.register.com> <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Jan 2001 18:04:42 -0500 To: Ietf-Provreg From: Edward Lewis Subject: Why Interim Meetings? Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CKkpZ19664 for ietf-provreg-outgoing; Fri, 12 Jan 2001 21:46:51 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CKkoi19659 for ; Fri, 12 Jan 2001 21:46:50 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA18892; Fri, 12 Jan 2001 15:36:22 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 15:41:57 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" Cc: ietf-provreg@cafax.se Subject: RE: Some more comments on your grrp-reqs-05.txt (second try) Date: Fri, 12 Jan 2001 15:41:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. -----Original Message----- From: Jaap Akkerhuis [mailto:jaap@sidn.nl] Sent: Friday, January 12, 2001 9:49 AM To: Hollenbeck, Scott Cc: ietf-provreg@cafax.se 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)? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CKgef19559 for ietf-provreg-outgoing; Fri, 12 Jan 2001 21:42:40 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CKgdi19554 for ; Fri, 12 Jan 2001 21:42:39 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA18880; Fri, 12 Jan 2001 15:32:41 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 15:38:17 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Marcos Sanz/Denic'" Cc: ietf-provreg@cafax.se Subject: RE: RE: comments on your grrp-reqs-05.txt (second try) Date: Fri, 12 Jan 2001 15:38:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. -----Original Message----- From: Marcos Sanz/Denic [mailto:sanz@denic.de] Sent: Friday, January 12, 2001 9:58 AM To: Hollenbeck, Scott Cc: ietf-provreg@cafax.se Subject: Re: RE: comments on your grrp-reqs-05.txt (second try) On 10.01.01 14:37 "Hollenbeck, Scott" 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CFkkf16676 for ietf-provreg-outgoing; Fri, 12 Jan 2001 16:46:46 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CFkYi16671 for ; Fri, 12 Jan 2001 16:46:34 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0CFk7e05477 for ietf-provreg@cafax.se; Fri, 12 Jan 2001 16:46:07 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CFdMi16549 for ; Fri, 12 Jan 2001 16:39:22 +0100 (MET) Received: by dnspri.npac.com; id JAA25547; Fri, 12 Jan 2001 09:38:22 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xmaa24414; Fri, 12 Jan 01 09:37:40 -0600 Message-Id: <5.0.2.1.2.20010112102432.02d73050@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 10:31:33 -0500 To: "Paul George" , "Ietf-Provreg" From: Richard Shockey Subject: RE: Interim meeting: was RE: Charter last call summary In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CFE8p16220 for ietf-provreg-outgoing; Fri, 12 Jan 2001 16:14:08 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CFE7i16215 for ; Fri, 12 Jan 2001 16:14:07 +0100 (MET) Subject: Re: RE: comments on your grrp-reqs-05.txt (second try) To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Marcos Sanz/Denic" Date: Fri, 12 Jan 2001 15:57:48 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 12.01.2001 16:13:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 10.01.01 14:37 "Hollenbeck, Scott" 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CEmkG15876 for ietf-provreg-outgoing; Fri, 12 Jan 2001 15:48:46 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaamjurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CEmji15871 for ; Fri, 12 Jan 2001 15:48:45 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id PAA55941; Fri, 12 Jan 2001 15:48:45 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id PAA10374; Fri, 12 Jan 2001 15:48:45 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101121448.PAA10374@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: ietf-provreg@cafax.se Subject: Some more comments on your grrp-reqs-05.txt (second try) Date: Fri, 12 Jan 2001 15:48:45 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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)? Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CDIbB14429 for ietf-provreg-outgoing; Fri, 12 Jan 2001 14:18:37 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0CDIai14424 for ; Fri, 12 Jan 2001 14:18:36 +0100 (MET) Received: (qmail 25536 invoked from network); 12 Jan 2001 13:20:38 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.96) by ns1.saraf.net with SMTP; 12 Jan 2001 13:20:38 -0000 From: "Paul George" To: "Ietf-Provreg" Subject: RE: Interim meeting: was RE: Charter last call summary Date: Fri, 12 Jan 2001 08:18:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0CDDTn14373 for ietf-provreg-outgoing; Fri, 12 Jan 2001 14:13:29 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0CDDSi14368 for ; Fri, 12 Jan 2001 14:13:28 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA17483 for ; Fri, 12 Jan 2001 08:03:31 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 08:09:07 -0500 Message-ID: From: "Hollenbeck, Scott" To: Ietf-Provreg Subject: RE: Interim meeting: was RE: Charter last call summary Date: Fri, 12 Jan 2001 08:09:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0C9ZR912532 for ietf-provreg-outgoing; Fri, 12 Jan 2001 10:35:27 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0C9ZPi12527 for ; Fri, 12 Jan 2001 10:35:25 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0C9Z3104445 for ietf-provreg@cafax.se; Fri, 12 Jan 2001 10:35:03 +0100 (MET) Received: from BILL (armada.NDL.NET.NU [208.36.200.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BMQti07180 for ; Thu, 11 Jan 2001 23:26:56 +0100 (MET) Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Thu, 11 Jan 2001 17:25:12 -0500 Message-Id: <3.0.5.32.20010111172511.05a0bb80@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Jan 2001 17:25:11 -0500 To: Dave Crocker From: "J. William Semich" Subject: Re: Interim meeting: was RE: Charter last call summary Cc: Ietf-Provreg , tld@aptld.org In-Reply-To: <5.1.0.2.2.20010111140605.051fdb70@mail.bayarea.net> References: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 >Brandenburg Consulting >Tel: +1.408.246.8253, Fax: +1.408.273.6464 > > Bill Semich President and Founder WorldNames, Inc. http://www.worldnames.net bsemich@worldnames.net Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0C36kH10011 for ietf-provreg-outgoing; Fri, 12 Jan 2001 04:06:46 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0C36ii10006 for ; Fri, 12 Jan 2001 04:06:44 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id TAA04326; Thu, 11 Jan 2001 19:06:42 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.2.2.20010111185747.059ed730@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.2 (Beta) Date: Thu, 11 Jan 2001 19:06:38 -0800 To: Ietf-Provreg , tld@aptld.org From: Dave Crocker Subject: Re: Interim meeting: was RE: Charter last call summary In-Reply-To: <5.0.2.1.0.20010111174840.018c2340@mail.register.com> References: <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0C1uYI08734 for ietf-provreg-outgoing; Fri, 12 Jan 2001 02:56:34 +0100 (MET) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0C1uUi08729 for ; Fri, 12 Jan 2001 02:56:30 +0100 (MET) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f0C241d33918; Thu, 11 Jan 2001 21:04:01 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010111195335.02dbaa50@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 11 Jan 2001 19:57:40 -0500 To: Edward Lewis From: Marc Blanchet Subject: Re: Interim meeting Cc: Ietf-Provreg , tld@aptld.org In-Reply-To: References: <5.0.2.1.0.20010111161909.02eda008@mail.register.com> <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > >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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BMpMT07411 for ietf-provreg-outgoing; Thu, 11 Jan 2001 23:51:22 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BMpKi07406 for ; Thu, 11 Jan 2001 23:51:20 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id 2A3AE7A56; Thu, 11 Jan 2001 17:51:19 -0500 (EST) Message-Id: <5.0.2.1.0.20010111174840.018c2340@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 11 Jan 2001 17:49:45 -0500 To: Dave Crocker , Edward Lewis From: "Jordyn A. Buchanan" Subject: Re: Interim meeting: was RE: Charter last call summary Cc: "J. William Semich" , Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org In-Reply-To: <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> References: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BM9sS07010 for ietf-provreg-outgoing; Thu, 11 Jan 2001 23:09:54 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BM9ri07005 for ; Thu, 11 Jan 2001 23:09:53 +0100 (MET) Received: by sentry.gw.tislabs.com; id RAA16611; Thu, 11 Jan 2001 17:03:00 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma016607; Thu, 11 Jan 01 17:02:15 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.0.2.1.0.20010111161909.02eda008@mail.register.com> References: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jan 2001 16:55:54 -0500 To: "Jordyn A. Buchanan" From: Edward Lewis Subject: Re: Interim meeting: was RE: Charter last call summary Cc: Edward Lewis , "J. William Semich" , Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BM8Te06977 for ietf-provreg-outgoing; Thu, 11 Jan 2001 23:08:29 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BM8Mi06965 for ; Thu, 11 Jan 2001 23:08:22 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id OAA29919; Thu, 11 Jan 2001 14:08:16 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.2.2.20010111140605.051fdb70@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.2 (Beta) Date: Thu, 11 Jan 2001 14:06:17 -0800 To: "J. William Semich" From: Dave Crocker Subject: Re: Interim meeting: was RE: Charter last call summary Cc: Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org In-Reply-To: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> References: <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BM8TU06978 for ietf-provreg-outgoing; Thu, 11 Jan 2001 23:08:29 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BM8Mi06964 for ; Thu, 11 Jan 2001 23:08:22 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id OAA29912; Thu, 11 Jan 2001 14:08:14 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.2.2.20010111140446.0520ffd8@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.2 (Beta) Date: Thu, 11 Jan 2001 14:05:21 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Interim meeting: was RE: Charter last call summary Cc: "J. William Semich" , Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org In-Reply-To: References: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BLMEl06463 for ietf-provreg-outgoing; Thu, 11 Jan 2001 22:22:14 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BLMDi06458 for ; Thu, 11 Jan 2001 22:22:13 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id 4D71E7A56; Thu, 11 Jan 2001 16:22:09 -0500 (EST) Message-Id: <5.0.2.1.0.20010111161909.02eda008@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 11 Jan 2001 16:21:31 -0500 To: Edward Lewis , "J. William Semich" From: "Jordyn A. Buchanan" Subject: Re: Interim meeting: was RE: Charter last call summary Cc: Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org In-Reply-To: References: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BLEE306397 for ietf-provreg-outgoing; Thu, 11 Jan 2001 22:14:14 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BLECi06392 for ; Thu, 11 Jan 2001 22:14:12 +0100 (MET) Received: by sentry.gw.tislabs.com; id QAA16045; Thu, 11 Jan 2001 16:16:57 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma016043; Thu, 11 Jan 01 16:16:36 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> References: <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jan 2001 16:10:20 -0500 To: "J. William Semich" From: Edward Lewis Subject: Re: Interim meeting: was RE: Charter last call summary Cc: Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: > > >>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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BL0tj06227 for ietf-provreg-outgoing; Thu, 11 Jan 2001 22:00:55 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaamjurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BL0ri06222 for ; Thu, 11 Jan 2001 22:00:53 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA51610; Thu, 11 Jan 2001 22:00:48 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA07049; Thu, 11 Jan 2001 22:00:47 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101112100.WAA07049@bartok.sidn.nl> To: "J. William Semich" cc: Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg , tld@aptld.org Subject: Re: Interim meeting: was RE: Charter last call summary In-reply-to: Your message of Thu, 11 Jan 2001 12:00:26 -0500. <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> Date: Thu, 11 Jan 2001 22:00:47 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BHSrC03881 for ietf-provreg-outgoing; Thu, 11 Jan 2001 18:28:53 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BHSqi03875 for ; Thu, 11 Jan 2001 18:28:52 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0BHPGZ08288 for ; Thu, 11 Jan 2001 12:25:16 -0500 Date: Thu, 11 Jan 2001 12:25:16 -0500 (EST) From: Sheer El-Showk To: ietf-provreg@cafax.se Subject: RE: Security vs. Authorization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BHPru03818 for ietf-provreg-outgoing; Thu, 11 Jan 2001 18:25:53 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BHPni03811 for ; Thu, 11 Jan 2001 18:25:49 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0BHPX403087 for ietf-provreg@cafax.se; Thu, 11 Jan 2001 18:25:33 +0100 (MET) Received: from BILL (armada.NDL.NET.NU [208.36.200.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BH4wi03324 for ; Thu, 11 Jan 2001 18:04:59 +0100 (MET) Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Thu, 11 Jan 2001 12:00:27 -0500 Message-Id: <3.0.5.32.20010111120026.07fdab60@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Jan 2001 12:00:26 -0500 To: Richard Shockey , "Hollenbeck, Scott" , Ietf-Provreg From: "J. William Semich" Subject: Re: Interim meeting: was RE: Charter last call summary Cc: tld@aptld.org In-Reply-To: <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:09 PM 1/10/01 -0500, Richard Shockey wrote: >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 bsemich@worldnames.net Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BC3Ze28623 for ietf-provreg-outgoing; Thu, 11 Jan 2001 13:03:35 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BC3Y228618 for ; Thu, 11 Jan 2001 13:03:34 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA15193 for ; Thu, 11 Jan 2001 06:53:37 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 06:59:15 -0500 Message-ID: From: "Hollenbeck, Scott" To: Ietf-Provreg Subject: RE: Interim meeting: was RE: Charter last call summary Date: Thu, 11 Jan 2001 06:59:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BB0fr28173 for ietf-provreg-outgoing; Thu, 11 Jan 2001 12:00:41 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BB0d228168 for ; Thu, 11 Jan 2001 12:00:39 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0BB0PJ01990 for ietf-provreg@cafax.se; Thu, 11 Jan 2001 12:00:25 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0B7Xw226644 for ; Thu, 11 Jan 2001 08:33:59 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0B7XuU16887; Wed, 10 Jan 2001 23:33:56 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0B7WSm04363; Wed, 10 Jan 2001 23:32:28 -0800 Message-Id: <200101110732.f0B7WSm04363@zed.isi.edu> Subject: Re: Security vs. Authorization To: peter@2day.com (Peter Mott) Date: Wed, 10 Jan 2001 23:32:28 -0800 (PST) Cc: dcohen@register.com (Dan Cohen), ietf-provreg@cafax.se In-Reply-To: from "Peter Mott" at Jan 11, 2001 11:27:11 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BAtnx28097 for ietf-provreg-outgoing; Thu, 11 Jan 2001 11:55:49 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BAtl228085 for ; Thu, 11 Jan 2001 11:55:47 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0BAtV801930 for ietf-provreg@cafax.se; Thu, 11 Jan 2001 11:55:31 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AHhB219656 for ; Wed, 10 Jan 2001 18:43:12 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0AHhAU17882; Wed, 10 Jan 2001 09:43:10 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0AGhtc03084; Wed, 10 Jan 2001 08:43:55 -0800 Message-Id: <200101101643.f0AGhtc03084@zed.isi.edu> Subject: Re: Security vs. Authorization To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 10 Jan 2001 08:43:55 -0800 (PST) Cc: Olivier.Guillard@nic.fr ('Olivier Guillard'), ietf-provreg@cafax.se (Ietf-Provreg) In-Reply-To: from "Hollenbeck, Scott" at Jan 10, 2001 12:21:53 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % > 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. % % 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BAtcB28083 for ietf-provreg-outgoing; Thu, 11 Jan 2001 11:55:38 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0BAta228078 for ; Thu, 11 Jan 2001 11:55:36 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0BAtMx01922 for ietf-provreg@cafax.se; Thu, 11 Jan 2001 11:55:22 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AH6M219251 for ; Wed, 10 Jan 2001 18:06:22 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0AH61U12196; Wed, 10 Jan 2001 09:06:01 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0AG6e503002; Wed, 10 Jan 2001 08:06:40 -0800 Message-Id: <200101101606.f0AG6e503002@zed.isi.edu> Subject: Re: Security vs. Authorization To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 10 Jan 2001 08:06:40 -0800 (PST) Cc: pgeorge@saraf.com ('Paul George'), ietf-provreg@cafax.se (Ietf-Provreg) In-Reply-To: from "Hollenbeck, Scott" at Jan 10, 2001 08:57:44 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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.) % % -- --bill Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0B924t27142 for ietf-provreg-outgoing; Thu, 11 Jan 2001 10:02:04 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0B922227137 for ; Thu, 11 Jan 2001 10:02:02 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 11 Jan 2001 22:02:00 +1300 From: "Peter Mott" To: "Bill Manning" Cc: "Dan Cohen" , Subject: RE: Security vs. Authorization Date: Thu, 11 Jan 2001 22:02:00 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200101110732.f0B7WSm04363@zed.isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0B8IuS26905 for ietf-provreg-outgoing; Thu, 11 Jan 2001 09:18:56 +0100 (MET) Received: from notes.denic.de (notes.denic.de [194.246.96.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0B8It226900 for ; Thu, 11 Jan 2001 09:18:55 +0100 (MET) Subject: Antwort: RE: Security vs. Authorization To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Thu, 11 Jan 2001 09:17:47 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 11.01.2001 09:17:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > > % > 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. > > % > > % 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 : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0B386q25163 for ietf-provreg-outgoing; Thu, 11 Jan 2001 04:08:06 +0100 (MET) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0B385225158 for ; Thu, 11 Jan 2001 04:08:06 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivelst.dialup.mindspring.com [165.247.87.157]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA14085; Wed, 10 Jan 2001 22:07:53 -0500 (EST) Message-Id: <5.0.2.1.2.20010110214547.0274d310@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 21:46:14 -0500 To: "Paul George" , "Ietf-Provreg" From: Richard Shockey Subject: RE: Charter last call summary In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0B385f25156 for ietf-provreg-outgoing; Thu, 11 Jan 2001 04:08:05 +0100 (MET) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0B384225151 for ; Thu, 11 Jan 2001 04:08:04 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivelst.dialup.mindspring.com [165.247.87.157]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA32586; Wed, 10 Jan 2001 22:07:58 -0500 (EST) Message-Id: <5.0.2.1.2.20010110215055.02755ec0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 22:09:50 -0500 To: "Hollenbeck, Scott" , Ietf-Provreg From: Richard Shockey Subject: Re: Interim meeting: was RE: Charter last call summary In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. 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:lewis@tislabs.com] > > 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0ANAk022580 for ietf-provreg-outgoing; Thu, 11 Jan 2001 00:10:46 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0ANAj222575 for ; Thu, 11 Jan 2001 00:10:45 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 11 Jan 2001 12:10:43 +1300 From: "Peter Mott" To: , Subject: RE: Security vs. Authorization Date: Thu, 11 Jan 2001 12:10:43 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200101102251.QAA23055@alliance.globalnetlink.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AMRFA22209 for ietf-provreg-outgoing; Wed, 10 Jan 2001 23:27:15 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AMRD222204 for ; Wed, 10 Jan 2001 23:27:14 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 11 Jan 2001 11:27:11 +1300 From: "Peter Mott" To: "Dan Cohen" , Subject: RE: Security vs. Authorization Date: Thu, 11 Jan 2001 11:27:11 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.1.2.20010110153752.0478aa40@mail.forman.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AMJaZ22139 for ietf-provreg-outgoing; Wed, 10 Jan 2001 23:19:36 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AMJZ222134 for ; Wed, 10 Jan 2001 23:19:35 +0100 (MET) Received: from pentium3 (ppp8.bdg.melsa.net.id [202.138.227.8]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA23118 for ; Wed, 10 Jan 2001 16:55:48 -0600 Message-Id: <200101102255.QAA23118@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Thu, 11 Jan 2001 05:22:49 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Technical (was: security, authorization, definition, etc.) In-reply-to: <20010110174941.E19336@james.nic.fr> References: ; from peter@2day.com on Tue, Jan 09, 2001 at 09:25:51AM +1300 X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AMF3222086 for ietf-provreg-outgoing; Wed, 10 Jan 2001 23:15:03 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AMF2222081 for ; Wed, 10 Jan 2001 23:15:02 +0100 (MET) Received: from pentium3 (ppp8.bdg.melsa.net.id [202.138.227.8]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA23055 for ; Wed, 10 Jan 2001 16:51:09 -0600 Message-Id: <200101102251.QAA23055@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Thu, 11 Jan 2001 05:18:03 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Security vs. Authorization In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AKoMA21253 for ietf-provreg-outgoing; Wed, 10 Jan 2001 21:50:22 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AKoL221248 for ; Wed, 10 Jan 2001 21:50:21 +0100 (MET) Received: from [10.10.24.36] (helo=techpc3.forman.com) by rcommail1 with esmtp (Exim 3.16 #2) id 14GSCJ-0004q8-00 for ietf-provreg@cafax.se; Wed, 10 Jan 2001 15:50:19 -0500 Message-Id: <4.3.1.2.20010110153752.0478aa40@mail.forman.com> X-Sender: dcohen@mail.forman.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 10 Jan 2001 15:49:16 -0500 To: From: Dan Cohen Subject: RE: Security vs. Authorization In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AK1U920930 for ietf-provreg-outgoing; Wed, 10 Jan 2001 21:01:30 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0AK1T220925 for ; Wed, 10 Jan 2001 21:01:29 +0100 (MET) Received: (qmail 32121 invoked from network); 10 Jan 2001 20:03:24 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 10 Jan 2001 20:03:24 -0000 From: "Paul George" To: Subject: RE: Security vs. Authorization Date: Wed, 10 Jan 2001 15:04:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Hollenbeck, Scott Sent: Wednesday, January 10, 2001 2:22 PM To: ietf-provreg@cafax.se 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? > -----Original Message----- > From: Bill Manning [mailto:bmanning@ISI.EDU] > Sent: Wednesday, January 10, 2001 11:44 AM > To: shollenbeck@verisign.com > Cc: Olivier.Guillard@nic.fr; ietf-provreg@cafax.se > 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. > % > % > > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AJhkA20777 for ietf-provreg-outgoing; Wed, 10 Jan 2001 20:43:46 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AJhj220772 for ; Wed, 10 Jan 2001 20:43:46 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id 0FF657A87; Wed, 10 Jan 2001 14:43:44 -0500 (EST) Message-Id: <5.0.2.1.0.20010110142842.02f541a8@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 14:43:05 -0500 To: "Hollenbeck, Scott" , ietf-provreg@cafax.se From: "Jordyn A. Buchanan" Subject: RE: Security vs. Authorization In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AJQEL20608 for ietf-provreg-outgoing; Wed, 10 Jan 2001 20:26:14 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AJQD220603 for ; Wed, 10 Jan 2001 20:26:13 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA14033 for ; Wed, 10 Jan 2001 14:16:16 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 14:21:56 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Security vs. Authorization Date: Wed, 10 Jan 2001 14:21:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? > -----Original Message----- > From: Bill Manning [mailto:bmanning@ISI.EDU] > Sent: Wednesday, January 10, 2001 11:44 AM > To: shollenbeck@verisign.com > Cc: Olivier.Guillard@nic.fr; ietf-provreg@cafax.se > 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. > % > % > > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AHeFT19592 for ietf-provreg-outgoing; Wed, 10 Jan 2001 18:40:15 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AHeA219587 for ; Wed, 10 Jan 2001 18:40:11 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id SAA13057 ; Wed, 10 Jan 2001 18:39:58 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0AHddR03268; Wed, 10 Jan 2001 18:39:39 +0100 Date: Wed, 10 Jan 2001 18:39:39 +0100 From: Olivier Guillard To: "Jordyn A. Buchanan" Cc: Olivier Guillard , "Hollenbeck, Scott" , "'Paul George'" , Ietf-Provreg Subject: Re: Security vs. Authorization Message-ID: <20010110183939.E26632@james.nic.fr> References: <20010110180253.B26632@james.nic.fr> <5.0.2.1.0.20010110121213.030fca78@mail.register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.0.20010110121213.030fca78@mail.register.com>; from jordyn@register.com on Wed, Jan 10, 2001 at 12:27:07PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AHa7A19550 for ietf-provreg-outgoing; Wed, 10 Jan 2001 18:36:07 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AHa1219544 for ; Wed, 10 Jan 2001 18:36:04 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id SAA00134 ; Wed, 10 Jan 2001 18:35:48 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0AHZTm02325; Wed, 10 Jan 2001 18:35:29 +0100 Date: Wed, 10 Jan 2001 18:35:29 +0100 From: Olivier Guillard To: "Hollenbeck, Scott" Cc: "'Olivier Guillard'" , Ietf-Provreg Subject: Re: Security vs. Authorization Message-ID: <20010110183529.D26632@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Wed, Jan 10, 2001 at 12:21:53PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AHRqf19466 for ietf-provreg-outgoing; Wed, 10 Jan 2001 18:27:52 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AHRp219461 for ; Wed, 10 Jan 2001 18:27:51 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id F38857A9C; Wed, 10 Jan 2001 12:27:49 -0500 (EST) Message-Id: <5.0.2.1.0.20010110121213.030fca78@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 12:27:07 -0500 To: Olivier Guillard , "Hollenbeck, Scott" From: "Jordyn A. Buchanan" Subject: Re: Security vs. Authorization Cc: "'Paul George'" , Ietf-Provreg In-Reply-To: <20010110180253.B26632@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AHRSv19451 for ietf-provreg-outgoing; Wed, 10 Jan 2001 18:27:28 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AHRS219446 for ; Wed, 10 Jan 2001 18:27:28 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA13655; Wed, 10 Jan 2001 12:16:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 12:21:54 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Olivier Guillard'" Cc: Ietf-Provreg Subject: RE: Security vs. Authorization Date: Wed, 10 Jan 2001 12:21:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Olivier Guillard [mailto:Olivier.Guillard@nic.fr] > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AH45d19222 for ietf-provreg-outgoing; Wed, 10 Jan 2001 18:04:05 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AH43219217 for ; Wed, 10 Jan 2001 18:04:03 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id SAA31717 ; Wed, 10 Jan 2001 18:03:16 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0AH2rn28156; Wed, 10 Jan 2001 18:02:53 +0100 Date: Wed, 10 Jan 2001 18:02:53 +0100 From: Olivier Guillard To: "Hollenbeck, Scott" Cc: "'Paul George'" , Ietf-Provreg Subject: Re: Security vs. Authorization Message-ID: <20010110180253.B26632@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Wed, Jan 10, 2001 at 08:57:44AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > [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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AGoP519051 for ietf-provreg-outgoing; Wed, 10 Jan 2001 17:50:25 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AGoH219043 for ; Wed, 10 Jan 2001 17:50:19 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id RAA29650 ; Wed, 10 Jan 2001 17:50:05 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0AGnfU27347; Wed, 10 Jan 2001 17:49:41 +0100 Date: Wed, 10 Jan 2001 17:49:41 +0100 From: Olivier Guillard To: Peter Mott Cc: Annie Renard , budi@alliance.globalnetlink.com, ietf-provreg@cafax.se Subject: Re: Definition of Registry Message-ID: <20010110174941.E19336@james.nic.fr> References: <20010108142719.A12581@james.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from peter@2day.com on Tue, Jan 09, 2001 at 09:25:51AM +1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 youngrussian@usa.net N.J. N.J., N.J. 12345678 US 456-7895 Technical Contact: Menas, John youngrussian@usa.net N.J. N.J., N.J. 12345678 US 456-7895 Billing Contact: Menas, John youngrussian@usa.net 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AG6w618640 for ietf-provreg-outgoing; Wed, 10 Jan 2001 17:06:58 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AG6v218635 for ; Wed, 10 Jan 2001 17:06:57 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA13344 for ; Wed, 10 Jan 2001 10:56:59 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 11:02:39 -0500 Message-ID: From: "Hollenbeck, Scott" To: Ietf-Provreg Subject: Re: Interim meeting: was RE: Charter last call summary Date: Wed, 10 Jan 2001 11:02:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > -----Original Message----- > From: Edward Lewis [mailto:lewis@tislabs.com] > 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] Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AG5Da18616 for ietf-provreg-outgoing; Wed, 10 Jan 2001 17:05:13 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AG5C218611 for ; Wed, 10 Jan 2001 17:05:12 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14GNkM-0005IG-00; Wed, 10 Jan 2001 17:05:10 +0100 To: Edward Lewis cc: "Paul George" , ietf-provreg@cafax.se Subject: Re: Charter last call summary In-reply-to: Message from Edward Lewis of "Wed, 10 Jan 2001 09:35:17 -0500." References: Message from Edward Lewis of "Tue, 09 Jan 2001 14:52:50 -0500." Message from "Paul George" of "Tue, 09 Jan 2001 12:17:41 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20349.979142710.1@smtp.switch.ch> Date: Wed, 10 Jan 2001 17:05:10 +0100 Message-ID: <20351.979142710@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > Dilbert is an optimist. > Opinions expressed are property of my evil twin, not my employer. Marcel Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFpo118503 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:51:50 +0100 (MET) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AFpg218498 for ; Wed, 10 Jan 2001 16:51:42 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id QAA20385 ; Wed, 10 Jan 2001 16:51:28 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f0AFp9n25018; Wed, 10 Jan 2001 16:51:09 +0100 Date: Wed, 10 Jan 2001 16:51:09 +0100 From: Olivier Guillard To: Peter Mott Cc: Olivier Guillard , Annie Renard , budi@alliance.globalnetlink.com, ietf-provreg@cafax.se Subject: Re: Definition of Registry Message-ID: <20010110165109.D19336@james.nic.fr> References: <20010108142719.A12581@james.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from peter@2day.com on Tue, Jan 09, 2001 at 09:25:51AM +1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFfju18334 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:41:45 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AFfi218329 for ; Wed, 10 Jan 2001 16:41:44 +0100 (MET) Received: by sentry.gw.tislabs.com; id KAA12194; Wed, 10 Jan 2001 10:44:54 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma012187; Wed, 10 Jan 01 10:43:57 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.0.2.1.0.20010110101722.02fab858@mail.register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jan 2001 10:38:00 -0500 To: "Jordyn A. Buchanan" From: Edward Lewis Subject: Interim meeting: was RE: Charter last call summary Cc: "Paul George" , "Ietf-Provreg" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFTuU18247 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:29:56 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AFTt218240 for ; Wed, 10 Jan 2001 16:29:55 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA13218 for ; Wed, 10 Jan 2001 10:18:18 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 10:23:58 -0500 Message-ID: From: "Hollenbeck, Scott" To: Ietf-Provreg Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 10:23:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > -----Original Message----- > From: Jordyn A. Buchanan [mailto:jordyn@register.com] > 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 > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFKPY18162 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:20:25 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AFKO218157 for ; Wed, 10 Jan 2001 16:20:24 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id 351D17A79; Wed, 10 Jan 2001 10:20:23 -0500 (EST) Message-Id: <5.0.2.1.0.20010110101722.02fab858@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 10:19:45 -0500 To: "Paul George" , "Ietf-Provreg" From: "Jordyn A. Buchanan" Subject: RE: Charter last call summary In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFE7Q18056 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:14:07 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0AFE6218050 for ; Wed, 10 Jan 2001 16:14:06 +0100 (MET) Received: (qmail 23336 invoked from network); 10 Jan 2001 15:16:01 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 10 Jan 2001 15:16:01 -0000 From: "Paul George" To: "Ietf-Provreg" Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 10:17:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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:lewis@tislabs.com] Sent: Wednesday, January 10, 2001 9:35 AM To: Marcel Schneider Cc: Edward Lewis; Paul George; ietf-provreg@cafax.se 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AFBBW18023 for ietf-provreg-outgoing; Wed, 10 Jan 2001 16:11:11 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f0AFBA218018 for ; Wed, 10 Jan 2001 16:11:10 +0100 (MET) Received: (qmail 23205 invoked from network); 10 Jan 2001 15:13:05 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 10 Jan 2001 15:13:05 -0000 From: "Paul George" To: "Ietf-Provreg" Subject: RE: Security vs. Authorization Date: Wed, 10 Jan 2001 10:14:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C07AEE.1D055DF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:shollenbeck@verisign.com] 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.) > -----Original Message----- > From: Paul George [mailto:pgeorge@saraf.com] > 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" eJ8+IhsPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAQAKAAoADgAAAAMA/gAB A5AGACAEAAAgAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAbAAAAU2VjdXJpdHkgdnMuIEF1dGhvcml6YXRpb24AAAIBcQABAAAAIAAAAAHA endNjs1OanDmLxHUslAAAQIn+qkAJSEZkAAC/tQgAgEdDAEAAAAXAAAAU01UUDpQR0VPUkdFQFNB UkFGLkNPTQAACwABDgAAAABAAAYOAGyF9Rd7wAECAQoOAQAAABgAAAAAAAAA3lwXcpjh1BGyTQAB Aif6qcKAAAAeAEIQAQAAAEUAAAA8REY3MzdFNjIwNTc5RDQxMUE4RTQwMEQwQjc3RTY3MUQ3NTA0 NUNAcmVnZG9tLWV4MDEucHJvZC5uZXRzb2wuY29tPgAAAAALAAGACCAGAAAAAADAAAAAAAAARgAA AAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAA AAAAAEYAAAAAUoUAACdqAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAA HgAKgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAA AABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEA AAAAAAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAA RgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAA wAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AI IAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAA3lwXcpjh1BGyTQABAif6qQIB +g8BAAAAEAAAAN5cF3KY4dQRsk0AAQIn+qkCAfsPAQAAAJEAAAAAAAAAOKG7EAXlEBqhuwgAKypW wgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xw Z2VvcmdlXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tc b3V0bG9vay5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADxORUJCTENFTk5PRk5C RkZGR0NFSUtFQ0NDQUFBLnBnZW9yZ2VAc2FyYWYuY29tPgAAAACNtQ== ------=_NextPart_000_0000_01C07AEE.1D055DF0-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AEcgn17637 for ietf-provreg-outgoing; Wed, 10 Jan 2001 15:38:42 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AEcf217631 for ; Wed, 10 Jan 2001 15:38:41 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA09480; Wed, 10 Jan 2001 09:41:50 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma009453; Wed, 10 Jan 01 09:40:54 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <6597.979117480@smtp.switch.ch> References: Message from Edward Lewis of "Tue, 09 Jan 2001 14:52:50 -0500." Message from "Paul George" of "Tue, 09 Jan 2001 12:17:41 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jan 2001 09:35:17 -0500 To: Marcel Schneider From: Edward Lewis Subject: Re: Charter last call summary Cc: Edward Lewis , "Paul George" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AE23117333 for ietf-provreg-outgoing; Wed, 10 Jan 2001 15:02:03 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AE22217328 for ; Wed, 10 Jan 2001 15:02:02 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA12864 for ; Wed, 10 Jan 2001 08:52:04 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 08:57:45 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Paul George'" , Ietf-Provreg Subject: RE: Security vs. Authorization Date: Wed, 10 Jan 2001 08:57:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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.) > -----Original Message----- > From: Paul George [mailto:pgeorge@saraf.com] > 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0ADg8S17058 for ietf-provreg-outgoing; Wed, 10 Jan 2001 14:42:08 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0ADg7217053 for ; Wed, 10 Jan 2001 14:42:07 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA12809; Wed, 10 Jan 2001 08:31:38 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 08:37:18 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jordyn A. Buchanan'" , "'Jaap Akkerhuis'" Cc: ietf-provreg@cafax.se Subject: RE: comments on your grrp-reqs-05.txt (second try) Date: Wed, 10 Jan 2001 08:37:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > -----Original Message----- > From: Jordyn A. Buchanan [mailto:jordyn@register.com] > Sent: Tuesday, January 09, 2001 1:03 PM > To: Hollenbeck, Scott; 'Jaap Akkerhuis' > Cc: ietf-provreg@cafax.se > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0AAUqS15586 for ietf-provreg-outgoing; Wed, 10 Jan 2001 11:30:52 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0AAUo215581 for ; Wed, 10 Jan 2001 11:30:51 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Wed, 10 Jan 2001 23:30:49 +1300 From: "Peter Mott" To: "Marcel Schneider" , "Paul George" Cc: "Ietf-Provreg" Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 23:30:48 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <6353.979116958@smtp.switch.ch> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0A94hd14916 for ietf-provreg-outgoing; Wed, 10 Jan 2001 10:04:43 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0A94g214911 for ; Wed, 10 Jan 2001 10:04:42 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14GHBQ-0001iQ-00; Wed, 10 Jan 2001 10:04:40 +0100 To: Edward Lewis cc: "Paul George" , ietf-provreg@cafax.se Subject: Re: Charter last call summary In-reply-to: Message from Edward Lewis of "Tue, 09 Jan 2001 14:52:50 -0500." References: Message from "Paul George" of "Tue, 09 Jan 2001 12:17:41 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6596.979117480.1@smtp.switch.ch> Date: Wed, 10 Jan 2001 10:04:40 +0100 Message-ID: <6597.979117480@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com > Dilbert is an optimist. > Opinions expressed are property of my evil twin, not my employer. Marcel Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0A8u1U14822 for ietf-provreg-outgoing; Wed, 10 Jan 2001 09:56:01 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0A8tx214815 for ; Wed, 10 Jan 2001 09:55:59 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14GH30-0001eU-00; Wed, 10 Jan 2001 09:55:58 +0100 To: "Paul George" cc: "Ietf-Provreg" Subject: Re: Charter last call summary In-reply-to: Message from "Paul George" of "Tue, 09 Jan 2001 14:19:23 -0500." References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6352.979116958.1@smtp.switch.ch> Date: Wed, 10 Jan 2001 09:55:58 +0100 Message-ID: <6353.979116958@smtp.switch.ch> From: Marcel Schneider Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f0A8u0214816 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of Marcel Schneider > Sent: Tuesday, January 09, 2001 1:39 PM > To: Paul George > Cc: ietf-provreg@cafax.se > 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On >> Behalf Of Marcel Schneider >> Sent: Tuesday, January 09, 2001 11:50 AM >> Cc: ietf-provreg@cafax.se >> 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 >>> Jaap Akkerhius >>> APPLICATIONS AREA DIRECTOR(S): >>> Patrik Fältström >>> Ned Freed >>> AREA ADVISOR: >>> Patrik Fältström >>> MAILING LISTS: >>> General Discussion: ietf-provreg@cafax.se >>> To Subscribe: majordomo@cafax.se >>> In Body: subscribe ietf-provreg >>> Archive: http://www.cafax.se/ietf-provreg/maillist/ >>> DESCRIPTION OF WORKING GROUP: >>> Administration of Domain Name Service (DNS) registration increasingly >>> distinguishes between the operation of a "back-end" registry data base >>> service for registrations, versus "front-end" support services by >>> registrars who interact with registrants and with the registry. >> Especially >>> for various Top-Level Domains, the desire is to permit multiple > registrars >>> to share access to the 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" and the >>> Extensible Provisioning Protocol presentation, documented in >>> . >>> 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: lewis@tislabs.com >>> Dilbert is an optimist. >>> Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09LD8Q09639 for ietf-provreg-outgoing; Tue, 9 Jan 2001 22:13:08 +0100 (MET) Received: from balsa.cetp.ipsl.fr (balsa.cetp.ipsl.fr [193.52.172.32]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09LD3209633 for ; Tue, 9 Jan 2001 22:13:03 +0100 (MET) Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id WAA03442; Tue, 9 Jan 2001 22:12:57 +0100 (MET) Date: Tue, 9 Jan 2001 22:12:57 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200101092112.WAA03442@balsa.cetp.ipsl.fr> To: ietf-provreg@cafax.se, peter@2day.com, pgeorge@saraf.com Subject: RE: Charter last call summary Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09KaDt09266 for ietf-provreg-outgoing; Tue, 9 Jan 2001 21:36:13 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f09KaC209261 for ; Tue, 9 Jan 2001 21:36:12 +0100 (MET) Received: (qmail 12474 invoked from network); 9 Jan 2001 20:38:04 -0000 Received: from unknown (HELO saraf.com) (63.217.189.91) by ns1.saraf.net with SMTP; 9 Jan 2001 20:38:04 -0000 Message-ID: <3A5B75F6.D5070B56@saraf.com> Date: Tue, 09 Jan 2001 15:35:02 -0500 From: Neeran Saraf X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: Charter last call summary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 (neeran@saraf.com) 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09KSxx09203 for ietf-provreg-outgoing; Tue, 9 Jan 2001 21:28:59 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09KSw209198 for ; Tue, 9 Jan 2001 21:28:58 +0100 (MET) Received: by sentry.gw.tislabs.com; id PAA25502; Tue, 9 Jan 2001 15:32:05 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma025494; Tue, 9 Jan 01 15:31:35 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <17311.979065525@smtp.switch.ch> References: Message from "Paul George" of "Tue, 09 Jan 2001 12:17:41 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jan 2001 14:52:50 -0500 To: Marcel Schneider From: Edward Lewis Subject: Re: Charter last call summary Cc: "Paul George" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09KHPf09111 for ietf-provreg-outgoing; Tue, 9 Jan 2001 21:17:25 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09KHO209106 for ; Tue, 9 Jan 2001 21:17:24 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Wed, 10 Jan 2001 09:17:22 +1300 From: "Peter Mott" To: "Paul George" , "Ietf-Provreg" Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 09:17:22 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09K0do08954 for ietf-provreg-outgoing; Tue, 9 Jan 2001 21:00:39 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f09K0c208949 for ; Tue, 9 Jan 2001 21:00:38 +0100 (MET) Received: (qmail 11689 invoked from network); 9 Jan 2001 20:02:30 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 9 Jan 2001 20:02:30 -0000 From: "Paul George" To: "Ietf-Provreg" Subject: Security vs. Authorization Date: Tue, 9 Jan 2001 15:03:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01C07A4D.64DC17F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-MS-TNEF-Correlator: Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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" eJ8+IjoUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAQAJAA8AAwAAAAIA9gAB A5AGADgIAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAGwAAAFNlY3VyaXR5IHZzLiBBdXRob3JpemF0aW9uAAACAXEAAQAAABYAAAABwHp3TY7NTmpw 5i8R1LJQAAECJ/qpAAACAR0MAQAAABcAAABTTVRQOlBHRU9SR0VAU0FSQUYuQ09NAAALAAEOAAAA AEAABg4Aso0qd3rAAQIBCg4BAAAAGAAAAAAAAADeXBdymOHUEbJNAAECJ/qpwoAAAAsAHw4BAAAA AgEJEAEAAADRAwAAzQMAAJQFAABMWkZ1/qfE7AMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQD 4wIAY2gKwHPwZXQwIAcTAoMAUAPVVxF4DlAQb0MJ8HQIcHlgIEdvdGgN4AKAfbMKgAjIIDsJbw4w NQKAJQqBdgiQd2sLgGQ0HQxgYwBQCwMLtSBJIAJ3CGBsZCBsaWvAZSB0byBiBRAPIAAgdXAgYSBw b38LgAVAAaAIYAVAFRAaUGStBpBmBJAJ8GMaUGIRMK53CeEcAxEgYwhxdBTQKGFzcAWQdAQgKHcV FSFoHbBoGdNOT1QHHPEbIgrAdCkgb2ZxHANSUlAbIBhQHANhhxvgH1AFEHphdGkCIM8ewCFSBaAA gGVxClACMOpsFNBwA2B0HoEicSCDtmUA0B8gIhSBHhEiHEDzCHEa0XRyAHEA0CJjI9F3HNAEEBrB LgqiCoQKgFftFSBsGlAZoGEJwhwBIlD3GbAdoR9UbhUAHEEekCJQvx2pI9Im8AbwBCAhUnMYkIxo LBmRFRFuayAeEP8tEAQgB3AbUAAgAHAb8ilE+xxQBPB1BBEe4ClBA2Aocf8cEitmHzYLURTQC4Aj xyXi/xwhJSMIkAQgJaUkwyYZJ3v2RgWxC4BzLdEc0CyAH0VXL8sJcAWgZwMAei+kZv8mYSkTLIAe 4ShxKXEKwBwx/wEQC4AawhtxBJAmZAQgHQa/AiAjoR0gGoAgQjLCKAlw7mcEACYQFNAtN1E84wrA viksgBwROZE5giZhdQdA/yOhIrAFQChwHlAgcRUQKOK/PDYxUQdABGA1oCSwdgSQ5xTQIwEc0Gl2 AaAocQIQvHJtIJIJcAdAGbFyGfGPLYFBMBSBIlM/ICA1QvhleGFD8TXxLKYvxiQU/yCWFRELICAz P0EcEj12AjDXIIAtWyFSbgngZAQgGnL7GlAjAmkEgQmALxEdUTnH9S/KLkTARUGgA6AGkC0V/nMD cBEwLNEa4B5QHbBD4j8gAU5xMSAx9ClBL8tTSPBPVUxEQREJAAfgQrH9ToMgB4AGIiChIdYawlKj bwWxPxEgmiYZcyd7GaBknQIgJylRLeMagHJ1ASD/QoIkwD4yLWEgsi1REPA7At8dUQlwWcEcICFx bxqAIKD1JABuLIBiG+EZqxUBBJBpG0Blb0VhJ0qxH1Fn/mgeoSKBWXMAwAJABJBNgT5UEPAs8Cvh W4EcwGghHyeKCNAAQQwwC+E0IFCLIdADIEddEHJnZWDhfwoRAtESEgwBJ5QTMAYAQfhSQUYGAFsh V8A5kWRAXwpAOsMCsieTFXEAZjAAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA A4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA ACdqAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAA wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB AAAAAQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAgg BgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAA3lwXcpjh1BGyTQABAif6qQIB+g8BAAAAEAAAAN5c F3KY4dQRsk0AAQIn+qkCAfsPAQAAAJEAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRM TAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xwZ2VvcmdlXExvY2Fs IFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QA AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADxORUJCTENFTk5PRk5CRkZGR0NFSUNFQk1D QUFBLnBnZW9yZ2VAc2FyYWYuY29tPgAAAAADAAYQrAkjogMABxCoAwAAAwAQEAAAAAADABEQAAAA AB4ACBABAAAAZQAAAElXT1VMRExJS0VUT0JSSU5HVVBBUE9JTlRBQk9VVFRIRURJRkZFUkVOQ0VC RVRXRUVOVEhFU0VDVVJJVFlBU1BFQ1RTKFdISUNIU0hPVUxETk9UQkVBUEFSVClPRlRIRVJSUEEA AAAA0fQ= ------=_NextPart_000_0024_01C07A4D.64DC17F0-- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09JfnA08785 for ietf-provreg-outgoing; Tue, 9 Jan 2001 20:41:49 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f09Jfm208780 for ; Tue, 9 Jan 2001 20:41:48 +0100 (MET) Received: (qmail 11189 invoked from network); 9 Jan 2001 19:43:40 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 9 Jan 2001 19:43:40 -0000 From: "Paul George" To: Subject: RE: Charter last call summary Date: Tue, 9 Jan 2001 14:45:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I agree with the charter. Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Edward Lewis Sent: Tuesday, January 09, 2001 11:01 AM To: ietf-provreg@cafax.se Cc: lewis@tislabs.com 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 Jaap Akkerhius APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: Patrik Fältström MAILING LISTS: General Discussion: ietf-provreg@cafax.se To Subscribe: majordomo@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ DESCRIPTION OF WORKING GROUP: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the 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" and the Extensible Provisioning Protocol presentation, documented in . 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09JG4F08563 for ietf-provreg-outgoing; Tue, 9 Jan 2001 20:16:04 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f09JG3208558 for ; Tue, 9 Jan 2001 20:16:03 +0100 (MET) Received: (qmail 9564 invoked from network); 9 Jan 2001 19:17:54 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 9 Jan 2001 19:17:54 -0000 From: "Paul George" To: "Ietf-Provreg" Subject: RE: Charter last call summary Date: Tue, 9 Jan 2001 14:19:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <17311.979065525@smtp.switch.ch> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Marcel Schneider Sent: Tuesday, January 09, 2001 1:39 PM To: Paul George Cc: ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of Marcel Schneider > Sent: Tuesday, January 09, 2001 11:50 AM > Cc: ietf-provreg@cafax.se > 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 >> Jaap Akkerhius >> APPLICATIONS AREA DIRECTOR(S): >> Patrik Fältström >> Ned Freed >> AREA ADVISOR: >> Patrik Fältström >> MAILING LISTS: >> General Discussion: ietf-provreg@cafax.se >> To Subscribe: majordomo@cafax.se >> In Body: subscribe ietf-provreg >> Archive: http://www.cafax.se/ietf-provreg/maillist/ >> DESCRIPTION OF WORKING GROUP: >> Administration of Domain Name Service (DNS) registration increasingly >> distinguishes between the operation of a "back-end" registry data base >> service for registrations, versus "front-end" support services by >> registrars who interact with registrants and with the registry. > Especially >> for various Top-Level Domains, the desire is to permit multiple registrars >> to share access to the 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" and the >> Extensible Provisioning Protocol presentation, documented in >> . >> 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: lewis@tislabs.com >> Dilbert is an optimist. >> Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09JAwJ08485 for ietf-provreg-outgoing; Tue, 9 Jan 2001 20:10:58 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09JAu208480 for ; Tue, 9 Jan 2001 20:10:56 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Wed, 10 Jan 2001 08:10:55 +1300 From: "Peter Mott" To: "Edward Lewis" , Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 08:10:54 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09J0TC08387 for ietf-provreg-outgoing; Tue, 9 Jan 2001 20:00:29 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09J0S208382 for ; Tue, 9 Jan 2001 20:00:28 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Wed, 10 Jan 2001 08:00:26 +1300 From: "Peter Mott" To: "Marcel Schneider" , "Paul George" Cc: Subject: RE: Charter last call summary Date: Wed, 10 Jan 2001 08:00:25 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <17311.979065525@smtp.switch.ch> Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09IwUu08329 for ietf-provreg-outgoing; Tue, 9 Jan 2001 19:58:30 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09IwR208324 for ; Tue, 9 Jan 2001 19:58:27 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f09IwO900480 for ietf-provreg@cafax.se; Tue, 9 Jan 2001 19:58:24 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09HKX207476 for ; Tue, 9 Jan 2001 18:20:33 +0100 (MET) Received: by dnspri.npac.com; id LAA04869; Tue, 9 Jan 2001 11:20:01 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xma004798; Tue, 9 Jan 01 11:19:37 -0600 Message-Id: <5.0.2.1.2.20010109120305.026ea690@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 12:03:28 -0500 To: Dave Crocker , Edward Lewis From: Richard Shockey Subject: Re: Charter last call summary Cc: ietf-provreg@cafax.se In-Reply-To: <5.1.0.2.2.20010109083307.02c992a8@mail.bayarea.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09Icuf08121 for ietf-provreg-outgoing; Tue, 9 Jan 2001 19:38:56 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09Ict208116 for ; Tue, 9 Jan 2001 19:38:55 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14G3fR-0004VE-00; Tue, 09 Jan 2001 19:38:45 +0100 To: "Paul George" cc: ietf-provreg@cafax.se Subject: Re: Charter last call summary In-reply-to: Message from "Paul George" of "Tue, 09 Jan 2001 12:17:41 -0500." References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17310.979065525.1@smtp.switch.ch> Date: Tue, 09 Jan 2001 19:38:45 +0100 Message-ID: <17311.979065525@smtp.switch.ch> From: Marcel Schneider Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f09Icu208117 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of Marcel Schneider > Sent: Tuesday, January 09, 2001 11:50 AM > Cc: ietf-provreg@cafax.se > 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 >> Jaap Akkerhius >> APPLICATIONS AREA DIRECTOR(S): >> Patrik Fältström >> Ned Freed >> AREA ADVISOR: >> Patrik Fältström >> MAILING LISTS: >> General Discussion: ietf-provreg@cafax.se >> To Subscribe: majordomo@cafax.se >> In Body: subscribe ietf-provreg >> Archive: http://www.cafax.se/ietf-provreg/maillist/ >> DESCRIPTION OF WORKING GROUP: >> Administration of Domain Name Service (DNS) registration increasingly >> distinguishes between the operation of a "back-end" registry data base >> service for registrations, versus "front-end" support services by >> registrars who interact with registrants and with the registry. > Especially >> for various Top-Level Domains, the desire is to permit multiple registrars >> to share access to the 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" and the >> Extensible Provisioning Protocol presentation, documented in >> . >> 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: lewis@tislabs.com >> Dilbert is an optimist. >> Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09I5CI07905 for ietf-provreg-outgoing; Tue, 9 Jan 2001 19:05:12 +0100 (MET) Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09I5A207900 for ; Tue, 9 Jan 2001 19:05:10 +0100 (MET) Received: from tech146-jordyn.register.com (unknown [209.208.136.140]) by total.confusion.net (Postfix) with ESMTP id 8133E7A93; Tue, 9 Jan 2001 13:05:08 -0500 (EST) Message-Id: <5.0.2.1.0.20010109110503.02f8c4e8@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 13:02:41 -0500 To: "Hollenbeck, Scott" , "'Jaap Akkerhuis'" From: "Jordyn A. Buchanan" Subject: RE: comments on your grrp-reqs-05.txt (second try) Cc: ietf-provreg@cafax.se In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09HEVI07424 for ietf-provreg-outgoing; Tue, 9 Jan 2001 18:14:31 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f09HEU207419 for ; Tue, 9 Jan 2001 18:14:30 +0100 (MET) Received: (qmail 7367 invoked from network); 9 Jan 2001 17:16:11 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 9 Jan 2001 17:16:11 -0000 From: "Paul George" To: Subject: RE: Charter last call summary Date: Tue, 9 Jan 2001 12:17:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <14875.979059005@smtp.switch.ch> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Marcel Schneider Sent: Tuesday, January 09, 2001 11:50 AM Cc: ietf-provreg@cafax.se 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 > Jaap Akkerhius > APPLICATIONS AREA DIRECTOR(S): > Patrik Fältström > Ned Freed > AREA ADVISOR: > Patrik Fältström > MAILING LISTS: > General Discussion: ietf-provreg@cafax.se > To Subscribe: majordomo@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > DESCRIPTION OF WORKING GROUP: > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. Especially > for various Top-Level Domains, the desire is to permit multiple registrars > to share access to the 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" and the > Extensible Provisioning Protocol presentation, documented in > . > 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: lewis@tislabs.com > Dilbert is an optimist. > Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09Gt7I07227 for ietf-provreg-outgoing; Tue, 9 Jan 2001 17:55:07 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09Gt6207222 for ; Tue, 9 Jan 2001 17:55:07 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14G238-0003um-00 for ietf-provreg@cafax.se; Tue, 09 Jan 2001 17:55:06 +0100 To: ietf-provreg@cafax.se Subject: Re: Charter last call summary In-reply-to: Your message of "Tue, 09 Jan 2001 17:50:05 +0100." <14875.979059005@smtp.switch.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <15050.979059305.1@smtp.switch.ch> Date: Tue, 09 Jan 2001 17:55:06 +0100 Message-ID: <15051.979059306@smtp.switch.ch> From: Marcel Schneider Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f09Gt7207223 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 > Jaap Akkerhius > APPLICATIONS AREA DIRECTOR(S): > Patrik Fältström > Ned Freed > AREA ADVISOR: > Patrik Fältström > MAILING LISTS: > General Discussion: ietf-provreg@cafax.se > To Subscribe: majordomo@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > DESCRIPTION OF WORKING GROUP: > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. Especially > for various Top-Level Domains, the desire is to permit multiple registrars > to share access to the 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. ... Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09Go7B07181 for ietf-provreg-outgoing; Tue, 9 Jan 2001 17:50:07 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09Go6207176 for ; Tue, 9 Jan 2001 17:50:07 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14G1yH-0003rw-00 for ietf-provreg@cafax.se; Tue, 09 Jan 2001 17:50:05 +0100 cc: ietf-provreg@cafax.se Subject: Re: Charter last call summary In-reply-to: Message from Edward Lewis of "Tue, 09 Jan 2001 11:00:56 -0500." References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <14874.979059005.1@smtp.switch.ch> Date: Tue, 09 Jan 2001 17:50:05 +0100 Message-ID: <14875.979059005@smtp.switch.ch> From: Marcel Schneider Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f09Go7207177 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 > Jaap Akkerhius > APPLICATIONS AREA DIRECTOR(S): > Patrik Fältström > Ned Freed > AREA ADVISOR: > Patrik Fältström > MAILING LISTS: > General Discussion: ietf-provreg@cafax.se > To Subscribe: majordomo@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > DESCRIPTION OF WORKING GROUP: > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. Especially > for various Top-Level Domains, the desire is to permit multiple registrars > to share access to the 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" and the > Extensible Provisioning Protocol presentation, documented in > . > 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: lewis@tislabs.com > Dilbert is an optimist. > Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09GXWl07057 for ietf-provreg-outgoing; Tue, 9 Jan 2001 17:33:32 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09GXU207052 for ; Tue, 9 Jan 2001 17:33:30 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id IAA13220; Tue, 9 Jan 2001 08:33:27 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.2.2.20010109083307.02c992a8@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.2 (Beta) Date: Tue, 09 Jan 2001 08:33:31 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Charter last call summary Cc: ietf-provreg@cafax.se, lewis@tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f09G4T606800 for ietf-provreg-outgoing; Tue, 9 Jan 2001 17:04:29 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f09G4S206795 for ; Tue, 9 Jan 2001 17:04:28 +0100 (MET) Received: by sentry.gw.tislabs.com; id LAA14990; Tue, 9 Jan 2001 11:07:36 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma014966; Tue, 9 Jan 01 11:06:45 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jan 2001 11:00:56 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Charter last call summary Cc: lewis@tislabs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f09G4S206796 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Jaap Akkerhius APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: Patrik Fältström MAILING LISTS: General Discussion: ietf-provreg@cafax.se To Subscribe: majordomo@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ DESCRIPTION OF WORKING GROUP: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the 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" and the Extensible Provisioning Protocol presentation, documented in . 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: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f08KPv026712 for ietf-provreg-outgoing; Mon, 8 Jan 2001 21:25:57 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f08KPt226707 for ; Mon, 8 Jan 2001 21:25:55 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Tue, 9 Jan 2001 09:25:52 +1300 From: "Peter Mott" To: "Olivier Guillard" Cc: "Annie Renard" , , Subject: RE: Definition of Registry Date: Tue, 9 Jan 2001 09:25:51 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010108142719.A12581@james.nic.fr> Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > 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 -/- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f08Ep3D23666 for ietf-provreg-outgoing; Mon, 8 Jan 2001 15:51:03 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f08Ep2223661 for ; Mon, 8 Jan 2001 15:51:02 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA06936; Mon, 8 Jan 2001 09:40:32 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 09:46:17 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" Cc: ietf-provreg@cafax.se Subject: RE: comments on your grrp-reqs-05.txt (second try) Date: Mon, 8 Jan 2001 09:46:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks, Jaap. I'll answer your questions etc. below. > -----Original Message----- > From: Jaap Akkerhuis [mailto:jaap@sidn.nl] > Sent: Monday, January 08, 2001 7:34 AM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > 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. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f08DSUb22555 for ietf-provreg-outgoing; Mon, 8 Jan 2001 14:28:30 +0100 (MET) Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f08DSS222550 for ; Mon, 8 Jan 2001 14:28:28 +0100 (MET) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id OAA20230 ; Mon, 8 Jan 2001 14:27:12 +0100 (MET) Received: (from guillard@localhost) by james.nic.fr (8.10.1/8.10.1) id f08DRJk22019; Mon, 8 Jan 2001 14:27:19 +0100 Date: Mon, 8 Jan 2001 14:27:19 +0100 From: Olivier Guillard To: Peter Mott Cc: Annie Renard , budi@alliance.globalnetlink.com, ietf-provreg@cafax.se Subject: Re: Definition of Registry Message-ID: <20010108142719.A12581@james.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from peter@2day.com on Fri, Jan 05, 2001 at 11:15:10PM +1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:guillard@nic.fr Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f08CXcW21749 for ietf-provreg-outgoing; Mon, 8 Jan 2001 13:33:38 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaamjurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f08CXb221744 for ; Mon, 8 Jan 2001 13:33:37 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id NAA30798; Mon, 8 Jan 2001 13:33:37 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id NAA92463; Mon, 8 Jan 2001 13:33:36 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101081233.NAA92463@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: ietf-provreg@cafax.se Subject: comments on your grrp-reqs-05.txt (second try) Date: Mon, 08 Jan 2001 13:33:36 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f088IDg19443 for ietf-provreg-outgoing; Mon, 8 Jan 2001 09:18:13 +0100 (MET) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f088IB219438 for ; Mon, 8 Jan 2001 09:18:12 +0100 (MET) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id JAA00113; Mon, 8 Jan 2001 09:18:03 +0100 (MET) Message-ID: <3A597803.C53D87D2@knipp.de> Date: Mon, 08 Jan 2001 09:19:15 +0100 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: budi@alliance.globalnetlink.com CC: ietf-provreg@cafax.se Subject: Re: Ok. let's move on (was: RE: Definition of Registry) References: <200101052239.QAA09535@alliance.globalnetlink.com> <200101062307.RAA29377@alliance.globalnetlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk budi@alliance.globalnetlink.com 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f06MWrN07856 for ietf-provreg-outgoing; Sat, 6 Jan 2001 23:32:53 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f06MWq207851 for ; Sat, 6 Jan 2001 23:32:52 +0100 (MET) Received: from pentium3 (ppp19.bdg.melsa.net.id [202.138.227.19]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id RAA29377 for ; Sat, 6 Jan 2001 17:07:53 -0600 Message-Id: <200101062307.RAA29377@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Sun, 7 Jan 2001 05:35:40 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Ok. let's move on (was: RE: Definition of Registry) In-reply-to: References: <200101052239.QAA09535@alliance.globalnetlink.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f069WHh03859 for ietf-provreg-outgoing; Sat, 6 Jan 2001 10:32:17 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f069WF203854 for ; Sat, 6 Jan 2001 10:32:15 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Sat, 6 Jan 2001 22:32:11 +1300 From: "Peter Mott" To: , Subject: RE: Definition of Registry Date: Sat, 6 Jan 2001 22:32:11 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <200101052239.QAA09535@alliance.globalnetlink.com> Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f068gvD03631 for ietf-provreg-outgoing; Sat, 6 Jan 2001 09:42:57 +0100 (MET) Received: from server.vitzthum.at (N068P003.adsl.highway.telekom.at [213.33.8.99]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f068gt203626 for ; Sat, 6 Jan 2001 09:42:56 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Sat, 6 Jan 2001 09:42:15 +0100 From: "Herbert Vitzthum" To: "Klaus Malorny" , Cc: Subject: AW: Definition of Registry Date: Sat, 6 Jan 2001 09:42:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3A565BCE.467E16EE@knipp.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 06 Jan 2001 08:42:15.0761 (UTC) FILETIME=[92402C10:01C077BC] Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thats the perfect picture Herbert > -----Ursprungliche Nachricht----- > Von: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von Klaus Malorny > Gesendet: Samstag, 06. Janner 2001 00:42 > An: budi@alliance.globalnetlink.com > Cc: ietf-provreg@cafax.se > Betreff: Re: Definition of Registry > > > > > budi@alliance.globalnetlink.com 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 > Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05NdRZ00128 for ietf-provreg-outgoing; Sat, 6 Jan 2001 00:39:27 +0100 (MET) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05NdQ200123 for ; Sat, 6 Jan 2001 00:39:27 +0100 (MET) Received: from knipp.de (logan5.knipp.de [194.77.55.101]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id AAA14575; Sat, 6 Jan 2001 00:39:08 +0100 (MET) Message-ID: <3A565BCE.467E16EE@knipp.de> Date: Sat, 06 Jan 2001 00:42:06 +0100 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: budi@alliance.globalnetlink.com CC: ietf-provreg@cafax.se Subject: Re: Definition of Registry References: <200101050019.SAA19131@alliance.globalnetlink.com> <200101052239.QAA09535@alliance.globalnetlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk budi@alliance.globalnetlink.com 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05M4ki29007 for ietf-provreg-outgoing; Fri, 5 Jan 2001 23:04:46 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05M4j229002 for ; Fri, 5 Jan 2001 23:04:45 +0100 (MET) Received: from pentium3 (ppp3d.dialin.elga.net.id [202.173.64.131]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA09535 for ; Fri, 5 Jan 2001 16:39:29 -0600 Message-Id: <200101052239.QAA09535@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Sat, 6 Jan 2001 05:07:58 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Definition of Registry In-reply-to: References: <200101050019.SAA19131@alliance.globalnetlink.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05M3Io28986 for ietf-provreg-outgoing; Fri, 5 Jan 2001 23:03:18 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05M3H228981 for ; Fri, 5 Jan 2001 23:03:17 +0100 (MET) Received: from pentium3 (ppp3d.dialin.elga.net.id [202.173.64.131]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA09505 for ; Fri, 5 Jan 2001 16:38:00 -0600 Message-Id: <200101052238.QAA09505@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Sat, 6 Jan 2001 05:06:08 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Definition of Registry In-reply-to: References: <200101050019.SAA19131@alliance.globalnetlink.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05LLsv28689 for ietf-provreg-outgoing; Fri, 5 Jan 2001 22:21:54 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05LLr228684 for ; Fri, 5 Jan 2001 22:21:53 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA17717; Fri, 5 Jan 2001 22:21:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA78475; Fri, 5 Jan 2001 22:21:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101052121.WAA78475@bartok.sidn.nl> To: ietf-provreg@cafax.se cc: "Hollenbeck, Scott" Subject: Oh shit Date: Fri, 05 Jan 2001 22:21:51 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05LG4e28623 for ietf-provreg-outgoing; Fri, 5 Jan 2001 22:16:04 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05LG1228617 for ; Fri, 5 Jan 2001 22:16:01 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA17692; Fri, 5 Jan 2001 22:15:55 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id WAA78456; Fri, 5 Jan 2001 22:15:54 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101052115.WAA78456@bartok.sidn.nl> To: ietf-provreg@cafax.se cc: "Hollenbeck, Scott" Subject: comments on grrp-05 Date: Fri, 05 Jan 2001 22:15:54 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05KXf128259 for ietf-provreg-outgoing; Fri, 5 Jan 2001 21:33:41 +0100 (MET) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05KXd228254 for ; Fri, 5 Jan 2001 21:33:39 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f05KXaK11578; Fri, 5 Jan 2001 12:33:36 -0800 Date: Fri, 5 Jan 2001 12:33:36 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: "Ross Wm. Rader" cc: "Ietf-Provreg@Cafax. Se" Subject: Re: Domain Name/Whois Data Element and Related Definitions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05KFi528107 for ietf-provreg-outgoing; Fri, 5 Jan 2001 21:15:44 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05KFh228102 for ; Fri, 5 Jan 2001 21:15:43 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 21:15:03 +0100 From: "Herbert Vitzthum" To: "Ross Wm. Rader" , "Ietf-Provreg@Cafax. Se" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: AW: Domain Name/Whois Data Element and Related Definitions Date: Fri, 5 Jan 2001 21:15:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <009101c07721$6bb31b20$dd4ffea9@rader> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal X-OriginalArrivalTime: 05 Jan 2001 20:15:03.0556 (UTC) FILETIME=[302C9440:01C07754] Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Ross > -----Ursprüngliche Nachricht----- > Von: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05JBEu27596 for ietf-provreg-outgoing; Fri, 5 Jan 2001 20:11:14 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with SMTP id f05JBD227591 for ; Fri, 5 Jan 2001 20:11:13 +0100 (MET) Received: (qmail 17756 invoked from network); 5 Jan 2001 19:12:50 -0000 Received: from unknown (HELO nepal) (63.217.189.114) by ns1.saraf.net with SMTP; 5 Jan 2001 19:12:50 -0000 From: "Paul George" To: Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 14:14:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-reply-to: Sender: owner-ietf-provreg@cafax.se Precedence: bulk (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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Herbert Vitzthum Sent: Friday, January 05, 2001 3:35 AM To: Peter Mott; Jaap Akkerhuis; Hollenbeck, Scott Cc: Alf.Hansen@uninett.no; ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von Peter Mott > Gesendet: Donnerstag, 04. Jänner 2001 22:15 > An: Jaap Akkerhuis; Hollenbeck, Scott > Cc: Alf.Hansen@uninett.no; ietf-provreg@cafax.se > 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 > -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05IwGK27460 for ietf-provreg-outgoing; Fri, 5 Jan 2001 19:58:16 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05IwE227451 for ; Fri, 5 Jan 2001 19:58:14 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f05Gbmo00990 for ietf-provreg@cafax.se; Fri, 5 Jan 2001 17:37:48 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04GGV214504 for ; Thu, 4 Jan 2001 17:16:31 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id RAA11918; Thu, 4 Jan 2001 17:16:30 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id RAA73673; Thu, 4 Jan 2001 17:16:30 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101041616.RAA73673@bartok.sidn.nl> To: Alf.Hansen@uninett.no cc: ietf-provreg@cafax.se Subject: Re: Definition of Registry In-reply-to: Your message of Thu, 04 Jan 2001 16:12:08 +0100. Date: Thu, 04 Jan 2001 17:16:30 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05IwEc27455 for ietf-provreg-outgoing; Fri, 5 Jan 2001 19:58:14 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05Iw8227443 for ; Fri, 5 Jan 2001 19:58:08 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f05GdMu01012 for ietf-provreg@cafax.se; Fri, 5 Jan 2001 17:39:22 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03Mj0205112 for ; Wed, 3 Jan 2001 23:45:00 +0100 (MET) Received: by dnspri.npac.com; id QAA29509; Wed, 3 Jan 2001 16:44:58 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xma029491; Wed, 3 Jan 01 16:44:54 -0600 Message-Id: <5.0.2.1.2.20010103173834.0296a9f0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 03 Jan 2001 17:39:53 -0500 To: , From: Richard Shockey Subject: RE: Definition of Registry In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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... Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05F3jN25621 for ietf-provreg-outgoing; Fri, 5 Jan 2001 16:03:45 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05F3i225616 for ; Fri, 5 Jan 2001 16:03:45 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14EYP9-0003Do-00 for ietf-provreg@cafax.se; Fri, 05 Jan 2001 16:03:43 +0100 To: "Ietf-Provreg@Cafax. Se" Subject: Re: Domain Name/Whois Data Element and Related Definitions In-reply-to: Message from "Ross Wm. Rader" of "Fri, 05 Jan 2001 09:11:38 -0500." <009101c07721$6bb31b20$dd4ffea9@rader> References: <009101c07721$6bb31b20$dd4ffea9@rader> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12386.978707023.1@smtp.switch.ch> Date: Fri, 05 Jan 2001 16:03:43 +0100 Message-ID: <12387.978707023@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05ECfY24965 for ietf-provreg-outgoing; Fri, 5 Jan 2001 15:12:41 +0100 (MET) Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05ECe224960 for ; Fri, 5 Jan 2001 15:12:40 +0100 (MET) Received: from rader ([64.229.112.106]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010105141238.FPK1054.tomts6-srv.bellnexxia.net@rader>; Fri, 5 Jan 2001 09:12:38 -0500 Message-ID: <009d01c07721$c6efbc00$dd4ffea9@rader> From: "Ross Wm. Rader" To: "Herbert Vitzthum" , "Ietf-Provreg@Cafax. Se" References: Subject: Re: Domain Name/Whois Data Element and Related Definitions Date: Fri, 5 Jan 2001 09:14:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-provreg@cafax.se Precedence: bulk From: Herbert Vitzthum To: ; Ietf-Provreg@Cafax. Se 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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. ross@tucows.com > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05EA7w24911 for ietf-provreg-outgoing; Fri, 5 Jan 2001 15:10:07 +0100 (MET) Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05EA6224906 for ; Fri, 5 Jan 2001 15:10:07 +0100 (MET) Received: from rader ([64.229.112.106]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010105141005.ESF1054.tomts6-srv.bellnexxia.net@rader>; Fri, 5 Jan 2001 09:10:05 -0500 Message-ID: <009101c07721$6bb31b20$dd4ffea9@rader> From: "Ross Wm. Rader" To: "Ietf-Provreg@Cafax. Se" , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= References: Subject: Re: Domain Name/Whois Data Element and Related Definitions Date: Fri, 5 Jan 2001 09:11:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05DJif24521 for ietf-provreg-outgoing; Fri, 5 Jan 2001 14:19:44 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05DJh224516 for ; Fri, 5 Jan 2001 14:19:43 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14EWmU-0002G2-00 for ietf-provreg@cafax.se; Fri, 05 Jan 2001 14:19:42 +0100 To: ietf-provreg@cafax.se Subject: Re: Definition of Registry In-reply-to: Message from Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= of "Fri, 05 Jan 2001 12:07:33 +0100." References: <29108.978691105@smtp.switch.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8680.978700782.1@smtp.switch.ch> Date: Fri, 05 Jan 2001 14:19:42 +0100 Message-ID: <8681.978700782@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05Ccn324208 for ietf-provreg-outgoing; Fri, 5 Jan 2001 13:38:49 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05Ccm224203 for ; Fri, 5 Jan 2001 13:38:49 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA03398; Fri, 5 Jan 2001 07:28:09 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 07:34:01 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" Cc: ietf-provreg@cafax.se Subject: RE: hello and some initial comments Date: Fri, 5 Jan 2001 07:33:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f05Ccn224204 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. -----Original Message----- From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] Sent: Friday, January 05, 2001 7:28 AM To: Hollenbeck, Scott Cc: ietf-provreg@cafax.se 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? > > > 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05CWl024172 for ietf-provreg-outgoing; Fri, 5 Jan 2001 13:32:47 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05CWf224167 for ; Fri, 5 Jan 2001 13:32:41 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA03386 for ; Fri, 5 Jan 2001 07:22:41 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 07:28:33 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Herbert Vitzthum'" , ietf-provreg@cafax.se Subject: RE: Object Registration Date: Fri, 5 Jan 2001 07:28:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. > -----Original Message----- > From: Herbert Vitzthum [mailto:herbert@vitzthum.at] > Sent: Friday, January 05, 2001 7:17 AM > To: ietf-provreg@cafax.se > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05CQsn24127 for ietf-provreg-outgoing; Fri, 5 Jan 2001 13:26:54 +0100 (MET) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05CQr224122 for ; Fri, 5 Jan 2001 13:26:53 +0100 (MET) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id NAA03557; Fri, 5 Jan 2001 13:26:48 +0100 (MET) Message-ID: <3A55BDC7.6E45DDE@knipp.de> Date: Fri, 05 Jan 2001 13:27:51 +0100 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: hello and some initial comments References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "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? > > > 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05CHvS23871 for ietf-provreg-outgoing; Fri, 5 Jan 2001 13:17:57 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05CHt223866 for ; Fri, 5 Jan 2001 13:17:55 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 13:17:15 +0100 From: "Herbert Vitzthum" To: Subject: Object Registration Date: Fri, 5 Jan 2001 13:17:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C07719.D29A28E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-MS-TNEF-Correlator: X-OriginalArrivalTime: 05 Jan 2001 12:17:15.0854 (UTC) FILETIME=[70E466E0:01C07711] Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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" eJ8+Ig8MAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAQAFAA0AEQAAAAUAAQEB A5AGAOQFAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAFAAAAE9iamVjdCBSZWdpc3RyYXRpb24AAgFxAAEAAAAWAAAAAcB3EXCvZCoCJqw2TCaiimhl EI589wAAAgEdDAEAAAAZAAAAU01UUDpIRVJCRVJUQFZJVFpUSFVNLkFUAAAAAAsAAQ4AAAAAQAAG DgBGcWcRd8ABAgEKDgEAAAAYAAAAAAAAABnwQrkiIa1Dt7C9+9tUTwDCgAAACwAfDgEAAAACAQkQ AQAAAGoBAABmAQAAzwEAAExaRnV8AtCMAwAKAHJjcGcxMjUGMgD4C2BuZzMwN545AfcCpAPjAgBj aArAYHNldDAgBxMCgH0lCoF2CJB3awuAZDQdDGBjAFALAwu1IERl4QrBQWxsLAqiCoQKgAELgCB0 aGUgZHICYQGAIDMuNCBPjGJqBZAFQFJlZwQAUnQVoHRpAiA6FGpboDFdIG11FuAgB0Awc28gYhVw CfBkbDsHkAQgYQQgGOAHgCBjsGNUTEQEIBDwdhVw3G5vGKEDoBlBZBcQFXBfFSUFoAIwFaAWcC4X ezQtGFB0GPAYMDAYUFRotwQAG+AEIHAG8A3geRsx/mQYZBsAGQIcYQCQBIEJgK0b4mEVQAWQaAMA YwdAbx7gA2Ad8AjhLh5hFXByDRDQIAIQBcBzbXRw+Ri0ZG8HkRsCIFYcFwnweQVAb2YbMwDAAxAc 60LfB5AWgwsRELAUeUgEkBkQFwAgFGQR4QAp4AAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UA AAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABG AAAAAFKFAACOagEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAB4ACoAI IAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAA AAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAA AAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAA DoUAAAAAAAADADyACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAA AABGAAAAABiFAAAAAAAACwBSgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAA AADAAAAAAAAARgAAAAABhQAAAAAAAAIB+A8BAAAAEAAAABnwQrkiIa1Dt7C9+9tUTwACAfoPAQAA ABAAAAAZ8EK5IiGtQ7ewvfvbVE8AAgH7DwEAAACqAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBT VFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9rdW1lbnRlIHVuZCBFaW5zdGVs bHVuZ2VuXEhlcmJWLlZJVFpUSFVNXExva2FsZSBFaW5zdGVsbHVuZ2VuXEFud2VuZHVuZ3NkYXRl blxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29rLnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAA ADMAAAA8S05FRExITEFLRUFMSkpPTkdOQ0JBRUhKQ0FBQS5oZXJiZXJ0QHZpdHp0aHVtLmF0PgAA AwAGEKVL5BEDAAcQ4QAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABERUFSQUxMLElOVEhF RFJBRlQzNE9CSkVDVFJFR0lTVFJBVElPTjoxTVVTVEFMU09CRUVORExFU1NBU1NPTUVDQ1RMRFNI QVZFTk9UQU5FTkREQVRFSU5USEVDT05UUkFDVDRUAAAAAHg0 ------=_NextPart_000_0000_01C07719.D29A28E0-- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05CGLQ23828 for ietf-provreg-outgoing; Fri, 5 Jan 2001 13:16:21 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05CGK223823 for ; Fri, 5 Jan 2001 13:16:20 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA03375; Fri, 5 Jan 2001 07:05:32 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 07:11:24 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: hello and some initial comments Date: Fri, 5 Jan 2001 07:11:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? -----Original Message----- From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] Sent: Friday, January 05, 2001 3:47 AM To: ietf-provreg@cafax.se 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05BEKZ23418 for ietf-provreg-outgoing; Fri, 5 Jan 2001 12:14:20 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05BEJ223413 for ; Fri, 5 Jan 2001 12:14:19 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 12:13:40 +0100 From: "Herbert Vitzthum" To: , Subject: AW: Domain Name/Whois Data Element and Related Definitions Date: Fri, 5 Jan 2001 12:13:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200101051134.FAA32619@alliance.globalnetlink.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 05 Jan 2001 11:13:40.0077 (UTC) FILETIME=[8E8309D0:01C07708] Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von budi@alliance.globalnetlink.com > Gesendet: Freitag, 05. Jänner 2001 12:02 > An: ietf-provreg@cafax.se > 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: > my presentation materials, papers, scrapbook, ... and more > What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05BCpJ23391 for ietf-provreg-outgoing; Fri, 5 Jan 2001 12:12:51 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05BCo223386 for ; Fri, 5 Jan 2001 12:12:50 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 12:12:10 +0100 From: "Herbert Vitzthum" To: "Marcel Schneider" , Subject: AW: Definition of Registry Date: Fri, 5 Jan 2001 12:12:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <29108.978691105@smtp.switch.ch> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 05 Jan 2001 11:12:10.0678 (UTC) FILETIME=[5939D560:01C07708] Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Marcel, very clear view, thank you very much. Herbert > -----Ursprungliche Nachricht----- > Von: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von Marcel Schneider > Gesendet: Freitag, 05. Janner 2001 11:38 > An: ietf-provreg@cafax.se > 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 > > -/- > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05B7qs23349 for ietf-provreg-outgoing; Fri, 5 Jan 2001 12:07:52 +0100 (MET) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05B7p223344 for ; Fri, 5 Jan 2001 12:07:51 +0100 (MET) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id DAA28236; Fri, 5 Jan 2001 03:07:49 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f05B7nV03182; Fri, 5 Jan 2001 03:07:49 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id DAA24471; Fri, 5 Jan 2001 03:07:41 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <29108.978691105@smtp.switch.ch> References: <29108.978691105@smtp.switch.ch> Date: Fri, 5 Jan 2001 12:07:33 +0100 To: Marcel Schneider , ietf-provreg@cafax.se From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Definition of Registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05AxaZ23276 for ietf-provreg-outgoing; Fri, 5 Jan 2001 11:59:36 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05AxZ223271 for ; Fri, 5 Jan 2001 11:59:35 +0100 (MET) Received: from pentium3 (ppp10.bdg.melsa.net.id [202.138.227.10]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id FAA32619 for ; Fri, 5 Jan 2001 05:34:09 -0600 Message-Id: <200101051134.FAA32619@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Fri, 5 Jan 2001 18:02:05 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: Domain Name/Whois Data Element and Related Definitions In-reply-to: References: X-mailer: Pegasus Mail for Win32 (v3.12a) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by nic.cafax.se id f05Axa223272 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05AcSZ23121 for ietf-provreg-outgoing; Fri, 5 Jan 2001 11:38:28 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05AcR223116 for ; Fri, 5 Jan 2001 11:38:27 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14EUGP-0007ZV-00 for ietf-provreg@cafax.se; Fri, 05 Jan 2001 11:38:25 +0100 To: ietf-provreg@cafax.se Subject: Re: Definition of Registry In-reply-to: Message from "Peter Mott" of "Fri, 05 Jan 2001 23:15:10 +1300." References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29107.978691105.1@smtp.switch.ch> Date: Fri, 05 Jan 2001 11:38:25 +0100 Message-ID: <29108.978691105@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 > -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f05AFDb22958 for ietf-provreg-outgoing; Fri, 5 Jan 2001 11:15:13 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f05AFC222953 for ; Fri, 5 Jan 2001 11:15:12 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 5 Jan 2001 23:15:10 +1300 From: "Peter Mott" To: "Annie Renard" , Cc: Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 23:15:10 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200101050937.KAA18855@vespucci.nic.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f059nbP22765 for ietf-provreg-outgoing; Fri, 5 Jan 2001 10:49:37 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f059nW222760 for ; Fri, 5 Jan 2001 10:49:32 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 10:48:53 +0100 From: "Herbert Vitzthum" To: , "Ietf-Provreg@Cafax. Se" Subject: AW: Domain Name/Whois Data Element and Related Definitions Date: Fri, 5 Jan 2001 10:48:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 05 Jan 2001 09:48:53.0192 (UTC) FILETIME=[B67DFC80:01C076FC] Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]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. ross@tucows.com > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f059bQe22673 for ietf-provreg-outgoing; Fri, 5 Jan 2001 10:37:26 +0100 (MET) Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f059bO222668 for ; Fri, 5 Jan 2001 10:37:25 +0100 (MET) Received: from vespucci.nic.fr (IDENT:root@vespucci.nic.fr [192.134.4.68]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id KAA01591 ; Fri, 5 Jan 2001 10:36:51 +0100 (MET) Received: from vespucci.nic.fr (IDENT:renard@localhost.nic.fr [127.0.0.1]) by vespucci.nic.fr (8.9.3/8.9.3) with ESMTP id KAA18855; Fri, 5 Jan 2001 10:37:22 +0100 Message-Id: <200101050937.KAA18855@vespucci.nic.fr> From: Annie Renard To: budi@alliance.globalnetlink.com Cc: ietf-provreg@cafax.se Subject: Re: Definition of Registry In-reply-to: Your message of Fri, 05 Jan 2001 06:47:42 +0700. <200101050019.SAA19131@alliance.globalnetlink.com> Date: Fri, 05 Jan 2001 10:37:22 +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 [nic@nic.fr] AFNIC/NIC France c/o INRIA domaine de Voluceau BP105, 78153 Le Chesnay CEDEX, France http://www.nic.fr/ Personal Email: Annie.Renard@nic.fr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f058m7q22321 for ietf-provreg-outgoing; Fri, 5 Jan 2001 09:48:07 +0100 (MET) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f058m5222316 for ; Fri, 5 Jan 2001 09:48:06 +0100 (MET) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA00512; Fri, 5 Jan 2001 00:47:34 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f058lZY21618; Fri, 5 Jan 2001 00:47:35 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id AAA16975; Fri, 5 Jan 2001 00:47:27 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 5 Jan 2001 09:41:59 +0100 To: "Ross Wm. Rader" , "Ietf-Provreg@Cafax. Se" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Domain Name/Whois Data Element and Related Definitions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f058kPf22294 for ietf-provreg-outgoing; Fri, 5 Jan 2001 09:46:25 +0100 (MET) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f058kK222289 for ; Fri, 5 Jan 2001 09:46:20 +0100 (MET) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id JAA28380; Fri, 5 Jan 2001 09:46:19 +0100 (MET) Message-ID: <3A558A1B.E3A65A6D@knipp.de> Date: Fri, 05 Jan 2001 09:47:23 +0100 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: hello and some initial comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f058Zva22216 for ietf-provreg-outgoing; Fri, 5 Jan 2001 09:35:57 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f058Zu222211 for ; Fri, 5 Jan 2001 09:35:56 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 09:35:17 +0100 From: "Herbert Vitzthum" To: "Peter Mott" , "Jaap Akkerhuis" , "Hollenbeck, Scott" Cc: , Subject: AW: Definition of Registry Date: Fri, 5 Jan 2001 09:35:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 05 Jan 2001 08:35:17.0403 (UTC) FILETIME=[6E7A0EB0:01C076F2] Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von Peter Mott > Gesendet: Donnerstag, 04. Jänner 2001 22:15 > An: Jaap Akkerhuis; Hollenbeck, Scott > Cc: Alf.Hansen@uninett.no; ietf-provreg@cafax.se > 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 > -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f058YIR22192 for ietf-provreg-outgoing; Fri, 5 Jan 2001 09:34:18 +0100 (MET) Received: from server.vitzthum.at (N179P027.adsl.highway.telekom.at [213.33.22.91]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f058YG222187 for ; Fri, 5 Jan 2001 09:34:16 +0100 (MET) Received: from buero ([192.168.3.138]) by server.vitzthum.at with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Jan 2001 09:33:32 +0100 From: "Herbert Vitzthum" To: "Peter Mott" , , Subject: AW: Definition of Registry Date: Fri, 5 Jan 2001 09:33:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 05 Jan 2001 08:33:32.0642 (UTC) FILETIME=[3008CC20:01C076F2] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Ursprüngliche Nachricht----- > Von: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]Im > Auftrag von Peter Mott > Gesendet: Donnerstag, 04. Jänner 2001 22:06 > An: Alf.Hansen@uninett.no; ietf-provreg@cafax.se > 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 > -/- > > > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0516fH19050 for ietf-provreg-outgoing; Fri, 5 Jan 2001 02:06:41 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0516d219045 for ; Fri, 5 Jan 2001 02:06:40 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 5 Jan 2001 14:06:38 +1300 From: "Peter Mott" To: , Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 14:06:37 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200101050019.SAA19131@alliance.globalnetlink.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04NjDq18570 for ietf-provreg-outgoing; Fri, 5 Jan 2001 00:45:13 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04NjC218565 for ; Fri, 5 Jan 2001 00:45:12 +0100 (MET) Received: from pentium3 (ppp20d.dialin.elga.net.id [202.173.64.148]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id SAA19131 for ; Thu, 4 Jan 2001 18:19:36 -0600 Message-Id: <200101050019.SAA19131@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Fri, 5 Jan 2001 06:47:42 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Definition of Registry In-reply-to: References: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04Mwor18237 for ietf-provreg-outgoing; Thu, 4 Jan 2001 23:58:50 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04Mwn218232 for ; Thu, 4 Jan 2001 23:58:49 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14EJKi-00060J-00; Thu, 04 Jan 2001 17:58:08 -0500 Reply-To: From: "Ross Wm. Rader" To: "Ietf-Provreg@Cafax. Se" Subject: Domain Name/Whois Data Element and Related Definitions Date: Thu, 4 Jan 2001 17:59:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. ross@tucows.com 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04ME9i17861 for ietf-provreg-outgoing; Thu, 4 Jan 2001 23:14:09 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04ME7217856 for ; Thu, 4 Jan 2001 23:14:07 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 5 Jan 2001 11:14:05 +1300 From: "Peter Mott" To: "Mike Lampson" , Cc: Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 11:14:05 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <083b01c07699$09ad4c80$5591a6a5@IS.INFOAVE.NET> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > (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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04Lte317622 for ietf-provreg-outgoing; Thu, 4 Jan 2001 22:55:40 +0100 (MET) Received: from smtp02.infoave.net (smtp02.infoave.net [165.166.0.27]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04Ltd217617 for ; Thu, 4 Jan 2001 22:55:39 +0100 (MET) Received: from KR ([165.166.145.85]) by SMTP00.InfoAve.Net (PMDF V6.0-24 #45321) with SMTP id <01JYILVF5AUI9EFTVD@SMTP00.InfoAve.Net> for ietf-provreg@cafax.se; Thu, 04 Jan 2001 16:55:23 -0500 (EST) Date: Thu, 04 Jan 2001 16:55:22 -0500 From: Mike Lampson Subject: Re: Definition of Registry To: ietf-provreg@cafax.se Cc: Peter Mott , Alf.Hansen@uninett.no Message-id: <083b01c07699$09ad4c80$5591a6a5@IS.INFOAVE.NET> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04LFVO17271 for ietf-provreg-outgoing; Thu, 4 Jan 2001 22:15:31 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04LFT217266 for ; Thu, 4 Jan 2001 22:15:29 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 5 Jan 2001 10:15:28 +1300 From: "Peter Mott" To: "Jaap Akkerhuis" , "Hollenbeck, Scott" Cc: , Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 10:15:28 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200101041319.OAA72923@bartok.sidn.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04L62C17181 for ietf-provreg-outgoing; Thu, 4 Jan 2001 22:06:02 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04L60217174 for ; Thu, 4 Jan 2001 22:06:01 +0100 (MET) Received: from cdt2 (unverified [202.37.240.50]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 5 Jan 2001 10:05:58 +1300 From: "Peter Mott" To: , Subject: RE: Definition of Registry Date: Fri, 5 Jan 2001 10:05:57 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 -/- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04FDjO13619 for ietf-provreg-outgoing; Thu, 4 Jan 2001 16:13:45 +0100 (MET) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04FDj213614 for ; Thu, 4 Jan 2001 16:13:45 +0100 (MET) Received: from alf (IDENT:root@leangen.uninett.no [158.38.60.11]) by tyholt.uninett.no (8.11.1/8.11.1) with SMTP id f04FDif00693 for ; Thu, 4 Jan 2001 16:13:44 +0100 Reply-To: From: "Alf Hansen" To: Subject: Re: Definition of Registry Date: Thu, 4 Jan 2001 16:12:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of Marcos Sanz/Denic > Sent: 4. januar 2001 15:24 > To: Jaap Akkerhuis > Cc: ietf-provreg@cafax.se > Subject: Re: Re: Defenition of Registry > > > On 04.01.01 14:19 Jaap Akkerhuis 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) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04Ef5713241 for ietf-provreg-outgoing; Thu, 4 Jan 2001 15:41:05 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04Ef4213236 for ; Thu, 4 Jan 2001 15:41:04 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id PAA11308; Thu, 4 Jan 2001 15:41:04 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id PAA73342; Thu, 4 Jan 2001 15:41:03 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101041441.PAA73342@bartok.sidn.nl> To: Dave Crocker cc: ietf-provreg@cafax.se Subject: Re: Draft provreg charter (v01) In-reply-to: Your message of Tue, 02 Jan 2001 09:31:03 -0800. <5.0.2.1.2.20010102092925.033f8d10@mail.bayarea.net> Date: Thu, 04 Jan 2001 15:41:03 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04EOjE13051 for ietf-provreg-outgoing; Thu, 4 Jan 2001 15:24:45 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04EOi213046 for ; Thu, 4 Jan 2001 15:24:44 +0100 (MET) Subject: Re: Re: Defenition of Registry To: Jaap Akkerhuis Cc: ietf-provreg@cafax.se X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Marcos Sanz/Denic" Date: Thu, 4 Jan 2001 15:23:40 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 04.01.2001 15:23:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 04.01.01 14:19 Jaap Akkerhuis 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) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04DJIs12428 for ietf-provreg-outgoing; Thu, 4 Jan 2001 14:19:18 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04DJH212423 for ; Thu, 4 Jan 2001 14:19:17 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id OAA10557; Thu, 4 Jan 2001 14:19:17 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost [127.0.0.1]) by bartok.sidn.nl (8.9.3/8.9.3) with ESMTP id OAA72923; Thu, 4 Jan 2001 14:19:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101041319.OAA72923@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: "'Alf.Hansen@uninett.no'" , ietf-provreg@cafax.se Subject: Re: Defenition of Registry In-reply-to: Your message of Thu, 04 Jan 2001 07:58:14 -0500. Date: Thu, 04 Jan 2001 14:19:16 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f04D2U512047 for ietf-provreg-outgoing; Thu, 4 Jan 2001 14:02:30 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f04D2S212042 for ; Thu, 4 Jan 2001 14:02:28 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA01159; Thu, 4 Jan 2001 07:52:22 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 07:58:14 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Alf.Hansen@uninett.no'" , ietf-provreg@cafax.se Subject: RE: Defenition of Registry Date: Thu, 4 Jan 2001 07:58:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:Alf.Hansen@uninett.no] Sent: Wednesday, January 03, 2001 4:22 PM To: Hollenbeck, Scott; ietf-provreg@cafax.se Subject: RE: Defenition of Registry Scott, > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: 3. januar 2001 15:59 > To: 'Alf.Hansen@uninett.no'; ietf-provreg@cafax.se > 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f049gDQ10437 for ietf-provreg-outgoing; Thu, 4 Jan 2001 10:42:13 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f049gC210432 for ; Thu, 4 Jan 2001 10:42:12 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14E6uR-0002BZ-00 for ietf-provreg@cafax.se; Thu, 04 Jan 2001 10:42:11 +0100 To: ietf-provreg@cafax.se Subject: Re: Defenition of Registry In-reply-to: Message from "Alf Hansen" of "Wed, 03 Jan 2001 22:21:35 +0100." References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8403.978601331.1@smtp.switch.ch> Date: Thu, 04 Jan 2001 10:42:11 +0100 Message-ID: <8404.978601331@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f047u1g09512 for ietf-provreg-outgoing; Thu, 4 Jan 2001 08:56:01 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.pilsnet.sunet.se [192.36.125.212]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f047tx209504 for ; Thu, 4 Jan 2001 08:55:59 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f047ssT01255 for ietf-provreg@cafax.se; Thu, 4 Jan 2001 08:54:54 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03Mj0205112 for ; Wed, 3 Jan 2001 23:45:00 +0100 (MET) Received: by dnspri.npac.com; id QAA29509; Wed, 3 Jan 2001 16:44:58 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xma029491; Wed, 3 Jan 01 16:44:54 -0600 Message-Id: <5.0.2.1.2.20010103173834.0296a9f0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 03 Jan 2001 17:39:53 -0500 To: , From: Richard Shockey Subject: RE: Definition of Registry In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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... Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f041Ui506501 for ietf-provreg-outgoing; Thu, 4 Jan 2001 02:30:44 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f041Uh206496 for ; Thu, 4 Jan 2001 02:30:44 +0100 (MET) Received: from 207-172-149-166.s39.as6.anp.md.dialup.rcn.com ([207.172.149.166]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14DzEn-0001xu-00 ; Wed, 03 Jan 2001 20:30:41 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 2001 20:24:11 -0500 To: Karl Auerbach From: Edward Lewis Subject: belated response to Re: Comments on overall direction Cc: Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03LmFD04663 for ietf-provreg-outgoing; Wed, 3 Jan 2001 22:48:15 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03LmF204655 for ; Wed, 3 Jan 2001 22:48:15 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14Dvkt-00008t-00 for ietf-provreg@cafax.se; Wed, 03 Jan 2001 16:47:35 -0500 Reply-To: From: "Ross Wm. Rader" To: Subject: RE: Definition of Registry Date: Wed, 3 Jan 2001 16:48:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of Alf Hansen < Sent: Wednesday, January 03, 2001 4:22 PM < To: Hollenbeck, Scott; ietf-provreg@cafax.se < Subject: RE: Defenition of Registry < < < Scott, < < > -----Original Message----- < > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] < > Sent: 3. januar 2001 15:59 < > To: 'Alf.Hansen@uninett.no'; ietf-provreg@cafax.se < > 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 < Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03LNJl04474 for ietf-provreg-outgoing; Wed, 3 Jan 2001 22:23:19 +0100 (MET) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03LNI204469 for ; Wed, 3 Jan 2001 22:23:18 +0100 (MET) Received: from alf (marinen.uninett.no [158.38.60.135]) by tyholt.uninett.no (8.11.1/8.11.1) with SMTP id f03LNBf21779; Wed, 3 Jan 2001 22:23:11 +0100 Reply-To: From: "Alf Hansen" To: "Hollenbeck, Scott" , Subject: RE: Defenition of Registry Date: Wed, 3 Jan 2001 22:21:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: 3. januar 2001 15:59 > To: 'Alf.Hansen@uninett.no'; ietf-provreg@cafax.se > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03KjPi04151 for ietf-provreg-outgoing; Wed, 3 Jan 2001 21:45:25 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03KjO204146 for ; Wed, 3 Jan 2001 21:45:24 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA00260; Wed, 3 Jan 2001 15:35:24 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 15:41:18 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Karl Auerbach'" Cc: Edward Lewis , ietf-provreg@cafax.se Subject: RE: provreg mailing list LAST CALL: charter Date: Wed, 3 Jan 2001 15:41:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:karl@CaveBear.com] Sent: Wednesday, January 03, 2001 3:10 PM To: Hollenbeck, Scott Cc: Edward Lewis; ietf-provreg@cafax.se 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03KAt103898 for ietf-provreg-outgoing; Wed, 3 Jan 2001 21:10:55 +0100 (MET) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03KAs203893 for ; Wed, 3 Jan 2001 21:10:54 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f03KAKE06569; Wed, 3 Jan 2001 12:10:20 -0800 Date: Wed, 3 Jan 2001 12:10:20 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: "Hollenbeck, Scott" cc: Edward Lewis , Subject: RE: provreg mailing list LAST CALL: charter In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03IjCW03214 for ietf-provreg-outgoing; Wed, 3 Jan 2001 19:45:12 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03IjB203207 for ; Wed, 3 Jan 2001 19:45:11 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA29883; Wed, 3 Jan 2001 13:35:10 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 13:41:04 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Karl Auerbach'" , Edward Lewis Cc: ietf-provreg@cafax.se Subject: RE: provreg mailing list LAST CALL: charter Date: Wed, 3 Jan 2001 13:40:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:karl@CaveBear.com] Sent: Wednesday, January 03, 2001 1:29 PM To: Edward Lewis Cc: ietf-provreg@cafax.se 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03ITUY03032 for ietf-provreg-outgoing; Wed, 3 Jan 2001 19:29:30 +0100 (MET) Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03ITR203027 for ; Wed, 3 Jan 2001 19:29:28 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id f03ITHf06335; Wed, 3 Jan 2001 10:29:17 -0800 Date: Wed, 3 Jan 2001 10:29:16 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Edward Lewis cc: Subject: Re: provreg mailing list LAST CALL: charter In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03FPno01019 for ietf-provreg-outgoing; Wed, 3 Jan 2001 16:25:49 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03FPh201014 for ; Wed, 3 Jan 2001 16:25:44 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f03FOd300858 for ietf-provreg@cafax.se; Wed, 3 Jan 2001 16:24:39 +0100 (MET) Received: from bastiont.npac.com (bastiont.npac.com [208.143.34.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02I8v220868 for ; Tue, 2 Jan 2001 19:08:57 +0100 (MET) Received: by bastiont.npac.com; id NAA09950; Tue, 2 Jan 2001 13:07:56 -0500 (EST) Received: from unknown(192.168.20.111) by bastiont.npac.com via smap (V5.0) id xmab09944; Tue, 2 Jan 01 13:07:19 -0500 Message-Id: <5.0.2.1.2.20010102124456.02afab00@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 12:46:29 -0500 To: "Hollenbeck, Scott" , ietf-provreg@cafax.se From: Richard Shockey Subject: RE: One additional requirement... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:rich.shockey@neustar.com] >Sent: Friday, December 22, 2000 1:02 PM >To: ietf-provreg@cafax.se >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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03FMFI00837 for ietf-provreg-outgoing; Wed, 3 Jan 2001 16:22:15 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03FLv200822 for ; Wed, 3 Jan 2001 16:21:57 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f03FKqC00816 for ietf-provreg@cafax.se; Wed, 3 Jan 2001 16:20:52 +0100 (MET) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02Fqv219691 for ; Tue, 2 Jan 2001 16:52:57 +0100 (MET) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f02Ffp017406; Tue, 2 Jan 2001 07:41:51 -0800 (PST) Message-ID: <00bc01c074d3$fd7c30f0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Hollenbeck, Scott" , "'Edward Lewis'" , Cc: "Marshall Rose" References: Subject: Re: State of Provreg Date: Tue, 2 Jan 2001 07:52:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03FMFB00836 for ietf-provreg-outgoing; Wed, 3 Jan 2001 16:22:15 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03FMD200827 for ; Wed, 3 Jan 2001 16:22:13 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f03FL8e00832 for ietf-provreg@cafax.se; Wed, 3 Jan 2001 16:21:08 +0100 (MET) Received: from dorsey.fcc.net (dorsey.fcc.net [207.198.253.29]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02GNI219969 for ; Tue, 2 Jan 2001 17:23:19 +0100 (MET) Received: from j51.com ([216.44.71.168]) by dorsey.fcc.net (Post.Office MTA v3.5.3 release 223 ID# 0-57968U12500L1250S0V35) with ESMTP id net for ; Tue, 2 Jan 2001 11:25:35 -0500 Message-ID: <3A5200C5.E4C77990@j51.com> Date: Tue, 02 Jan 2001 11:24:37 -0500 From: Jordan Glogau X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: SUBSCRIBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk SUBSCRIBE Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03FMFI00837 for ietf-provreg-outgoing; Wed, 3 Jan 2001 16:22:15 +0100 (MET) Received: from naptop.pilsnet.sunet.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03FLv200822 for ; Wed, 3 Jan 2001 16:21:57 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f03FKqC00816 for ietf-provreg@cafax.se; Wed, 3 Jan 2001 16:20:52 +0100 (MET) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02Fqv219691 for ; Tue, 2 Jan 2001 16:52:57 +0100 (MET) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f02Ffp017406; Tue, 2 Jan 2001 07:41:51 -0800 (PST) Message-ID: <00bc01c074d3$fd7c30f0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Hollenbeck, Scott" , "'Edward Lewis'" , Cc: "Marshall Rose" References: Subject: Re: State of Provreg Date: Tue, 2 Jan 2001 07:52:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03F3Ak00521 for ietf-provreg-outgoing; Wed, 3 Jan 2001 16:03:10 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03F39200516 for ; Wed, 3 Jan 2001 16:03:10 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA29166; Wed, 3 Jan 2001 09:52:58 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 09:58:53 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Alf.Hansen@uninett.no'" , ietf-provreg@cafax.se Subject: RE: Defenition of Registry Date: Wed, 3 Jan 2001 09:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:Alf.Hansen@uninett.no] Sent: Wednesday, January 03, 2001 8:04 AM To: ietf-provreg@cafax.se 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03ERQv29979 for ietf-provreg-outgoing; Wed, 3 Jan 2001 15:27:26 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03ERP229974 for ; Wed, 3 Jan 2001 15:27:25 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA11081; Wed, 3 Jan 2001 09:30:31 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma011063; Wed, 3 Jan 01 09:29:59 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 2001 09:24:31 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: provreg mailing list LAST CALL: charter Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03EEvx29844 for ietf-provreg-outgoing; Wed, 3 Jan 2001 15:14:57 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03EEu229839 for ; Wed, 3 Jan 2001 15:14:57 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA28956; Wed, 3 Jan 2001 09:04:07 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 09:10:01 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'budi@alliance.globalnetlink.com'" , ietf-provreg@cafax.se Subject: RE: Requirements for object existence queries Date: Wed, 3 Jan 2001 09:09:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: budi@alliance.globalnetlink.com [mailto:budi@alliance.globalnetlink.com] Sent: Wednesday, January 03, 2001 8:08 AM To: ietf-provreg@cafax.se 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] Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03D5w329047 for ietf-provreg-outgoing; Wed, 3 Jan 2001 14:05:58 +0100 (MET) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03D5v229041 for ; Wed, 3 Jan 2001 14:05:57 +0100 (MET) Received: from alf (IDENT:root@leangen.uninett.no [158.38.60.11]) by tyholt.uninett.no (8.11.1/8.11.1) with SMTP id f03D5vf19067 for ; Wed, 3 Jan 2001 14:05:57 +0100 Reply-To: From: "Alf Hansen" To: Subject: Defenition of Registry Date: Wed, 3 Jan 2001 14:04:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03D5Tp29031 for ietf-provreg-outgoing; Wed, 3 Jan 2001 14:05:29 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03D5S229026 for ; Wed, 3 Jan 2001 14:05:28 +0100 (MET) Received: from pentium3 (ppp41.bdg.melsa.net.id [202.138.227.41]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id HAA26508 for ; Wed, 3 Jan 2001 07:39:28 -0600 Message-Id: <200101031339.HAA26508@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Wed, 3 Jan 2001 20:08:21 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Requirements for object existence queries In-reply-to: <4.3.1.2.20010102170144.0472c470@mail.forman.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f03Btfv28501 for ietf-provreg-outgoing; Wed, 3 Jan 2001 12:55:41 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f03Bte228496 for ; Wed, 3 Jan 2001 12:55:40 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA28748; Wed, 3 Jan 2001 06:44:54 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 06:50:49 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Martin Oldfield'" , ietf-provreg@cafax.se Subject: RE: Where is the requirements draft ? Date: Wed, 3 Jan 2001 06:50:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-05.txt Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Martin Oldfield [mailto:m@mail.tc] Sent: Wednesday, January 03, 2001 4:55 AM To: ietf-provreg@cafax.se 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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f039tQS27556 for ietf-provreg-outgoing; Wed, 3 Jan 2001 10:55:26 +0100 (MET) Received: from joanna.william.org (joanna.william.org [195.153.6.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f039tQ227551 for ; Wed, 3 Jan 2001 10:55:26 +0100 (MET) Received: from mjo by joanna.william.org with local (Exim 3.16 #1) id 14DkdZ-0006kj-00 (Debian); Wed, 03 Jan 2001 09:55:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 3 Jan 2001 09:55:17 +0000 (GMT) To: ietf-provreg@cafax.se Subject: Where is the requirements draft ? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14930.63159.263472.661730@joanna.william.org> From: Martin Oldfield Sender: owner-ietf-provreg@cafax.se Precedence: bulk Sorry if this is obvious to the congoscenti, but where can I find a copy of the requirements draft ? Cheers, -- Martin Oldfield, AdamsNames Ltd. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02MH3h22787 for ietf-provreg-outgoing; Tue, 2 Jan 2001 23:17:03 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02MH2222782 for ; Tue, 2 Jan 2001 23:17:02 +0100 (MET) Received: from [10.10.24.36] (helo=techpc3.forman.com) by rcommail2 with esmtp (Exim 3.16 #2) id 14DZjo-0002EE-00 for ietf-provreg@cafax.se; Tue, 02 Jan 2001 17:17:00 -0500 Message-Id: <4.3.1.2.20010102170144.0472c470@mail.forman.com> X-Sender: dcohen@mail.forman.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 02 Jan 2001 17:16:00 -0500 To: ietf-provreg@cafax.se From: Dan Cohen Subject: Requirements for object existence queries Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02L3Eg22286 for ietf-provreg-outgoing; Tue, 2 Jan 2001 22:03:14 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02L3D222281 for ; Tue, 2 Jan 2001 22:03:13 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA27906; Tue, 2 Jan 2001 15:53:07 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 15:59:03 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Dave Crocker'" , ietf-provreg@cafax.se Subject: RE: Draft provreg charter (v01) Date: Tue, 2 Jan 2001 15:58:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk We have mailing list and archive information, described below. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Dave Crocker [mailto:dcrocker@brandenburg.com] Sent: Tuesday, January 02, 2001 12:31 PM To: ietf-provreg@cafax.se Subject: Draft provreg charter (v01) [snip] MAILING LISTS: General Discussion: ietf-provreg@cafax.se To Subscribe: majordomo@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ [snip] Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02IAbF20898 for ietf-provreg-outgoing; Tue, 2 Jan 2001 19:10:37 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02IAa220893 for ; Tue, 2 Jan 2001 19:10:36 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14DVtL-0001LI-00 for ietf-provreg@cafax.se; Tue, 02 Jan 2001 19:10:35 +0100 To: ietf-provreg@cafax.se Subject: Re: Draft provreg charter (v01) In-reply-to: Your message of "Tue, 02 Jan 2001 09:31:03 PST." <5.0.2.1.2.20010102092925.033f8d10@mail.bayarea.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5162.978459035.1@smtp.switch.ch> Date: Tue, 02 Jan 2001 19:10:35 +0100 Message-ID: <5163.978459035@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02I8l020858 for ietf-provreg-outgoing; Tue, 2 Jan 2001 19:08:47 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02I8l220853 for ; Tue, 2 Jan 2001 19:08:47 +0100 (MET) Received: from central ([130.59.4.1] helo=smtp.switch.ch) by central.switch.ch with esmtp (Exim 3.15 #3) id 14DVrX-0001Kt-00 for ietf-provreg@cafax.se; Tue, 02 Jan 2001 19:08:43 +0100 cc: ietf-provreg@cafax.se Subject: Re: Draft provreg charter (v01) In-reply-to: Message from Dave Crocker of "Tue, 02 Jan 2001 09:31:03 -0800." <5.0.2.1.2.20010102092925.033f8d10@mail.bayarea.net> References: <5.0.2.1.2.20010102092925.033f8d10@mail.bayarea.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5137.978458923.1@smtp.switch.ch> Date: Tue, 02 Jan 2001 19:08:43 +0100 Message-ID: <5138.978458923@smtp.switch.ch> From: Marcel Schneider Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02HUjo20489 for ietf-provreg-outgoing; Tue, 2 Jan 2001 18:30:45 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02HUi220484 for ; Tue, 2 Jan 2001 18:30:44 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id JAA01055 for ; Tue, 2 Jan 2001 09:30:43 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.0.2.1.2.20010102092925.033f8d10@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 09:31:03 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Draft provreg charter (v01) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Provisioning Registry Protocol (ProvReg) ------------------------------- CHAIR(S): Edward Lewis APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed 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 . 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02HS6u20462 for ietf-provreg-outgoing; Tue, 2 Jan 2001 18:28:06 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02HS5220457 for ; Tue, 2 Jan 2001 18:28:05 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id JAA00992; Tue, 2 Jan 2001 09:27:03 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.0.2.1.2.20010102092032.03421d00@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 09:21:22 -0800 To: "Christopher Ambler" From: Dave Crocker Subject: Re: Draft provreg charter Cc: In-Reply-To: <01b501c0716a$b860d640$140a0a0a@ambler.net> References: <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02GxgD20228 for ietf-provreg-outgoing; Tue, 2 Jan 2001 17:59:42 +0100 (MET) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02Gxf220223 for ; Tue, 2 Jan 2001 17:59:42 +0100 (MET) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f02H5hd00114; Tue, 2 Jan 2001 12:05:43 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010102114234.037bae68@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 12:02:22 -0500 To: "Hollenbeck, Scott" , "'Edward Lewis'" , ietf-provreg@cafax.se From: Marc Blanchet Subject: RE: State of Provreg In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:lewis@tislabs.com] >Sent: Tuesday, January 02, 2001 10:04 AM >To: ietf-provreg@cafax.se >Cc: lewis@tislabs.com >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: lewis@tislabs.com > >"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. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02GlFY20127 for ietf-provreg-outgoing; Tue, 2 Jan 2001 17:47:15 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02GlD220122 for ; Tue, 2 Jan 2001 17:47:14 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id IAA32701; Tue, 2 Jan 2001 08:47:02 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.0.2.1.2.20010102083810.034fc850@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 08:42:18 -0800 To: Rick H Wesson From: Dave Crocker Subject: RE: State of Provreg Cc: "Hollenbeck, Scott" , "'Edward Lewis'" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02GRDq20002 for ietf-provreg-outgoing; Tue, 2 Jan 2001 17:27:13 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02GRB219997 for ; Tue, 2 Jan 2001 17:27:12 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id IAA32425; Tue, 2 Jan 2001 08:27:00 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.0.2.1.2.20010102081521.03a6bec0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 08:24:12 -0800 To: "Paul M. Kane" From: Dave Crocker Subject: Re: Draft provreg charter Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se In-Reply-To: <3A5095E2.EFF72FED@REACTO.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02GJgb19930 for ietf-provreg-outgoing; Tue, 2 Jan 2001 17:19:42 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02GJf219925 for ; Tue, 2 Jan 2001 17:19:41 +0100 (MET) Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id IAA24000; Tue, 2 Jan 2001 08:19:28 -0800 (PST) Date: Tue, 2 Jan 2001 08:19:27 -0800 (PST) From: Rick H Wesson To: "Hollenbeck, Scott" cc: "'Edward Lewis'" , Subject: RE: State of Provreg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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? > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02GH3b19904 for ietf-provreg-outgoing; Tue, 2 Jan 2001 17:17:03 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02GH1219899 for ; Tue, 2 Jan 2001 17:17:02 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id IAA32093; Tue, 2 Jan 2001 08:16:59 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.0.2.1.2.20010102081229.03a69380@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 08:13:08 -0800 To: "Hollenbeck, Scott" From: Dave Crocker Subject: RE: Draft provreg charter Cc: ietf-provreg@cafax.se In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02FjF519627 for ietf-provreg-outgoing; Tue, 2 Jan 2001 16:45:15 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02FjE219622 for ; Tue, 2 Jan 2001 16:45:14 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27097; Tue, 2 Jan 2001 10:35:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 10:41:11 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: State of Provreg Date: Tue, 2 Jan 2001 10:41:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:lewis@tislabs.com] Sent: Tuesday, January 02, 2001 10:04 AM To: ietf-provreg@cafax.se Cc: lewis@tislabs.com 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: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02F6XD19311 for ietf-provreg-outgoing; Tue, 2 Jan 2001 16:06:33 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02F6W219306 for ; Tue, 2 Jan 2001 16:06:32 +0100 (MET) Received: by sentry.gw.tislabs.com; id KAA12233; Tue, 2 Jan 2001 10:09:38 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xmab12181; Tue, 2 Jan 01 10:09:15 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Jan 2001 10:04:18 -0500 To: From: Edward Lewis Subject: State of Provreg Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02DmoE18485 for ietf-provreg-outgoing; Tue, 2 Jan 2001 14:48:50 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02Dmn218480 for ; Tue, 2 Jan 2001 14:48:49 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26775; Tue, 2 Jan 2001 08:38:49 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 08:44:46 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Richard Shockey'" , ietf-provreg@cafax.se Subject: RE: One additional requirement... Date: Tue, 2 Jan 2001 08:44:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:rich.shockey@neustar.com] Sent: Friday, December 22, 2000 1:02 PM To: ietf-provreg@cafax.se Subject: One additional requirement... IMHO we should be explicit in our requirements document that we invent no new transport protocols. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02Dgem18446 for ietf-provreg-outgoing; Tue, 2 Jan 2001 14:42:40 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02Dgd218441 for ; Tue, 2 Jan 2001 14:42:39 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26751 for ; Tue, 2 Jan 2001 08:32:39 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 08:38:36 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Draft provreg charter Date: Tue, 2 Jan 2001 08:38:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:rshockey@ix.netcom.com] Sent: Saturday, December 30, 2000 11:34 AM To: Edward Lewis; Christopher Ambler Cc: ietf-provreg@cafax.se; lewis@tislabs.com 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 . 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 :-) Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02AUpE16960 for ietf-provreg-outgoing; Tue, 2 Jan 2001 11:30:51 +0100 (MET) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02AUn216955; Tue, 2 Jan 2001 11:30:49 +0100 (MET) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id CAA14492; Tue, 2 Jan 2001 02:30:56 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f02AUoo13114; Tue, 2 Jan 2001 02:30:50 -0800 (PST) Received: from [192.168.1.11] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id CAA17929; Tue, 2 Jan 2001 02:30:40 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010102103838Z.liman@autonomica.se> References: <20010102103838Z.liman@autonomica.se> Date: Tue, 2 Jan 2001 11:29:10 +0100 To: Lars-Johan Liman , ietf-provreg@cafax.se From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Provreg list administratrivia. Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10.38 +0100 01-01-02, Lars-Johan Liman wrote: >Please note that the mail server for the >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 -archive@lists.ietf.org must be subscribed to the mailing list. paf -- Patrik Fältström 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 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02AL8u16898 for ietf-provreg-outgoing; Tue, 2 Jan 2001 11:21:08 +0100 (MET) Received: from naptop.pilsnet.sunet.se (fliptop.pilsnet.sunet.se [192.36.125.196]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f02AL6216893 for ; Tue, 2 Jan 2001 11:21:06 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f029ccu02875 for ; Tue, 2 Jan 2001 10:38:38 +0100 (MET) To: ietf-provreg@cafax.se Subject: Provreg list administratrivia. From: Lars-Johan Liman X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010102103838Z.liman@autonomica.se> Date: Tue, 02 Jan 2001 10:38:38 +0100 X-Dispatcher: imput version 990905(IM130) Lines: 16 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Folks, Please note that the mail server for the 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: liman@autonomica.se # Autonomica AB, Stockholm ! HTTP : //www.autonomica.se/ #---------------------------------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f029Mpd16158 for ietf-provreg-outgoing; Tue, 2 Jan 2001 10:22:51 +0100 (MET) Received: from naptop.pilsnet.sunet.se (fliptop.pilsnet.sunet.se [192.36.125.196]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f029Ml216153 for ; Tue, 2 Jan 2001 10:22:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f029MCv02605 for ietf-provreg@cafax.se; Tue, 2 Jan 2001 10:22:12 +0100 (MET) Received: from www.io.io (www.io.io [194.205.62.108]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f01EXe209723 for ; Mon, 1 Jan 2001 15:33:40 +0100 (MET) Received: from REACTO.com (atl-tgn-yds-vty19.as.wcom.net [216.192.188.19]) by www.io.io (8.9.3/8.8.7) with ESMTP id OAA17486; Mon, 1 Jan 2001 14:36:46 GMT Message-ID: <3A5095E2.EFF72FED@REACTO.com> Date: Mon, 01 Jan 2001 14:36:19 +0000 From: "Paul M. Kane" Organization: REACTO.com X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: Draft provreg charter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f02980s15970 for ietf-provreg-outgoing; Tue, 2 Jan 2001 10:08:00 +0100 (MET) Received: from naptop.pilsnet.sunet.se (fliptop.pilsnet.sunet.se [192.36.125.196]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0297u215946 for ; Tue, 2 Jan 2001 10:07:57 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0297Lv02175 for ietf-provreg@cafax.se; Tue, 2 Jan 2001 10:07:21 +0100 (MET) Received: from bastiont.npac.com (bastiont.npac.com [208.143.34.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBMI0o221807 for ; Fri, 22 Dec 2000 19:00:50 +0100 (MET) Received: by bastiont.npac.com; id NAA10207; Fri, 22 Dec 2000 13:00:49 -0500 (EST) Received: from unknown(192.168.20.111) by bastiont.npac.com via smap (V5.0) id xma010203; Fri, 22 Dec 00 13:00:15 -0500 Message-Id: <5.0.2.1.2.20001222130052.02a72b60@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 22 Dec 2000 13:01:46 -0500 To: ietf-provreg@cafax.se From: Richard Shockey Subject: One additional requirement... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0297xr15958 for ietf-provreg-outgoing; Tue, 2 Jan 2001 10:07:59 +0100 (MET) Received: from naptop.pilsnet.sunet.se (fliptop.pilsnet.sunet.se [192.36.125.196]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0297r215944 for ; Tue, 2 Jan 2001 10:07:53 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0297In02171 for ietf-provreg@cafax.se; Tue, 2 Jan 2001 10:07:18 +0100 (MET) Received: from bastiont.npac.com (bastiont.npac.com [208.143.34.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBMHpo221729 for ; Fri, 22 Dec 2000 18:51:50 +0100 (MET) Received: by bastiont.npac.com; id MAA10145; Fri, 22 Dec 2000 12:51:49 -0500 (EST) Received: from unknown(192.168.20.111) by bastiont.npac.com via smap (V5.0) id xmaa10142; Fri, 22 Dec 00 12:51:41 -0500 Message-Id: <5.0.2.1.2.20001222125218.028e1090@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 22 Dec 2000 12:52:34 -0500 To: "Jordyn A. Buchanan" , "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" From: Richard Shockey Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] In-Reply-To: <5.0.2.1.0.20001221122625.02b4d170@mail.register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0297qu15942 for ietf-provreg-outgoing; Tue, 2 Jan 2001 10:07:52 +0100 (MET) Received: from naptop.pilsnet.sunet.se (fliptop.pilsnet.sunet.se [192.36.125.196]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0297l215937 for ; Tue, 2 Jan 2001 10:07:47 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.11.2.Beta0/8.11.2.Beta0) id f0297C402167 for ietf-provreg@cafax.se; Tue, 2 Jan 2001 10:07:12 +0100 (MET) Received: from bastiont.npac.com (bastiont.npac.com [208.143.34.66]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBMHpo221728 for ; Fri, 22 Dec 2000 18:51:50 +0100 (MET) Received: by bastiont.npac.com; id MAA10146; Fri, 22 Dec 2000 12:51:49 -0500 (EST) Received: from unknown(192.168.20.111) by bastiont.npac.com via smap (V5.0) id xma010142; Fri, 22 Dec 00 12:51:40 -0500 Message-Id: <5.0.2.1.2.20001222124528.028cdec0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 22 Dec 2000 12:51:41 -0500 To: "J. William Semich" , "'provreg List'" From: Richard Shockey Subject: Re: Scope [was Re: Expiration times] In-Reply-To: <3.0.5.32.20001221102150.03d16630@mail.nic.nu> References: <5.0.2.1.0.20001221094557.02b04e98@mail.register.com> <20001221093108.B38157@bruno.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk > > > > >This is a valid point. At the same time, I think it's important to avoid > >too much scope creep here too. > 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f01GLW310214 for ietf-provreg-outgoing; Mon, 1 Jan 2001 17:21:32 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f01GLV210209 for ; Mon, 1 Jan 2001 17:21:31 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA26412; Mon, 1 Jan 2001 11:10:59 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jan 2001 11:16:58 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Paul M. Kane'" Cc: ietf-provreg@cafax.se Subject: RE: Draft provreg charter Date: Mon, 1 Jan 2001 11:16:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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:Paul.Kane@REACTO.com] Sent: Monday, January 01, 2001 9:36 AM To: Hollenbeck, Scott Cc: ietf-provreg@cafax.se 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