Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBV1RkV28130 for ietf-provreg-outgoing; Sun, 31 Dec 2000 02:27:46 +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 eBV1Ri228125 for ; Sun, 31 Dec 2000 02:27:45 +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 UAA25930; Sat, 30 Dec 2000 20:17:37 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Sat, 30 Dec 2000 20:23:39 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Geva Patz'" , ietf-provreg@cafax.se Cc: paf@cisco.com Subject: RE: Presentation of Ed Lewis Date: Sat, 30 Dec 2000 20:23:34 -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 eBV1Rj228126 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Isn't breadth of perspective something that we as WG can ensure? We've been moving along quite well for the last two weeks before Patrik introduced Ed. Personally, I think it's a good idea to have a chair whose background isn't closely aligned with any particular registry or registrar model. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Saturday, December 30, 2000 12:55 PM To: ietf-provreg@cafax.se Cc: paf@cisco.com Subject: Re: Presentation of Ed Lewis On Sat, Dec 30, 2000 at 05:39:02PM +0100, Patrik Fältström wrote: Patrik, > I just want you to know that I as AD has accepted the proposal from > Ed that he become the proposed chair in the draft charter which you > are working on on this mailing list. I have no problem at all with this, but I would suggest (subject, of course, to the availaibilty of volunteers) that a co-chair be nominated with a background in the ccTLDs, too. As I mentioned at the BOF, and as a couple of posters have mentioned on the list, there's a broader range of issues out there that don't necessarily manifset themselves in the current crop of gTLDs (most of which run along similar or identical lines). It's important (in my view, at least; and, it would seem, in the view of a number of others) to make sure that any standard that our work ends up producing has broad applicability across the Internet. I'd therefore really like to see a co-chair with ccTLD background who can help ensure that the WG stays on track with a broader focus. This isn't in any way meant to be a slight against Ed or his ability as potential chair, but I do believe that breadth of perspective would be very useful here. Volunteers, anyone? :) -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBUKoR826815 for ietf-provreg-outgoing; Sat, 30 Dec 2000 21:50:27 +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 eBUKoP226810 for ; Sat, 30 Dec 2000 21:50:25 +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 MAA25502; Sat, 30 Dec 2000 12:50:23 -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 eBUKoIl25661; Sat, 30 Dec 2000 12:50:18 -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 MAA23834; Sat, 30 Dec 2000 12:50:02 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20001230125504.A60628@bruno.bbn.com> References: <01b501c0716a$b860d640$140a0a0a@ambler.net> <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net> <5.0.2.1.2.20001230105559.02ddbd50@127.0.0.1> <20001230125504.A60628@bruno.bbn.com> Date: Sat, 30 Dec 2000 21:49:21 +0100 To: Geva Patz , ietf-provreg@cafax.se From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Presentation of Ed Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 12.55 -0500 00-12-30, Geva Patz wrote: >I have no problem at all with this, but I would suggest (subject, >of course, to the availaibilty of volunteers) that a co-chair be >nominated with a background in the ccTLDs, too. Sure, if that is the wish of the community. I wanted though to mention that Ed, and none of the co-chairs of the BOF, is the one that for now (at least) is the one which will announce what he think is consensus of this 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 eBUHt7D25779 for ietf-provreg-outgoing; Sat, 30 Dec 2000 18:55:07 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBUHt6225774 for ; Sat, 30 Dec 2000 18:55:06 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id MAA60684; Sat, 30 Dec 2000 12:55:05 -0500 (EST) (envelope-from geva) Date: Sat, 30 Dec 2000 12:55:04 -0500 From: Geva Patz To: ietf-provreg@cafax.se Cc: paf@cisco.com Subject: Re: Presentation of Ed Lewis Message-ID: <20001230125504.A60628@bruno.bbn.com> Mail-Followup-To: ietf-provreg@cafax.se, paf@cisco.com References: <01b501c0716a$b860d640$140a0a0a@ambler.net> <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net> <5.0.2.1.2.20001230105559.02ddbd50@127.0.0.1> 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 Sat, Dec 30, 2000 at 05:39:02PM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Sat, Dec 30, 2000 at 05:39:02PM +0100, Patrik Fältström wrote: Patrik, > I just want you to know that I as AD has accepted the proposal from > Ed that he become the proposed chair in the draft charter which you > are working on on this mailing list. I have no problem at all with this, but I would suggest (subject, of course, to the availaibilty of volunteers) that a co-chair be nominated with a background in the ccTLDs, too. As I mentioned at the BOF, and as a couple of posters have mentioned on the list, there's a broader range of issues out there that don't necessarily manifset themselves in the current crop of gTLDs (most of which run along similar or identical lines). It's important (in my view, at least; and, it would seem, in the view of a number of others) to make sure that any standard that our work ends up producing has broad applicability across the Internet. I'd therefore really like to see a co-chair with ccTLD background who can help ensure that the WG stays on track with a broader focus. This isn't in any way meant to be a slight against Ed or his ability as potential chair, but I do believe that breadth of perspective would be very useful here. Volunteers, anyone? :) -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBUGdpi25415 for ietf-provreg-outgoing; Sat, 30 Dec 2000 17:39:51 +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 eBUGdn225410 for ; Sat, 30 Dec 2000 17:39:50 +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 IAA23674 for ; Sat, 30 Dec 2000 08:39: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 eBUGdoO23146 for ; Sat, 30 Dec 2000 08:39: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 IAA11792 for ; Sat, 30 Dec 2000 08:39:43 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <5.0.2.1.2.20001230105559.02ddbd50@127.0.0.1> References: <01b501c0716a$b860d640$140a0a0a@ambler.net> <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net> <5.0.2.1.2.20001230105559.02ddbd50@127.0.0.1> Date: Sat, 30 Dec 2000 17:39:02 +0100 To: From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Presentation of Ed Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I just want you to know that I as AD has accepted the proposal from Ed that he become the proposed chair in the draft charter which you are working on on this mailing list. Ed is because of that the person which will try to get the charter more specific and submitted to myself. Given that you all accept him of course. 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: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBUGWN325369 for ietf-provreg-outgoing; Sat, 30 Dec 2000 17:32:23 +0100 (MET) Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBUGWM225364 for ; Sat, 30 Dec 2000 17:32:22 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivekf7.dialup.mindspring.com [165.247.81.231]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA30523; Sat, 30 Dec 2000 11:32:07 -0500 (EST) Message-Id: <5.0.2.1.2.20001230105559.02ddbd50@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: Sat, 30 Dec 2000 11:34:02 -0500 To: Edward Lewis , "Christopher Ambler" From: Richard Shockey Subject: Re: Draft provreg charter Cc: , lewis@tislabs.com In-Reply-To: References: <01b501c0716a$b860d640$140a0a0a@ambler.net> <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 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: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBUFH1Q25001 for ietf-provreg-outgoing; Sat, 30 Dec 2000 16:17:01 +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 eBUFH0224996 for ; Sat, 30 Dec 2000 16:17:01 +0100 (MET) Received: from rock.viagenie.qc.ca (modemcable241.164-202-24.que.mc.videotron.ca [24.202.164.241]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eBUFMqd79188; Sat, 30 Dec 2000 10:22:52 -0500 (EST) Message-Id: <5.0.0.25.2.20001230101426.00a935f0@localhost> X-Sender: acormier@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Dec 2000 10:18:16 -0500 To: "Hollenbeck, Scott" , "'Patrik Fältström'" , "Provreg (E-mail)" From: André Cormier Subject: RE: My personal comments on the requirements. 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 Sorry for the late reply, i am away for the holliday and it is difficult to read my mail often. At 12:07 2000-12-27 -0500, Hollenbeck, Scott wrote: >OK then, how about leaving 9-[1] as-is to cover domain and host names and >adding a new requirement for internationalized meta-data: > >[2] The protocol MUST allow exchange of meta-data associated with objects in >formats consistent with current internationalized character encoding >standards. I think this would be fine. >Scott Hollenbeck >VeriSign Global Registry Services > >-----Original Message----- >From: Patrik Fältström [mailto:paf@cisco.com] >Sent: Tuesday, December 26, 2000 2:09 PM >To: AndrÈ Cormier; Provreg (E-mail) >Subject: Re: My personal comments on the requirements. > > >At 13.49 -0500 00-12-22, AndrÈ Cormier wrote: > >9. Internationalization Considerations > > [1] Current Internet standards restrict the encoding of Internet host > > and domain names to a subset of the 7-bit US-ASCII character set. > > Registries and registrars now serve customers whose native languages > > require encodings other than US-ASCII, which automatically disallows > > use of those languages when registering host and domain names. > > Support for internationalized host and domain names will greatly > > increase world-wide usability of a generic registry registrar > > protocol, so standards for internationalized host and domain names > > MUST be considered during the protocol design process. > >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable > >AC: the use of internationalized data. > >The information in section 9 should be syncronized with what happens >in the IDN working group -- BUT, I would like to differ between two >different types of data: > > - The Domain Names themselves > - Other meta-data which goes along with the domainname, such as the > street address of the admin contact etc, which can include not only > non-ascii characters but also the address in a different format than > what is default by the registry. Example: Street name and number is > in the US written as " " while in Sweden the > order is the inverse " ". > >To start with, the meta information should be able to be both in >"english" ascii and in the native characters using Unicode, but the >domainname definition should wait for the IDN definition (it might be >that the domainname should be in some ACE encoding, already >nameprepped -- or equivalent). > > paf ______________________________________________________________________ André Cormier | Téléphone : (418) 656-9254 2875 boul. Laurier | Télécopie : (418) 266-5539 Bureau 300 | Sainte-Foy, (Québec) G1V 2M2 | Andre.Cormier@viagenie.qc.ca Canada | Radio : VA2UNX, VA2ACE ---------------------------------------------------------------------- Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ---------------------------------------------------------------------- PGP: D434 547D 712A E44F C978 4673 BD50 A248 C262 CB06 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBTLggd19282 for ietf-provreg-outgoing; Fri, 29 Dec 2000 22:42:42 +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 eBTLgf219277 for ; Fri, 29 Dec 2000 22:42:41 +0100 (MET) Received: by sentry.gw.tislabs.com; id QAA28468; Fri, 29 Dec 2000 16:45:45 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma028415; Fri, 29 Dec 00 16:44:47 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: 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" Date: Fri, 29 Dec 2000 16:39:03 -0500 To: "Christopher Ambler" From: Edward Lewis Subject: Re: Draft provreg charter Cc: , lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk 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. 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. Bare in mind that delays in achieving the protocol specification may have an impact on the registry to registrar business model for some time. 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 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. At 2:40 AM -0500 12/29/00, 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? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 eBT7fKQ14609 for ietf-provreg-outgoing; Fri, 29 Dec 2000 08:41:20 +0100 (MET) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBT7fJ214602 for ; Fri, 29 Dec 2000 08:41:19 +0100 (MET) Received: from vulcan (1Cust107.tnt5.redmond.wa.da.uu.net [63.23.203.107]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id XAA18148 for ; Thu, 28 Dec 2000 23:41:15 -0800 (PST) Message-ID: <01b501c0716a$b860d640$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net> Subject: Re: Draft provreg charter Date: Thu, 28 Dec 2000 23:40:53 -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 eBT7fJ214605 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >The specification will allow multiple registrars to register domain names >within a single Top Level Domain (TLD). The working group will use as input >the Extensible Provisioning Protocol presentation, documented in >. Suggest that in addition to "register," we also call out "modify, delete, ...?" Additionally, I think the specification that it is within a single TLD is already obsolete, as the operating NSI system allows for more than one, no? >Feb, 2001 Working group agreement on functional requirements for protocol >Feb, 2001 Initial specification of provreg protocol 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? Christopher Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBRIiK400263 for ietf-provreg-outgoing; Wed, 27 Dec 2000 19:44:20 +0100 (MET) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBRIiJ200258 for ; Wed, 27 Dec 2000 19:44:20 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivemfo.dialup.mindspring.com [165.247.89.248]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA14021; Wed, 27 Dec 2000 13:44:11 -0500 (EST) Message-Id: <5.0.2.1.2.20001227133532.02b71a20@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, 27 Dec 2000 13:36:27 -0500 To: "Hollenbeck, Scott" , "'Karl Auerbach'" , ietf-provreg@cafax.se From: Richard Shockey Subject: RE: Comments on overall direction 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 09:23 AM 12/27/2000 -0500, Hollenbeck, Scott wrote: >While I know of at least one company that would be thrilled to see >requirements for millions of domain name owners to become PKI-capable (or >even just the subset who wish to request transfers), I bet :-) > I have to echo the >point raised by Dave concerning deployment and adoption. I'm sure there are >domain name holders who would understand and welcome such developments, but >people aren't exactly falling over each other to install applications that >provide cryptographic services. > >I don't disagree that transactional integrity is essential, but we may have >different ideas on where that integrity service needs to be available or >applied. I believe that we have a far better chance to produce a widely >accepted protocol if we do our best to keep the protocol itself extremely >simple, and using a layered approach to add services that make sense in >particular operational environments. > >Scott Hollenbeck >VeriSign Global Registry Services I just want to echo my agreement with Scott here.. I think he and Dave are correct here. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 eBRIiIN00256 for ietf-provreg-outgoing; Wed, 27 Dec 2000 19:44:18 +0100 (MET) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBRIiH200251 for ; Wed, 27 Dec 2000 19:44:17 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivemfo.dialup.mindspring.com [165.247.89.248]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA25512; Wed, 27 Dec 2000 13:44:08 -0500 (EST) Message-Id: <5.0.2.1.2.20001227132655.02b74510@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, 27 Dec 2000 13:33:51 -0500 To: =?iso-8859-1?Q?Andr=E9?= Cormier , "Provreg (E-mail)" From: Richard Shockey Subject: RE: My personal comments on the requirements. In-Reply-To: <5.0.0.25.2.20001226233040.00a91a18@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk >> >>[SAH] I don't have a problem with the basic idea here, but I'd like to >>suggest that this doesn't need to be a MUST in the protocol itself. Other >>layers can do this as well; for example, BEEP offers just such a negotiation >>mechanism and I think it would be overkill to do the negotiation within both >>BEEP and another application layer protocol. Would this re-wording be >>acceptable?: > >[AC]Yes it would be overkill to do it in both BEEP and the protocol. But i >still think it should be part of the requirements. If BEEP is used with >the proposed protocol than BEEP will meet the negociation requirement. If >BEEP is not used, the protocol should include this kind of negociation. > >What do you think ? Well I think you are correct... and that is one reason I would encourage us to look at the BEEP framework as the transport for this protocol application ..though I'm told there may be some limitations on its use during the pre-sale search mechanism that puts heavy stress on the registry. >>"[3] The protocol or another layered protocol MUST provide services to >>negotiate an authentication mechanism acceptable to both the server and the >>client." >> >>I don't think the advertisement requirement is necessary if the mechanism >>must be negotiated. Some kind of information exchange has to happen as part >>of the negotiation process. BEEP offers this as a option ..another reason to consider its adoption ... >>[SAH] Can you be more specific about the purpose of this new field? I'd >>much prefer to enumerate required information vs. providing some kind of >>unformatted registry-specific field. > >[AC] For each objects, registries may require additionnal fields. I'd like >to see what other ccTLDs or gTLDs needs for the contact object or for >other objects. I do not say that the objects are incomplete but i think >that it should not be too restrictive. This way if such a need arise, than >the protocol will not need an update to support a new field for the >contact object. I'd like to see some additional information on what registries are thinking about this. I'm beginning to believe that certain registries may have different requirements than others. The needs of .de are clearly different from .com or .biz for that matter ..this goes to extensibility again. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 eBRHBN429536 for ietf-provreg-outgoing; Wed, 27 Dec 2000 18:11: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 eBRHBM229531 for ; Wed, 27 Dec 2000 18:11:22 +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 MAA21648; Wed, 27 Dec 2000 12:01:15 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 12:07:25 -0500 Message-ID: From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , =?iso-8859-1?Q?Andr=C8_Cormier?= , "Provreg (E-mail)" Subject: RE: My personal comments on the requirements. Date: Wed, 27 Dec 2000 12:07:25 -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 eBRHBN229532 Sender: owner-ietf-provreg@cafax.se Precedence: bulk OK then, how about leaving 9-[1] as-is to cover domain and host names and adding a new requirement for internationalized meta-data: [2] The protocol MUST allow exchange of meta-data associated with objects in formats consistent with current internationalized character encoding standards. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, December 26, 2000 2:09 PM To: AndrÈ Cormier; Provreg (E-mail) Subject: Re: My personal comments on the requirements. At 13.49 -0500 00-12-22, AndrÈ Cormier wrote: >9. Internationalization Considerations > [1] Current Internet standards restrict the encoding of Internet host > and domain names to a subset of the 7-bit US-ASCII character set. > Registries and registrars now serve customers whose native languages > require encodings other than US-ASCII, which automatically disallows > use of those languages when registering host and domain names. > Support for internationalized host and domain names will greatly > increase world-wide usability of a generic registry registrar > protocol, so standards for internationalized host and domain names > MUST be considered during the protocol design process. >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable >AC: the use of internationalized data. The information in section 9 should be syncronized with what happens in the IDN working group -- BUT, I would like to differ between two different types of data: - The Domain Names themselves - Other meta-data which goes along with the domainname, such as the street address of the admin contact etc, which can include not only non-ascii characters but also the address in a different format than what is default by the registry. Example: Street name and number is in the US written as " " while in Sweden the order is the inverse " ". To start with, the meta information should be able to be both in "english" ascii and in the native characters using Unicode, but the domainname definition should wait for the IDN definition (it might be that the domainname should be in some ACE encoding, already nameprepped -- or equivalent). paf Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBRFom428902 for ietf-provreg-outgoing; Wed, 27 Dec 2000 16:50:48 +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 eBRFok228897 for ; Wed, 27 Dec 2000 16:50:46 +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 HAA31953; Wed, 27 Dec 2000 07:37:55 -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.20001227073235.03513990@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 27 Dec 2000 07:35:07 -0800 To: Karl Auerbach From: Dave Crocker Subject: Re: Comments on overall direction Cc: In-Reply-To: References: <5.0.2.1.2.20001226235525.0349d680@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 02:07 AM 12/27/00 -0800, Karl Auerbach wrote: > > It would help to have a description of an existing service that has similar > > scale and scope, that uses a similar mechanism. > >A bill of lading. It's a technique that's been in use since about the >year 1500. Sorry for my serious lack of completeness. I mean Internet-based service, or the technological equivalent. >It's not a big extension to conceive of a digitally signed object that >represents an instruction to perform some action on some asset - such as a >domain name. Indeed, we are part way there with the PGP signed domain >update forms that we use today. PGP is used in very small scale, in Internet terms. 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 eBRFQsk28733 for ietf-provreg-outgoing; Wed, 27 Dec 2000 16:26:54 +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 eBRFQq228728 for ; Wed, 27 Dec 2000 16:26:52 +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 HAA15137; Wed, 27 Dec 2000 07:26:50 -0800 (PST) Date: Wed, 27 Dec 2000 07:26:50 -0800 (PST) From: Rick H Wesson To: Karl Auerbach cc: Subject: Re: Comments on overall direction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Karl, On Wed, 27 Dec 2000, Karl Auerbach wrote: > It's not a big extension to conceive of a digitally signed object that > represents an instruction to perform some action on some asset - such as a > domain name. Indeed, we are part way there with the PGP signed domain > update forms that we use today. CORE's protocol does this, PGP signed MIME. Its ok but in my experence the utility of this mechanism was not all that great. There are certainly better ways provide the same today. Besides CORE had the requirement because of other encription issues. Today those barriers are gone and end to end encription shold be used where ever possable. In short, we tried your suggestion and I found it to be not that usefull and burdonsome. -rick Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBRFJ7o28693 for ietf-provreg-outgoing; Wed, 27 Dec 2000 16:19:07 +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 eBRFJ3228688 for ; Wed, 27 Dec 2000 16:19:03 +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 eBRFOVd51162; Wed, 27 Dec 2000 10:24:32 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20001227101718.0380b138@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 27 Dec 2000 10:20:30 -0500 To: "Hollenbeck, Scott" , "'Dave Crocker'" , ietf-provreg@cafax.se From: Marc Blanchet Subject: RE: Draft provreg charter 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 Suggested change to charter (related to the support of the different models of registries (thin, thick, ...): From: The specification will allow multiple registrars to register domain names within a single Top Level Domain (TLD). The working group will use as input the Extensible Provisioning Protocol presentation, documented in . To: The specification will allow multiple registrars to register domain names within a single Top Level Domain (TLD). 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 . Marc. 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: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBREmmv28521 for ietf-provreg-outgoing; Wed, 27 Dec 2000 15:48:48 +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 eBREmA228514 for ; Wed, 27 Dec 2000 15:48: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 JAA21301; Wed, 27 Dec 2000 09:38:03 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 09:44:14 -0500 Message-ID: From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Andr=E9_Cormier=27?= , "Provreg (E-mail)" Subject: RE: My personal comments on the requirements. Date: Wed, 27 Dec 2000 09:44:13 -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 eBREmm228517 Sender: owner-ietf-provreg@cafax.se Precedence: bulk André, I think we're in agreement on all of the comments you've provided. I can reword requirements as described, and I can add a requirement to allow for a registry-specific contact field if that's OK with everyone else. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: André Cormier [mailto:Andre.Cormier@viagenie.qc.ca] Sent: Wednesday, December 27, 2000 12:20 AM To: Provreg (E-mail) Subject: RE: My personal comments on the requirements. >-------------- > >3.2 Identification and Authentication > > >AC: 2 new items proposed. New protocols allow for negociation of the >AC: authentication mechanism. This protocol one should be open enough = =3D >to allow >AC: such negociation. >AC: [3] The protocol MUST provide services to allow the negociatoin of = =3D >the >AC: authentication mechanism that will be used to authenticate =3D >registrar=3D20 >clients. >AC: [4] The protocol MUST provide services to advertise = authentication=3D20 >mechanism >AC: supported by both the server and the client. > >[SAH] I don't have a problem with the basic idea here, but I'd like to >suggest that this doesn't need to be a MUST in the protocol itself. = Other >layers can do this as well; for example, BEEP offers just such a = negotiation >mechanism and I think it would be overkill to do the negotiation = within both >BEEP and another application layer protocol. Would this re-wording be >acceptable?: [AC]Yes it would be overkill to do it in both BEEP and the protocol. = But i=20 still think it should be part of the requirements. If BEEP is used with = the=20 proposed protocol than BEEP will meet the negociation requirement. If = BEEP=20 is not used, the protocol should include this kind of negociation. What do you think ? >"[3] The protocol or another layered protocol MUST provide services to >negotiate an authentication mechanism acceptable to both the server = and the >client." > >I don't think the advertisement requirement is necessary if the = mechanism >must be negotiated. Some kind of information exchange has to happen = as part >of the negotiation process. > >-------------- > >3.3 Transaction Identification >AC: I suggest we add a paragraph to clearly state that this number = MUST =3D >be=3D20 >randomly >AC: generated so it would be nearly impossible for someone to guess = =3D >what will >AC: be the identifier used by another registrar. >AC: [3] The unique transaction identifier MUST be randomly generated = so =3D >it >AC: would be nearly impossible for someone to guess what number as = been =3D > >assigned >AC: to a registrar. > >[SAH] Actually, I prefer the text proposed by Geva last week that says = that >each transaction must be "identified in a permanent and globally = unique >manner". Requiring randomization gets into "how" the protocol should = behave >instead of describing "what" it should do. [AC] This number is used for security measure while transferting domain = objects between registrars. If this number is easily guessed it could = be a=20 security problem. Unless i've misunderstood the use of this identifier. = That's why i thought it would be nice to have a random part in this = number. >-------------- >3.4 Object Registration > > [4] The protocol MUST provide services to register name servers. = =3D >Name > > server registration MUST NOT be limited to a specific period of = =3D >time. > > Name servers registered within the registry's authoritative TLDs = =3D >MUST > > be registered with a valid Internet Protocol (IP) address. A = name > > server MAY be registered with multiple IP addresses. An IP = address > > MAY be shared among multiple name servers using distinct server = =3D >names. > > Name servers that exist in TLDs other than those for which the > > registry is authoritative MUST be registered without an IP = address > > providing that the server TLD is itself a valid TLD. >AC: The protocol MUST allow the identification of the type of address. = =3D >This >AC: way we will be able to add IPv6 addresses when the time will come. = =3D >I do not >AC: say that we should include AAAA and A6 records. We should define a = =3D >way that >AC: enables us to tag the type of address so it would be possible = to=3D20 >register AAAA >AC: and A6 records in the future. We should support IPv6 to have less = =3D >impact >AC: when the time will come. > >[SAH] Section 1.1 states that the term "IP Address" means either or = both >IPv4 or IPv6 address. I'll modify the text in this section to clearly = state >that support for both IPv4 and IPv6 addresses is required without = specifying >how that support should be provided. [AC] Yes you are correct, i've missed that definition :-( sorry. > > [5] The protocol MUST consider that the name server associated = with =3D >a > > domain might not be registered in the same domain or even in a = TLD =3D >for > > which the registry is authoritative. This means that IP = addresses =3D >for > > name servers whose parent domain exists in another TLD MUST be > > registered only in the registry that is authoritative for the TLD = =3D >of > > the name server. Glue records (DNS "A" records) MUST NOT be =3D >created > > for DNS NS records for which the registry is not authoritative. >AC: I do not think this is protocol related. It will be the = registry=3D20 >application that >AC: will create the DNS zone file and glue records. It should not be = =3D >state as a >AC: requirement. I caan easily see that as a comment in the = protocol=3D20 >definition draft >AC: and a pointer to a companion document for best current practices. > >[SAH] This text was added quite some time ago at the urging of our = Area >Director. I'll defer to Patrik to decide if we should remove this = text or >reword it so that it's clearly not a protocol requirement. Patrik? [AC] I saw Patrick's response. I understand the need. > > [6] The protocol MUST provide services to register contact =3D >information > > describing human and organizational entities. Contact = registration > > MUST NOT be limited to a specific period of time. Contact > > registration MUST include a name (individual name, organization = =3D >name, > > or both), address (including street address, city, state or =3D >province > > (if applicable), postal code, and country), telephone number, and = =3D >e- > > mail address. A facsimile telephone number MAY be provided. >AC: The protocol MUST allow for registry specific field for all = objects =3D >managed >AC: by the protocol. Those field should be state as optional by = the=3D20 >protocol but >AC: MAY be forced mandatory by the registry with the use of error = codes =3D >stating >AC: that a specific field is required. > >[SAH] Can you be more specific about the purpose of this new field? = I'd >much prefer to enumerate required information vs. providing some kind = of >unformatted registry-specific field. [AC] For each objects, registries may require additionnal fields. I'd = like=20 to see what other ccTLDs or gTLDs needs for the contact object or for = other=20 objects. I do not say that the objects are incomplete but i think that = it=20 should not be too restrictive. This way if such a need arise, than the=20 protocol will not need an update to support a new field for the contact = object. > > [9] A registry MUST provide services to support a configurable = =3D >grace > > period during which time a request to register a domain name or = =3D >other > > billable object can be undone without harm. >AC: I think this should be The protocol MUST provides services... If = it =3D >is the >AC: registry than it's not protocol related but policy issue or =3D >implementation >AC: issue and does not belong in that document. > >[SAH] I'd prefer to pull this requirement out of the document than to >require protocol support for something that isn't negotiated between >registrar and registry but is rather a registry policy issue. OK to = pull it >out? [AC] That's fine with me. >-------------- >3.5 Object Association > > [2] The protocol MUST provide services to associate IP addresses = =3D >with > > name servers. A name server MAY have multiple IP addresses. An = IP > > address MAY be associated with multiple name servers. >AC: The same comment apply here for IP address type. We should provide = =3D >means >AC: to tag IP address type so it would be possible to add IPv6 =3D >addresses. > >[SAH] I'd like to address this by again clearly stating required = support for >both IPv4 and IPv6 address. Tagging describes "how" that support is >provided, and is thus something that I think would be more = appropriately >addressed in a protocol specification. [AC] If tagging it is not a requirement it may be omited in the=20 specification and it would still meet the requirements. The goal of=20 requirements his to state what the protocol specification must meet in=20 order to achieve the specified task. >-------------- >9. Internationalization Considerations > [1] Current Internet standards restrict the encoding of Internet = =3D >host > and domain names to a subset of the 7-bit US-ASCII character set. > Registries and registrars now serve customers whose native = languages > require encodings other than US-ASCII, which automatically = disallows > use of those languages when registering host and domain names. > Support for internationalized host and domain names will greatly > increase world-wide usability of a generic registry registrar > protocol, so standards for internationalized host and domain names > MUST be considered during the protocol design process. >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to = =3D >enable >AC: the use of internationalized data. > >[SAH] I'd prefer to reword the last sentence than to explicitly = require >UTF-8 because it again addresses "how" to solve a particular problem. = How >about changing this: > >"so standards for internationalized host and domain names MUST be = considered >during the protocol design process" > >to this: > >"so standards for exchanging internationalized information MUST be >considered during the protocol design process" > >I think that covers more than domain and host names without requiring = a >specific solution. [AC] If IDN uses ACE format, it would still fit in the UTF-8 = requirement=20 since ASCII remains the same within UTF-8. I like the idea of Patrick.=20 English MUST be use and local language in UTF-8 MAY be used for all=20 elements other than domain name, and domain name should be expressed as = UTF-8 (for now) and a new protocol version could deal with the result = of=20 the IDN wg when they will be done if it could not be done with UTF-8. = For=20 the way data is expressed (Patrick stated an example for sweden) it = would=20 be nice to have feeback from other countries. If whois protocol is revised, it would be interesting to have an=20 internationalized version of it. But it is not in the scope of this = list. ;-) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBREhYP28495 for ietf-provreg-outgoing; Wed, 27 Dec 2000 15:43:34 +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 eBREhS228490 for ; Wed, 27 Dec 2000 15:43: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 JAA21285; Wed, 27 Dec 2000 09:33:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 09:39:25 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Dave Crocker'" , ietf-provreg@cafax.se Subject: RE: Draft provreg charter Date: Wed, 27 Dec 2000 09:39:24 -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 eBREhY228491 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dave, I think we'd like to have the group chartered in January 2001, not 2005. ;-) I see some extra words in the third paragraph, which I would suggest rewording as follows: "The group will consider support for multiple operational choices, such as for transport and security, and may consider use of the 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:" I'd like to list some specific object identification targets in the first documentation bullet if possible. Leaving it open-ended makes it difficult to determine when the group has finished it's work. At a minimum, I think we need to address domain name, host, and contact provisioning. IP addresses, ASNs, and telephone numbers have also been mentioned. Do we want to tackle those as formal working group deliverables? Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Dave Crocker [mailto:dcrocker@brandenburg.com] Sent: Tuesday, December 26, 2000 12:29 PM To: ietf-provreg@cafax.se Subject: Draft provreg charter Folks, Here is a draft of the working group charter. (Sorry for the delay.) It reflects the changes I typed during the BOF, and string changes from 'domreg' to 'provreg'. d/ Provisioning Registry Protocol (ProvReg) ------------------------------ CHAIR(S): APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: 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 data base for registrations, called the registry, versus the "front-end" sales and support services by registrars who interact with registrants and with the "back-end" 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 protocol for registrar access to the registry. 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 domain names within a single Top Level Domain (TLD). 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, and may consider use the protocol for other for other registration and update 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, their relationships to each other, and the protocol for exchanging objects between a registrar and the registry * Describe appropriate mechanisms for security and protection during registrar access * List useful examples of registrar access transactions GOALS AND MILESTONES: Jan, 2005 Working group chartered Feb, 2001 Working group agreement on functional requirements for protocol Feb, 2001 Initial specification of provreg protocol May, 2001 Second draft specification Sep, 2001 Submit provreg draft for standards track =-=-=-=-= 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 eBREU8B28426 for ietf-provreg-outgoing; Wed, 27 Dec 2000 15:30:08 +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 eBREU5228421 for ; Wed, 27 Dec 2000 15:30:06 +0100 (MET) Received: from rock.viagenie.qc.ca (ts1-40.f1333.quebectel.com [142.169.79.50]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eBREZrd50590 for ; Wed, 27 Dec 2000 09:35:54 -0500 (EST) Message-Id: <5.0.0.25.2.20001226233040.00a91a18@localhost> X-Sender: acormier@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Dec 2000 00:19:56 -0500 To: "Provreg (E-mail)" From: André Cormier Subject: RE: My personal comments on the requirements. 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 >-------------- > >3.2 Identification and Authentication > > >AC: 2 new items proposed. New protocols allow for negociation of the >AC: authentication mechanism. This protocol one should be open enough = >to allow >AC: such negociation. >AC: [3] The protocol MUST provide services to allow the negociatoin of = >the >AC: authentication mechanism that will be used to authenticate = >registrar=20 >clients. >AC: [4] The protocol MUST provide services to advertise authentication=20 >mechanism >AC: supported by both the server and the client. > >[SAH] I don't have a problem with the basic idea here, but I'd like to >suggest that this doesn't need to be a MUST in the protocol itself. Other >layers can do this as well; for example, BEEP offers just such a negotiation >mechanism and I think it would be overkill to do the negotiation within both >BEEP and another application layer protocol. Would this re-wording be >acceptable?: [AC]Yes it would be overkill to do it in both BEEP and the protocol. But i still think it should be part of the requirements. If BEEP is used with the proposed protocol than BEEP will meet the negociation requirement. If BEEP is not used, the protocol should include this kind of negociation. What do you think ? >"[3] The protocol or another layered protocol MUST provide services to >negotiate an authentication mechanism acceptable to both the server and the >client." > >I don't think the advertisement requirement is necessary if the mechanism >must be negotiated. Some kind of information exchange has to happen as part >of the negotiation process. > >-------------- > >3.3 Transaction Identification >AC: I suggest we add a paragraph to clearly state that this number MUST = >be=20 >randomly >AC: generated so it would be nearly impossible for someone to guess = >what will >AC: be the identifier used by another registrar. >AC: [3] The unique transaction identifier MUST be randomly generated so = >it >AC: would be nearly impossible for someone to guess what number as been = > >assigned >AC: to a registrar. > >[SAH] Actually, I prefer the text proposed by Geva last week that says that >each transaction must be "identified in a permanent and globally unique >manner". Requiring randomization gets into "how" the protocol should behave >instead of describing "what" it should do. [AC] This number is used for security measure while transferting domain objects between registrars. If this number is easily guessed it could be a security problem. Unless i've misunderstood the use of this identifier. That's why i thought it would be nice to have a random part in this number. >-------------- >3.4 Object Registration > > [4] The protocol MUST provide services to register name servers. = >Name > > server registration MUST NOT be limited to a specific period of = >time. > > Name servers registered within the registry's authoritative TLDs = >MUST > > be registered with a valid Internet Protocol (IP) address. A name > > server MAY be registered with multiple IP addresses. An IP address > > MAY be shared among multiple name servers using distinct server = >names. > > Name servers that exist in TLDs other than those for which the > > registry is authoritative MUST be registered without an IP address > > providing that the server TLD is itself a valid TLD. >AC: The protocol MUST allow the identification of the type of address. = >This >AC: way we will be able to add IPv6 addresses when the time will come. = >I do not >AC: say that we should include AAAA and A6 records. We should define a = >way that >AC: enables us to tag the type of address so it would be possible to=20 >register AAAA >AC: and A6 records in the future. We should support IPv6 to have less = >impact >AC: when the time will come. > >[SAH] Section 1.1 states that the term "IP Address" means either or both >IPv4 or IPv6 address. I'll modify the text in this section to clearly state >that support for both IPv4 and IPv6 addresses is required without specifying >how that support should be provided. [AC] Yes you are correct, i've missed that definition :-( sorry. > > [5] The protocol MUST consider that the name server associated with = >a > > domain might not be registered in the same domain or even in a TLD = >for > > which the registry is authoritative. This means that IP addresses = >for > > name servers whose parent domain exists in another TLD MUST be > > registered only in the registry that is authoritative for the TLD = >of > > the name server. Glue records (DNS "A" records) MUST NOT be = >created > > for DNS NS records for which the registry is not authoritative. >AC: I do not think this is protocol related. It will be the registry=20 >application that >AC: will create the DNS zone file and glue records. It should not be = >state as a >AC: requirement. I caan easily see that as a comment in the protocol=20 >definition draft >AC: and a pointer to a companion document for best current practices. > >[SAH] This text was added quite some time ago at the urging of our Area >Director. I'll defer to Patrik to decide if we should remove this text or >reword it so that it's clearly not a protocol requirement. Patrik? [AC] I saw Patrick's response. I understand the need. > > [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 MUST 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, and = >e- > > mail address. A facsimile telephone number MAY be provided. >AC: The protocol MUST allow for registry specific field for all objects = >managed >AC: by the protocol. Those field should be state as optional by the=20 >protocol but >AC: MAY be forced mandatory by the registry with the use of error codes = >stating >AC: that a specific field is required. > >[SAH] Can you be more specific about the purpose of this new field? I'd >much prefer to enumerate required information vs. providing some kind of >unformatted registry-specific field. [AC] For each objects, registries may require additionnal fields. I'd like to see what other ccTLDs or gTLDs needs for the contact object or for other objects. I do not say that the objects are incomplete but i think that it should not be too restrictive. This way if such a need arise, than the protocol will not need an update to support a new field for the contact object. > > [9] A registry MUST provide services to support a configurable = >grace > > period during which time a request to register a domain name or = >other > > billable object can be undone without harm. >AC: I think this should be The protocol MUST provides services... If it = >is the >AC: registry than it's not protocol related but policy issue or = >implementation >AC: issue and does not belong in that document. > >[SAH] I'd prefer to pull this requirement out of the document than to >require protocol support for something that isn't negotiated between >registrar and registry but is rather a registry policy issue. OK to pull it >out? [AC] That's fine with me. >-------------- >3.5 Object Association > > [2] The protocol MUST provide services to associate IP addresses = >with > > name servers. A name server MAY have multiple IP addresses. An IP > > address MAY be associated with multiple name servers. >AC: The same comment apply here for IP address type. We should provide = >means >AC: to tag IP address type so it would be possible to add IPv6 = >addresses. > >[SAH] I'd like to address this by again clearly stating required support for >both IPv4 and IPv6 address. Tagging describes "how" that support is >provided, and is thus something that I think would be more appropriately >addressed in a protocol specification. [AC] If tagging it is not a requirement it may be omited in the specification and it would still meet the requirements. The goal of requirements his to state what the protocol specification must meet in order to achieve the specified task. >-------------- >9. Internationalization Considerations > [1] Current Internet standards restrict the encoding of Internet = >host > and domain names to a subset of the 7-bit US-ASCII character set. > Registries and registrars now serve customers whose native languages > require encodings other than US-ASCII, which automatically disallows > use of those languages when registering host and domain names. > Support for internationalized host and domain names will greatly > increase world-wide usability of a generic registry registrar > protocol, so standards for internationalized host and domain names > MUST be considered during the protocol design process. >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to = >enable >AC: the use of internationalized data. > >[SAH] I'd prefer to reword the last sentence than to explicitly require >UTF-8 because it again addresses "how" to solve a particular problem. How >about changing this: > >"so standards for internationalized host and domain names MUST be considered >during the protocol design process" > >to this: > >"so standards for exchanging internationalized information MUST be >considered during the protocol design process" > >I think that covers more than domain and host names without requiring a >specific solution. [AC] If IDN uses ACE format, it would still fit in the UTF-8 requirement since ASCII remains the same within UTF-8. I like the idea of Patrick. English MUST be use and local language in UTF-8 MAY be used for all elements other than domain name, and domain name should be expressed as UTF-8 (for now) and a new protocol version could deal with the result of the IDN wg when they will be done if it could not be done with UTF-8. For the way data is expressed (Patrick stated an example for sweden) it would be nice to have feeback from other countries. If whois protocol is revised, it would be interesting to have an internationalized version of it. But it is not in the scope of this list. ;-) ______________________________________________________________________ André Cormier | Téléphone : (418) 656-9254 2875 boul. Laurier | Télécopie : (418) 266-5539 Bureau 300 | Sainte-Foy, (Québec) G1V 2M2 | Andre.Cormier@viagenie.qc.ca Canada | Radio : VA2UNX, VA2ACE ---------------------------------------------------------------------- Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ---------------------------------------------------------------------- PGP: D434 547D 712A E44F C978 4673 BD50 A248 C262 CB06 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBRERSe28399 for ietf-provreg-outgoing; Wed, 27 Dec 2000 15: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 eBRERP228394 for ; Wed, 27 Dec 2000 15:27:26 +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 JAA21225; Wed, 27 Dec 2000 09:17:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 09:23:25 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Karl Auerbach'" , ietf-provreg@cafax.se Subject: RE: Comments on overall direction Date: Wed, 27 Dec 2000 09:23: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 While I know of at least one company that would be thrilled to see requirements for millions of domain name owners to become PKI-capable (or even just the subset who wish to request transfers), I have to echo the point raised by Dave concerning deployment and adoption. I'm sure there are domain name holders who would understand and welcome such developments, but people aren't exactly falling over each other to install applications that provide cryptographic services. I don't disagree that transactional integrity is essential, but we may have different ideas on where that integrity service needs to be available or applied. I believe that we have a far better chance to produce a widely accepted protocol if we do our best to keep the protocol itself extremely simple, and using a layered approach to add services that make sense in particular operational environments. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Karl Auerbach [mailto:karl@CaveBear.com] Sent: Wednesday, December 27, 2000 5:08 AM To: ietf-provreg@cafax.se Subject: Re: Comments on overall direction > At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote: > > >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. > > It would help to have a description of an existing service that has similar > scale and scope, that uses a similar mechanism. A bill of lading. It's a technique that's been in use since about the year 1500. In recent times, in operating systems the technique has been called a "capability". It's not a big extension to conceive of a digitally signed object that represents an instruction to perform some action on some asset - such as a domain name. Indeed, we are part way there with the PGP signed domain update forms that we use today. When I ask for my domain to be transfered from agent A to agent B, I tell agent A to initiate a transfer, A gets a digitally signed certificate of control from the database/registry, signs it itself, and then hands it to me. I sign it. I, in turn, hand it to agent B who verifies the various signatures. Agent B signs it and hands it to the database/registry, which also verifies everything and, if they check out, performs the transfer. > >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. > > > >This suggests to me that there ought to be adequate information in the > >protocols to build unambiguous, timestamped, transaction journals. > > "in the protocols"? Sites can and do do high quality, timestamped > journaling without special protocol issues. What specific mechanisms or > information do you believe affect the protocols? Timestamps can be faked, that's why there needs to be both client and server timestamps, and for them to be integrity protected in the packets. > >It also suggests to me that there be provision for solid identification > >and authenticatation of all transactions. > > so, you want a public key signature on every protocol unit? Not every PDU - but certainly on every transaction. --karl-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBRA7bh26932 for ietf-provreg-outgoing; Wed, 27 Dec 2000 11:07:37 +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 eBRA7Z226927 for ; Wed, 27 Dec 2000 11:07:36 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id eBRA7Y401902 for ; Wed, 27 Dec 2000 02:07:35 -0800 Date: Wed, 27 Dec 2000 02:07:34 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Subject: Re: Comments on overall direction In-Reply-To: <5.0.2.1.2.20001226235525.0349d680@mail.bayarea.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote: > > >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. > > It would help to have a description of an existing service that has similar > scale and scope, that uses a similar mechanism. A bill of lading. It's a technique that's been in use since about the year 1500. In recent times, in operating systems the technique has been called a "capability". It's not a big extension to conceive of a digitally signed object that represents an instruction to perform some action on some asset - such as a domain name. Indeed, we are part way there with the PGP signed domain update forms that we use today. When I ask for my domain to be transfered from agent A to agent B, I tell agent A to initiate a transfer, A gets a digitally signed certificate of control from the database/registry, signs it itself, and then hands it to me. I sign it. I, in turn, hand it to agent B who verifies the various signatures. Agent B signs it and hands it to the database/registry, which also verifies everything and, if they check out, performs the transfer. > >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. > > > >This suggests to me that there ought to be adequate information in the > >protocols to build unambiguous, timestamped, transaction journals. > > "in the protocols"? Sites can and do do high quality, timestamped > journaling without special protocol issues. What specific mechanisms or > information do you believe affect the protocols? Timestamps can be faked, that's why there needs to be both client and server timestamps, and for them to be integrity protected in the packets. > >It also suggests to me that there be provision for solid identification > >and authenticatation of all transactions. > > so, you want a public key signature on every protocol unit? Not every PDU - but certainly on every transaction. --karl-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBR8olx26495 for ietf-provreg-outgoing; Wed, 27 Dec 2000 09:50:47 +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 eBR8ok226490 for ; Wed, 27 Dec 2000 09:50:46 +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 AAA27395; Wed, 27 Dec 2000 00:01:23 -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.20001226235525.0349d680@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 27 Dec 2000 00:02:35 -0800 To: Karl Auerbach From: Dave Crocker Subject: Re: Comments on overall direction Cc: 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 12:29 PM 12/26/00 -0800, Karl Auerbach wrote: >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. It would help to have a description of an existing service that has similar scale and scope, that uses a similar mechanism. Absent that, we will need to be clear about the portions of the mechanism that you are proposing that will carry significant risk of not being deployed or adopted. >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. > >This suggests to me that there ought to be adequate information in the >protocols to build unambiguous, timestamped, transaction journals. "in the protocols"? Sites can and do do high quality, timestamped journaling without special protocol issues. What specific mechanisms or information do you believe affect the protocols? >It also suggests to me that there be provision for solid identification >and authenticatation of all transactions. so, you want a public key signature on every protocol unit? 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 eBR0pn423115 for ietf-provreg-outgoing; Wed, 27 Dec 2000 01:51: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 eBR0pm223108 for ; Wed, 27 Dec 2000 01:51:48 +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 JAA17173 for ; Tue, 26 Dec 2000 09:26:58 -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.20001226092136.039ad860@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 26 Dec 2000 09:28:34 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Draft provreg charter 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 Folks, Here is a draft of the working group charter. (Sorry for the delay.) It reflects the changes I typed during the BOF, and string changes from 'domreg' to 'provreg'. d/ Provisioning Registry Protocol (ProvReg) ------------------------------ CHAIR(S): APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: 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 data base for registrations, called the registry, versus the "front-end" sales and support services by registrars who interact with registrants and with the "back-end" 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 protocol for registrar access to the registry. 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 domain names within a single Top Level Domain (TLD). 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, and may consider use the protocol for other for other registration and update 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, their relationships to each other, and the protocol for exchanging objects between a registrar and the registry * Describe appropriate mechanisms for security and protection during registrar access * List useful examples of registrar access transactions GOALS AND MILESTONES: Jan, 2005 Working group chartered Feb, 2001 Working group agreement on functional requirements for protocol Feb, 2001 Initial specification of provreg protocol May, 2001 Second draft specification Sep, 2001 Submit provreg draft for standards track =-=-=-=-= 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 eBQKTPc21578 for ietf-provreg-outgoing; Tue, 26 Dec 2000 21:29:25 +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 eBQKTO221573 for ; Tue, 26 Dec 2000 21:29:24 +0100 (MET) Received: from localhost (karl@localhost) by p2.cavebear.com (8.11.0/8.11.0) with ESMTP id eBQKTML25685 for ; Tue, 26 Dec 2000 12:29:23 -0800 Date: Tue, 26 Dec 2000 12:29:22 -0800 (PST) From: Karl Auerbach Reply-To: Karl Auerbach To: Subject: Comments on overall direction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk I've just read through the e-mail that came in over the last week. What struck me is how much it seems tied to existing practices of NSI's registry. For example, just because NSI today has registrations in year units is no reason to think that that must be true for everyone everywhere. And what struck me further is how quickly the discussion focused on domain name registration and forgot that there are other kinds of network resources that need similar services. So -- my comments: 1. A nit: I'd like to get rid of this horrid "registrar", "registry", "registrant" terminology. There have been more instances than I can count where discussions went off into the weeds because somebody accidently used the wrong ending to the string "registr". Mike O'Dell has suggested "repository" and "agent" in lieu of "registry" and "registrar". Personally I like the trio "database", "agent", and "customer". 2. There are many kinds of Internet resources that customers will want to lay claim to - domain names, IP address blocks, and ASNs come to mind as some we have today. The common feature about these is that they can all be described using the following skeletal paradigm: (The following is for illustration, I'm aware that there are more detailed versions.) ... ... ... ... ... This suggests several things to me: - That we can have a single protocol to handle registrations of all kinds of things, not just DNS names. - That there is no reason why this package can't also be used between all parties to this system - agents-to-database (and vice-versa), customers to agents, agents-to-agents, databases-to-escrow systems, agents-to-escrow systems. - That the protocol should be designed in "chunks". Thus one chunk would support a lockable registration exchange between a customer and its selected agent, and also between an agent and the database. And another chunk of protocol would support unlocked query access. (This latter function happens to be a nice alternative to the underdefined port 43 mechanism.) 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. 4. I'm nervous about the inclusion of fancy negotion protocols - such as have been aluded to with regard to the negotion of expiration timestamps. My own preference is that the protocols simply have a code to express that a request has been "rejected due to unacceptable expiration timestamp". To my mind external channels should be used to convey policies about these kinds of things. 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. This suggests to me that there ought to be adequate information in the protocols to build unambiguous, timestamped, transaction journals. It also suggests to me that there be provision for solid identification and authenticatation of all transactions. I don't care whether this comes as part of this protocol or as part of a lower layer protocol. However, since we are going to have to abide by inconsistant privacy laws I have this more than sneaking suspicion that implementations are going to have to resort to call-outs to policy servers - as such we ought to make sure that these protocols and data representations are amenible to being filtered by some sort of policy expressions that might come back from such policy servers. --karl-- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBQJB2C21141 for ietf-provreg-outgoing; Tue, 26 Dec 2000 20:11:02 +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 eBQJB1221134 for ; Tue, 26 Dec 2000 20:11:01 +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 LAA25569; Tue, 26 Dec 2000 11:10:57 -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 eBQJAuj05988; Tue, 26 Dec 2000 11:10:56 -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 LAA25796; Tue, 26 Dec 2000 11:10:52 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <5.0.0.25.2.20001222133748.03403600@localhost> References: <5.0.0.25.2.20001222133748.03403600@localhost> Date: Tue, 26 Dec 2000 20:09:10 +0100 To: =?iso-8859-1?Q?Andr=C8?= Cormier , "Provreg (E-mail)" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: My personal comments on the requirements. Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13.49 -0500 00-12-22, AndrÈ Cormier wrote: >9. Internationalization Considerations > [1] Current Internet standards restrict the encoding of Internet host > and domain names to a subset of the 7-bit US-ASCII character set. > Registries and registrars now serve customers whose native languages > require encodings other than US-ASCII, which automatically disallows > use of those languages when registering host and domain names. > Support for internationalized host and domain names will greatly > increase world-wide usability of a generic registry registrar > protocol, so standards for internationalized host and domain names > MUST be considered during the protocol design process. >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable >AC: the use of internationalized data. The information in section 9 should be syncronized with what happens in the IDN working group -- BUT, I would like to differ between two different types of data: - The Domain Names themselves - Other meta-data which goes along with the domainname, such as the street address of the admin contact etc, which can include not only non-ascii characters but also the address in a different format than what is default by the registry. Example: Street name and number is in the US written as " " while in Sweden the order is the inverse " ". To start with, the meta information should be able to be both in "english" ascii and in the native characters using Unicode, but the domainname definition should wait for the IDN definition (it might be that the domainname should be in some ACE encoding, already nameprepped -- or equivalent). 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 eBQJB1t21133 for ietf-provreg-outgoing; Tue, 26 Dec 2000 20:11:01 +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 eBQJB0221126 for ; Tue, 26 Dec 2000 20:11:00 +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 LAA25518; Tue, 26 Dec 2000 11:10:51 -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 eBQJAo605945; Tue, 26 Dec 2000 11:10: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 LAA25763; Tue, 26 Dec 2000 11:10:43 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <5.0.0.25.2.20001222133748.03403600@localhost> References: <5.0.0.25.2.20001222133748.03403600@localhost> Date: Tue, 26 Dec 2000 20:04:51 +0100 To: =?iso-8859-1?Q?Andr=C8?= Cormier , "Provreg (E-mail)" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: My personal comments on the requirements. Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13.49 -0500 00-12-22, AndrÈ Cormier wrote: > > [5] The protocol MUST consider that the name server associated with a >> domain might not be registered in the same domain or even in a TLD for >> which the registry is authoritative. This means that IP addresses for >> name servers whose parent domain exists in another TLD MUST be >> registered only in the registry that is authoritative for the TLD of >> the name server. Glue records (DNS "A" records) MUST NOT be created >> for DNS NS records for which the registry is not authoritative. >AC: I do not think this is protocol related. It will be the registry >application that >AC: will create the DNS zone file and glue records. It should not be >state as a >AC: requirement. I caan easily see that as a comment in the protocol >definition draft >AC: and a pointer to a companion document for best current practices. The problem with glue in some zones or registries which do not belong there but in a different zone is what happens when the IP address of those glues change. Should one owner of a nameserver remember to talk to _every_ registry and change the IP address, or just the one which the IP address really belong? If you say it is only a requirement of the zone that is generated, what is your thought of why the IP address need to be in the database of the registry? What happens if that IP address becomes out of date? I.e. if you are a registry, and have one Ip address in your database, and you by using DNS find a different IP address in DNS, which one will you trust (I hope the one in DNS) and why in that case do you need one in the database? I need more arguments for why the IP address needs to be in more than one place, i.e. in the registry which really own the correct TLD for the NS, where the glue really should be. Storing the same information in more than one place is generally (in my experience) a bad thing, and always leads to inconsistency between records. 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 eBQFYIm20045 for ietf-provreg-outgoing; Tue, 26 Dec 2000 16:34:18 +0100 (MET) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBQFYH220040 for ; Tue, 26 Dec 2000 16:34:17 +0100 (MET) Received: from computer.ix.netcom.com (user-2ivels3.dialup.mindspring.com [165.247.87.131]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA14189; Tue, 26 Dec 2000 10:33:53 -0500 (EST) Message-Id: <5.0.2.1.2.20001226103220.02a987e0@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: Tue, 26 Dec 2000 10:33:13 -0500 To: "J. William Semich" , "'provreg List'" From: Richard Shockey Subject: Re: Scope [was Re: Expiration times] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Forgive me if this made it to the list before ..I've made a couple of postings and I'm not sure they made it..I did not get a reflection back. > > > >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: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBQFAv119931 for ietf-provreg-outgoing; Tue, 26 Dec 2000 16:10: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 eBQFAt219926 for ; Tue, 26 Dec 2000 16:10:56 +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 KAA19881; Tue, 26 Dec 2000 10:00:47 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:07:00 -0500 Message-ID: From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Andr=E9_Cormier=27?= , "Provreg (E-mail)" Subject: RE: My personal comments on the requirements. Date: Tue, 26 Dec 2000 10:06:52 -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 eBQFAu219927 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks for your comments, André. I'd like to respond and suggest some alternative re-wordings if I may; my responses, suggestions, and rationale are included below preceded by "[SAH]". Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: André Cormier [mailto:Andre.Cormier@viagenie.qc.ca] Sent: Friday, December 22, 2000 1:49 PM To: Provreg (E-mail) Subject: My personal comments on the requirements. I got interested in this at last IETF in San Diego. Here are my "humble" comments on the requirement documents. I think = they might be of interest. I've provided only the sections that i have commented. We can spread different threads as needed to discuss them if any of you agrees with these. My comments starts with "AC: ". Regards Andr=E9 >1. Introduction > This document is being discussed on the "rrp" mailing list. To = join > the list, send a message to with the = words > "subscribe rrp" in the body of the message. There is a web site = for > the list archives at . AC: Do not forget to point to the new mailing list... [SAH] Yes, of course. -------------- >3.2 Identification and Authentication > AC: 2 new items proposed. New protocols allow for negociation of the AC: authentication mechanism. This protocol one should be open enough = to allow AC: such negociation. AC: [3] The protocol MUST provide services to allow the negociatoin of = the AC: authentication mechanism that will be used to authenticate = registrar=20 clients. AC: [4] The protocol MUST provide services to advertise authentication=20 mechanism AC: supported by both the server and the client. [SAH] I don't have a problem with the basic idea here, but I'd like to suggest that this doesn't need to be a MUST in the protocol itself. Other layers can do this as well; for example, BEEP offers just such a negotiation mechanism and I think it would be overkill to do the negotiation within both BEEP and another application layer protocol. Would this re-wording be acceptable?: "[3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both the server and the client." I don't think the advertisement requirement is necessary if the mechanism must be negotiated. Some kind of information exchange has to happen as part of the negotiation process. -------------- >3.3 Transaction Identification AC: I suggest we add a paragraph to clearly state that this number MUST = be=20 randomly AC: generated so it would be nearly impossible for someone to guess = what will AC: be the identifier used by another registrar. AC: [3] The unique transaction identifier MUST be randomly generated so = it AC: would be nearly impossible for someone to guess what number as been = assigned AC: to a registrar. [SAH] Actually, I prefer the text proposed by Geva last week that says that each transaction must be "identified in a permanent and globally unique manner". Requiring randomization gets into "how" the protocol should behave instead of describing "what" it should do. -------------- 3.4 Object Registration > [4] The protocol MUST provide services to register name servers. = Name > server registration MUST NOT be limited to a specific period of = time. > Name servers registered within the registry's authoritative TLDs = MUST > be registered with a valid Internet Protocol (IP) address. A name > server MAY be registered with multiple IP addresses. An IP address > MAY be shared among multiple name servers using distinct server = names. > Name servers that exist in TLDs other than those for which the > registry is authoritative MUST be registered without an IP address > providing that the server TLD is itself a valid TLD. AC: The protocol MUST allow the identification of the type of address. = This AC: way we will be able to add IPv6 addresses when the time will come. = I do not AC: say that we should include AAAA and A6 records. We should define a = way that AC: enables us to tag the type of address so it would be possible to=20 register AAAA AC: and A6 records in the future. We should support IPv6 to have less = impact AC: when the time will come. [SAH] Section 1.1 states that the term "IP Address" means either or both IPv4 or IPv6 address. I'll modify the text in this section to clearly state that support for both IPv4 and IPv6 addresses is required without specifying how that support should be provided. > [5] The protocol MUST consider that the name server associated with = a > domain might not be registered in the same domain or even in a TLD = for > which the registry is authoritative. This means that IP addresses = for > name servers whose parent domain exists in another TLD MUST be > registered only in the registry that is authoritative for the TLD = of > the name server. Glue records (DNS "A" records) MUST NOT be = created > for DNS NS records for which the registry is not authoritative. AC: I do not think this is protocol related. It will be the registry=20 application that AC: will create the DNS zone file and glue records. It should not be = state as a AC: requirement. I caan easily see that as a comment in the protocol=20 definition draft AC: and a pointer to a companion document for best current practices. [SAH] This text was added quite some time ago at the urging of our Area Director. I'll defer to Patrik to decide if we should remove this text or reword it so that it's clearly not a protocol requirement. Patrik? > [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 MUST 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, and = e- > mail address. A facsimile telephone number MAY be provided. AC: The protocol MUST allow for registry specific field for all objects = managed AC: by the protocol. Those field should be state as optional by the=20 protocol but AC: MAY be forced mandatory by the registry with the use of error codes = stating AC: that a specific field is required. [SAH] Can you be more specific about the purpose of this new field? I'd much prefer to enumerate required information vs. providing some kind of unformatted registry-specific field. > [9] A registry MUST provide services to support a configurable = grace > period during which time a request to register a domain name or = other > billable object can be undone without harm. AC: I think this should be The protocol MUST provides services... If it = is the AC: registry than it's not protocol related but policy issue or = implementation AC: issue and does not belong in that document. [SAH] I'd prefer to pull this requirement out of the document than to require protocol support for something that isn't negotiated between registrar and registry but is rather a registry policy issue. OK to pull it out? -------------- 3.5 Object Association > [2] The protocol MUST provide services to associate IP addresses = with > name servers. A name server MAY have multiple IP addresses. An IP > address MAY be associated with multiple name servers. AC: The same comment apply here for IP address type. We should provide = means AC: to tag IP address type so it would be possible to add IPv6 = addresses. [SAH] I'd like to address this by again clearly stating required support for both IPv4 and IPv6 address. Tagging describes "how" that support is provided, and is thus something that I think would be more appropriately addressed in a protocol specification. -------------- 3.7 Object Transfer > [5] A transfer request MUST include a new transaction identifier. = The > new transaction identifier MUST be returned to the registrant by = the > registrar to facilitate authorization of future transfer requests. AC: The same comment for this number. It should random as i said = earlier. [SAH] Actually I think this requirement should be removed because it describes a "how" and not a "what". > [10] A registry MUST provide a default transfer action in case of > registrar inaction. If a registry-specified period of time elapses > without explicit approval, rejection, or cancellation, a registry = MUST > perform the default transfer action on behalf of the requesting > registrar. AC: This should not be in the requirements unless the action period = MUST be AC: speficied in the protocol or domain name object. If the action = period=20 is not AC: part of the protocol than it is implementation issue or policy = related and AC: therefore should not be expressed in this document. [SAH] I agree, so I'd like to remove this requirement. -------------- 3.10 Object Deletion > [1] The protocol MUST provide services to remove a domain name from > the registry. Deleting a domain name MUST also delete all child = name > servers. A domain name MUST NOT be deleted if child name servers = are > being used to host other domain names. AC: The first phrase should be left intact but the rest should be = removed. AC: This is an important issue but not really protocol related. I think = that AC: maybe another document should be written as implementation guide to = state AC: important issues related to domain name registration and DNS zone = file AC: creation. It is not the protocol that updates the database but the AC: registry application. This applications uses the protocol to = exchange AC: with clients. This document defines functional requirements for the = protocol, AC: not the registry application. I really think that another document = should AC: be written for registries and registrars that will implement the=20 protocol. It AC: should be done as a companion document. [SAH] Agreed, so I'll remove the text. > [2] The protocol MUST provide services to remove a name server from > the registry. Name servers MUST be referenced by fully-qualified > name. A name server MUST NOT be deleted if it is being used to = host a > domain name. AC: Same comment as above. [SAH] Agreed. > [3] The protocol MUST provide services to remove a contact from the > registry. Contacts MUST be referenced by registry identifier. A > contact MUST NOT be deleted if it is associated with a domain. AC: Same comment as above. [SAH] Agreed. -------------- 9. Internationalization Considerations [1] Current Internet standards restrict the encoding of Internet = host and domain names to a subset of the 7-bit US-ASCII character set. Registries and registrars now serve customers whose native languages require encodings other than US-ASCII, which automatically disallows use of those languages when registering host and domain names. Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for internationalized host and domain names MUST be considered during the protocol design process. AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to = enable AC: the use of internationalized data. [SAH] I'd prefer to reword the last sentence than to explicitly require UTF-8 because it again addresses "how" to solve a particular problem. How about changing this: "so standards for internationalized host and domain names MUST be considered during the protocol design process" to this: "so standards for exchanging internationalized information MUST be considered during the protocol design process" I think that covers more than domain and host names without requiring a specific solution. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBMIv6K22164 for ietf-provreg-outgoing; Fri, 22 Dec 2000 19:57:06 +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 eBMIv5222159 for ; Fri, 22 Dec 2000 19:57:05 +0100 (MET) Received: from rock.viagenie.qc.ca (modemcable241.164-202-24.que.mc.videotron.ca [24.202.164.241]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id eBMJ2Kd17028; Fri, 22 Dec 2000 14:02:20 -0500 (EST) Message-Id: <5.0.0.25.2.20001222133748.03403600@localhost> X-Sender: acormier@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 13:49:29 -0500 To: "Provreg (E-mail)" From: André Cormier Subject: My personal comments on the requirements. 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 I got interested in this at last IETF in San Diego. Here are my "humble" comments on the requirement documents. I think they might be of interest. I've provided only the sections that i have commented. We can spread different threads as needed to discuss them if any of you agrees with these. My comments starts with "AC: ". Regards André >1. Introduction > This document is being discussed on the "rrp" mailing list. To join > the list, send a message to with the words > "subscribe rrp" in the body of the message. There is a web site for > the list archives at . AC: Do not forget to point to the new mailing list... -------------- >3.2 Identification and Authentication > AC: 2 new items proposed. New protocols allow for negociation of the AC: authentication mechanism. This protocol one should be open enough to allow AC: such negociation. AC: [3] The protocol MUST provide services to allow the negociatoin of the AC: authentication mechanism that will be used to authenticate registrar clients. AC: [4] The protocol MUST provide services to advertise authentication mechanism AC: supported by both the server and the client. -------------- >3.3 Transaction Identification AC: I suggest we add a paragraph to clearly state that this number MUST be randomly AC: generated so it would be nearly impossible for someone to guess what will AC: be the identifier used by another registrar. AC: [3] The unique transaction identifier MUST be randomly generated so it AC: would be nearly impossible for someone to guess what number as been assigned AC: to a registrar. -------------- 3.4 Object Registration > [4] The protocol MUST provide services to register name servers. Name > server registration MUST NOT be limited to a specific period of time. > Name servers registered within the registry's authoritative TLDs MUST > be registered with a valid Internet Protocol (IP) address. A name > server MAY be registered with multiple IP addresses. An IP address > MAY be shared among multiple name servers using distinct server names. > Name servers that exist in TLDs other than those for which the > registry is authoritative MUST be registered without an IP address > providing that the server TLD is itself a valid TLD. AC: The protocol MUST allow the identification of the type of address. This AC: way we will be able to add IPv6 addresses when the time will come. I do not AC: say that we should include AAAA and A6 records. We should define a way that AC: enables us to tag the type of address so it would be possible to register AAAA AC: and A6 records in the future. We should support IPv6 to have less impact AC: when the time will come. > [5] The protocol MUST consider that the name server associated with a > domain might not be registered in the same domain or even in a TLD for > which the registry is authoritative. This means that IP addresses for > name servers whose parent domain exists in another TLD MUST be > registered only in the registry that is authoritative for the TLD of > the name server. Glue records (DNS "A" records) MUST NOT be created > for DNS NS records for which the registry is not authoritative. AC: I do not think this is protocol related. It will be the registry application that AC: will create the DNS zone file and glue records. It should not be state as a AC: requirement. I caan easily see that as a comment in the protocol definition draft AC: and a pointer to a companion document for best current practices. > [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 MUST 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, and e- > mail address. A facsimile telephone number MAY be provided. AC: The protocol MUST allow for registry specific field for all objects managed AC: by the protocol. Those field should be state as optional by the protocol but AC: MAY be forced mandatory by the registry with the use of error codes stating AC: that a specific field is required. > [9] A registry MUST provide services to support a configurable grace > period during which time a request to register a domain name or other > billable object can be undone without harm. AC: I think this should be The protocol MUST provides services... If it is the AC: registry than it's not protocol related but policy issue or implementation AC: issue and does not belong in that document. -------------- 3.5 Object Association > [2] The protocol MUST provide services to associate IP addresses with > name servers. A name server MAY have multiple IP addresses. An IP > address MAY be associated with multiple name servers. AC: The same comment apply here for IP address type. We should provide means AC: to tag IP address type so it would be possible to add IPv6 addresses. -------------- 3.7 Object Transfer > [5] A transfer request MUST include a new transaction identifier. The > new transaction identifier MUST be returned to the registrant by the > registrar to facilitate authorization of future transfer requests. AC: The same comment for this number. It should random as i said earlier. > [10] A registry MUST provide a default transfer action in case of > registrar inaction. If a registry-specified period of time elapses > without explicit approval, rejection, or cancellation, a registry MUST > perform the default transfer action on behalf of the requesting > registrar. AC: This should not be in the requirements unless the action period MUST be AC: speficied in the protocol or domain name object. If the action period is not AC: part of the protocol than it is implementation issue or policy related and AC: therefore should not be expressed in this document. -------------- 3.10 Object Deletion > [1] The protocol MUST provide services to remove a domain name from > the registry. Deleting a domain name MUST also delete all child name > servers. A domain name MUST NOT be deleted if child name servers are > being used to host other domain names. AC: The first phrase should be left intact but the rest should be removed. AC: This is an important issue but not really protocol related. I think that AC: maybe another document should be written as implementation guide to state AC: important issues related to domain name registration and DNS zone file AC: creation. It is not the protocol that updates the database but the AC: registry application. This applications uses the protocol to exchange AC: with clients. This document defines functional requirements for the protocol, AC: not the registry application. I really think that another document should AC: be written for registries and registrars that will implement the protocol. It AC: should be done as a companion document. > [2] The protocol MUST provide services to remove a name server from > the registry. Name servers MUST be referenced by fully-qualified > name. A name server MUST NOT be deleted if it is being used to host a > domain name. AC: Same comment as above. > [3] The protocol MUST provide services to remove a contact from the > registry. Contacts MUST be referenced by registry identifier. A > contact MUST NOT be deleted if it is associated with a domain. AC: Same comment as above. -------------- 9. Internationalization Considerations [1] Current Internet standards restrict the encoding of Internet host and domain names to a subset of the 7-bit US-ASCII character set. Registries and registrars now serve customers whose native languages require encodings other than US-ASCII, which automatically disallows use of those languages when registering host and domain names. Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for internationalized host and domain names MUST be considered during the protocol design process. AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable AC: the use of internationalized data. ______________________________________________________________________ André Cormier | Téléphone : (418) 656-9254 2875 boul. Laurier | Télécopie : (418) 266-5539 Bureau 300 | Sainte-Foy, (Québec) G1V 2M2 | Andre.Cormier@viagenie.qc.ca Canada | Radio : VA2UNX, VA2ACE ---------------------------------------------------------------------- Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ---------------------------------------------------------------------- PGP: D434 547D 712A E44F C978 4673 BD50 A248 C262 CB06 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLKmXP12807 for ietf-provreg-outgoing; Thu, 21 Dec 2000 21:48:33 +0100 (MET) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLKmV212802 for ; Thu, 21 Dec 2000 21:48:32 +0100 (MET) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22626 for ; Thu, 21 Dec 2000 12:45:07 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <31EF955E0A3BD411AE7F004F4E01F08423A7EA@mailut2.vpnx.com> References: <31EF955E0A3BD411AE7F004F4E01F08423A7EA@mailut2.vpnx.com> Date: Thu, 21 Dec 2000 12:48:08 -0800 To: "Provreg (E-mail)" From: Paul Hoffman / IMC Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:25 AM -0700 12/21/00, Brian Jarvis wrote: > > So you're recommending instituting a "class of service" identifier, >> where the default (perhaps) is mandated? You realize that you're >> introducing the need for an "IANA function" to register the classes, >> as I see it? > >I agree that a "class of service" identifier is appropriate. However, >in order to ease/eliminate the IANA function, I would prefer it be an OID. OIDs still need to be registered somewhere to help people understand what their semantics are. Using a new IANA registry would probably lead to much greater interoperability. At least, that is what we have found (painfully) in the PKIX and S/MIME world... --Paul Hoffman, Director --Internet Mail Consortium Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJu2T12500 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:56:02 +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 eBLJu1212495 for ; Thu, 21 Dec 2000 20:56:01 +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 OAA15976; Thu, 21 Dec 2000 14:45:38 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 14:52:02 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Geva Patz'" , "'ietf-provreg@cafax.se'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 14:51:58 -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 As I read this again I need one more clarification, please. Should "domain name" be added to the first sentence to be clear that the paragraph refers to domain names? "The protocol MUST permit a starting and ending time for a domain name registration to be negotiated" Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Thursday, December 21, 2000 2:30 PM To: 'ietf-provreg@cafax.se' Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote: > I think I misread one piece of your most recent proposal (reading > "registrars" where you wrote "registries"). The way you characterized the > requirement mapping in your last paragraph gives me an idea, though - why > not phrase the requirement like this: > [2] The protocol MUST allow a registry to implement policies allowing a > range of domain registration time periods, where registrars MAY choose to > offer (not necessarily identical) subsets of the range of periods, and where > registrants get to choose an element from that subset. Why not, indeed! (I find it remarkably hard to argue against what are practically my own words :) I'd perhaps suggest a slight re-wording to enhance clarity while (I hope) preserving the semantics of the original wording you suggest above: [2] The protocol MUST permit a starting and ending time for a registration to be negotiated, thereby enabling a registry to implement policies allowing a range of registration validity periods, and enabling registrars to select a period for each registration they submit from within the valid range based on out-of-band negotiation between the registrar and the registrant. Registries SHOULD be allowed to accept indefiniteily valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. The protocol MUST ensure that, at the successful conclusion of a registration event, the registrar and registry have the same, unambiguous, conception of the validity period of the registration. The wording of the last sentence probably needs work. What I'm trying to avoid here is the situation where a registrar, on 1/1/2001, says "Register domain name X from now until 3/1/2001", and the registry says "OK", and silently rounds the validity period up to a year. The protocol should either have the registry respond with "I can't do that!" or "OK, I've registered the name until 12/31/2001". I've also resuscitated the rare but necessary case of indefinite registrations (some ccTLDs use these, as do some non-domain name identifier registries). -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJmc412445 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:48:38 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLJmb212440 for ; Thu, 21 Dec 2000 20:48:37 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id OAA11358 for ietf-provreg@cafax.se; Thu, 21 Dec 2000 14:48:36 -0500 (EST) (envelope-from geva) Date: Thu, 21 Dec 2000 14:48:36 -0500 From: Geva Patz To: "'ietf-provreg@cafax.se'" Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Message-ID: <20001221144836.B7997@bruno.bbn.com> Mail-Followup-To: "'ietf-provreg@cafax.se'" 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 Thu, Dec 21, 2000 at 02:41:44PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Dec 21, 2000 at 02:41:44PM -0500, Hollenbeck, Scott wrote: > I can live with this. How's this for work on the last sentence: > > "The protocol MUST provide features to ensure that both registry and > registrar have a mutual understanding of the validity period at the > conclusion of a successful registration event." Much better, thanks. -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJjl412424 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:45: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 eBLJjk212419 for ; Thu, 21 Dec 2000 20:45:46 +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 OAA15923; Thu, 21 Dec 2000 14:35:28 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 14:41:52 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Geva Patz'" , "'ietf-provreg@cafax.se'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 14:41: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 I can live with this. How's this for work on the last sentence: "The protocol MUST provide features to ensure that both registry and registrar have a mutual understanding of the validity period at the conclusion of a successful registration event." Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Thursday, December 21, 2000 2:30 PM To: 'ietf-provreg@cafax.se' Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote: > I think I misread one piece of your most recent proposal (reading > "registrars" where you wrote "registries"). The way you characterized the > requirement mapping in your last paragraph gives me an idea, though - why > not phrase the requirement like this: > [2] The protocol MUST allow a registry to implement policies allowing a > range of domain registration time periods, where registrars MAY choose to > offer (not necessarily identical) subsets of the range of periods, and where > registrants get to choose an element from that subset. Why not, indeed! (I find it remarkably hard to argue against what are practically my own words :) I'd perhaps suggest a slight re-wording to enhance clarity while (I hope) preserving the semantics of the original wording you suggest above: [2] The protocol MUST permit a starting and ending time for a registration to be negotiated, thereby enabling a registry to implement policies allowing a range of registration validity periods, and enabling registrars to select a period for each registration they submit from within the valid range based on out-of-band negotiation between the registrar and the registrant. Registries SHOULD be allowed to accept indefiniteily valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. The protocol MUST ensure that, at the successful conclusion of a registration event, the registrar and registry have the same, unambiguous, conception of the validity period of the registration. The wording of the last sentence probably needs work. What I'm trying to avoid here is the situation where a registrar, on 1/1/2001, says "Register domain name X from now until 3/1/2001", and the registry says "OK", and silently rounds the validity period up to a year. The protocol should either have the registry respond with "I can't do that!" or "OK, I've registered the name until 12/31/2001". I've also resuscitated the rare but necessary case of indefinite registrations (some ccTLDs use these, as do some non-domain name identifier registries). -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJUHp12341 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:30:17 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLJUG212336 for ; Thu, 21 Dec 2000 20:30:17 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id OAA09972 for ietf-provreg@cafax.se; Thu, 21 Dec 2000 14:30:15 -0500 (EST) (envelope-from geva) Date: Thu, 21 Dec 2000 14:30:15 -0500 From: Geva Patz To: "'ietf-provreg@cafax.se'" Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Message-ID: <20001221143015.A7997@bruno.bbn.com> Mail-Followup-To: "'ietf-provreg@cafax.se'" 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 Thu, Dec 21, 2000 at 01:56:40PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote: > I think I misread one piece of your most recent proposal (reading > "registrars" where you wrote "registries"). The way you characterized the > requirement mapping in your last paragraph gives me an idea, though - why > not phrase the requirement like this: > [2] The protocol MUST allow a registry to implement policies allowing a > range of domain registration time periods, where registrars MAY choose to > offer (not necessarily identical) subsets of the range of periods, and where > registrants get to choose an element from that subset. Why not, indeed! (I find it remarkably hard to argue against what are practically my own words :) I'd perhaps suggest a slight re-wording to enhance clarity while (I hope) preserving the semantics of the original wording you suggest above: [2] The protocol MUST permit a starting and ending time for a registration to be negotiated, thereby enabling a registry to implement policies allowing a range of registration validity periods, and enabling registrars to select a period for each registration they submit from within the valid range based on out-of-band negotiation between the registrar and the registrant. Registries SHOULD be allowed to accept indefiniteily valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. The protocol MUST ensure that, at the successful conclusion of a registration event, the registrar and registry have the same, unambiguous, conception of the validity period of the registration. The wording of the last sentence probably needs work. What I'm trying to avoid here is the situation where a registrar, on 1/1/2001, says "Register domain name X from now until 3/1/2001", and the registry says "OK", and silently rounds the validity period up to a year. The protocol should either have the registry respond with "I can't do that!" or "OK, I've registered the name until 12/31/2001". I've also resuscitated the rare but necessary case of indefinite registrations (some ccTLDs use these, as do some non-domain name identifier registries). -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJ6TR12227 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:06: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 eBLJ6S212222 for ; Thu, 21 Dec 2000 20:06: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 NAA15812; Thu, 21 Dec 2000 13:55:49 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 14:02:30 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jordyn A. Buchanan'" , "'ietf-provreg@cafax.se'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 14:02:23 -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 Sure, ensuring that things don't break for other types of objects is a Good Thing. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Jordyn A. Buchanan [mailto:jordyn@register.com] Sent: Thursday, December 21, 2000 12:34 PM To: Hollenbeck, Scott; 'ietf-provreg@cafax.se' Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] 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. Jordyn Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLJ0uj12146 for ietf-provreg-outgoing; Thu, 21 Dec 2000 20:00: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 eBLJ0t212141 for ; Thu, 21 Dec 2000 20:00:55 +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 NAA15795; Thu, 21 Dec 2000 13:50:26 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 13:56:50 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Geva Patz'" , "'ietf-provreg@cafax.se'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 13:56:40 -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 Geza, I can come up with some text for section two to describe the object extensibility goal. The first sentence described below seems like a good starting point. I think I misread one piece of your most recent proposal (reading "registrars" where you wrote "registries"). The way you characterized the requirement mapping in your last paragraph gives me an idea, though - why not phrase the requirement like this: [2] The protocol MUST allow a registry to implement policies allowing a range of domain registration time periods, where registrars MAY choose to offer (not necessarily identical) subsets of the range of periods, and where registrants get to choose an element from that subset. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Thursday, December 21, 2000 12:45 PM To: 'ietf-provreg@cafax.se' Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] On Thu, Dec 21, 2000 at 12:05:59PM -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: > "[2] The requirements described in this document are not intended to limit > the set of objects that may be managed by a generic registry-registrar > protocol. A generic protocol MUST include features that allow extension to > object types that are not described in this document." I'll buy that. I'd like to see a reference to the idea somewat earlier in the document, too, just to emphasize the point (section 2 seems a prime candidate for such rewriting). > while creating a new 3.4-[2] that deals with the registration period. WRT > to [2] as suggested below, I would really like to understand which > registries support the registration model as described. I'm all for > architectural agility, but I would prefer to work with current real-world > requirements vs. trying to guess what might be done in the future to avoid > kruft introduction. I'm not for the introduction of cruft. Rather, I'm against the introduction of arbitrary restictions. Our ultimate goal, after all, is to create a protocol that will become an Internet standard. To be useful as a standard, it ought to accommodate a wide range of registration application with as wide range of policy models (within, of course, the overall scope of the type of application we're trying to support). The Internet is large, diverse and global, so if we have any aspirations to standardhood, we must take the responsibility of serving that wider audience seriously. For an example of the registration model I described, where a registry implements a policy allowing a range of time periods, where registrars choose to offer (not necessarily identical) subsets of the range of periods, and where registrants get to choose an element from that subset, may I refer you to the gTLDs '.com', '.net' or '.org', where precisely such a mechanism is currently in place. ;) -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLIfii12038 for ietf-provreg-outgoing; Thu, 21 Dec 2000 19:41:44 +0100 (MET) Received: from mailut2.vpnx.com (mailut2.vpnx.com [38.168.152.27]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLIfe212031 for ; Thu, 21 Dec 2000 19:41:41 +0100 (MET) Received: by mailut2.vpnx.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 11:25:21 -0700 Message-ID: <31EF955E0A3BD411AE7F004F4E01F08423A7EA@mailut2.vpnx.com> From: Brian Jarvis To: "'Christopher Ambler'" Cc: "Provreg (E-mail)" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 11:25:18 -0700 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 > > [1] The protocol MUST provide services to register Internet domain > > names, and SHOULD allow for the registration of other unique > > alphanumeric identifiers. > > So you're recommending instituting a "class of service" identifier, > where the default (perhaps) is mandated? You realize that you're > introducing the need for an "IANA function" to register the classes, > as I see it? I agree that a "class of service" identifier is appropriate. However, in order to ease/eliminate the IANA function, I would prefer it be an OID. --the walrus Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLHix611777 for ietf-provreg-outgoing; Thu, 21 Dec 2000 18:44:59 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLHiw211772 for ; Thu, 21 Dec 2000 18:44:58 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id MAA05269 for ietf-provreg@cafax.se; Thu, 21 Dec 2000 12:44:57 -0500 (EST) (envelope-from geva) Date: Thu, 21 Dec 2000 12:44:56 -0500 From: Geva Patz To: "'ietf-provreg@cafax.se'" Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Message-ID: <20001221124456.G38157@bruno.bbn.com> Mail-Followup-To: "'ietf-provreg@cafax.se'" 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 Thu, Dec 21, 2000 at 12:05:59PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Dec 21, 2000 at 12:05:59PM -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: > "[2] The requirements described in this document are not intended to limit > the set of objects that may be managed by a generic registry-registrar > protocol. A generic protocol MUST include features that allow extension to > object types that are not described in this document." I'll buy that. I'd like to see a reference to the idea somewat earlier in the document, too, just to emphasize the point (section 2 seems a prime candidate for such rewriting). > while creating a new 3.4-[2] that deals with the registration period. WRT > to [2] as suggested below, I would really like to understand which > registries support the registration model as described. I'm all for > architectural agility, but I would prefer to work with current real-world > requirements vs. trying to guess what might be done in the future to avoid > kruft introduction. I'm not for the introduction of cruft. Rather, I'm against the introduction of arbitrary restictions. Our ultimate goal, after all, is to create a protocol that will become an Internet standard. To be useful as a standard, it ought to accommodate a wide range of registration application with as wide range of policy models (within, of course, the overall scope of the type of application we're trying to support). The Internet is large, diverse and global, so if we have any aspirations to standardhood, we must take the responsibility of serving that wider audience seriously. For an example of the registration model I described, where a registry implements a policy allowing a range of time periods, where registrars choose to offer (not necessarily identical) subsets of the range of periods, and where registrants get to choose an element from that subset, may I refer you to the gTLDs '.com', '.net' or '.org', where precisely such a mechanism is currently in place. ;) -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLHYit11690 for ietf-provreg-outgoing; Thu, 21 Dec 2000 18:34: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 eBLHYh211685 for ; Thu, 21 Dec 2000 18:34:43 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail1 with esmtp (Exim 3.16 #2) id 1499bW-000654-00; Thu, 21 Dec 2000 12:34:10 -0500 Message-Id: <5.0.2.1.0.20001221122625.02b4d170@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 12:34:10 -0500 To: "Hollenbeck, Scott" , "'ietf-provreg@cafax.se'" From: "Jordyn A. Buchanan" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] 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 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. Jordyn Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLH9tl11498 for ietf-provreg-outgoing; Thu, 21 Dec 2000 18:09:55 +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 eBLH9s211493 for ; Thu, 21 Dec 2000 18:09:54 +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 LAA15523 for ; Thu, 21 Dec 2000 11:59:43 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 12:06:07 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 12:05: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 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: "[2] The requirements described in this document are not intended to limit the set of objects that may be managed by a generic registry-registrar protocol. A generic protocol MUST include features that allow extension to object types that are not described in this document." I would prefer to see this kind of global statement in section 7.5 than in section 3.4 because 3.4 describes object registration only. If we add such a statement to 3.4, I think we have to add similar statements to 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11 to be consistent. I'd like to keep 3.4-[1] limited to domain names as in: > [1] The protocol MUST provide services to register Internet domain > names. while creating a new 3.4-[2] that deals with the registration period. WRT to [2] as suggested below, I would really like to understand which registries support the registration model as described. I'm all for architectural agility, but I would prefer to work with current real-world requirements vs. trying to guess what might be done in the future to avoid kruft introduction. I fully agree that any other descriptions in the document that describe a "how" should be generalized into a "what". There's also something that smells like a "how" in section 8.4; I'll fix that. Identification of other offending sections is welcome. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Thursday, December 21, 2000 9:31 AM To: 'provreg List' Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote: > > Requirement 7.5-[1] already exists to ensure that the protocol allows for > registration of objects not explicitly specified in the draft, so I think > the second sentence is redundant. I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:, generic registry-registrar protocol SHOULD provide features that at a minimum allow for the management of new object types without requiring revisions to the protocol itself". There's a subtle difference in sense between this, which basically suggests that the protocol be extensible, and my proposed rewording of 3.4-[1], which suggests that the protocol should be designed from the outset to accommodate a broader range of identifiers than domain names (which the EPP proposal, for instance, does). I won't re-hash the reasons why we changed the name from `domreg' to `provreg', but I think it's important to capture those in the requirements. > My immediate objection to [2] isn't with the suggested concept, though I do > have a philosophical objection to it that we can take that up when we start > to talk protocol. The requirements draft describes functional requirements, > which I have interpreted to mean "requirements for _what_ the protocol is > supposed to do". I believe the suggested new text is getting into the > specifics of _how_ the protocol is supposed to solve a particular issue, and > is thus out of place in this document. A fair point, except that several other parts of the requirements draft get into exactly such issues. For instance 3.3-[1]: " Registry operations that create, update, or delete objects MUST be associated with a registry-unique transaction identifier. The identifier SHOULD be created using the current date and a combination of identification information assigned by and unique to the registry (such as a registrar identifier) and information assigned by and unique to the registrar requesting the operation (such as a coded combination of letters and numbers)." On your principle (which certainly has merit), this should probably be re-worded something along the lines of: " The protocol MUST allow each transaction to be identified in a permanent and globally unique manner" There are several other examples elswehere in the text. I think we need to decide as a group where we'd like the requirements to be, and if we decide to come down firmly on the side of "what, not how" (which, again, I don't think is a bad idea), then we'd best go through the draft in some detail to make sure that it adheres to that principle. > I think it would be more appropriate > to say something along the lines of "a domain name must have a registration > period whose value is determined by registry policy". ... except that the value may not be determined by registry policy, but by registrar policy (or by registrant request). All registries have a policy, even if only by implication ("we'll register anything"), but that policy doesn't necessarily determine the value. Consider a registry policy of "We will register identifiers for any finite length of time, provided that the time is paid for up front at the rate of $0.03/day". The only constraints that this imposes is disallowing indefinite registrations, and setting the resolution of time periods in days. Now suppose a registrar in that domain has the policy that "We'll register names for 1 year at $x, 2 years at $y, or 5 years at $z". That further constrains the periods to the set {1 year; 2 years; 5 years}, but _still_ doesn't determine the period, until a registrant choses a specific value. The registrant/registrar negotiation is (probably) out of our scope, but the idea that the registrar (optionally) determines the expiration date, which the registry may reject, is an important one. So, we could have wording like this: [1] The protocol MUST provide services to register unique alphanumeric identifiers, in particluar Internet domain names [2] Identifiers MUST be registered for an unambiguous period (which MAY be indefinite if registry policy allows). The protocol MUST allow registries to specify a start and end time for the registration period on behalf of the registrant, and MUST allow the registry, depending on its policy, to confirm the proposed period, reject it, or specify a default period if the proposal is omitted. -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLGPEe11273 for ietf-provreg-outgoing; Thu, 21 Dec 2000 17:25: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 eBLGPD211268 for ; Thu, 21 Dec 2000 17:25:13 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail2 with esmtp (Exim 3.16 #2) id 1498Wh-0000lY-00; Thu, 21 Dec 2000 11:25:07 -0500 Message-Id: <5.0.2.1.0.20001221112034.02a32e28@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 11:25:10 -0500 To: "J. William Semich" , "'provreg List'" From: "Jordyn A. Buchanan" 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 At 10:21 AM 12/21/2000 -0500, J. William Semich wrote: >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? An "ENUM type identifier" is still a domain name--there just happens to be a mapping between that domain name and an E.164 number. Even if the requirements only talked about domain names, they'd still cover ENUM. Jordyn Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLFM0t10871 for ietf-provreg-outgoing; Thu, 21 Dec 2000 16:22:00 +0100 (MET) Received: from BILL (h00508b5474ca.ne.mediaone.net [24.91.78.68]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLFLx210866 for ; Thu, 21 Dec 2000 16:21:59 +0100 (MET) Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Thu, 21 Dec 2000 10:21:51 -0500 Message-Id: <3.0.5.32.20001221102150.03d16630@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Dec 2000 10:21:50 -0500 To: "'provreg List'" From: "J. William Semich" Subject: Re: Scope [was Re: Expiration times] In-Reply-To: <5.0.2.1.0.20001221094557.02b04e98@mail.register.com> References: <20001221093108.B38157@bruno.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:06 AM 12/21/00 -0500, Jordyn A. Buchanan wrote: >At 09:31 AM 12/21/2000 -0500, Geva Patz wrote: >>On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote: >> > >> > Requirement 7.5-[1] already exists to ensure that the protocol allows for >> > registration of objects not explicitly specified in the draft, so I think >> > the second sentence is redundant. >> >>I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:, >>generic registry-registrar protocol SHOULD provide features >>that at a minimum allow for the management of new object types >>without requiring revisions to the protocol itself". There's a >>subtle difference in sense between this, which basically suggests >>that the protocol be extensible, and my proposed rewording of >>3.4-[1], which suggests that the protocol should be designed from >>the outset to accommodate a broader range of identifiers than >>domain names (which the EPP proposal, for instance, does). I >>won't re-hash the reasons why we changed the name from `domreg' >>to `provreg', but I think it's important to capture those in the >>requirements. > >This is a valid point. At the same time, I think it's important to avoid >too much scope creep here too. 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? Bill Semich .NU Domain Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLF6gA10738 for ietf-provreg-outgoing; Thu, 21 Dec 2000 16:06:42 +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 eBLF6f210733 for ; Thu, 21 Dec 2000 16:06:41 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail1 with esmtp (Exim 3.16 #2) id 1497Il-0004Ex-00 for ietf-provreg@cafax.se; Thu, 21 Dec 2000 10:06:40 -0500 Message-Id: <5.0.2.1.0.20001221094557.02b04e98@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 21 Dec 2000 10:06:37 -0500 To: "'provreg List'" From: "Jordyn A. Buchanan" Subject: Scope [was Re: Expiration times] In-Reply-To: <20001221093108.B38157@bruno.bbn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 09:31 AM 12/21/2000 -0500, Geva Patz wrote: >On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote: > > > > Requirement 7.5-[1] already exists to ensure that the protocol allows for > > registration of objects not explicitly specified in the draft, so I think > > the second sentence is redundant. > >I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:, >generic registry-registrar protocol SHOULD provide features >that at a minimum allow for the management of new object types >without requiring revisions to the protocol itself". There's a >subtle difference in sense between this, which basically suggests >that the protocol be extensible, and my proposed rewording of >3.4-[1], which suggests that the protocol should be designed from >the outset to accommodate a broader range of identifiers than >domain names (which the EPP proposal, for instance, does). I >won't re-hash the reasons why we changed the name from `domreg' >to `provreg', but I think it's important to capture those in the >requirements. This is a valid point. At the same time, I think it's important to avoid too much scope creep here too. One thing we should get a handle on is "what types of registrations do we want the initial requirements document to cover?" Some specificity on this issue allows us to craft good requirements throughout the rest of the document. We should keep extensibility in mind, obviously, because I don't think anyone wants to end up with a protocol that only registers domain names, but at the same time we don't want to end up with the "generic database update protocol", either. >[snip] >There are several other examples elswehere in the text. I think we need >to decide as a group where we'd like the requirements to be, and if we >decide to come down firmly on the side of "what, not how" (which, again, >I don't think is a bad idea), then we'd best go through the draft in >some detail to make sure that it adheres to that principle. I agree. The principle is good, and it should be applied throughout the requirements document. >[snip] >So, we could have wording like this: > >[1] The protocol MUST provide services to register unique >alphanumeric identifiers, in particluar Internet domain names As above, can we tighten this up? I'd suggest wording, but I think we need to agree about the scope of our efforts first. This may determine how we think about our approach to the subsequent requirements. To jump start this conversation, here are things that people have suggested we might want the protocol to register: - Domain names - IP address ranges - AS numbers Should we try to deal with all of these? Are there things not on this list that we want to try to deal with? Jordyn Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLEVB310376 for ietf-provreg-outgoing; Thu, 21 Dec 2000 15:31:11 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBLEV9210371 for ; Thu, 21 Dec 2000 15:31:10 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id JAA96879 for ietf-provreg@cafax.se; Thu, 21 Dec 2000 09:31:08 -0500 (EST) (envelope-from geva) Date: Thu, 21 Dec 2000 09:31:08 -0500 From: Geva Patz To: "'provreg List'" Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Message-ID: <20001221093108.B38157@bruno.bbn.com> Reply-To: ietf-provreg@cafax.se Mail-Followup-To: 'provreg List' 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 Thu, Dec 21, 2000 at 07:39:13AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote: > > Requirement 7.5-[1] already exists to ensure that the protocol allows for > registration of objects not explicitly specified in the draft, so I think > the second sentence is redundant. I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:, generic registry-registrar protocol SHOULD provide features that at a minimum allow for the management of new object types without requiring revisions to the protocol itself". There's a subtle difference in sense between this, which basically suggests that the protocol be extensible, and my proposed rewording of 3.4-[1], which suggests that the protocol should be designed from the outset to accommodate a broader range of identifiers than domain names (which the EPP proposal, for instance, does). I won't re-hash the reasons why we changed the name from `domreg' to `provreg', but I think it's important to capture those in the requirements. > My immediate objection to [2] isn't with the suggested concept, though I do > have a philosophical objection to it that we can take that up when we start > to talk protocol. The requirements draft describes functional requirements, > which I have interpreted to mean "requirements for _what_ the protocol is > supposed to do". I believe the suggested new text is getting into the > specifics of _how_ the protocol is supposed to solve a particular issue, and > is thus out of place in this document. A fair point, except that several other parts of the requirements draft get into exactly such issues. For instance 3.3-[1]: " Registry operations that create, update, or delete objects MUST be associated with a registry-unique transaction identifier. The identifier SHOULD be created using the current date and a combination of identification information assigned by and unique to the registry (such as a registrar identifier) and information assigned by and unique to the registrar requesting the operation (such as a coded combination of letters and numbers)." On your principle (which certainly has merit), this should probably be re-worded something along the lines of: " The protocol MUST allow each transaction to be identified in a permanent and globally unique manner" There are several other examples elswehere in the text. I think we need to decide as a group where we'd like the requirements to be, and if we decide to come down firmly on the side of "what, not how" (which, again, I don't think is a bad idea), then we'd best go through the draft in some detail to make sure that it adheres to that principle. > I think it would be more appropriate > to say something along the lines of "a domain name must have a registration > period whose value is determined by registry policy". ... except that the value may not be determined by registry policy, but by registrar policy (or by registrant request). All registries have a policy, even if only by implication ("we'll register anything"), but that policy doesn't necessarily determine the value. Consider a registry policy of "We will register identifiers for any finite length of time, provided that the time is paid for up front at the rate of $0.03/day". The only constraints that this imposes is disallowing indefinite registrations, and setting the resolution of time periods in days. Now suppose a registrar in that domain has the policy that "We'll register names for 1 year at $x, 2 years at $y, or 5 years at $z". That further constrains the periods to the set {1 year; 2 years; 5 years}, but _still_ doesn't determine the period, until a registrant choses a specific value. The registrant/registrar negotiation is (probably) out of our scope, but the idea that the registrar (optionally) determines the expiration date, which the registry may reject, is an important one. So, we could have wording like this: [1] The protocol MUST provide services to register unique alphanumeric identifiers, in particluar Internet domain names [2] Identifiers MUST be registered for an unambiguous period (which MAY be indefinite if registry policy allows). The protocol MUST allow registries to specify a start and end time for the registration period on behalf of the registrant, and MUST allow the registry, depending on its policy, to confirm the proposed period, reject it, or specify a default period if the proposal is omitted. -- Geva Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBLCgtf09506 for ietf-provreg-outgoing; Thu, 21 Dec 2000 13:42:55 +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 eBLCgs209501 for ; Thu, 21 Dec 2000 13:42:54 +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 HAA14718 for ; Thu, 21 Dec 2000 07:32:49 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 07:39:13 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'provreg List'" Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 07:39:13 -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 have a minor objection to [1] and a fundamental objection to [2]. I'll explain my minor objection first. Requirement 7.5-[1] already exists to ensure that the protocol allows for registration of objects not explicitly specified in the draft, so I think the second sentence is redundant. I agree with altering the current second sentence of 3.4-[1] (the "registration period" sentence) and will propose new text in a moment. My immediate objection to [2] isn't with the suggested concept, though I do have a philosophical objection to it that we can take that up when we start to talk protocol. The requirements draft describes functional requirements, which I have interpreted to mean "requirements for _what_ the protocol is supposed to do". I believe the suggested new text is getting into the specifics of _how_ the protocol is supposed to solve a particular issue, and is thus out of place in this document. I think it would be more appropriate to say something along the lines of "a domain name must have a registration period whose value is determined by registry policy". Here's what I propose for new text: [1] The protocol MUST provide services to register Internet domain names with a well defined registration period. [2] The protocol MUST provide minimum and maximum values for a domain name registration period that allow the period to be determined by registry policy. This new text describes "what" the protocol is supposed to do without getting into "how" it should be implemented, or imposing limits based on any current policy. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Wednesday, December 20, 2000 3:26 PM To: 'provreg List' Subject: Expiration times [was Re: domreg BOF Meeting Minutes] OK, given the chorus of approval on the idea that the registration period wording needs to change, here's a proposal for some specific wording. How about changing this: < [1] The protocol MUST provide services to register Internet domain < names. The registration period for domain names MUST be measured in < years, with a minimum period of one year and a maximum period defined < by registry policy. Into this: > [1] The protocol MUST provide services to register Internet domain > names, and SHOULD allow for the registration of other unique > alphanumeric identifiers. > > [2] The protocol MUST allow registrars to specify an optional > expiration date for each object registered, and MUST allow > registries to accept or reject the proposed expiration date based > on their local policies. Dates MAY be specified either as > absolute times or as forward deltas from the time of actual > registration. Notice that I've sneaked a few other things into here, too, besides the relaxation of the exiration requirement: * I've hinted at the more general applicability of the protocol in the SHOULD clause of [1] * I've moved the focus of specifying an expiration date from the registry to the registrar, while still allowing the registry to have ultimate policy control over the duration of registrations. This, to my mind, better mirrors the situation in the real world, where different registrars offer different periods of initial registration in the same TLD, sometimes for different prices. * I've made the expiration date optional, to cater for the case where objects are registered indefinitely (rare for domain names, common in some other identifier spaces). * I've added a hint that protocol designers may wish to consider time deltas. This seems to make more sense if you've got registrars proposing expiry times, to allow for network delays and clock skews. To illustrate the issue here, consider a registrar asking for a one-year registration from a registry whose policy allows registrations only in one-year increments, where the registrar's clock is behind the registry's by m minutes, and where network congestion induces an n-minute delay in transmission. Given an absolute time, the registry may reject the request as being (n+m) minutes short of a year. -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBL9DZK07971 for ietf-provreg-outgoing; Thu, 21 Dec 2000 10:13:35 +0100 (MET) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBL9DY207966 for ; Thu, 21 Dec 2000 10:13:34 +0100 (MET) Received: from rader ([64.229.102.186]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001221091333.LRFZ1081.tomts7-srv.bellnexxia.net@rader> for ; Thu, 21 Dec 2000 04:13:33 -0500 Message-ID: <008401c06b2e$5e8647a0$dd4ffea9@rader> From: "Ross Wm. Rader" To: "'provreg List'" References: <00bf01c06b29$fa3b5f00$140a0a0a@ambler.net> Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 04:14:06 -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 > > [1] The protocol MUST provide services to register Internet domain > > names, and SHOULD allow for the registration of other unique > > alphanumeric identifiers. > > So you're recommending instituting a "class of service" identifier, > where the default (perhaps) is mandated? You realize that you're > introducing the need for an "IANA function" to register the classes, > as I see it? Which isn't necessarily a bad thing. At the very least it ensures that the classes aren't inadvertently overlapping, thereby guaranteeing at least a modicum of consistency. The question is, does this attribute have any real value? > > > * I've made the expiration date optional, to cater for the case > > where objects are registered indefinitely (rare for domain names, > > common in some other identifier spaces). > > I would suggest making it non-optional, but allowing that a specific > "forever" value be acceptable (subject to rejection by the registry, > based on local policies, as you've indicated). To be complete, I > don't like the thought of the default no-info meaning "forever." Agreed, too much grey...I'm not sure what the current fashion is, but I certainly prefer explicit statements where possible... -rwr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBL8goG07648 for ietf-provreg-outgoing; Thu, 21 Dec 2000 09:42:50 +0100 (MET) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBL8gm207643 for ; Thu, 21 Dec 2000 09:42:48 +0100 (MET) Received: from vulcan (1Cust55.tnt6.redmond.wa.da.uu.net [63.23.204.55]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id AAA22679 for ; Thu, 21 Dec 2000 00:42:46 -0800 (PST) Message-ID: <00bf01c06b29$fa3b5f00$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "'provreg List'" Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] Date: Thu, 21 Dec 2000 00:42:39 -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 eBL8gn207644 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > [1] The protocol MUST provide services to register Internet domain > names, and SHOULD allow for the registration of other unique > alphanumeric identifiers. So you're recommending instituting a "class of service" identifier, where the default (perhaps) is mandated? You realize that you're introducing the need for an "IANA function" to register the classes, as I see it? > [2] The protocol MUST allow registrars to specify an optional > expiration date for each object registered, and MUST allow > registries to accept or reject the proposed expiration date based > on their local policies. Dates MAY be specified either as > absolute times or as forward deltas from the time of actual > registration. Don't you mean MUST on that last one? Either one or the other MUST be specified. MAY would indicate that neither is an option, as you say below, but... > * I've made the expiration date optional, to cater for the case > where objects are registered indefinitely (rare for domain names, > common in some other identifier spaces). I would suggest making it non-optional, but allowing that a specific "forever" value be acceptable (subject to rejection by the registry, based on local policies, as you've indicated). To be complete, I don't like the thought of the default no-info meaning "forever." -- 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 eBKLIA501863 for ietf-provreg-outgoing; Wed, 20 Dec 2000 22:18:10 +0100 (MET) Received: from smtp01.infoave.net (smtp01.infoave.net [165.166.0.26]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKLI9201858 for ; Wed, 20 Dec 2000 22:18:09 +0100 (MET) Received: from KR ([165.166.145.85]) by SMTP00.InfoAve.Net (PMDF V5.2-33 #45321) with SMTP id <01JXXM7QZKS49EDSEE@SMTP00.InfoAve.Net> for ietf-provreg@cafax.se; Wed, 20 Dec 2000 16:17:55 EST Date: Wed, 20 Dec 2000 16:17:54 -0500 From: Mike Lampson IARegistry Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes] To: "'provreg List'" Message-id: <032701c06aca$5135eb00$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: <20001220095040.A37763@bruno.bbn.com> <008001c06abd$9a073260$140a0a0a@ambler.net> <20001220152544.A38157@bruno.bbn.com> Sender: owner-ietf-provreg@cafax.se Precedence: bulk I like the changes being recommended here. A couple of questions: 1) Should we use "expiration timestamp" instead of "expiration date" for conciseness? 2) Should the requirements state that if objects require an expiration date by policy, then those objects {MUST?/SHOULD?} have a policy-defined default when an expiration timestamp or forward delta is not provided? Cheers, _Mike -- Mike Lampson The Registry at Info Avenue, LLC (803) 802-6584 ----- Original Message ----- From: "Geva Patz" To: "'provreg List'" Sent: Wednesday, December 20, 2000 3:25 PM Subject: Expiration times [was Re: domreg BOF Meeting Minutes] > OK, given the chorus of approval on the idea that the > registration period wording needs to change, here's a proposal > for some specific wording. How about changing this: > > < [1] The protocol MUST provide services to register Internet domain > < names. The registration period for domain names MUST be measured in > < years, with a minimum period of one year and a maximum period defined > < by registry policy. > > Into this: > > > [1] The protocol MUST provide services to register Internet domain > > names, and SHOULD allow for the registration of other unique > > alphanumeric identifiers. > > > > [2] The protocol MUST allow registrars to specify an optional > > expiration date for each object registered, and MUST allow > > registries to accept or reject the proposed expiration date based > > on their local policies. Dates MAY be specified either as > > absolute times or as forward deltas from the time of actual > > registration. > > Notice that I've sneaked a few other things into here, too, besides > the relaxation of the exiration requirement: > > * I've hinted at the more general applicability of the protocol in > the SHOULD clause of [1] > > * I've moved the focus of specifying an expiration date from the > registry to the registrar, while still allowing the registry to > have ultimate policy control over the duration of registrations. > This, to my mind, better mirrors the situation in the real world, > where different registrars offer different periods of initial > registration in the same TLD, sometimes for different prices. > > * I've made the expiration date optional, to cater for the case > where objects are registered indefinitely (rare for domain names, > common in some other identifier spaces). > > * I've added a hint that protocol designers may wish to consider > time deltas. This seems to make more sense if you've got registrars > proposing expiry times, to allow for network delays and clock skews. > To illustrate the issue here, consider a registrar asking for a > one-year registration from a registry whose policy allows > registrations only in one-year increments, where the registrar's > clock is behind the registry's by m minutes, and where network > congestion induces an n-minute delay in transmission. Given an > absolute time, the registry may reject the request as being (n+m) > minutes short of a year. > > -- Geva > Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKKPk901487 for ietf-provreg-outgoing; Wed, 20 Dec 2000 21:25:46 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKKPj201482 for ; Wed, 20 Dec 2000 21:25:45 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id PAA39454 for ietf-provreg@cafax.se; Wed, 20 Dec 2000 15:25:44 -0500 (EST) (envelope-from geva) Date: Wed, 20 Dec 2000 15:25:44 -0500 From: Geva Patz To: "'provreg List'" Subject: Expiration times [was Re: domreg BOF Meeting Minutes] Message-ID: <20001220152544.A38157@bruno.bbn.com> Reply-To: ieft-provreg@cafax.se Mail-Followup-To: 'provreg List' References: <20001220095040.A37763@bruno.bbn.com> <008001c06abd$9a073260$140a0a0a@ambler.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <008001c06abd$9a073260$140a0a0a@ambler.net>; from cambler-ietf@iodesign.com on Wed, Dec 20, 2000 at 11:46:51AM -0800 Sender: owner-ietf-provreg@cafax.se Precedence: bulk OK, given the chorus of approval on the idea that the registration period wording needs to change, here's a proposal for some specific wording. How about changing this: < [1] The protocol MUST provide services to register Internet domain < names. The registration period for domain names MUST be measured in < years, with a minimum period of one year and a maximum period defined < by registry policy. Into this: > [1] The protocol MUST provide services to register Internet domain > names, and SHOULD allow for the registration of other unique > alphanumeric identifiers. > > [2] The protocol MUST allow registrars to specify an optional > expiration date for each object registered, and MUST allow > registries to accept or reject the proposed expiration date based > on their local policies. Dates MAY be specified either as > absolute times or as forward deltas from the time of actual > registration. Notice that I've sneaked a few other things into here, too, besides the relaxation of the exiration requirement: * I've hinted at the more general applicability of the protocol in the SHOULD clause of [1] * I've moved the focus of specifying an expiration date from the registry to the registrar, while still allowing the registry to have ultimate policy control over the duration of registrations. This, to my mind, better mirrors the situation in the real world, where different registrars offer different periods of initial registration in the same TLD, sometimes for different prices. * I've made the expiration date optional, to cater for the case where objects are registered indefinitely (rare for domain names, common in some other identifier spaces). * I've added a hint that protocol designers may wish to consider time deltas. This seems to make more sense if you've got registrars proposing expiry times, to allow for network delays and clock skews. To illustrate the issue here, consider a registrar asking for a one-year registration from a registry whose policy allows registrations only in one-year increments, where the registrar's clock is behind the registry's by m minutes, and where network congestion induces an n-minute delay in transmission. Given an absolute time, the registry may reject the request as being (n+m) minutes short of a year. -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKJmKX01157 for ietf-provreg-outgoing; Wed, 20 Dec 2000 20:48:20 +0100 (MET) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKJmJ201152 for ; Wed, 20 Dec 2000 20:48:19 +0100 (MET) Received: from vulcan (1Cust26.tnt2.redmond.wa.da.uu.net [63.23.199.26]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA27967 for ; Wed, 20 Dec 2000 11:48:17 -0800 (PST) Message-ID: <008001c06abd$9a073260$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "'provreg List'" References: <20001220095040.A37763@bruno.bbn.com> Subject: Re: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 11:46:51 -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 eBKJmK201153 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Greetings, all. This point is well taken, in that our registry system does not measure the registration length in years, but instead uses an "expiration date." While that is currently set to n years past the current date, there's no reason it has to be. I can foresee a future in which a .movie domain, for example, might sell 6-month registrations. Or an annual-event registry might sell pro-rated registrations for "the rest of the year," all set to expire on 31 December. -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web > > The registration period for domain names MUST be measured in > > years, with a minimum period of one year and a maximum period > > defined by registry policy. > > Although this captures the current situation in most gTLDs (and > many ccTLDs) accurately, there's absolutely no reason to make > the minimum period of a year a high-level requirement. In fact, > there's a good reason not to: a protocol designed literally > to this requirement might include a validity counter with a > resolution in years, making it impossible for registries to > implement a policy with finer resolution. Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKG6rC28818 for ietf-provreg-outgoing; Wed, 20 Dec 2000 17:06:53 +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 eBKG6q228813 for ; Wed, 20 Dec 2000 17:06: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 RAA46172; Wed, 20 Dec 2000 17:06:52 +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 RAA07458; Wed, 20 Dec 2000 17:06:51 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200012201606.RAA07458@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: "'provreg List'" Subject: Re: domreg BOF Meeting Minutes In-reply-to: Your message of Wed, 20 Dec 2000 10:56:01 -0500. Date: Wed, 20 Dec 2000 17:06:51 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I am really hoping that someone (or multiple someones) will take the time to point out the specific text that they feel encroaches on policy issues. We've found one situation, minimum registration period. If you know of others please post them to the list. Yes, it was my intention to go over the document and post them all at once, but I need some time. I discussed some of them with Jorg Bauer of the German ccTLD. I will ask him to post his objections as well. jaap Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKG3hY28785 for ietf-provreg-outgoing; Wed, 20 Dec 2000 17:03: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 eBKG3g228780 for ; Wed, 20 Dec 2000 17:03:42 +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 KAA12840; Wed, 20 Dec 2000 10:53:08 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 10:59:32 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Ross Wm. Rader'" , "'provreg List'" Subject: RE: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 10:59: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 Yes, and the draft currently states that point quite clearly. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Ross Wm. Rader [mailto:ross@tucows.com] Sent: Wednesday, December 20, 2000 11:02 AM To: 'provreg List' Subject: Re: domreg BOF Meeting Minutes > Bill, > > That's a policy decision. The requirement is intended to define the units > of measurement, and registry policy should determine the actual minimum > value. And maximum I would assume... -rwr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKG0wH28666 for ietf-provreg-outgoing; Wed, 20 Dec 2000 17:00:58 +0100 (MET) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKG0v228661 for ; Wed, 20 Dec 2000 17:00:57 +0100 (MET) Received: from rader ([64.229.98.56]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001220160056.KRHI9566.tomts8-srv.bellnexxia.net@rader> for ; Wed, 20 Dec 2000 11:00:56 -0500 Message-ID: <03ab01c06a9e$230856e0$dd4ffea9@rader> From: "Ross Wm. Rader" To: "'provreg List'" References: Subject: Re: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 11:01: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 > Bill, > > That's a policy decision. The requirement is intended to define the units > of measurement, and registry policy should determine the actual minimum > value. And maximum I would assume... -rwr Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKG0Ux28645 for ietf-provreg-outgoing; Wed, 20 Dec 2000 17:00: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 eBKG0T228640 for ; Wed, 20 Dec 2000 17:00:29 +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 KAA12820; Wed, 20 Dec 2000 10:49:37 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 10:56:02 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" , Geva Patz Cc: "'provreg List'" Subject: RE: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 10:56: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 Jaap, I am really hoping that someone (or multiple someones) will take the time to point out the specific text that they feel encroaches on policy issues. We've found one situation, minimum registration period. If you know of others please post them to the list. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Jaap Akkerhuis [mailto:jaap@sidn.nl] Sent: Wednesday, December 20, 2000 10:36 AM To: Geva Patz Cc: 'provreg List' Subject: Re: domreg BOF Meeting Minutes Geza, On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote: > Many (the majority?) of the ccTLDs require a minimum two-year initial > registration period. Precisely my point. Minimum and maximum initial periods and renewal periods are all policy issues, not protocol issues. The protocol should allow policy to be expressed, but shouldn't dictate policy through design limitations. We shouldn't even mandate that registrations need expire: although the contrary is true only in a small minority of cases, we should nonetheless cater for these cases, particularly if we envisage the protocol potentially being used to register other classes of objects (AS registrations, for instance, don't expire). The protocol should allow an expiry date to be specified, but shouldn't require it, and certainly shouldn't constrain it to one-year resolution. You beat me in time, but this is also my point. In the GRRP draft are more places where were policy issues are specified as protocol issues. Talking to the German ccTLD peole, they had the same problem with the draft; policy issues are mixed with the protocol issues. It might be natural for someone from NSI/Verisign to mix them in, but if you have a different policy, one tends to notice this. jaap Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKFrZJ28569 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:53: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 eBKFrY228563 for ; Wed, 20 Dec 2000 16:53: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 KAA12801; Wed, 20 Dec 2000 10:43:24 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 10:49:49 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'J. William Semich'" , Geva Patz , "'provreg List'" Subject: RE: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 10:49: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 Bill, That's a policy decision. The requirement is intended to define the units of measurement, and registry policy should determine the actual minimum value. That specific text can certainly be changed to make it more clear that the intention is to define units and not policy. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: J. William Semich [mailto:bsemich@worldnames.net] Sent: Wednesday, December 20, 2000 10:07 AM To: Geva Patz; 'provreg List' Subject: Re: domreg BOF Meeting Minutes Many (the majority?) of the ccTLDs require a minimum two-year initial registration period. Bill Semich .NU Domain At 09:50 AM 12/20/00 -0500, Geva Patz wrote: >Finally, we should probably go through the draft to make >sure that there aren't any small details in it that aren't >requirements per se. An example is this sort of thing: > >> The registration period for domain names MUST be measured in >> years, with a minimum period of one year and a maximum period >> defined by registry policy. > >Although this captures the current situation in most gTLDs (and >many ccTLDs) accurately, there's absolutely no reason to make >the minimum period of a year a high-level requirement. In fact, >there's a good reason not to: a protocol designed literally >to this requirement might include a validity counter with a >resolution in years, making it impossible for registries to >implement a policy with finer resolution. > >This is the only example that leapt out at me on my first few >passes, but a closer reading may yield other, similar situations >where current practice should not be reflected as a requirement. > >Geva Patz >geva@bbn.com > > 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 eBKFaKD28405 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:36:20 +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 eBKFaJ228400 for ; Wed, 20 Dec 2000 16:36:19 +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 KAA12722; Wed, 20 Dec 2000 10:25:39 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 10:32:04 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" Cc: "'provreg List'" Subject: RE: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 10:32:03 -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, Yes, Mark took the notes but they are being reported by me. What you see written isn't what Mark wrote. I recall only two people _saying_ anything significant about draft discomfort, hence the wording in the minutes. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Jaap Akkerhuis [mailto:jaap@sidn.nl] Sent: Wednesday, December 20, 2000 8:42 AM To: Hollenbeck, Scott Cc: 'provreg List' Subject: Re: domreg BOF Meeting Minutes Hi, Minutes of the domreg BOF 14 December 2000 49th IETF San Diego, CA Reported by Scott Hollenbeck Maybe I'm mistaken, but I actually that Mark Kosters was the official scribe at this BOF. You state that: One speaker was not comfortable with the requirements etc. But not only this speaker was not comfortable with the requirements. Patrick Falstrom did a poll whether there were more uncpomfortable people. Quite some hands were raised. My wild quess is at least 20. You probably haven't seen it due to the fact that most of these were seated behind you. Later this week I will try to send spme of my problems with the draft to this list. jaap Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKFa5C28390 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:36: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 eBKFa5228385 for ; Wed, 20 Dec 2000 16:36: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 QAA45915; Wed, 20 Dec 2000 16:36: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 QAA07266; Wed, 20 Dec 2000 16:36:04 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200012201536.QAA07266@bartok.sidn.nl> To: Geva Patz cc: "'provreg List'" Subject: Re: domreg BOF Meeting Minutes In-reply-to: Your message of Wed, 20 Dec 2000 10:15:31 -0500. <20001220101530.B37763@bruno.bbn.com> Date: Wed, 20 Dec 2000 16:36:04 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Geza, On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote: > Many (the majority?) of the ccTLDs require a minimum two-year initial > registration period. Precisely my point. Minimum and maximum initial periods and renewal periods are all policy issues, not protocol issues. The protocol should allow policy to be expressed, but shouldn't dictate policy through design limitations. We shouldn't even mandate that registrations need expire: although the contrary is true only in a small minority of cases, we should nonetheless cater for these cases, particularly if we envisage the protocol potentially being used to register other classes of objects (AS registrations, for instance, don't expire). The protocol should allow an expiry date to be specified, but shouldn't require it, and certainly shouldn't constrain it to one-year resolution. You beat me in time, but this is also my point. In the GRRP draft are more places where were policy issues are specified as protocol issues. Talking to the German ccTLD peole, they had the same problem with the draft; policy issues are mixed with the protocol issues. It might be natural for someone from NSI/Verisign to mix them in, but if you have a different policy, one tends to notice this. jaap Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKFTQU28332 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:29:26 +0100 (MET) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKFTO228327 for ; Wed, 20 Dec 2000 16:29:25 +0100 (MET) Received: from rader ([64.229.98.56]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001220152920.CCLW1081.tomts7-srv.bellnexxia.net@rader> for ; Wed, 20 Dec 2000 10:29:20 -0500 Message-ID: <037401c06a99$b967c4e0$dd4ffea9@rader> From: "Ross Wm. Rader" To: "'provreg List'" References: <20001220095040.A37763@bruno.bbn.com> <3.0.5.32.20001220100648.03d4f100@mail.nic.nu> <20001220101530.B37763@bruno.bbn.com> Subject: Re: domreg BOF Meeting Minutes Date: Wed, 20 Dec 2000 10:30:03 -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 > The protocol should > allow an expiry date to be specified, but shouldn't require it, and > certainly shouldn't constrain it to one-year resolution. Would it not make more sense to define a TTL within the payload that deals with all time periods? If this is to be truly applicable to all models, we must ensure that we move forward with the philosophy that this protocol will be used predominantly in environments which do not yet exist (over the longer term). It is highly likely that these environments will employ models that also do not yet exist. Therefore, putting a stake in the ground around "years" seems to be remarkably short-sighted in my mind. If we accomodate for TTL's, we can let the applications sort out the expiry models. Thanks, -rwr Ross Wm. Rader Director, Innovation & Research Tucows Inc. t. 416.538.5492 Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKFFWM28213 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:15:32 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKFFV228208 for ; Wed, 20 Dec 2000 16:15:32 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id KAA38039 for ietf-provreg@cafax.se; Wed, 20 Dec 2000 10:15:31 -0500 (EST) (envelope-from geva) Date: Wed, 20 Dec 2000 10:15:31 -0500 From: Geva Patz To: "'provreg List'" Subject: Re: domreg BOF Meeting Minutes Message-ID: <20001220101530.B37763@bruno.bbn.com> Mail-Followup-To: 'provreg List' References: <20001220095040.A37763@bruno.bbn.com> <3.0.5.32.20001220100648.03d4f100@mail.nic.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3.0.5.32.20001220100648.03d4f100@mail.nic.nu>; from bsemich@worldnames.net on Wed, Dec 20, 2000 at 10:06:48AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote: > Many (the majority?) of the ccTLDs require a minimum two-year initial > registration period. Precisely my point. Minimum and maximum initial periods and renewal periods are all policy issues, not protocol issues. The protocol should allow policy to be expressed, but shouldn't dictate policy through design limitations. We shouldn't even mandate that registrations need expire: although the contrary is true only in a small minority of cases, we should nonetheless cater for these cases, particularly if we envisage the protocol potentially being used to register other classes of objects (AS registrations, for instance, don't expire). The protocol should allow an expiry date to be specified, but shouldn't require it, and certainly shouldn't constrain it to one-year resolution. -- Geva Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKF73A28148 for ietf-provreg-outgoing; Wed, 20 Dec 2000 16:07:03 +0100 (MET) Received: from BILL (h00508b5474ca.ne.mediaone.net [24.91.78.68]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKF72228143 for ; Wed, 20 Dec 2000 16:07:02 +0100 (MET) Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Wed, 20 Dec 2000 10:06:48 -0500 Message-Id: <3.0.5.32.20001220100648.03d4f100@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 20 Dec 2000 10:06:48 -0500 To: Geva Patz , "'provreg List'" From: "J. William Semich" Subject: Re: domreg BOF Meeting Minutes In-Reply-To: <20001220095040.A37763@bruno.bbn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Many (the majority?) of the ccTLDs require a minimum two-year initial registration period. Bill Semich .NU Domain At 09:50 AM 12/20/00 -0500, Geva Patz wrote: >Finally, we should probably go through the draft to make >sure that there aren't any small details in it that aren't >requirements per se. An example is this sort of thing: > >> The registration period for domain names MUST be measured in >> years, with a minimum period of one year and a maximum period >> defined by registry policy. > >Although this captures the current situation in most gTLDs (and >many ccTLDs) accurately, there's absolutely no reason to make >the minimum period of a year a high-level requirement. In fact, >there's a good reason not to: a protocol designed literally >to this requirement might include a validity counter with a >resolution in years, making it impossible for registries to >implement a policy with finer resolution. > >This is the only example that leapt out at me on my first few >passes, but a closer reading may yield other, similar situations >where current practice should not be reflected as a requirement. > >Geva Patz >geva@bbn.com > > Bill Semich President and Founder WorldNames, Inc. http://www.worldnames.net bsemich@worldnames.net Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKEohY27955 for ietf-provreg-outgoing; Wed, 20 Dec 2000 15:50:43 +0100 (MET) Received: from bruno.bbn.com (BRUNO.BBN.COM [128.89.34.101]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBKEof227949 for ; Wed, 20 Dec 2000 15:50:42 +0100 (MET) Received: (from geva@localhost) by bruno.bbn.com (8.9.3/8.9.2) id JAA37884 for ietf-provreg@cafax.se; Wed, 20 Dec 2000 09:50:40 -0500 (EST) (envelope-from geva) Date: Wed, 20 Dec 2000 09:50:40 -0500 From: Geva Patz To: "'provreg List'" Subject: Re: domreg BOF Meeting Minutes Message-ID: <20001220095040.A37763@bruno.bbn.com> Mail-Followup-To: 'provreg List' 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 Tue, Dec 19, 2000 at 03:09:01PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Dec 19, 2000 at 03:09:01PM -0500, Hollenbeck, Scott wrote: > Comments from the floor were generally > positive about the state of the requirements, though one speaker > suggested some additional text at the beginning of the I-D to note > that the requirements were defined for a specific operational model > and that other models exist. One speaker was not comfortable with > the requirements, though he had not provided any specific concerns > to the mailing list. In the end it was agreed that a little more > work is needed to finalize the requirements draft before it can > be considered complete. Speaking as at least one of the "one speakers" mentioned above, let me restate my concern to clarify: As it currently stands, the requirements capture the current model (multiple registrars, single registry per repository) well. This isn't, however, the only possible model. I'm aware of more than one ccTLD that wishes to implement a replicated registry model, where the repository is replicated amongst the registrars. It's entirely possible that one or more of the gTLDs may move in that direction, too. As technology evolves, it's possible to imagine even a distribued repository model. I'm not suggesting that it is the job of this group to design a replicated registry database. I don't even believe that the architecture for such a thing needs to be standardized. I do, however, believe that in our requirements we should make it explicitly clear that whatever we design should be flexible enough to accommodate these different models. It would be a shame to go through all the effort of developing a standard that only has narrow relevance to one specific model. Fortunately, relatively little needs to change in the requirements to accommodate this, most of it early on. I'll have a go at wording the changes shortly. While I'm on the requirements, a couple of other comments: The section on security could do with some expansion. In particular, it would be a good idea to elaborate somewhat on the trust assumptions that should underlie any protocol design. One of the problems with the one protocol proposal that we've seen so far (draft-hollenbeck-epp-00.txt) is that it assumes trust between registrar and registry, and between registrant and reigstrar (and hence, implicitly, registry). I won't spend much time at this point going into the mechanics of trust in the EPP proposal, because we're still in the requirements phase, but the main point I'm trying to make is that we should state in the requirements that any protocol design should assume no trust between any pair in {registrant, registrar, registry}. This implies, for instance, that any authentication credentials given to the registrant by the registry to confirm registration (and hence allow updates) should not be passed in the clear through the registrar. It implies a certain amount of care in the design of the query operation, to prevent 'false positives' being given. Again, details such as these are more protocol design issues than requirements issues, but I do believe that the 'no trust' assumption (along with some of its conceptual implications) should be written into the requirements draft. Once more, I'll try and write up this proposal into something concrete later. Finally, we should probably go through the draft to make sure that there aren't any small details in it that aren't requirements per se. An example is this sort of thing: > The registration period for domain names MUST be measured in > years, with a minimum period of one year and a maximum period > defined by registry policy. Although this captures the current situation in most gTLDs (and many ccTLDs) accurately, there's absolutely no reason to make the minimum period of a year a high-level requirement. In fact, there's a good reason not to: a protocol designed literally to this requirement might include a validity counter with a resolution in years, making it impossible for registries to implement a policy with finer resolution. This is the only example that leapt out at me on my first few passes, but a closer reading may yield other, similar situations where current practice should not be reflected as a requirement. Geva Patz geva@bbn.com Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBKDfsh27354 for ietf-provreg-outgoing; Wed, 20 Dec 2000 14:41: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 eBKDfr227349 for ; Wed, 20 Dec 2000 14:41: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 OAA44972; Wed, 20 Dec 2000 14:41:52 +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 OAA06357; Wed, 20 Dec 2000 14:41:52 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200012201341.OAA06357@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: "'provreg List'" Subject: Re: domreg BOF Meeting Minutes In-reply-to: Your message of Tue, 19 Dec 2000 15:09:01 -0500. Date: Wed, 20 Dec 2000 14:41:52 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, Minutes of the domreg BOF 14 December 2000 49th IETF San Diego, CA Reported by Scott Hollenbeck Maybe I'm mistaken, but I actually that Mark Kosters was the official scribe at this BOF. You state that: One speaker was not comfortable with the requirements etc. But not only this speaker was not comfortable with the requirements. Patrick Falstrom did a poll whether there were more uncpomfortable people. Quite some hands were raised. My wild quess is at least 20. You probably haven't seen it due to the fact that most of these were seated behind you. Later this week I will try to send spme of my problems with the draft to this list. jaap Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBJKCfN18571 for ietf-provreg-outgoing; Tue, 19 Dec 2000 21:12: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 eBJKCd218566 for ; Tue, 19 Dec 2000 21:12: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 PAA11507 for ; Tue, 19 Dec 2000 15:02:35 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 15:09:02 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'provreg List'" Subject: domreg BOF Meeting Minutes Date: Tue, 19 Dec 2000 15:09: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 Minutes of the domreg BOF 14 December 2000 49th IETF San Diego, CA Reported by Scott Hollenbeck (Sorry for the repeat -- I'm sending it again to get a copy into the list archives, which didn't pick up the message sent earlier today.) The goals and scope of the BOF were described as follows: This BOF will assess interest in forming a working group to develop a generic registry-registrar protocol for use in shared registration systems. The goal of the BOF is two-fold: 1. To determine if a working group should be formed to develop such a protocol, and 2. To produce draft goals and an outline for a charter if there is interest in forming a working group. The scope of the BOF will be limited to technical issues associated with protocol development, including: - Discussion of existing Internet-Draft requirements for a generic registry-registrar protocol. - Discussion of interest in forming a working group to develop a generic protocol. - Presentation of an existing published protocol proposal. - Working group goal and charter development. First presentation document reference: draft-hollenbeck-grrp-reqs-05.txt The first presentation covered requirements for a generic protocol for use in shared registration systems. The presentation described the how the need for requirements was identified, how the requirements were developed, and the state of the requirements today. At the conclusion of the presentation the question was asked if the attendees felt that the requirements draft represented community consensus, noting that such consensus was apparently reached on the discussion mailing list two months ago. Comments from the floor were generally positive about the state of the requirements, though one speaker suggested some additional text at the beginning of the I-D to note that the requirements were defined for a specific operational model and that other models exist. One speaker was not comfortable with the requirements, though he had not provided any specific concerns to the mailing list. In the end it was agreed that a little more work is needed to finalize the requirements draft before it can be considered complete. After this presentation the question was asked if there was sufficient problem definition and interest in forming a working group to develop a standards track protocol. After discussion of the anticipated purpose and expected outcome, the clear opinion of the group was "yes". Second presentation document reference: draft-hollenbeck-epp-00.txt The second presentation described a protocol proposal that was developed to meet and exceed the requirements described in the first presentation. The presentation described the problem as more than a domain name registration problem, but as a generic object provisioning problem. XML was shown to provide a way to define a simple base protocol that separates object semantics from the protocol itself. The presentation described a layered approach to manage transport, security, and object provisioning. Comments from the floor were positive, with several people noting that such a general provisioning approach is far more desirable than a narrow domain name registration approach. The final portion of the BOF was dedicated to brainstorming ideas about the scope and charter of a working group. The first point of agreement was that the focus should not be only on domain name registration, but on the more general problem of object provisioning. A person from the floor volunteered a draft charter, and a few minutes were spent looking at the draft to see if people were generally comfortable with it. There was some debate about the amount of time needed to complete working group tasks, with the general consensus being that people preferred to try to get work items completed as quickly as possible. Some minor changes were made on the floor, and agreement was reached to continue the discussion on a new working group mailing list. It was agreed that both charter development and requirements completion can proceed in parallel, with the charter completion date targeted for 5 January 2001. The name of the working group mailing list was quickly discussed, and the name "provreg" (for provisioning/registration) was agreed upon. A person agreed to create the list as quickly as possible, and the name was announced to all: ietf-provreg@cafax.se. Subscription requests will be managed by majordomo@cafax.se. Scott Hollenbeck VeriSign Global Registry Services Return-Path: Received: from naptop.pilsnet.sunet.se (ietf.207.137.73.28.tx.verio.net [207.137.73.28]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBF0j8206631 for ; Fri, 15 Dec 2000 01:45:08 +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 eBF0is601559 for ; Thu, 14 Dec 2000 16:44:54 -0800 (PST) To: ietf-provreg-logger@cafax.se Subject: Logger test nr 1 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: <20001214164453K.liman@sunet.se> Date: Thu, 14 Dec 2000 16:44:53 -0800 Sender: Lars-Johan Liman X-Dispatcher: imput version 990905(IM130) Lines: 1 foo bar baz