Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1SB1Krw004958 for ietf-provreg-outgoing; Wed, 28 Feb 2001 12:01:20 +0100 (MET) Received: from naptop.autonomica.se (liman.iku.sunet.se [193.10.90.131]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1SB19AY004953 for ; Wed, 28 Feb 2001 12:01:09 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1SAxP2M000833 for ietf-provreg@cafax.se; Wed, 28 Feb 2001 11:59:25 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1S1a8AY002203 for ; Wed, 28 Feb 2001 02:36:10 +0100 (MET) Received: from jamessonyvaio (pc74.pwtc.jaring.my [202.186.141.74]) by mail.i-dns.net (Postfix) with SMTP id CDE5AFFC01; Wed, 28 Feb 2001 09:35:41 +0800 (SGT) Message-ID: <01e401c0a126$a60ca690$4a8dbaca@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: , "Patrik Faltstrom" , References: <200102272226.f1RMQl807437@nic-naa.net> Subject: Re: APRICOT'2001 Date: Wed, 28 Feb 2001 09:34:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Your contribution to the requirements statements appear to be: > > 1. differences in policy, management, and business models exist. I don't have contribution to the requirements doc. My company have a registry but I am not involved in that part of it anymore. But my opinion is that Asian NICs should put their requirements to the table themselves. So what I am doing is informing them about the presence of this group. And I am feedbacking their response to this group. > 2. a useless work-product will not be adopted. And your XPR is? I don't think a 112 page I-D is something what I call easy to understand, especially for those whose native language is not English. I could not even be bother to give comment on it. > Is that the best that can be done when the APRICOT best-and-brightest are > in one room? Your continual sacarism against me indirectly is only getting silly. "Please continue to act like an idiot", really, please continue to do so. But I am saying too much. I am going to keep quiet until I get my proposal into this group. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1S5U8ug003675 for ietf-provreg-outgoing; Wed, 28 Feb 2001 06:30:08 +0100 (MET) Received: from sunraysvr1.jaring.my ([202.186.141.3]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1S5U4AY003670 for ; Wed, 28 Feb 2001 06:30:06 +0100 (MET) Received: from [202.186.141.60] ([202.186.141.60]) by sunraysvr1.jaring.my (8.9.3+Sun/8.9.1) with ESMTP id NAA25236; Wed, 28 Feb 2001 13:22:52 +0800 (SGT) X-Sender: lewis@202.186.141.60 Message-Id: In-Reply-To: <200102272023.f1RKNdH03804@bartok.sidn.nl> References: Your message of Tue, 27 Feb 2001 11:28:59 -0800. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Feb 2001 00:19:10 -0500 To: Jaap Akkerhuis From: Edward Lewis Subject: Re: Interim meeting minutes Cc: Rick H Wesson , "Bason, Chris" , Edward Lewis , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 3:23 PM -0500 2/27/01, Jaap Akkerhuis wrote: >Speaking as Ed's (evil) twin, why not discuss is here first? Good idea, speaking for the other twin... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1S21oUX002331 for ietf-provreg-outgoing; Wed, 28 Feb 2001 03:01:50 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1S21nAY002326 for ; Wed, 28 Feb 2001 03:01:49 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.2/8.9.3) with ESMTP id f1S205808114; Tue, 27 Feb 2001 21:00:05 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102280200.f1S205808114@nic-naa.net> To: "James Seng/Personal" cc: "Eric Brunner-Williams in Portland Maine" , ietf-provreg@cafax.se, "Patrik Faltstrom" , brunner@nic-naa.net Subject: Re: APRICOT'2001 In-Reply-To: Your message of "Wed, 28 Feb 2001 09:34:52 +0800." <01e401c0a126$a60ca690$4a8dbaca@jamessonyvaio> Date: Tue, 27 Feb 2001 21:00:04 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk James, What was your point in making a presentation if not to elicit requirements? Do you have the impression that you've convayed useful information from one group to another? Something is wrong when the only information comming out of a regional operational meeting is non-specific. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1S1vLYM002302 for ietf-provreg-outgoing; Wed, 28 Feb 2001 02:57:21 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1S1vJAY002297 for ; Wed, 28 Feb 2001 02:57:20 +0100 (MET) Received: from pc113.pwtc.jaring.my (pc113.pwtc.jaring.my [202.186.141.113]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id RAA28152; Tue, 27 Feb 2001 17:57:10 -0800 X-Authentication-Warning: joy.songbird.com: pc113.pwtc.jaring.my [202.186.141.113] didn't use HELO protocol Message-Id: <5.1.0.10.2.20010228095345.02b877c8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.10 (Beta) Date: Wed, 28 Feb 2001 09:54:16 +0800 To: "James Seng/Personal" From: Dave Crocker Subject: Re: APRICOT'2001 Cc: , "Patrik Faltstrom" In-Reply-To: <00c801c0a0bc$497b7f60$4a8dbaca@jamessonyvaio> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 08:15 PM 2/27/2001, James Seng/Personal wrote: >Some feedback that this group can feel free to do what they like but if >it the result is not suitable, they will just ignore it. This is true for any IETF effort. The way that specifications meet needs is for those who have the needs to participate in the IETF discussions. Have they read the requirements or proposed specification? Do they have criticisms or suggestions (or even demands) about the details? d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RMSTvF001493 for ietf-provreg-outgoing; Tue, 27 Feb 2001 23:28:29 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RMSRAY001488 for ; Tue, 27 Feb 2001 23:28:27 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.2/8.9.3) with ESMTP id f1RMQl807437; Tue, 27 Feb 2001 17:26:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102272226.f1RMQl807437@nic-naa.net> To: "James Seng/Personal" cc: ietf-provreg@cafax.se, "Patrik Faltstrom" , brunner@nic-naa.net Subject: Re: APRICOT'2001 In-Reply-To: Your message of "Tue, 27 Feb 2001 20:15:39 +0800." <00c801c0a0bc$497b7f60$4a8dbaca@jamessonyvaio> Date: Tue, 27 Feb 2001 17:26:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk James, Your contribution to the requirements statements appear to be: 1. differences in policy, management, and business models exist. 2. a useless work-product will not be adopted. Is that the best that can be done when the APRICOT best-and-brightest are in one room? Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RMJ5Wu001447 for ietf-provreg-outgoing; Tue, 27 Feb 2001 23:19:05 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RMJ4AY001442 for ; Tue, 27 Feb 2001 23:19:05 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.2/8.9.3) with ESMTP id f1RMHO807403; Tue, 27 Feb 2001 17:17:24 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102272217.f1RMHO807403@nic-naa.net> To: Jaap Akkerhuis cc: Richard Shockey , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: NewLevel XRP draft In-Reply-To: Your message of "Tue, 27 Feb 2001 15:07:39 +0100." <200102271407.f1RE7dH03099@bartok.sidn.nl> Date: Tue, 27 Feb 2001 17:17:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jaap, > I know see two xrp documents. ... draft-brunner-xrp-00.txt is the memo NeuStar, Melboure IT, NeuLevel, and Sundry Elves (tm) submitted as an I-D. It superceeds a memo with a working title confusingly similar to one which it will have, after some more edits and adoption by the WG as a WG document. > Yuo mean that NeuLevel and NeuStar Melbourne are different companies? I think so. Anyway, that's a non-technical detail and I don't care what company name(s) associate themselves with any WG work-product. I didn't intend our -00 as a placeholder, and I plan to submit a revision prior to the -0n deadline of the 2nd, adding containers and profiles. It should be obvious to everyone that xrp owes considerable to epp. I want to thank everyone who worked the table mic at the Interim. I'd two snow-bound munchkins at home and a third in-hospital, so "participation" was as a short-order-cook, activity-animator, and social-worker, and even so, I felt adequately "present". Very sorry about the beers. Minneapolis. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RKJY9D000763 for ietf-provreg-outgoing; Tue, 27 Feb 2001 21:19:34 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RKJYAY000758 for ; Tue, 27 Feb 2001 21:19:34 +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 VAA19290; Tue, 27 Feb 2001 21:19:33 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.2/8.11.2) with ESMTP id f1RKNdH03804; Tue, 27 Feb 2001 21:23:39 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102272023.f1RKNdH03804@bartok.sidn.nl> To: Rick H Wesson cc: "Bason, Chris" , Edward Lewis , ietf-provreg@cafax.se Subject: Re: Interim meeting minutes In-reply-to: Your message of Tue, 27 Feb 2001 11:28:59 -0800. Date: Tue, 27 Feb 2001 21:23:39 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I believe the minutes were stated correctly. > I don't think we came to a general consensus > that Global Unique Handles were a "Good Thing". That is what I also recall. I guess we should just re-debate this topic, Ed, could we get 10 minutes in Minneapolis to go over the issue? Speaking as Ed's (evil) twin, why not discuss is here first? jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RJTSul000400 for ietf-provreg-outgoing; Tue, 27 Feb 2001 20:29:28 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RJTQAY000395 for ; Tue, 27 Feb 2001 20:29:27 +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 LAA00279; Tue, 27 Feb 2001 11:28:59 -0800 (PST) Date: Tue, 27 Feb 2001 11:28:59 -0800 (PST) From: Rick H Wesson To: "Bason, Chris" cc: Edward Lewis , Subject: RE: Interim meeting minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk chris, > I believe the minutes were stated correctly. > I don't think we came to a general consensus > that Global Unique Handles were a "Good Thing". I guess we should just re-debate this topic, Ed, could we get 10 minutes in Minneapolis to go over the issue? -rick Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RFoKQl028827 for ietf-provreg-outgoing; Tue, 27 Feb 2001 16:50:20 +0100 (MET) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RFoHAY028822 for ; Tue, 27 Feb 2001 16:50:18 +0100 (MET) Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA27389; Tue, 27 Feb 2001 16:49:32 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <00c801c0a0bc$497b7f60$4a8dbaca@jamessonyvaio> References: <00c801c0a0bc$497b7f60$4a8dbaca@jamessonyvaio> Date: Tue, 27 Feb 2001 07:46:44 -0800 To: "James Seng/Personal" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: APRICOT'2001 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 20.15 +0800 01-02-27, James Seng/Personal wrote: >I have done the first discussion of ProvReg at the APRICOT'2001 today. >Some NICs has expressed their shock this Working Group wish to push thru >the Protocol, given that there are so many differences in policy, >management and business models. Even among the Asian NICs, they do not >have uniformed policy yet. You have to differ between trying to do things quickly and "pushing" which for me implies creating a sloppy specification for a sloppy protocol. The IETF process should be able to do a proper review on protocols which are created in a short timeframe, and what the review process is to look into is whether the protocol is bad or not fulfilling all requirements (or that the requiurements are not correct). Just because there is a great interest in this protocol, and so many people want it, it is _extremely_ important that all people which have interest let this wg know whether some requirement is not fulfilled in the protocol, or missing in the requirements document. It is a fact that different registries (please don't talk about TLD's) have different policy, have different things you can register (domains, ip-address blocks and whatever) and the requirements document have to list all of those requirements. For example that the policy is not known. So, my message to those people would be to please participate _now_. 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-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RE3Yud028168 for ietf-provreg-outgoing; Tue, 27 Feb 2001 15:03:34 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RE3YAY028163 for ; Tue, 27 Feb 2001 15:03:34 +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 PAA15171; Tue, 27 Feb 2001 15:03:33 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.2/8.11.2) with ESMTP id f1RE7dH03099; Tue, 27 Feb 2001 15:07:39 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102271407.f1RE7dH03099@bartok.sidn.nl> To: Richard Shockey cc: ietf-provreg@cafax.se Subject: Re: NewLevel XRP draft In-reply-to: Your message of Mon, 26 Feb 2001 18:05:21 -0500. <5.0.2.1.2.20010226180027.027d6ec0@127.0.0.1> Date: Tue, 27 Feb 2001 15:07:39 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk I did not see this come across the list here so I've taken the liberty of posting this here.. I noticed it before, This is the NeuLevel ( NeuStar Melbourne IT ) informational draft on our concepts for a Generic Registry Protocol for Domain Names. This document had many contributors from both companies and the next iteration of the draft will more accurately reflect these contributions. Yuo mean that NeuLevel and NeuStar Melbourne are different companies? As I mentioned in the off site..this document should not be considered "competitive" to existing proposals but hopefully commentary. To the Chair ..I hope this could be included in our official WG documents moving forward. I know see two xrp documents. There is this one, the is draft-ietf-provreg-xrp-00.txt by McGarry, Damaraju, Amsden and Zhang, and there is draft-brunner-xrp-00.txt Brunner, Damaraju, Zhang. This getting really confusing. Maybe someone should point out what is really meant with the `XRP' protocol. jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RDoV5k028086 for ietf-provreg-outgoing; Tue, 27 Feb 2001 14:50:31 +0100 (MET) Received: from naptop.autonomica.se (liman.iku.sunet.se [193.10.90.131]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RDoSAY028081 for ; Tue, 27 Feb 2001 14:50:28 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1RDmjPO000723 for ietf-provreg@cafax.se; Tue, 27 Feb 2001 14:48:45 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RCsmAY027334 for ; Tue, 27 Feb 2001 13:54:51 +0100 (MET) Received: from jamessonyvaio (pc74.pwtc.jaring.my [202.186.141.74]) by mail.i-dns.net (Postfix) with SMTP id 89323FFC0E; Tue, 27 Feb 2001 20:54:18 +0800 (SGT) Message-ID: <00c801c0a0bc$497b7f60$4a8dbaca@jamessonyvaio> From: "James Seng/Personal" To: Cc: "Patrik Faltstrom" References: Subject: APRICOT'2001 Date: Tue, 27 Feb 2001 20:15:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear all, I have done the first discussion of ProvReg at the APRICOT'2001 today. Some NICs has expressed their shock this Working Group wish to push thru the Protocol, given that there are so many differences in policy, management and business models. Even among the Asian NICs, they do not have uniformed policy yet. Some feedback that this group can feel free to do what they like but if it the result is not suitable, they will just ignore it. A personal note from me (and I shall go into silence again until I have my I-D): While I understand there is a lot of ICANN pressure and commerical interest to push thru ProvReg quickly (heck, I work for a company which provides Registry Outsourcing too like some who is pushing this), I think we also need to consider there are many registries (mostly non-profit) in the world out there who barely struggle with their current operation. Having a rigid, complicated protocol will only make life more difficult for them without the right sets of tools. Don't forget them in your equation while you chase for the $$$. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RDjCmH028050 for ietf-provreg-outgoing; Tue, 27 Feb 2001 14:45:12 +0100 (MET) Received: from naptop.autonomica.se (liman.iku.sunet.se [193.10.90.131]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RDj9AY028045 for ; Tue, 27 Feb 2001 14:45:10 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1RDhRuK000586 for ietf-provreg@cafax.se; Tue, 27 Feb 2001 14:43:27 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1QN67AY023373 for ; Tue, 27 Feb 2001 00:06:08 +0100 (MET) Received: by dnspri.npac.com; id RAA05306; Mon, 26 Feb 2001 17:06:06 -0600 (CST) Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0) id xmaa03934; Mon, 26 Feb 01 17:05:07 -0600 Message-Id: <5.0.2.1.2.20010226180027.027d6ec0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 26 Feb 2001 18:05:21 -0500 To: ietf-provreg@cafax.se From: Richard Shockey Subject: NewLevel XRP draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk I did not see this come across the list here so I've taken the liberty of posting this here.. This is the NeuLevel ( NeuStar Melbourne IT ) informational draft on our concepts for a Generic Registry Protocol for Domain Names. This document had many contributors from both companies and the next iteration of the draft will more accurately reflect these contributions. As I mentioned in the off site..this document should not be considered "competitive" to existing proposals but hopefully commentary. To the Chair ..I hope this could be included in our official WG documents moving forward. Comments always welcome. ####### To: IETF-Announce: ; CC: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-brunner-xrp-00.txt Date: Fri, 23 Feb 2001 06:46:08 -0500 Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Registry Protocol (XRP) Author(s) : E. Brunner et al. Filename : draft-brunner-xrp-00.txt Pages : 112 Date : 22-Feb-01 This memo describes a connection-oriented, application layer client- server protocol for the provisioning and management of objects stored in a shared top level domain (TLD) central registry. The protocol defines a command framework for object management operations and maps the commands to the objects defined in an extensible object data model. The protocol is specified in XML Schema Definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brunner-xrp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.12.0.Beta1/8.12.0.Beta1) id f1RDMo95027537 for ietf-provreg-outgoing; Tue, 27 Feb 2001 14:22:50 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1RDMnAY027532 for ; Tue, 27 Feb 2001 14:22:49 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA19423; Tue, 27 Feb 2001 08:22:16 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9L1R>; Tue, 27 Feb 2001 08:16:27 -0500 Message-ID: From: "Bason, Chris" To: Rick H Wesson , Edward Lewis Cc: ietf-provreg@cafax.se Subject: RE: Interim meeting minutes Date: Tue, 27 Feb 2001 08:16:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk One comment about the Global Unique Handles: I believe the minutes were stated correctly. I don't think we came to a general consensus that Global Unique Handles were a "Good Thing". Chris Bason > -----Original Message----- > From: Rick H Wesson [mailto:wessorh@ar.com] > Sent: Monday, February 26, 2001 9:41 PM > To: Edward Lewis > Cc: ietf-provreg@cafax.se > Subject: Re: Interim meeting minutes > > > > I have a few comments about the minutes taken, they are inline. > > -rick > > On Mon, 26 Feb 2001, Edward Lewis wrote: > > > > Handle Issues > > - ability to reference objects in other registries > > specifically: Contacts > > - move to a more general approach > > - a global namespace for object storage for each registry > > - privacy issues were brought up. > > - Decided that there is no reason NOT to use it (But > shouldn't be in > > this protocol - only the ability to do it should > be in the protocol) > > - Still an open issue > > I don't think we decided anything, as an interm meeting can't > decide. I > believe we recomended that Global Unique handles would be a > Good Thing(tm) > for the protocol to support. > > > > > Transport Issues (BEEP, parsing at client) > > - statement made that transport alternatives are needed to improve > > efficiency > > we discussed ways that the current proposals could shorten > the amount of > data transfered by establishing context oriented data in the session > establishment phase of protocol negoation. > > > Design Teams > > > - Design teams work all through March > > - Deadline - end of week (Feb 23) for design team formation (5-7 > > people) > [snip] > > I hope the chairs will announce these soon, with well defined > objectives. > > > > Discussion of consummating the collution effort > > - Having a "commercial Implmentors consortium > > - Interoperability testing > > - Load testing > > - Rich Shockey volunteered to start Implementors group > > * Email to rich.shockey@neustar.com to join mailing list > > The list is at pri@ar.com, PRI stands from ProvReg > Implementors. alot of > folks have already subscribed. To subscribe send a message > with the word > "Subscribe" (without the quotes) to pri-request@ar.com > > -rick > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1RCRGp8027204 for ietf-provreg-outgoing; Tue, 27 Feb 2001 13:27:16 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f1RCRCAY027199 for ; Tue, 27 Feb 2001 13:27:15 +0100 (MET) Received: (qmail 5479 invoked from network); 27 Feb 2001 12:32:07 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 27 Feb 2001 12:32:07 -0000 From: "Paul George" To: Subject: RE: Interim meeting minutes Date: Tue, 27 Feb 2001 07:27:06 -0500 Message-ID: <000801c0a0b8$99921c10$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Design Teams > - Design teams work all through March > - Deadline - end of week (Feb 23) for design team formation (5-7 people) Jaap, Ed, any idea as to when the design team members will be announced? Thanks. Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Rick H Wesson Sent: Monday, February 26, 2001 9:41 PM To: Edward Lewis Cc: ietf-provreg@cafax.se Subject: Re: Interim meeting minutes I have a few comments about the minutes taken, they are inline. -rick On Mon, 26 Feb 2001, Edward Lewis wrote: > Handle Issues > - ability to reference objects in other registries > specifically: Contacts > - move to a more general approach > - a global namespace for object storage for each registry > - privacy issues were brought up. > - Decided that there is no reason NOT to use it (But shouldn't be in > this protocol - only the ability to do it should be in the protocol) > - Still an open issue I don't think we decided anything, as an interm meeting can't decide. I believe we recomended that Global Unique handles would be a Good Thing(tm) for the protocol to support. > > Transport Issues (BEEP, parsing at client) > - statement made that transport alternatives are needed to improve > efficiency we discussed ways that the current proposals could shorten the amount of data transfered by establishing context oriented data in the session establishment phase of protocol negoation. > Design Teams > - Design teams work all through March > - Deadline - end of week (Feb 23) for design team formation (5-7 > people) [snip] I hope the chairs will announce these soon, with well defined objectives. > Discussion of consummating the collution effort > - Having a "commercial Implmentors consortium > - Interoperability testing > - Load testing > - Rich Shockey volunteered to start Implementors group > * Email to rich.shockey@neustar.com to join mailing list The list is at pri@ar.com, PRI stands from ProvReg Implementors. alot of folks have already subscribed. To subscribe send a message with the word "Subscribe" (without the quotes) to pri-request@ar.com -rick Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1R2fSlZ025423 for ietf-provreg-outgoing; Tue, 27 Feb 2001 03:41:28 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1R2fQAY025411 for ; Tue, 27 Feb 2001 03:41:27 +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 SAA28947; Mon, 26 Feb 2001 18:41:02 -0800 (PST) Date: Mon, 26 Feb 2001 18:41:02 -0800 (PST) From: Rick H Wesson To: Edward Lewis cc: Subject: Re: Interim meeting minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk I have a few comments about the minutes taken, they are inline. -rick On Mon, 26 Feb 2001, Edward Lewis wrote: > Handle Issues > - ability to reference objects in other registries > specifically: Contacts > - move to a more general approach > - a global namespace for object storage for each registry > - privacy issues were brought up. > - Decided that there is no reason NOT to use it (But shouldn't be in > this protocol - only the ability to do it should be in the protocol) > - Still an open issue I don't think we decided anything, as an interm meeting can't decide. I believe we recomended that Global Unique handles would be a Good Thing(tm) for the protocol to support. > > Transport Issues (BEEP, parsing at client) > - statement made that transport alternatives are needed to improve > efficiency we discussed ways that the current proposals could shorten the amount of data transfered by establishing context oriented data in the session establishment phase of protocol negoation. > Design Teams > - Design teams work all through March > - Deadline - end of week (Feb 23) for design team formation (5-7 > people) [snip] I hope the chairs will announce these soon, with well defined objectives. > Discussion of consummating the collution effort > - Having a "commercial Implmentors consortium > - Interoperability testing > - Load testing > - Rich Shockey volunteered to start Implementors group > * Email to rich.shockey@neustar.com to join mailing list The list is at pri@ar.com, PRI stands from ProvReg Implementors. alot of folks have already subscribed. To subscribe send a message with the word "Subscribe" (without the quotes) to pri-request@ar.com -rick Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1R1s9QM024386 for ietf-provreg-outgoing; Tue, 27 Feb 2001 02:54:09 +0100 (MET) Received: from sunraysvr1.jaring.my ([202.186.141.3]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1R1s6AY024381 for ; Tue, 27 Feb 2001 02:54:07 +0100 (MET) Received: from [202.186.141.60] ([202.186.141.60]) by sunraysvr1.jaring.my (8.9.3+Sun/8.9.1) with ESMTP id JAA16557; Tue, 27 Feb 2001 09:53:53 +0800 (SGT) X-Sender: lewis@202.186.141.60 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 2001 20:53:47 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Interim meeting minutes Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks to our scribe, Paul George. IETF provreg meeting Location: Washington Dulles International Airport Marriott Date: Feb 20, 2001 Start Time: 10:00 AM EST End Time: 3:00 PM EST Chairs present Ed Lewis Jaap Akkerhuis Minutes Agenda review - requests to add items to agenda * nameservers as objects * namespaces * alternate transport strategies * BEEP * Security - authentication/PGP State of the WG - Neustar's proposal side note - Slide: WG Documents - Slide: WG vs Milestones Begin Requirements Discussion Handle Issues - ability to reference objects in other registries specifically: Contacts - move to a more general approach - a global namespace for object storage for each registry - privacy issues were brought up. - Decided that there is no reason NOT to use it (But shouldn't be in this protocol - only the ability to do it should be in the protocol) - Still an open issue Transport Issues (BEEP, parsing at client) - statement made that transport alternatives are needed to improve efficiency - suggestion made to specify that transport is a separate issue (agreement that it already is). - BEEP Protocol (short background) * Performance issues were brought up. * Suggestion to possibly move the transport, authentication and security out of the protocol to simplify it. * Noted: the need to discuss the needs of domain lookups vs all other activities. * Decided that this is not critical for Requirements Document * Decision to move this discussion to the mailing list. Data Collection Issues - data flows defined as technical vs social. - Identification of 4 data flow/collection properties: * Purpose * Recipients * Retention * Access - Issue: who announces their data collection policy and how do they announce it (How to communicate data flow/collection policies) - It was brought up that this is distinct from security - Was suggested that this need arises when there are too many relationships to track "out-of-band" - Decision to continue discussion on mailing list - Agreement that there should be a data collection section in the requirements doc for the protocol Security Issues - Discussion of the use of PGP certs for accessing data - Ability for the protocol to provide other solutions (from registries and registrars) - The need to id a request by the Registrant all the way to the Registry - The need to provide a second (or multiple) access points. - Agreement to change "Authentication ID" to "Authentication Info" - Discussion of the types of Contacts * Note that "billing", "tech" and "Admin" are considered placeholders for the time being. Lunch NameServers as objects - nameserver roles: 1 - attributes of domains 2 - object in their own right - object would give the ability to lookup data with a handle at the registry and protocol level. - Consensus that NameServers should be represented as objects in the protocol. I18N - discussion about whether or not we should reference either UTF8, 1646, or 2277 as a requirement in the protocol - note that 2277 was already referenced - Decided that this was good enough. Neustar XRP Proposal - Note that this document should be considered Neustar's view of the RRP - Recognition that it is very similar to Hollenbeck's draft and noted differences: * Uses BEEP explicitly - Neustar does not consider this to be in competition with Scott's draft - Recognized the need to further ID differences between the two documents - Comments on XRP * Uses IP objects for notification of possible intellectual property violations - Remain discussion centered around the PRESALES query and the fact that it represents 80-90% of all traffic load on a Registry's servers. * Possibly isolate the presale process into a different protocol * Discussion of if the presale process belongs in the protocol - Check commands could be moved to another box (implementation problem) * A note about making the check command contain optional authentication, which then was noted: optional auth results in optionally robust data * Discussion about the point of separating the functionality between two protocols * Discussion about using BEEP (for short time to market considerations) - It was decided that a separate protocol is not yet necessary and that this protocol should try to make the presales lookup as lightweight as possible in the current protocol. * Assuming that the check domain functionality is actually a check object. Design Teams - expected outcome of design teams * an in-depth study as to what needs to be included in the protocol spec. * Concentrates on part of the draft -or- design protocol while evaluating candidate protocols - Noted the need for multiple design teams * 1st team looking at the base protocol * 2nd team looking at the transport mechanisms/issues * 3rd team looking at security - recognition of the need for multiple transport mechanisms because of email - Note that April is still the deadline for the initial requirements spec - Design teams work all through March - Deadline - end of week (Feb 23) for design team formation (5-7 people) - Note to make the next IETF meeting the deadline for the first deliverable: * 1st deliverable: Issues and trade-offs w/ possible strategy suggestions from each team. Email addresses used as unique identifier - decided that it was not a good thing for now - Discussion moved to mailing list Discussion : Security - transport security vs. information security - Security Design team should: * List threats * Suggest how to handle them * Perhaps categorize the threats and determine which of the two other teams should address the threat. Discussion of IETF RFC creation process Discussion of an Implementors Group to discuss design/protocol implementation issues Discussion of time-to-market for new registries Discussion of group collusion issues/problems Discussion of consummating the collution effort - Having a "commercial Implmentors consortium - Interoperability testing - Load testing - Rich Shockey volunteered to start Implementors group * Email to rich.shockey@neustar.com to join mailing list Scott said he will submit a new provreg 00 soon. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1Q2fXTu016197 for ietf-provreg-outgoing; Mon, 26 Feb 2001 03:41:33 +0100 (MET) Received: from sunraysvr1.jaring.my ([202.186.141.3]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1Q2fTLN016191 for ; Mon, 26 Feb 2001 03:41:31 +0100 (MET) Received: from [202.186.141.44] (pc44.pwtc.jaring.my [202.186.141.44]) by sunraysvr1.jaring.my (8.9.3+Sun/8.9.1) with ESMTP id KAA06124; Mon, 26 Feb 2001 10:41:13 +0800 (SGT) X-Sender: lewis@202.186.141.44 (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Feb 2001 21:01:01 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Re: Minneapolis time slot Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk Update - we're now at 3:45-4:45pm, same day. If you are planning on attending the IETF for just the day of the provreg meeting, track the agenda on the IETF website in case there are more changes. At 9:31 PM -0500 2/21/01, Edward Lewis wrote: >Our time slot in Minneapolis is *Tuesday* from 5pm-6pm. (March 20.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1NBkCBA027233 for ietf-provreg-outgoing; Fri, 23 Feb 2001 12:46:12 +0100 (MET) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1NBk9LN027228 for ; Fri, 23 Feb 2001 12:46:10 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27746; Fri, 23 Feb 2001 06:46:08 -0500 (EST) Message-Id: <200102231146.GAA27746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-brunner-xrp-00.txt Date: Fri, 23 Feb 2001 06:46:08 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Registry Protocol (XRP) Author(s) : E. Brunner et al. Filename : draft-brunner-xrp-00.txt Pages : 112 Date : 22-Feb-01 This memo describes a connection-oriented, application layer client- server protocol for the provisioning and management of objects stored in a shared top level domain (TLD) central registry. The protocol defines a command framework for object management operations and maps the commands to the objects defined in an extensible object data model. The protocol is specified in XML Schema Definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brunner-xrp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brunner-xrp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222144120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-xrp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brunner-xrp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222144120.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1MKXZCK020039 for ietf-provreg-outgoing; Thu, 22 Feb 2001 21:33:35 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1MKXWLN020034 for ; Thu, 22 Feb 2001 21:33:34 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1MKXBC67281; Thu, 22 Feb 2001 15:33:11 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102222033.f1MKXBC67281@nic-naa.net> To: ietf-provreg@cafax.se cc: ayesha.damaraju@neustar.com, Ning.Zhang@neustar.com Subject: The XRP Spec Date: Thu, 22 Feb 2001 15:33:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk has been submitted to the I-D editor. The XRP draft should be showing up on the IETF archive shortly. Until it does, it is available via anonymous ftp from nic-naa.net [24.95.12.91], and via http from here: http://world.std.com/~iipc/draft-brunner-xrp-00.txt Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1MC5SCn013560 for ietf-provreg-outgoing; Thu, 22 Feb 2001 13:05:28 +0100 (MET) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1MC5RLN013555 for ; Thu, 22 Feb 2001 13:05:27 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08028; Thu, 22 Feb 2001 07:05:27 -0500 (EST) Message-Id: <200102221205.HAA08028@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-00.txt Date: Thu, 22 Feb 2001 07:05:26 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-grrp-reqs-00.txt Pages : 23 Date : 21-Feb-01 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-grrp-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145709.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1MC5OvH013554 for ietf-provreg-outgoing; Thu, 22 Feb 2001 13:05:24 +0100 (MET) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1MC5MLN013549 for ; Thu, 22 Feb 2001 13:05:23 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08002; Thu, 22 Feb 2001 07:05:22 -0500 (EST) Message-Id: <200102221205.HAA08002@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-epp-00.txt Date: Thu, 22 Feb 2001 07:05:21 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-00.txt Pages : 49 Date : 21-Feb-01 This document describes a connection-oriented, application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-epp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-epp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145656.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1M9pUhU012151 for ietf-provreg-outgoing; Thu, 22 Feb 2001 10:51:30 +0100 (MET) Received: from naptop.autonomica.se (liman.iku.sunet.se [193.10.90.131]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1M9pSLN012143 for ; Thu, 22 Feb 2001 10:51:28 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1M9nw9O000858 for ietf-provreg@cafax.se; Thu, 22 Feb 2001 10:49:58 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1M3fLLN009310 for ; Thu, 22 Feb 2001 04:41:22 +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 TAA20238 for ; Wed, 21 Feb 2001 19:41:20 -0800 (PST) Date: Wed, 21 Feb 2001 19:41:19 -0800 (PST) From: Rick H Wesson To: "'ietf-provreg@cafax.se'" Subject: implementors list up Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk all: At the interim meeting we discussed setting up a list of implementors of EPP/XRP to discuss and exchange information about implementing the various schemas that have been discussed. To subscribe send a message pri-request@ar.com, the list is a majordomo list. The list is intended for registries, registrars and software developers that wish to exchange information and possibly code for EPP/XRP implementations. I will probably set up a cvs server and web page if folks have a desire for it. Once we have a public release we can go use sourceforge some something like that. problems, suggestions, etc. just drop me a note. -rick Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1M2VhbN008975 for ietf-provreg-outgoing; Thu, 22 Feb 2001 03:31:43 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1M2VfLN008970 for ; Thu, 22 Feb 2001 03:31:41 +0100 (MET) Received: from 207-172-150-129.s2.as10.anp.md.dialup.rcn.com ([207.172.150.129] helo=[207.172.149.151]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14VlXf-00003x-00 ; Wed, 21 Feb 2001 21:31:40 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Feb 2001 21:31:14 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Minneapolis time slot Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk Our time slot in Minneapolis is *Tuesday* from 5pm-6pm. (March 20.) I said the wrong night during the interim meeting yesterday. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1LBjkEs001069 for ietf-provreg-outgoing; Wed, 21 Feb 2001 12:45:46 +0100 (MET) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1LBjdLN001064 for ; Wed, 21 Feb 2001 12:45:45 +0100 (MET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22502; Wed, 21 Feb 2001 06:45:38 -0500 (EST) Message-Id: <200102211145.GAA22502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-dn-defn-00.txt Date: Wed, 21 Feb 2001 06:45:37 -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Domain Name and Related Definitions Author(s) : R. Rader Filename : draft-ietf-provreg-dn-defn-00.txt Pages : 7 Date : 20-Feb-01 Efforts are currently being undertaken to define and formalize registry/registrar communications protocols in light of the current and evolving scope and utility of DNS, domain name registries and related entities. In order for this work to be truly effective and broadly applicable, it is important that accepted definitions act as the foundation. This document is an attempt to create a starting point for the requisite dialogue that will ultimately foster the determination and acceptance of these new protocols. This document obsoletes . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-dn-defn-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-dn-defn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-dn-defn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010220160254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-dn-defn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-dn-defn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220160254.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1KMkFex025101 for ietf-provreg-outgoing; Tue, 20 Feb 2001 23:46:15 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1KMkELN025096 for ; Tue, 20 Feb 2001 23:46:14 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA06101 for ; Tue, 20 Feb 2001 17:46:13 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F92BS>; Tue, 20 Feb 2001 17:40:36 -0500 Message-ID: From: "Hollenbeck, Scott" Reply-To: jaap@sidn.nl, " lewis@tislabs.com" To: "'ietf-provreg@cafax.se'" Subject: Design Teams Date: Tue, 20 Feb 2001 17:40:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk One of the topics that came up at today's interim meeting was design team formation. The folks in the room though that three design teams would be appropriate: one focused on protocol design, one focused on protocol transport, and one focused on security. Each team will be tasked to produce a presentation of focus area issues and trade-offs to be discussed at the March IETF meeting. Teams of 5-7 people will be selected by our co-chairs Ed and Jaap, who will confirm selections directly with members and this list on Monday 26 February or Tuesday 27 February at the latest. Anyone interested a taking part on one of the design teams MUST send a mail note to both Ed and Jaap to confirm your interest. You must identify which team you wish to contribute to. It would also be helpful if you also provided some insights into any special skills that you would bring to the team. Here are the e-mail addresses you'll need to state your desire to participate: Jaap Akkerhuis , Edward Lewis Please send your "I want to participate" requests to them directly, _not_ to this list. Issues with the approach discussed at today's meeting should be sent to the list. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1KE3T3E020815 for ietf-provreg-outgoing; Tue, 20 Feb 2001 15:03:29 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1KE3RLN020810 for ; Tue, 20 Feb 2001 15:03:28 +0100 (MET) Received: from dialup-166.90.31.185.Washington1.Level3.net (dialup-166.90.31.185.Washington1.Level3.net [166.90.31.185]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id GAA28530; Tue, 20 Feb 2001 06:03:24 -0800 X-Authentication-Warning: joy.songbird.com: dialup-166.90.31.185.Washington1.Level3.net [166.90.31.185] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010220085950.01bb2e40@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) X-Priority: 1 (Highest) Date: Tue, 20 Feb 2001 09:03:28 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Conference Bridge - ProvReg @ Washington, 2/20/01 Cc: shollenbeck@verisign.com In-Reply-To: <200102201226.f1KCQxC53595@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk >\ Folks, Scott Hollenbeck has arranged a telephone bridge to today's interim working group meeting for ProvReg. 4 remote participants can be supported. Available: 10am - 5pm, Eastern US time. Call: +1.888.790.2032 Leader: Scott Hollenbeck Code: Marriott If you have a problem, call Scott: +1.703.927.0067 d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1KCRZ23020053 for ietf-provreg-outgoing; Tue, 20 Feb 2001 13:27:35 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1KCRXLN020048 for ; Tue, 20 Feb 2001 13:27:33 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1KCQxC53595; Tue, 20 Feb 2001 07:26:59 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102201226.f1KCQxC53595@nic-naa.net> To: shollenbeck@verisign.com, bmanning@isi.edu cc: ietf-provreg@cafax.se Subject: Today's teleconferencing info Date: Tue, 20 Feb 2001 07:26:57 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Bill, Please post the bridge no and the majik numbers. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1K2MHeG016574 for ietf-provreg-outgoing; Tue, 20 Feb 2001 03:22:17 +0100 (MET) Received: from hoteldns02.stsn.com (p38.usslc13.stsn.com [208.32.226.38]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1K2M9LN016569 for ; Tue, 20 Feb 2001 03:22:10 +0100 (MET) Received: from [10.1.208.99] ([10.1.208.99]) by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f1K2L7q21216 for ; Mon, 19 Feb 2001 19:21:07 -0700 X-Authentication-Warning: hoteldns02.stsn.com: [10.1.208.99] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010219180141.03008350@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Mon, 19 Feb 2001 18:05:52 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Re: grrp-reqs-06, 11. Security Considerations [3] In-Reply-To: <200102192205.f1JM5oA15676@zed.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk From the message thread, I am getting the sense that something basic is being missed. Indeed it might be that *I* am the one doing the missing, but just in case not... Policy vs. mechanism... It is neither complicated nor unusual to have a mechanism that permits separate bags of bits to be labeled, according to some SEPARATELY defined policy. Defining such policies can be quite difficult, but why don't we separate that task from the one of simply permitting data "sections", with each section having its own label and being subject to possibly separate handling policies? d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JM5ttA014689 for ietf-provreg-outgoing; Mon, 19 Feb 2001 23:05:55 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JM5rLN014684 for ; Mon, 19 Feb 2001 23:05:54 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1JM5os01362; Mon, 19 Feb 2001 14:05:50 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f1JM5oA15676; Mon, 19 Feb 2001 14:05:50 -0800 Message-Id: <200102192205.f1JM5oA15676@zed.isi.edu> Subject: Re: grrp-reqs-06, 11. Security Considerations [3] To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Mon, 19 Feb 2001 14:05:50 -0800 (PST) Cc: bmanning@isi.edu ('Bill Manning'), ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Feb 19, 2001 04:44:43 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hum... don't know where to put it. But it ought to be stated someplace. % % Agreed -- are you suggesting another rewording of [3] or a new requirement % [4]: % % [4] Some of the social information exchanged between a registrar and % registry MAY be REQUIRED % for proper generation of zone files. Information REQUIRED for proper % generation of zone files is subject to public disclosure. --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JLoRLE014553 for ietf-provreg-outgoing; Mon, 19 Feb 2001 22:50:27 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JLoQLN014548 for ; Mon, 19 Feb 2001 22:50:26 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA02586; Mon, 19 Feb 2001 16:50:19 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9HG7>; Mon, 19 Feb 2001 16:44:44 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Bill Manning'" Cc: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 11. Security Considerations [3] Date: Mon, 19 Feb 2001 16:44:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Agreed -- are you suggesting another rewording of [3] or a new requirement [4]: [4] Some of the social information exchanged between a registrar and registry MAY be REQUIRED for proper generation of zone files. Information REQUIRED for proper generation of zone files is subject to public disclosure. I don't have a problem with moving text like this and [3] out of the Security Considerations section since it does have more to do with use of collected data (as Eric noted) than protocol security. How about adding section 8.4 for Data Collection and Disclosure Requirements? I know Eric asked for a Data Collection Considerations section, but section 8 exists to capture requirements that don't have an explicit fit anywhere else. Why not put them here? -----Original Message----- From: Bill Manning [mailto:bmanning@ISI.EDU] Sent: Monday, February 19, 2001 2:57 PM To: shollenbeck@verisign.com Cc: ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 11. Security Considerations [3] from the archive: [3] Some of the social information exchanged between a registrar and registry can be considered personal, private, or otherwise restricted from public disclosure. Disclosure of such information MAY be restricted by laws and/or business practices. A generic protocol MUST provide services to identify social information that is subject to disclosure restrictions levied by laws and/or business practices. ----------------------------------------------------------- Very good. However, some of the social information may be REQUIRED for proper generation of zone files. Where this information is required, it is subject to public disclosure. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JL4Jom014251 for ietf-provreg-outgoing; Mon, 19 Feb 2001 22:04:19 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JL4ILN014246 for ; Mon, 19 Feb 2001 22:04:19 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=bminer) by toronto.mail.tucows.com with smtp (Exim 3.20 #2) id 14UxSj-0008To-00 for ietf-provreg@cafax.se; Mon, 19 Feb 2001 16:03:13 -0500 Message-ID: <001e01c09ab7$785e1be0$b80a000a@pc.internal.tucows.com> From: "Bruce Miner" To: "ietf-provreg" Subject: RE: Tuesday provreg meeting in DC Date: Mon, 19 Feb 2001 16:03:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C09A8D.8F774B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C09A8D.8F774B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll be over around 9:00 am since the meeting room will be open then. Bruce Miner ------=_NextPart_000_001B_01C09A8D.8F774B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll be over around 9:00 am since the = meeting room=20 will be open then.
 
Bruce Miner
 
 
 
------=_NextPart_000_001B_01C09A8D.8F774B00-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JJuZjG013741 for ietf-provreg-outgoing; Mon, 19 Feb 2001 20:56:35 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JJuYLN013736 for ; Mon, 19 Feb 2001 20:56:34 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1JJuXs11172; Mon, 19 Feb 2001 11:56:33 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f1JJuXv15444; Mon, 19 Feb 2001 11:56:33 -0800 Message-Id: <200102191956.f1JJuXv15444@zed.isi.edu> Subject: Re: grrp-reqs-06, 11. Security Considerations [3] To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Mon, 19 Feb 2001 11:56:33 -0800 (PST) Cc: ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Feb 19, 2001 12:35:54 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk from the archive: [3] Some of the social information exchanged between a registrar and registry can be considered personal, private, or otherwise restricted from public disclosure. Disclosure of such information MAY be restricted by laws and/or business practices. A generic protocol MUST provide services to identify social information that is subject to disclosure restrictions levied by laws and/or business practices. ----------------------------------------------------------- Very good. However, some of the social information may be REQUIRED for proper generation of zone files. Where this information is required, it is subject to public disclosure. % % Indeed, and that's why I suggested a rewording last week to make the intent % more explicit: % % http://www.cafax.se/ietf-provreg/maillist/2001-02/msg00169.html % % % % -----Original Message----- % From: Bill Manning [mailto:bmanning@ISI.EDU] % Sent: Monday, February 19, 2001 11:46 AM % To: shollenbeck@verisign.com % Cc: bmanning@ISI.EDU; ietf-provreg@cafax.se % Subject: Re: grrp-reqs-06, 11. Security Considerations [3] % % % Yup. I re-read it. % I'm concerned that depending on venue, the level of information % required changes. DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY % not counting the goofy CERT rr injections for PGP/SSH key % distribution % will all change the amount of data that will need to be maintained. % % % % % % % Bill, % % % % Have a read of the definitions section ("Thick Registry" specifically), % % where it describes "technical information" as "information needed to % produce % % zone files". % % % % % % % % -----Original Message----- % % From: Bill Manning [mailto:bmanning@ISI.EDU] % % Sent: Friday, February 16, 2001 10:27 AM % % To: shollenbeck@verisign.com % % Cc: ietf-provreg@cafax.se % % Subject: Re: grrp-reqs-06, 11. Security Considerations [3] % % % % % % % % % % Eric, % % % % % % The intention of requirement 11-[3] isn't to document that "a mechanism % % % exists to to distinguish technical from social information", it's % intended % % % to note that disclosure of non-technical information may be subject to % % % restrictions and the protocol needs to provide a way to identify % % information % % % that is subject to disclosure restrictions. This was added at the % request % % % of Karl Auerbach. % % % % What is the distinction between "technical" and "non-technical"? % % Are these definitions immutatble within/between juristictions? % % Will they withstand legal review? % % In which venues? % % % % --bill % -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JIT0Zn013082 for ietf-provreg-outgoing; Mon, 19 Feb 2001 19:29:00 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JISxLN013077 for ; Mon, 19 Feb 2001 19:28:59 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1JISGC50843; Mon, 19 Feb 2001 13:28:16 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102191828.f1JISGC50843@nic-naa.net> To: Bill Manning cc: shollenbeck@verisign.com (Hollenbeck, Scott), ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: grrp-reqs-06, 11. Security Considerations [3] In-Reply-To: Your message of "Mon, 19 Feb 2001 08:46:11 PST." <200102191646.f1JGkBV15164@zed.isi.edu> Date: Mon, 19 Feb 2001 13:28:16 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk So the answer is "many" if the question is "how many distinct flows exist?". There exist two or more flows within the "technical information", depending upon the model (Bill's note). There exist two or more flows within the "social information", depending upon the model (Eric's note). So, the reason why we have a "Security Considerations" section, but not a "Data Collection Considerations" section is ... To speak to Bill's earlier question: % What is the distinction between "technical" and "non-technical"? Covered, zone vs non, per Scott. % Are these definitions immutatble within/between juristictions? IMO no, given the variations between the US, the OEDC and EC data regiemes. % Will they withstand legal review? See above. % In which venues? See above. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JHfZSk012733 for ietf-provreg-outgoing; Mon, 19 Feb 2001 18:41:35 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JHfYLN012728 for ; Mon, 19 Feb 2001 18:41:34 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA02406 for ; Mon, 19 Feb 2001 12:41:33 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9HFT>; Mon, 19 Feb 2001 12:35:59 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 11. Security Considerations [3] Date: Mon, 19 Feb 2001 12:35:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Indeed, and that's why I suggested a rewording last week to make the intent more explicit: http://www.cafax.se/ietf-provreg/maillist/2001-02/msg00169.html -----Original Message----- From: Bill Manning [mailto:bmanning@ISI.EDU] Sent: Monday, February 19, 2001 11:46 AM To: shollenbeck@verisign.com Cc: bmanning@ISI.EDU; ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 11. Security Considerations [3] Yup. I re-read it. I'm concerned that depending on venue, the level of information required changes. DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY not counting the goofy CERT rr injections for PGP/SSH key distribution will all change the amount of data that will need to be maintained. % % Bill, % % Have a read of the definitions section ("Thick Registry" specifically), % where it describes "technical information" as "information needed to produce % zone files". % % % % -----Original Message----- % From: Bill Manning [mailto:bmanning@ISI.EDU] % Sent: Friday, February 16, 2001 10:27 AM % To: shollenbeck@verisign.com % Cc: ietf-provreg@cafax.se % Subject: Re: grrp-reqs-06, 11. Security Considerations [3] % % % % % % Eric, % % % % The intention of requirement 11-[3] isn't to document that "a mechanism % % exists to to distinguish technical from social information", it's intended % % to note that disclosure of non-technical information may be subject to % % restrictions and the protocol needs to provide a way to identify % information % % that is subject to disclosure restrictions. This was added at the request % % of Karl Auerbach. % % What is the distinction between "technical" and "non-technical"? % Are these definitions immutatble within/between juristictions? % Will they withstand legal review? % In which venues? % % --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JGkOii012324 for ietf-provreg-outgoing; Mon, 19 Feb 2001 17:46:24 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JGkHLN012319 for ; Mon, 19 Feb 2001 17:46:23 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1JGkBs15260; Mon, 19 Feb 2001 08:46:11 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f1JGkBV15164; Mon, 19 Feb 2001 08:46:11 -0800 Message-Id: <200102191646.f1JGkBV15164@zed.isi.edu> Subject: Re: grrp-reqs-06, 11. Security Considerations [3] To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Mon, 19 Feb 2001 08:46:11 -0800 (PST) Cc: bmanning@isi.edu ('Bill Manning'), ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Feb 16, 2001 10:32:06 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yup. I re-read it. I'm concerned that depending on venue, the level of information required changes. DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY not counting the goofy CERT rr injections for PGP/SSH key distribution will all change the amount of data that will need to be maintained. % % Bill, % % Have a read of the definitions section ("Thick Registry" specifically), % where it describes "technical information" as "information needed to produce % zone files". % % % % -----Original Message----- % From: Bill Manning [mailto:bmanning@ISI.EDU] % Sent: Friday, February 16, 2001 10:27 AM % To: shollenbeck@verisign.com % Cc: ietf-provreg@cafax.se % Subject: Re: grrp-reqs-06, 11. Security Considerations [3] % % % % % % Eric, % % % % The intention of requirement 11-[3] isn't to document that "a mechanism % % exists to to distinguish technical from social information", it's intended % % to note that disclosure of non-technical information may be subject to % % restrictions and the protocol needs to provide a way to identify % information % % that is subject to disclosure restrictions. This was added at the request % % of Karl Auerbach. % % What is the distinction between "technical" and "non-technical"? % Are these definitions immutatble within/between juristictions? % Will they withstand legal review? % In which venues? % % --bill % -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1JEv8dg011513 for ietf-provreg-outgoing; Mon, 19 Feb 2001 15:57:08 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1JEv5LN011508 for ; Mon, 19 Feb 2001 15:57:06 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1JEuRC50351; Mon, 19 Feb 2001 09:56:28 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102191456.f1JEuRC50351@nic-naa.net> To: ietf-provreg@cafax.se cc: rich.shockey@neustar.com, tom.mcgarry@neustar.com, mark.foster@neustar.com, ayesha.damaraju@neustar.com Subject: Re: Tuesday provreg meeting in DC Date: Mon, 19 Feb 2001 09:56:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk All, I won't be able to attend tomorrow's meeting. Eric Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1HHQg3W020731 for ietf-provreg-outgoing; Sat, 17 Feb 2001 18:26:42 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1HHQfLN020726 for ; Sat, 17 Feb 2001 18:26:41 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA01421; Sat, 17 Feb 2001 12:26:40 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9HAC>; Sat, 17 Feb 2001 12:21:10 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Edward Lewis'" , ietf-provreg@cafax.se Subject: RE: The agenda so far Date: Sat, 17 Feb 2001 12:21:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk We will have an LCD projector at our disposal. I'll have a laptop with me as I'm sure others will. > -----Original Message----- > From: Edward Lewis [mailto:lewis@tislabs.com] > Sent: Saturday, February 17, 2001 11:11 AM > To: ietf-provreg@cafax.se > Cc: lewis@tislabs.com > Subject: The agenda so far > > > At 2:13 PM -0500 2/16/01, Rick H Wesson wrote: > >would you please post the revised agenda for the meeting. > > 9am Pre-meeting gathering > > 10am Agenda bashing: 10 min > Name the scribe... > WG status: 5 min > Requirements Document - Remaining Issues 15 min (tops) > The EPP proposal as needed > Neustar's XRP as needed > Short lunch break 30 min to > get food, etc. > (Other proposals) as needed > Discussion of forming a design team as needed > > I haven't gotten any other requests for items. > > During the pre-meeting, it would be good to identify topics > that we want to > cover during the day - we are still getting comments on > requirements, so I > think we should spend some time on that. > > As far as logistics - Scott, do we have any display > equipment? Overhead > projector or screen projector? Apparently there is a pizza > franchise in > the hotel, that might be lunch for us. > > Remember that this meeting supplements the mailing list discussion. > Nothing will be finalized at the meeting and meeting notes > are due to the > list with 10 (or was it 15) days of the meeting. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1HHPoYR020721 for ietf-provreg-outgoing; Sat, 17 Feb 2001 18:25:50 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1HHPnLN020716 for ; Sat, 17 Feb 2001 18:25:49 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA01417; Sat, 17 Feb 2001 12:25:42 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9HAB>; Sat, 17 Feb 2001 12:20:12 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" , Edward Lewis Cc: ietf-provreg@cafax.se Subject: RE: The agenda so far Date: Sat, 17 Feb 2001 12:20:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Works for me, especially since there has been no other comment provided on the list. > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Saturday, February 17, 2001 12:10 PM > To: Edward Lewis > Cc: ietf-provreg@cafax.se; brunner@nic-naa.net > Subject: Re: The agenda so far > > > Ed, > > Scott and I can't seem to find a common ground for the i18n and data > collection issue, 5 minutes for each to (re-)state the problem, and > get sense-of-room, possibly at wrap-up. > > Eric > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1HHAjYm020626 for ietf-provreg-outgoing; Sat, 17 Feb 2001 18:10:45 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1HHAiLN020621 for ; Sat, 17 Feb 2001 18:10:44 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1HH9uC43753; Sat, 17 Feb 2001 12:09:56 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102171709.f1HH9uC43753@nic-naa.net> To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: The agenda so far In-Reply-To: Your message of "Sat, 17 Feb 2001 11:11:21 EST." Date: Sat, 17 Feb 2001 12:09:55 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Scott and I can't seem to find a common ground for the i18n and data collection issue, 5 minutes for each to (re-)state the problem, and get sense-of-room, possibly at wrap-up. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1HGBUvu020274 for ietf-provreg-outgoing; Sat, 17 Feb 2001 17:11:30 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1HGBSLN020269 for ; Sat, 17 Feb 2001 17:11:29 +0100 (MET) Received: from 207-172-151-29.s29.as12.anp.md.dialup.rcn.com ([207.172.151.29]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14U9xG-0000ob-00 ; Sat, 17 Feb 2001 11:11:26 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 Feb 2001 11:11:21 -0500 To: From: Edward Lewis Subject: The agenda so far Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 2:13 PM -0500 2/16/01, Rick H Wesson wrote: >would you please post the revised agenda for the meeting. 9am Pre-meeting gathering 10am Agenda bashing: 10 min Name the scribe... WG status: 5 min Requirements Document - Remaining Issues 15 min (tops) The EPP proposal as needed Neustar's XRP as needed Short lunch break 30 min to get food, etc. (Other proposals) as needed Discussion of forming a design team as needed I haven't gotten any other requests for items. During the pre-meeting, it would be good to identify topics that we want to cover during the day - we are still getting comments on requirements, so I think we should spend some time on that. As far as logistics - Scott, do we have any display equipment? Overhead projector or screen projector? Apparently there is a pizza franchise in the hotel, that might be lunch for us. Remember that this meeting supplements the mailing list discussion. Nothing will be finalized at the meeting and meeting notes are due to the list with 10 (or was it 15) days of the meeting. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1H3fuN5016887 for ietf-provreg-outgoing; Sat, 17 Feb 2001 04:41:56 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1H3fsLN016882 for ; Sat, 17 Feb 2001 04:41:55 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1H3f0C39365; Fri, 16 Feb 2001 22:41:00 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102170341.f1H3f0C39365@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: grrp-reqs-06, 11. Security Considerations [3] In-Reply-To: Your message of "Fri, 16 Feb 2001 12:42:39 EST." Date: Fri, 16 Feb 2001 22:41:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, If the remedy is well-defined in whatever legal arrangement exists between the parties involved, then there is no protocol requirement. I appreciate that you were attempting to address Karl's concern, but Karl isn't the sharpest knife in the drawer, and policy without mechanism is de rigeur in Privacy Advocacy Circles, but [3] doesn't appear to mean any thing in particular. How many data collection policy octets per session instantiation is "too much" overhead? The whole of the P3P vocabulary we mapped onto cookies is (maximally) 53, of which 18 may take on 3 possible modifiers, so with all pathological possibilities left in, the range of distinct values fits in 7 familiar bits. XMLification can expand that almost infinitely, as it can anything. How many policy and jurisdictional scope octets per transaction is "too much" overhead? As I mentioned, your reaching for OIDs and URI's is unnecessary, the number of meaningfully distinct statutory and existing business practice data collection models is very finite, smaller than the number of ICANN accredited registrars. We already have their identifiers, we're just per-hop (few of those to boot) picking an index into a well-known array of data collection statutory and business models. Fits on a small pin, possibly the pointy end, modulo the subsequent Baroque splendor of XMLification. > The issue I am trying to address is one of privacy WRT what a registry can > do with social data. Different issue, different section. My problem isn't one of a registry's access, but of a registrant's authorization. Data originates policied, it isn't apolicied until a registry (or registrar) makes a grant of policy to it. Please also see "purpose", "retention", and "access", in my notes to Jordyn, your whois example only touches on "recipient", not repurposing, persistence, or originator modification. "A registry ... may allow registrants to opt-out", now there's an idea. The rewording of [3] is different, but it isn't sufficient to prevent any R-* social information collector from becomming an on-line marketeer, or from merging off-line data with on-line data. Well, I've tried twice. As an author of the cpexchange work, which attempts onward-transport, _exactly_ what provreg is attempting, modulo the nuance that some data ends up in zone files, and fewer registries exist than CRM and list manager back ends, and an author of the p3p work, particularly the namespace-, method-, and state-specific portions of putting policy into the initial data collection, I'm disapointed. I'll put out a seperate requirements draft by Friday, which is easier than iterating on inadequate wording. Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GLs6in014028 for ietf-provreg-outgoing; Fri, 16 Feb 2001 22:54:06 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GLs5LN014023 for ; Fri, 16 Feb 2001 22:54:05 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1GLrCC38498; Fri, 16 Feb 2001 16:53:12 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102162153.f1GLrCC38498@nic-naa.net> To: lewis@tislabs.com, jaap@sidn.nl cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Agenda for Interim Meeting In-Reply-To: Your message of "Mon, 05 Feb 2001 11:16:46 EST." Date: Fri, 16 Feb 2001 16:53:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, and Jaap, > Agenda bashing: (short) > WG status: (short) > The EPP proposal > Other proposals > Discussion of forming a design team > > Comments? Yes. Under "Other proposals" Neustar's XRP. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GL1rXx013610 for ietf-provreg-outgoing; Fri, 16 Feb 2001 22:01:53 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GL1pLN013605 for ; Fri, 16 Feb 2001 22:01:51 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1GL0xC38295; Fri, 16 Feb 2001 16:00:59 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102162100.f1GL0xC38295@nic-naa.net> To: "Hollenbeck, Scott" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Tuesday provreg meeting in DC In-Reply-To: Your message of "Fri, 16 Feb 2001 14:47:43 EST." Date: Fri, 16 Feb 2001 16:00:59 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Yes. But only if you can prove: a) jurisdictionally appropriate age, b) the ability to express a data collection policy on a napkin (both sides may be used if expressed in xml), and c) Unicode fluency after sufficient labelprep. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GJrI0H012960 for ietf-provreg-outgoing; Fri, 16 Feb 2001 20:53:18 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GJrHLN012955 for ; Fri, 16 Feb 2001 20:53:17 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA00057 for ; Fri, 16 Feb 2001 14:53:11 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GWG>; Fri, 16 Feb 2001 14:47:43 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Tuesday provreg meeting in DC Date: Fri, 16 Feb 2001 14:47:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric's supplying the beer for a Monday night bar BOF? > -----Original Message----- > From: Jaap Akkerhuis [mailto:jaap@sidn.nl] > Sent: Friday, February 16, 2001 1:21 PM > To: Dave Crocker; ietf-provreg@cafax.se > Subject: Re: Tuesday provreg meeting in DC > > > > > I'kll bette, I'm flying in the nigt before (and leave > tuesday evening). > > H'mm, keyboard failure, actually, pilot error with new > keyboard. I'll try again. > > I'll be there probably early (like Scott). I'm flying in the night > before and will be around (So Eric can buy me a beer). > > jaap > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GJYrM5012826 for ietf-provreg-outgoing; Fri, 16 Feb 2001 20:34:53 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GJYpLN012821 for ; Fri, 16 Feb 2001 20:34:52 +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 LAA19450 for ; Fri, 16 Feb 2001 11:34:50 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010216113221.03267700@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) X-Priority: 2 (High) Date: Fri, 16 Feb 2001 11:34:57 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Re: Tuesday provreg meeting in DC In-Reply-To: <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 09:02 AM 2/16/2001, Dave Crocker wrote: >Since the meeting room will be available from 9am, I'm planning to show up >then. Folks, I was just asked where the meeting was, so here's the details, posted in: Washington Dulles Airport Marriott Tuesday 20 February, 10am - 5pm. That's about as far West of D.C. and Baltimore-Washington International Airport (BWI) is East of D.C... d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GJDdu2012669 for ietf-provreg-outgoing; Fri, 16 Feb 2001 20:13:39 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GJDbLN012664 for ; Fri, 16 Feb 2001 20:13:38 +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 LAA11201; Fri, 16 Feb 2001 11:13:08 -0800 (PST) Date: Fri, 16 Feb 2001 11:13:08 -0800 (PST) From: Rick H Wesson To: Edward Lewis cc: Jaap Akkerhuis , Dave Crocker , Subject: Re: Tuesday provreg meeting in DC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, would you please post the revised agenda for the meeting. thanks, -rick On Fri, 16 Feb 2001, Edward Lewis wrote: > I'll probably be a late arrival (compared to 9), I should be able to be > there by 10 but will try to get there earlier. I fear that any attempt to > get there close to 9 am will be thwarted by the DC Beltway. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GJ4H3Y012546 for ietf-provreg-outgoing; Fri, 16 Feb 2001 20:04:17 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GJ4FLN012541 for ; Fri, 16 Feb 2001 20:04:16 +0100 (MET) Received: by sentry.gw.tislabs.com; id OAA22697; Fri, 16 Feb 2001 14:07:37 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma022692; Fri, 16 Feb 01 14:06:39 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200102161821.f1GILFj05795@bartok.sidn.nl> References: Your message of Fri, 16 Feb 2001 19:12:46 +0100. <200102161812.f1GICkj05761@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 2001 13:47:41 -0500 To: Jaap Akkerhuis From: Edward Lewis Subject: Re: Tuesday provreg meeting in DC Cc: Dave Crocker , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'll probably be a late arrival (compared to 9), I should be able to be there by 10 but will try to get there earlier. I fear that any attempt to get there close to 9 am will be thwarted by the DC Beltway. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GIbhXv012304 for ietf-provreg-outgoing; Fri, 16 Feb 2001 19:37:43 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GIbfLN012298 for ; Fri, 16 Feb 2001 19:37:41 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1GIbes01057; Fri, 16 Feb 2001 10:37:40 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f1GIbZ101315; Fri, 16 Feb 2001 10:37:35 -0800 Message-Id: <200102161837.f1GIbZ101315@zed.isi.edu> Subject: Re: Tuesday provreg meeting in DC To: dcrocker@brandenburg.com (Dave Crocker) Date: Fri, 16 Feb 2001 10:37:35 -0800 (PST) Cc: ietf-provreg@cafax.se In-Reply-To: <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> from "Dave Crocker" at Feb 16, 2001 09:02:30 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Is there a conference bridge? If so, what are the majik numbers? -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GIHW9e012092 for ietf-provreg-outgoing; Fri, 16 Feb 2001 19:17:32 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GIHVLN012087 for ; Fri, 16 Feb 2001 19:17:32 +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 TAA95874; Fri, 16 Feb 2001 19:17:31 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.2/8.11.1) with ESMTP id f1GILFj05795; Fri, 16 Feb 2001 19:21:15 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102161821.f1GILFj05795@bartok.sidn.nl> To: Dave Crocker , ietf-provreg@cafax.se Subject: Re: Tuesday provreg meeting in DC In-reply-to: Your message of Fri, 16 Feb 2001 19:12:46 +0100. <200102161812.f1GICkj05761@bartok.sidn.nl> Date: Fri, 16 Feb 2001 19:21:15 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'kll bette, I'm flying in the nigt before (and leave tuesday evening). H'mm, keyboard failure, actually, pilot error with new keyboard. I'll try again. I'll be there probably early (like Scott). I'm flying in the night before and will be around (So Eric can buy me a beer). jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GI94pN012001 for ietf-provreg-outgoing; Fri, 16 Feb 2001 19:09:04 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GI93LN011996 for ; Fri, 16 Feb 2001 19:09:04 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id TAA95818; Fri, 16 Feb 2001 19:09:03 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.2/8.11.1) with ESMTP id f1GICkj05761; Fri, 16 Feb 2001 19:12:46 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102161812.f1GICkj05761@bartok.sidn.nl> To: Dave Crocker cc: ietf-provreg@cafax.se Subject: Re: Tuesday provreg meeting in DC In-reply-to: Your message of Fri, 16 Feb 2001 09:02:30 -0800. <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> Date: Fri, 16 Feb 2001 19:12:46 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Since the meeting room will be available from 9am, I'm planning to show up then. Is anybody else similarly inclined, to get discussion going early? I'kll bette, I'm flying in the nigt before (and leave tuesday evening). jaap Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GHmPS8011791 for ietf-provreg-outgoing; Fri, 16 Feb 2001 18:48:25 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GHmOLN011786 for ; Fri, 16 Feb 2001 18:48:24 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA29545; Fri, 16 Feb 2001 12:48:07 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GSJ>; Fri, 16 Feb 2001 12:42:39 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: grrp-reqs-06, 11. Security Considerations [3] Date: Fri, 16 Feb 2001 12:42:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Eric Brunner-Williams in Portland Maine >[mailto:brunner@nic-naa.net] >Sent: Friday, February 16, 2001 11:36 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se; brunner@nic-naa.net >Subject: Re: grrp-reqs-06, 11. Security Considerations [3] > > >Scott, > >Well I knew it wasn't added at my request as I recall mentioning onward >transport, jurisdictional issues, and data collection at San Diego. > >You make two points: > > 1. a mechanism capable of articulating a policy is not necessary > for session policing (A & I excepted, naturally), as contract > enforcement is available. > > 2. a mechanism capable of articulating data collection policy or > the applicable jurisdiction of the data providor and >collector > would be complex. > >Having finished last November a consortia activity for the >bulk transport >of customer profile data, which presumes the data originates from http >activity policed via P3P, and which looks dead similar to our notion of >social information, I'm convinced neither point is defensible. > >Consider the case of intra-entity social data flows, the >motivation that >brought IBM and HP to CPExchange, which is equivalent to the problem >NSI-as-Registrar and NSI-as-Registry-Operator face. How does >contract law >protect the participants? J-Random-Reseller originates >Registrant-J's data >to NSI-as-Registrar, which onward-transports J's data to >NSI-as-Registry, >and a policy botch is detected. Is the remedy J or >J-Random-Reseller forcing >NSI-as-Registrar to sue NSI-as-Registry for breach or specific >performance? The remedy should be well-defined in whatever legal arrangement exists between the parties involved. >Next, consider the case of inter-entity social data flows, without any >jurisdictional complications (67 RegistRARs and one Registry merrily >playing in CONUS only). No entity may make recourse to transaction- or >session-specific mechanisms to associate policy (other than A >& I, sigh) >with any datum. Everything better look like a nail. > >Finally, the above with jurisdictional complications, Sven >Moers in Berlin >goes to a local reseller who uses Harald Alvestrand's >Oslo-based regional >reseller who uses a UK-based Registrar to access a US-based >Registry. All >hypothetical, but in real life Sven works at the Berlin Data Protection >office. Jurisdiction shopping (the communicating parties have >some sort of >legal arrangement in place) will either be entertaining, or >everything better >look like a Deleware Nail. > >Do you assert that there no requirement for data collection >considerations, >equivalent to your first point? If I made that assertion the current requirement [3] (though I agree that the meaning may not be clear; see below) would not exist, and my offer to create such a section would not have been made. >(as I understand your first point, typing words on someone >else's keyboard >at least as error-prone as typing on myown keyboard) > >If so then there is no reason to look at any mechanism to see >if one or more >offer tractible solutions to an inextant requirement, however >I can't help >but point out that from draft-jaye-http-trust-state-mgt-01.txt >to Section 4 >of the P3P CR draft we managed to express data collection in a >few bytes, >and we've fewer than the old RIP limit on the number of >hops-to-Registry, so >record route is also tractible, and if we look at the set of >meaningfully >distinct statutory or contractual data collection practices, >the range of >usefully unique identifiers hardly motivates OIDs or URIs or other junk >in-band. > >I wouldn't have made the suggestion if I hadn't already >written the dtds, >and morphing the syntax to asn.1 or bnf, or schema is >standards overhead, >not operational overhead. True, but moving policy identification data around _is_ operational overhead, and I'm not convinced that it's necessary overhead in this environment. >Eric > >P.S. Just what exactly does [3] assert as a requirement other >than there > exists a mechanism exists to to distinguish technical from social > information? When I read it I thought "that doesn't say >anything the > cutting room floor doesn't already say -- data that >didn't get into > the zone file". Delete for lack of distinct meaning. The issue I am trying to address is one of privacy WRT what a registry can do with social data. [3] is supposed to assert that the protocol must provide a way to identify specific social data elements that require special handling based on privacy policies. For example, a registry's policy may require publication of a registrant's name via whois or protocol query, but it may allow registrants to opt-out of having other social information (such as address and/or telephone number) published via whois or protocol query. Would this re-wording be more clear: [3] Some of the social information exchanged between a registrar and registry can be considered personal, private, or otherwise restricted from public disclosure. Disclosure of such information MAY be restricted by laws and/or business practices. A generic protocol MUST provide services to identify social information that is subject to disclosure restrictions levied by laws and/or business practices. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GHUGQF011659 for ietf-provreg-outgoing; Fri, 16 Feb 2001 18:30:16 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GHUELN011654 for ; Fri, 16 Feb 2001 18:30:15 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1GHTPC37694; Fri, 16 Feb 2001 12:29:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102161729.f1GHTPC37694@nic-naa.net> To: Dave Crocker cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Tuesday provreg meeting in DC In-Reply-To: Your message of "Fri, 16 Feb 2001 09:02:30 PST." <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> Date: Fri, 16 Feb 2001 12:29:25 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'll be in-hotel early evening, Monday. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GHH9pa011525 for ietf-provreg-outgoing; Fri, 16 Feb 2001 18:17:09 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f1GHH7LN011520 for ; Fri, 16 Feb 2001 18:17:08 +0100 (MET) Received: (qmail 6281 invoked from network); 16 Feb 2001 17:21:07 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 16 Feb 2001 17:21:07 -0000 From: "Paul George" To: Subject: RE: Tuesday provreg meeting in DC Date: Fri, 16 Feb 2001 12:16:48 -0500 Message-ID: <001101c0983c$3f707c10$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yes, I will be there at 9am. Any suggestions as to what we could bring to make this meeting move along?? (Besides a cattle prod :-) ) Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Dave Crocker Sent: Friday, February 16, 2001 12:03 PM To: ietf-provreg@cafax.se Subject: Tuesday provreg meeting in DC Importance: High Since the meeting room will be available from 9am, I'm planning to show up then. Is anybody else similarly inclined, to get discussion going early? d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GHGGt1011505 for ietf-provreg-outgoing; Fri, 16 Feb 2001 18:16:16 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GHGFLN011500 for ; Fri, 16 Feb 2001 18:16:15 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA29378 for ; Fri, 16 Feb 2001 12:16:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GRA>; Fri, 16 Feb 2001 12:10:46 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Tuesday provreg meeting in DC Date: Fri, 16 Feb 2001 12:10:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'll be there, probably at 8 or so make sure it all comes together on time. >-----Original Message----- >From: Dave Crocker [mailto:dcrocker@brandenburg.com] >Sent: Friday, February 16, 2001 12:03 PM >To: ietf-provreg@cafax.se >Subject: Tuesday provreg meeting in DC >Importance: High > > >Since the meeting room will be available from 9am, I'm >planning to show up >then. > >Is anybody else similarly inclined, to get discussion going early? Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GH2RH5011387 for ietf-provreg-outgoing; Fri, 16 Feb 2001 18:02:27 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GH2PLN011382 for ; Fri, 16 Feb 2001 18:02:26 +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 JAA16130 for ; Fri, 16 Feb 2001 09:02:22 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010216090121.02f03ec8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) X-Priority: 2 (High) Date: Fri, 16 Feb 2001 09:02:30 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: Tuesday provreg meeting in DC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Since the meeting room will be available from 9am, I'm planning to show up then. Is anybody else similarly inclined, to get discussion going early? d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GGafLf011187 for ietf-provreg-outgoing; Fri, 16 Feb 2001 17:36:41 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GGadLN011182 for ; Fri, 16 Feb 2001 17:36:40 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1GGZlC37543; Fri, 16 Feb 2001 11:35:47 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102161635.f1GGZlC37543@nic-naa.net> To: "Hollenbeck, Scott" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: grrp-reqs-06, 11. Security Considerations [3] In-Reply-To: Your message of "Fri, 16 Feb 2001 08:51:49 EST." Date: Fri, 16 Feb 2001 11:35:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Well I knew it wasn't added at my request as I recall mentioning onward transport, jurisdictional issues, and data collection at San Diego. You make two points: 1. a mechanism capable of articulating a policy is not necessary for session policing (A & I excepted, naturally), as contract enforcement is available. 2. a mechanism capable of articulating data collection policy or the applicable jurisdiction of the data providor and collector would be complex. Having finished last November a consortia activity for the bulk transport of customer profile data, which presumes the data originates from http activity policed via P3P, and which looks dead similar to our notion of social information, I'm convinced neither point is defensible. Consider the case of intra-entity social data flows, the motivation that brought IBM and HP to CPExchange, which is equivalent to the problem NSI-as-Registrar and NSI-as-Registry-Operator face. How does contract law protect the participants? J-Random-Reseller originates Registrant-J's data to NSI-as-Registrar, which onward-transports J's data to NSI-as-Registry, and a policy botch is detected. Is the remedy J or J-Random-Reseller forcing NSI-as-Registrar to sue NSI-as-Registry for breach or specific performance? Next, consider the case of inter-entity social data flows, without any jurisdictional complications (67 RegistRARs and one Registry merrily playing in CONUS only). No entity may make recourse to transaction- or session-specific mechanisms to associate policy (other than A & I, sigh) with any datum. Everything better look like a nail. Finally, the above with jurisdictional complications, Sven Moers in Berlin goes to a local reseller who uses Harald Alvestrand's Oslo-based regional reseller who uses a UK-based Registrar to access a US-based Registry. All hypothetical, but in real life Sven works at the Berlin Data Protection office. Jurisdiction shopping (the communicating parties have some sort of legal arrangement in place) will either be entertaining, or everything better look like a Deleware Nail. Do you assert that there no requirement for data collection considerations, equivalent to your first point? (as I understand your first point, typing words on someone else's keyboard at least as error-prone as typing on myown keyboard) If so then there is no reason to look at any mechanism to see if one or more offer tractible solutions to an inextant requirement, however I can't help but point out that from draft-jaye-http-trust-state-mgt-01.txt to Section 4 of the P3P CR draft we managed to express data collection in a few bytes, and we've fewer than the old RIP limit on the number of hops-to-Registry, so record route is also tractible, and if we look at the set of meaningfully distinct statutory or contractual data collection practices, the range of usefully unique identifiers hardly motivates OIDs or URIs or other junk in-band. I wouldn't have made the suggestion if I hadn't already written the dtds, and morphing the syntax to asn.1 or bnf, or schema is standards overhead, not operational overhead. Eric P.S. Just what exactly does [3] assert as a requirement other than there exists a mechanism exists to to distinguish technical from social information? When I read it I thought "that doesn't say anything the cutting room floor doesn't already say -- data that didn't get into the zone file". Delete for lack of distinct meaning. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GFbo7j010607 for ietf-provreg-outgoing; Fri, 16 Feb 2001 16:37:50 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GFbnLN010597 for ; Fri, 16 Feb 2001 16:37:49 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA29004; Fri, 16 Feb 2001 10:37:37 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9G31>; Fri, 16 Feb 2001 10:32:09 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Bill Manning'" Cc: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 11. Security Considerations [3] Date: Fri, 16 Feb 2001 10:32:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Bill, Have a read of the definitions section ("Thick Registry" specifically), where it describes "technical information" as "information needed to produce zone files". -----Original Message----- From: Bill Manning [mailto:bmanning@ISI.EDU] Sent: Friday, February 16, 2001 10:27 AM To: shollenbeck@verisign.com Cc: ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 11. Security Considerations [3] % % Eric, % % The intention of requirement 11-[3] isn't to document that "a mechanism % exists to to distinguish technical from social information", it's intended % to note that disclosure of non-technical information may be subject to % restrictions and the protocol needs to provide a way to identify information % that is subject to disclosure restrictions. This was added at the request % of Karl Auerbach. What is the distinction between "technical" and "non-technical"? Are these definitions immutatble within/between juristictions? Will they withstand legal review? In which venues? --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GFQhM1010428 for ietf-provreg-outgoing; Fri, 16 Feb 2001 16:26:43 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GFQgLN010423 for ; Fri, 16 Feb 2001 16:26:42 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1GFQfs27137; Fri, 16 Feb 2001 07:26:41 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f1GFQfH01012; Fri, 16 Feb 2001 07:26:41 -0800 Message-Id: <200102161526.f1GFQfH01012@zed.isi.edu> Subject: Re: grrp-reqs-06, 11. Security Considerations [3] To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Fri, 16 Feb 2001 07:26:41 -0800 (PST) Cc: ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Feb 16, 2001 08:51:49 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % % Eric, % % The intention of requirement 11-[3] isn't to document that "a mechanism % exists to to distinguish technical from social information", it's intended % to note that disclosure of non-technical information may be subject to % restrictions and the protocol needs to provide a way to identify information % that is subject to disclosure restrictions. This was added at the request % of Karl Auerbach. What is the distinction between "technical" and "non-technical"? Are these definitions immutatble within/between juristictions? Will they withstand legal review? In which venues? --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GF4Yxt010210 for ietf-provreg-outgoing; Fri, 16 Feb 2001 16:04:34 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GF4WLN010205 for ; Fri, 16 Feb 2001 16:04:33 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA28853; Fri, 16 Feb 2001 10:04:21 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GM0>; Fri, 16 Feb 2001 09:58:54 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" , ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 9. Internationalization Considerations Date: Fri, 16 Feb 2001 09:58:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, Instead of waiting for the alternative text I requested from you for 9-[1], I've looked into rewriting it completely. How does this strike you?: [1] [RFC1035] restricts the encoding of Internet host and domain names in the DNS to a subset of the 7-bit US-ASCII character set. More recent standards, such as [RFC2130] and [RFC2277], describe the need to develop protocols for an international Internet. These and other standards MUST be considered during the protocol design process to ensure world-wide usability of a generic registry registrar protocol. -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Wednesday, February 14, 2001 11:12 AM To: ietf-provreg@cafax.se Cc: deng@pier.cnnic.net.cn; zwh6810@yahoo.com Subject: grrp-reqs-06, 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. Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a. - 0-9 A-Z a-z We may as well mention ASCII case folding, 1035 has a reasonable Note at the end of 2.3.1 Preferred name syntax. 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. Awkward language, what is it that "which" refers to? The "US-ASCII" restricition, first sentence. If the subordinate clause is phrased as a sentence ... Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for exchanging internationalized information MUST be considered during the protocol design process. Apple pie, but we don't actually state (or cite) what "internationalized" means, yet, and the jump from "host and domain names" (technical data) to social data (a subset of) "internationalized information" is left as an exercise to the reader. We could state: a. The protocol will support any encoding of technical and/or social data, (code-set independent, or csi) or b. The protocol will support some encodings (list) of technical data, and some, possibly different, encodings (list) of social data, (code-set dependent, or csd) or c. The protocol will not support some encodings (list) of technical data, and will not support some, possibly different, encodings (list) of social data, >From Deng Xiang's response we know that UTF8 encodings of technical data is a requirement of a provreg protocol deployed by the .CN ccTLD Registry and Registrars. It is possible that the range of encodings for social data includes GBK and Big5 as well as UTF8. [snip] Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GDwamd025367 for ietf-provreg-outgoing; Fri, 16 Feb 2001 14:58:36 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f1GDwZLN025362 for ; Fri, 16 Feb 2001 14:58:35 +0100 (MET) Received: (qmail 32155 invoked from network); 16 Feb 2001 14:02:48 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 16 Feb 2001 14:02:48 -0000 From: "Paul George" To: Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3] Date: Fri, 16 Feb 2001 08:58:31 -0500 Message-ID: <000801c09820$8c749580$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk It sounds fine to me. Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Hollenbeck, Scott Sent: Friday, February 16, 2001 8:39 AM To: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3] Are there any objections to Andre's proposed re-wording? -----Original Message----- From: Andre Cormier [mailto:Andre.Cormier@viagenie.qc.ca] Sent: Wednesday, February 14, 2001 5:02 PM To: Kent Crispin Cc: ietf-provreg@cafax.se; Eric Brunner-Williams in Portland Maine Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Here's a proposition: Lets change [3] The protocol or another layered protocol MUST provide services to negotiate an identification and authentication mechanism acceptable to both the server and the client. To [3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both the server and the client. [snip] Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GDvPai025351 for ietf-provreg-outgoing; Fri, 16 Feb 2001 14:57:25 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GDvOLN025346 for ; Fri, 16 Feb 2001 14:57:24 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA28656 for ; Fri, 16 Feb 2001 08:57:18 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GLP>; Fri, 16 Feb 2001 08:51:50 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 11. Security Considerations [3] Date: Fri, 16 Feb 2001 08:51:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, The intention of requirement 11-[3] isn't to document that "a mechanism exists to to distinguish technical from social information", it's intended to note that disclosure of non-technical information may be subject to restrictions and the protocol needs to provide a way to identify information that is subject to disclosure restrictions. This was added at the request of Karl Auerbach. I have strong reservations against adding requirements to carry specific policy or jurisdictional identification information because I believe this would add a layer of complexity that we don't need on a per-transaction or per-session basis. For example, data use and data retention are a matter of operational regulatory policy that is enforced by contract in some environments. Perhaps it's not that way in all environments (other opinions, please?), but is it something that needs to be carried around in the protocol when the communicating parties have some sort of legal arrangement in place? I wouldn't object to moving 11-[3] (or a rewording of it) to a new section, though. I just don't want to open a can of worms that will eventually require us to create OIDs or URIs or whatever and associated documentation to describe the policies behind those identifiers. -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Thursday, February 15, 2001 7:51 PM To: shollenbeck@verisign.com Cc: ietf-provreg@cafax.se Subject: grrp-reqs-06, 11. Security Considerations [3] Scott, Elsewhere we've established the division between technical and social information (zone files vs billing files). We can be specific about the minimum necessary data collection and onward-transport policies for technical data. We can be specific about the minimum necessary data collection and onward-transport policies for social data, What your [3] manages is simply to assert a mechanism exists to to distinguish technical from social information. I propose that [3] be removed from Section 11, and a section added with the requirements statements attempted in [3] revised and placed in this new section. 1x. Data Collection Considerations [1] The protocol MUST allow each data transfer to include aggregations of information identifying the parties exchanging data, information about the jurisdiction of each party, and the data collection policies applicable to different pieces of data in the exchange. [2] The protocol MUST allow aggregations of specific policy characteristics that describe how data can be used, how long data can be retained, who may be a recipient of the data, and the data access available to the data's originator. This will allow a "record route" like feature for onward transport after initial information collection, "signed" jurisdictionally and for business practices for technical and social information [1], and This will allow object-specific expression of applicable data collection policies (purpose/recipient/retention/access) [2]. Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1GDiQew025195 for ietf-provreg-outgoing; Fri, 16 Feb 2001 14:44:26 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1GDiOLN025190 for ; Fri, 16 Feb 2001 14:44:25 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA28581 for ; Fri, 16 Feb 2001 08:44:18 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9GK7>; Fri, 16 Feb 2001 08:38:51 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3] Date: Fri, 16 Feb 2001 08:38:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Are there any objections to Andre's proposed re-wording? -----Original Message----- From: Andre Cormier [mailto:Andre.Cormier@viagenie.qc.ca] Sent: Wednesday, February 14, 2001 5:02 PM To: Kent Crispin Cc: ietf-provreg@cafax.se; Eric Brunner-Williams in Portland Maine Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Here's a proposition: Lets change [3] The protocol or another layered protocol MUST provide services to negotiate an identification and authentication mechanism acceptable to both the server and the client. To [3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both the server and the client. [snip] Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1G8LUhx016022 for ietf-provreg-outgoing; Fri, 16 Feb 2001 09:21:30 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.pilsnet.sunet.se [192.36.125.212]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1G8LQLN016017 for ; Fri, 16 Feb 2001 09:21:26 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.12.0.Beta1/8.12.0.Beta1) id f1G8K1rd000803 for ietf-provreg@cafax.se; Fri, 16 Feb 2001 09:20:01 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1FHIXLN007846 for ; Thu, 15 Feb 2001 18:18:34 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f1FHHLX18461; Thu, 15 Feb 2001 12:17:21 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Thu, 15 Feb 2001 12:17:21 -0500 (EST) From: Sheer El-Showk To: Martin Oldfield cc: Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: <14987.58229.871413.628056@joanna.william.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >>>>> "Sheer" == Sheer El-Showk writes a splendid > >>>>> email in which the benefits of assigning each object in the > >>>>> registry its own key are discussed. (I hope that's not too great > >>>>> a misrepresentation.) First Martin, thank you for your very flatteringly phrased summary. I havn't gone over my email since reading your comments and its quite possible I gave the wrong impression in it because we are, in reality, in complete accord. In no way did I envision every registry object having a key associated with it. Rather, the keys belong to real-word individuals or entities and are used to sign registry objects to denote ownership. That is, as a person (not a contact or an SLD holder or whatever), I have a public key which (whether generated by a registrar on my behalf as has been suggested by some, or a personal one) I use to tag a registry entities over which I have authorities (which would be all the contacts assocaited with me as a person, all domains I own, and any nameservers in those domains). When I transfer these entities (actually only domains can be transfered) the registry must propagate the key change itself through all dependent entities (this is much simpler than its sounds -- even in a fat registries Contacts are not attributes of a domain, they are seperate records referenced by domains and their ownership does not change with domain ownership -- the only thing that has to be done is to change the key on the nameservers under that domain). That way the old owner has no ability to affect the domains anymore. Does this cover your concerns or did I misunderstand something you said. Regards, Sheer El-Showk > > I think there are two other disadvantages of this approach when > compared to a scheme in which `contacts' (for want of a better word) > authenticate themselves, and access rights are confered on the basis > of the inter-object relationships. > > 1. Typically the registrant will have a whole bunch of objects in the > database. If each one of these has its own key, then I think most > registrants will get confused. > > 2. Concentrating on the case of a domain being transfered for a > moment, I think giving the domain its own key makes this harder. If > registrant A sells the domain to B, then after the sale A really > shouldn't have access rights. If the access to the domain is > controlled on the basis of its contacts then all well and good; if > its on the basis of a public key then one needs to ensure that all > the key management happens in synchrony. > > Cheers, > -- > Martin Oldfield, > AdamsNames Ltd. > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1G0qJfS012152 for ietf-provreg-outgoing; Fri, 16 Feb 2001 01:52:19 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1G0qILN012147 for ; Fri, 16 Feb 2001 01:52:18 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1G0ocC35244; Thu, 15 Feb 2001 19:50:39 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102160050.f1G0ocC35244@nic-naa.net> To: shollenbeck@verisign.com cc: ietf-provreg@cafax.se Subject: grrp-reqs-06, 11. Security Considerations [3] Date: Thu, 15 Feb 2001 19:50:38 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Elsewhere we've established the division between technical and social information (zone files vs billing files). We can be specific about the minimum necessary data collection and onward-transport policies for technical data. We can be specific about the minimum necessary data collection and onward-transport policies for social data, What your [3] manages is simply to assert a mechanism exists to to distinguish technical from social information. I propose that [3] be removed from Section 11, and a section added with the requirements statements attempted in [3] revised and placed in this new section. 1x. Data Collection Considerations [1] The protocol MUST allow each data transfer to include aggregations of information identifying the parties exchanging data, information about the jurisdiction of each party, and the data collection policies applicable to different pieces of data in the exchange. [2] The protocol MUST allow aggregations of specific policy characteristics that describe how data can be used, how long data can be retained, who may be a recipient of the data, and the data access available to the data's originator. This will allow a "record route" like feature for onward transport after initial information collection, "signed" jurisdictionally and for business practices for technical and social information [1], and This will allow object-specific expression of applicable data collection policies (purpose/recipient/retention/access) [2]. Cheers, Eric Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1FFiBqj003299 for ietf-provreg-outgoing; Thu, 15 Feb 2001 16:44:11 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1FFi8LN003294 for ; Thu, 15 Feb 2001 16:44:09 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id HAA20795 for ietf-provreg@cafax.se; Thu, 15 Feb 2001 07:34:57 -0800 Message-ID: <20010215073457.A20622@songbird.com> Date: Thu, 15 Feb 2001 07:34:57 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Mail-Followup-To: ietf-provreg@cafax.se References: <20010207113210.C27379@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sheer El-Showk on Wed, Feb 14, 2001 at 06:58:02PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk wrote: [discussion of using PKI methods] It's interesting to note that this stuff was disccused for the CORE SRS at great length, in the context of what were called "Zone Keys" - a zone key is a public key associated with a zone that authorizes updates. Here's an informal paper I wrote a couple of years ago. It may contribute something to this discussion: Pros and Cons of NULL Zone Keys This document compares two alternative models for the registrar-registry protocol. The first model is the "Optional Zone Key" (Optional) model. The second is the "Mandatory Zone Key" (Mandatory) model. 1. Common assumptions Both models assume that 1) a domain record in the registry db has a field called "zone key" that contains a cryptographic key that can be used to verify digital signatures. 2) there is a "current registrar" field in the domain record that identifies the registrar currently representing the domain. A database of corresponding registrar keys is kept, so that registrar signatures may be verified. 3) a registrar signature is necessary for any transaction. 4) in addition, if there is a non-NULL key in the "zone key" field, any transaction for that domain *must* have a valid "zone signature". Furthermore, both models have a serious potential for disputes to arise when a user without a zone key wishes to change registrars. 2. Optional Zone Keys In this model a domain record may have a NULL zone key. In such a case, only the registrar signature is checked. If the request is not correctly signed by the registrar identified in the "current registrar" field, the request is ignored. The primary advantage of this model is simplicity. The primary problem with this model is that changing the value of the "current registrar" field cannot be done without either the cooperation of the current registrar, or involving a dispute that goes to the registry. More fundamentally, however, this is really just a manifestation of the fact that the domain owner has *no* mechanical(*) way of proving his identity. (*) A "mechanical" method is something that can be accomplished without involving human beings in the loop. 3. Mandatory Zone Keys In this model, *every* domain record in the registry db is required to have a unique zone key. Every request to modify data for the domain must be signed by that key. Since it is realized that the majority of domain owners do not and will not provide a zone key, and will not sign their requests, in the Mandatory model registrars are required to generate unique private keys for such customers, install such keys as the zone key, send a copy of the key back to the customer, and securely keep a copy for the customer. The primary advantage of this model is that every customer has available to them a mechanical method to change registrars, without involving the old registrar. However, there are several significant problems: 1) there is no simple, secure way to send the generated private key back to a user who doesn't use public key (PK) cryptography. 2) Since, by construction, the users involved are not knowledgable about PK and digital signature, they are unlikely to properly protect and preserve the key sent back to them. 3) Also, these users are unlikely to make use of the opportunity offered to them, since they would have to climb a learning curve to do so. 4) Assuming the user does learn about digital signatures, and wants to change registrars, the old registrar still has the zone key -- the user has to change the zone key, as well. 5) The big one -- every registrar has to *securely* maintain a database of private keys. While this can be largely automated, it adds a great deal of complexity to do so, and opens up other liability issues. 4. Disputes The interesting case is when a user who does not have (or has lost) a zone key wants to change to a different registrar. This is because the simplest way for a user to handle a disagreement with a registrar is to go to another registrar. With the Optional model there are two classes of users: 1) those who knowledgably use digital signatures, and 2) those who do not use digital signatures at all. With Mandatory model there are three classes of users: 1) those who knowledgably use digital signatures, 2) those who don't receive, or simply won't learn to use their private key (some customers may very well elect to not get their private key, since it will have to be sent in the clear if the customer doesn't already have PK technology under command), and 3) those who have received a private key from their registrar, and keep it, don't know how to use it, but could learn if necessary. Note that the description of classes 1 and 2 are essentially the same under both models. Class 1 (knowledgable digital signature users) cause very little problem to either model. I expect the size of class 1 to be slightly larger in the Mandatory model than in the Optional model (because there will be slightly more incentive to learn about digital signatures), but probably not significantly larger. Class 2 users comprise the largest class in either model, though we can expect the Mandatory model to have a significantly lower percentage of class 2 users than the Optional model (the class 3 users have to come from somewhere). It is my belief that, from a policy and dispute resolution point of view, class 2 users are essentially identical in both models. Both models will need to devise a non-mechanical inter-registrar domain transfer protocol for class 2 users, and the existence or non-existence of a zone key is the most trifling of technical details for this protocol. While the policy and dispute resolution procedures will be very similar, there is substantially less incentive for a registrar to try to "lock in" customers under the Mandatory model. This is because a registrar will have to assume that the user has a zone key and can change registrar independently. However, in *any* case the incentive for a registrar to lock in customers will be very low. One of the most widely trumpeted characteristics of the gTLD registries is domain name portability. Any registrar with a pattern of interfering with this property will certainly be in conflict with the gTLD MoU, and such a pattern will quickly be noticed and reported by customers. The consequences would be dire, the reward very small. Class 3 users are unique to the Mandatory model. The problem they present is key management and consulting load. Not only will the registrar have to worry about sending private keys in the clear to their customers (with whatever liability a clever lawyer can make of it), but they will be duty-bound to answer questions about the use of that key. There is also a class of disputes/liabilities involved in maintaining a key ring on behalf of a customer. A compromised key allows modifications to the domain; but there is no way of telling where that modification came from. The thief can send a modification request to any registrar, and it will be accepted without question. So a user who screws up their own domain can claim that the registrar exposed the key, and someone else (a key thief) did the damage. In general, it would be very hard for a registrar to prove that they did *not* expose the keys -- the registrars employees need to sign requests on behalf of their customers who don't use keys, so the security of the key database is always going to be a problem. Consider the anonymous, untraceable damage a disgruntled registrar employee could cause. Of course, in the Optional model a disgruntled registrar employee can cause damage as well, through misuse of the registrar key (which employees will need to access). However, it is *much* easier to change a single registrar key when an employee leaves, than it is to change thousands of zone keys. [Technical note -- this is why you store a registrar ID in a domain record, instead of a registrar KEY...] 5. Summary The issues are complex, unfortunately. I have a significant bias towards the optional model, and I am afraid I may have slanted this document. But, even so, I have to say that I think that scale clearly tips toward the Optional model. The disputes it allows are still largely present in the Mandatory model (though perhaps in somewhat diminished numbers), but it is simpler for the registrars to deal with, and the Mandatory model creates potential for a whole new class of disputes. If you have read this far, let me encourage you to make some comments. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1FEOQE7002448 for ietf-provreg-outgoing; Thu, 15 Feb 2001 15:24:26 +0100 (MET) Received: from joanna.william.org (joanna.william.org [195.153.6.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1FEOOLN002443 for ; Thu, 15 Feb 2001 15:24:25 +0100 (MET) Received: from mjo by joanna.william.org with local (Exim 3.16 #1 (Debian)) id 14TPJW-0005XR-00; Thu, 15 Feb 2001 14:23:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 Feb 2001 14:23:18 +0000 (GMT) To: Sheer El-Showk Cc: ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: References: <20010207113210.C27379@nohope.patoche.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14987.58229.871413.628056@joanna.william.org> From: Martin Oldfield Sender: owner-ietf-provreg@cafax.se Precedence: bulk >>>>> "Sheer" == Sheer El-Showk writes a splendid >>>>> email in which the benefits of assigning each object in the >>>>> registry its own key are discussed. (I hope that's not too great >>>>> a misrepresentation.) I think there are two other disadvantages of this approach when compared to a scheme in which `contacts' (for want of a better word) authenticate themselves, and access rights are confered on the basis of the inter-object relationships. 1. Typically the registrant will have a whole bunch of objects in the database. If each one of these has its own key, then I think most registrants will get confused. 2. Concentrating on the case of a domain being transfered for a moment, I think giving the domain its own key makes this harder. If registrant A sells the domain to B, then after the sale A really shouldn't have access rights. If the access to the domain is controlled on the basis of its contacts then all well and good; if its on the basis of a public key then one needs to ensure that all the key management happens in synchrony. Cheers, -- Martin Oldfield, AdamsNames Ltd. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1FCcOMl001464 for ietf-provreg-outgoing; Thu, 15 Feb 2001 13:38:24 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1FCcNLN001459 for ; Thu, 15 Feb 2001 13:38:23 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA26236; Thu, 15 Feb 2001 13:38:10 +0100 Date: Thu, 15 Feb 2001 13:38:09 +0100 From: Patrick To: Sheer El-Showk Cc: ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <20010215133809.J24060@nohope.patoche.org> References: <20010207113210.C27379@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sheer@saraf.com on Wed, Feb 14, 2001 at 06:58:02PM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk took time to write: > > I do not understand why here we try to let the registrant do things > > wirthout going through a Registrar. Why make the registration of > > nameserver a different case ? > > > > The same problem exist in other part : like for contacts in the thick > > registry. How do you handle them ? Someone register a contact through > > a given Registrar. To help avoid the actual handle problems (each > > different for a Registrar), they should be unique. Who can change > > them ? Through wich Registrar ? > > > Well, what I had mentioned, and what I think would be a good idea if we > could find a system that would withstand registrant carelessnes (I'll It is even more than a good idea : it is _mandatory_ in my eyes. Other than that someone (the registry ? every registrar ?) will have to support users and answer their request, when they forget their password/PGP key/whatever, etc... And that happens, a _lot_. If a Registrant can do modifications through any Registrar, the burden of support is on everyone involved (all Registrars). It might be quite a lot of work. And Registrars will not see benefit to do it, since someone can use a Registrar to make its modifications, which will not mean that the Registrar will earn money with this. That is, each Registrar will need to give few basic free services, not only to their customers, but to anyone having registered a domain, even with another Registrar. > The problem with this is registrant carelessness. Not that many people > use PGP, and its not generally a very good idea to depend on non-technical > people to safegaurd their data well (not that technical people are good at > it, but at least they know when its important). There would conceivably > be a lot of cases of registrants losing floppies or hard disks with the > only copy of their private key and hence losing their "proof of > ownership" of their domains. Exactly. Even more Registrants will forget their passphrase. Or they will use bad methods to protect their key, and it will be stolen, and such... If we go that route, things like that _must_ be taken into account at the beginning. > There is a second, and in my opinion, extremely important justification of > this passthrough key system. Registrar's aren't necassarily very good at > maintaining their data integrity, and, as business, are apt to go belly-up > every once in a while. This leaves the registry with a lot of domains but That is true. That is why the ICANN contract for .com/.net/.org Registrars mentions that. Each registrar must take care of this, so that its domains are going to another registrar in case of bankruptcy or such, without noticeable change for the Registrants. But that leads to a question. I register a domain with Registrar A. Then I decide to change the owner of the domain, by doing so through Registrar B which will authentify me with my PGP key or such. How are modifications going back to Registrar A in case of a thin Registry ? Same thing for change of contacts, nameservers, etc... Does that mean that Registrars will need to share a common database ? In that case I think it is more like a thick Registry. Or will each Registrar have complete read/write access to other Registrar databases ? > without any idea of user ownership (in the thin registry model > anyway) which is a Very Bad Thing (tm). So, it would be nice if Yes. Same thing, Registrar must be able to give all details to the Registry. Date have to be stored securely with frequent backups. > registrants could carry around some kind of uncompromisable proof of > ownership of a domain. Yes, but the problem lies down to : whatever proof you have (PGP key, certificate, etc...), two things can happen : - you can forget/destroy it - someone can steal it from you. The business in which you need this proof must take into account this events and provide mecanisms to correct the situation. Like I said, not an easy task. Patrick. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1F9Tvjd000346 for ietf-provreg-outgoing; Thu, 15 Feb 2001 10:29:57 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1F9TlLN000341 for ; Thu, 15 Feb 2001 10:29:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1F9SU9L000869 for ietf-provreg@cafax.se; Thu, 15 Feb 2001 10:28:30 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1ENwhLN026533 for ; Thu, 15 Feb 2001 00:58:43 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f1ENw2Y14220; Wed, 14 Feb 2001 18:58:07 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Wed, 14 Feb 2001 18:58:02 -0500 (EST) From: Sheer El-Showk To: Patrick cc: "Brian W. Spolarich" , James Seng/Personal , Kent Crispin , ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: <20010207113210.C27379@nohope.patoche.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Patrick, Sorry if this is a forgotten topic and for taking so long to get back to it. I'm playing catchup on the list right now so I'd rather respond as soon as I see a question directed to one of my posts. > I do not understand why here we try to let the registrant do things > wirthout going through a Registrar. Why make the registration of > nameserver a different case ? > > The same problem exist in other part : like for contacts in the thick > registry. How do you handle them ? Someone register a contact through > a given Registrar. To help avoid the actual handle problems (each > different for a Registrar), they should be unique. Who can change > them ? Through wich Registrar ? Well, what I had mentioned, and what I think would be a good idea if we could find a system that would withstand registrant carelessnes (I'll elaborate on this in a second) is to have any entity in the registry tagged via some public-private key mechanism. This way you could always direclty establish who owns it (without the hassle of "out-of-band" authentication like physical address, email address, etc... none of which can be practically implemented on any really scale). For contacts the owner (the key used to tag the data) should very obviusly be the person the contact represents; for nameservers the owner should be the owner of the appropriate domain; for domains the owner should be whoever registered it (or had it transfered to them). This way as a Registrant I can go to a registrar and create a domain which gets tagged with my public key. Then, I could go to another registrar and create a nameserver in that previous domain. The backend registry lets me do this (even thuogh its through another registrar, and even if its a thin-registry that doens't track the domain SLD Holder or whatever) because I can own the private key associated with that domains public key so it knows I'm the valid domain owner and have the right to add a nameserver to this domain. Of course this makes life difficult for registries since they can no longer assume they are the sole source of nameserver registerations for their domains, but that just means they have to redefine their function. The problem with this is registrant carelessness. Not that many people use PGP, and its not generally a very good idea to depend on non-technical people to safegaurd their data well (not that technical people are good at it, but at least they know when its important). There would conceivably be a lot of cases of registrants losing floppies or hard disks with the only copy of their private key and hence losing their "proof of ownership" of their domains. There is a second, and in my opinion, extremely important justification of this passthrough key system. Registrar's aren't necassarily very good at maintaining their data integrity, and, as business, are apt to go belly-up every once in a while. This leaves the registry with a lot of domains but without any idea of user ownership (in the thin registry model anyway) which is a Very Bad Thing (tm). So, it would be nice if registrants could carry around some kind of uncompromisable proof of ownership of a domain. > Other than that I really welcome a global setup where registrant > could make changes directly, without going through a Registrar, or > using whatever Registrar they want. But if you go that route, you must > consider all cases (change of ownership, change of contacts, change > of Registar, change of nameservers, etc...). > It seems to me a difficult case, but really interesting. > > However going that way can really fast lead to this question : what > purpose has the Registrar if a Registrant can do anything he wants > directly to the Registry without using a Registrar ? Or by choosing > any Registrar to do modifications by himself. > > Would RRP (or its successor) be also a RegisTRANT-RegisTRY protocol ? Registrars are, as I see them (especially in the fat registry model) service companies that proxy for domain registration and make domain management easier. They help the registry by giving it a few controllable sources of data access (ie only registrar's can directly access a registry) and they help the customers by making registration easy and managable (remember NSI a few years ago and the horror involved in not having some of the nicer registration interfaces we have today). The nice thing about my suggested key system is it allows this registrar interface to exist, but none-the-less authoritatively tracks domain ownership to an individual. Regards, Sheer Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1F98iP5000159 for ietf-provreg-outgoing; Thu, 15 Feb 2001 10:08:44 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1F973LN000152 for ; Thu, 15 Feb 2001 10:07:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f1F95kW5000615 for ietf-provreg@cafax.se; Thu, 15 Feb 2001 10:05:46 +0100 (MET) Received: from web5503.mail.yahoo.com (web5503.mail.yahoo.com [216.115.106.186]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f1E6tELN019095 for ; Wed, 14 Feb 2001 07:55:15 +0100 (MET) Message-ID: <20010214065513.3015.qmail@web5503.mail.yahoo.com> Received: from [159.226.6.26] by web5503.mail.yahoo.com; Tue, 13 Feb 2001 22:55:13 PST Date: Tue, 13 Feb 2001 22:55:13 -0800 (PST) From: wenhui zhang Subject: Re: [idn] FYI: CNNIC services GBK, Big5, and UTF8 encodings To: Eric Brunner-Williams in Portland Maine , ietf-idna@mail.apps.ietf.org, ietf-provreg@cafax.se Cc: idn@ops.ietf.org, duerst@w3.org, misha.wolf@reuters.com, cnnic-staff@cnnic.net.cn In-Reply-To: <200102101650.f1AGo3C10711@nic-naa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello The resolver of Chinese Domain Name System(CDNS), as a part of CDNS which CNNIC provides, is just like the resolver of Netscape browser that does not change the encoding of user's local requires and send the original requirement to a code-switcher. The code switcher can transfer local encoding to UTF-8 and vice versa. Any local encoding query before it enter to name server is changed to UTF8-based encoding query. The name server can handle UTF8-based encoding query.The ACE-based domain name will not be changed and its processes is just as former. Using this mechanism, no matter what kind of native encoding set, the multilingual domain name system will work correctly. Yours regards deng xiang 2001.2 --- Eric Brunner-Williams in Portland Maine wrote: > [Please trim the cc if replying!] > > Announced Monday, February 5th, at the following > URL: > > http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html > > My understanding is that CNNIC does or will provide > a resolver which has > support for these three encodings within the .cn > ccTLD, > defaults (like AOL keywords) any FQDN to FQDN.cn, > supports these three encodings within the the DNS > root, at least > for some set of iso3166 labels, e.g., cn, and > possibly tw > and probably does more than the peopledaily writer > describes. > > These aren't ASCII Compatible Extension (ACE) > encoding mechanisms, and differ > from the iDNS/NSI mechanism deployment of last > November, which is ACE-based. > > For those familiar with either GBK or Big5, feel > free to ignore the next > two paras. > > For those unfamiliar with the GB series, GBK is the > MS Windows PRC version > (K == kuozhan "extension"), see also GB 1390.1-93 > and GB 2312-80, and for > the EUC-centric (me, other Unix i18n weenies), > overlaps EUC-CN, and encodes > the Chinese subset of ISO 10646-1:1993. > > For those unfamiliar with Big5, it is the de facto > standard in Taiwan (Mac > and Windows) and is equivalent to the first two > planes of CNS 11643-1992, > and for the EUC-centric, differs from EUC-TW code > sets 0 and 1 mainly in > having an additional encoding block. > > The CNNIC's approach appears to be at odds with a > recent IDN WG I-D [1], > which observed: > > > Note also that because modern OS are Unicode based > and have network- > > downloadable IMEs, "interoperability" is becoming > less equivalent to > > "use BIG5 characters only" or "use GB2312 > character only" or "use > > Shift-JIS characters only". > > What appears to be the case is CNNIC is offering > network-downloadable > code-set-specific resolvers, independent of (native) > Unicode deployment > in OS products and input method extension delivery > mechanisms. > > Incidently, the January edition of the CNNIC > semiannual data is available. > Semiannual Survey Report on the Development of > China's Internet (Jan. 2001) > http://www.cnnic.cn/develst/e-cnnic200101.shtml > > Corrections and additional comments welcome, Maine > is a ways from Beijing. > > Eric > > [1] "Han Ideograph (CJK) for Internationalized > Domain Names", Seng et al., > > http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EMTRWJ026023 for ietf-provreg-outgoing; Wed, 14 Feb 2001 23:29:27 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EMTFLN026018 for ; Wed, 14 Feb 2001 23:29:26 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1EMRjC10069; Wed, 14 Feb 2001 17:27:45 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102142227.f1EMRjC10069@nic-naa.net> To: "Jordyn A. Buchanan" cc: Eric Brunner-Williams in Portland Maine , shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca, ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] In-Reply-To: Your message of "Wed, 14 Feb 2001 15:32:00 EST." <5.0.2.1.0.20010214150906.03000160@mail.register.com> Date: Wed, 14 Feb 2001 17:27:45 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jordyn, Kent, Thanks to both of you for reading my reply. There are two "big" issues, whether there is negociation (as originally proposed by Andre), and whether I & A exhaust the policies for which we have a requirement for in-band policing of subsequent data flows. What concerns me about negociation is existence. Unless a suitable wand is waved a simple request/reply rpc-like semantic becomes "full featured". There are lots of wands, I'm partial to a few, but none are in grrp-reqs-06. The second point is more nuanced. I-check and A-check are policy requirements, and we firmly believe that mechanisms exist (modulo a scaling comment by another commentor). Now we're ready to open the flood-gates and pour data registry-ward ... but ... _if_ P-check is possible, and since it is a real requirement (at least as real as the EC's data protection regime), then we haven't finished with required and feasible end-point property determination prior to data transmission. > - Name server objects may be subject to substantially different privacy > restrictions than contact objects. Technical data ends up in a zone file, social data doesn't. Further, depending on thick vs thin, social data delivery semantics differ from those of technical data. > DNS data probably needs to be generally > world-readable, whereas I can certainly think of circumstances in which > names, address and phone numbers should be generally not world-readable. We're not discussing whois publication, only the intra-R-* policied transport of data. One reason why we should be careful about the rrp==whois assumption many share. > - A country may pass a law along the lines of "no one may publish phone > numbers of any citizen of our country". Presumably, phone numbers of > citizens of other countries can be published, so restrictions on > publication vary based on the data. Actually you may be interested in reverse and multi-criteria directories, the subject of an EC DP WG publication, as it is germane to provreg. But, in the example I provided, the _end-point_ policy is to publish all data collected, w/o reference to the various policies for each originators' item of data. I'm sorry if I didn't make that sufficiently clear. > Even if you're right and I'm wrong, this affects only my assertion that we > solve this through extensions of object descriptions. We can solve the > problem through the addition of commands later. Thanks for humoring me thus far. Can we solve the problem (of I & A) through subsequent additional mechanism? > I agree they exist, but my point is that these policies are likely to be > announced and negotiated out-of-band on a contractual or regulatory > basis. The P3P profile (subset produced with a hatchet) for (dns) technical data isn't complicated. The one for social data should be no more difficult than the one the CPExchange group developed for the onward-transport of customer data, or for P3P for very dull web pages. > Additionally, they are unlikely to change with regularity, so > there's no need for dynamic negotiation to occur. I never sought dynamic negotiation of data collection, just an announcement and consistent semantics requirement. However, now that you mention it, had Gore won the US would have transitioned from "opt-out" to "opt-in" in the current Congress, at least that was what all the smart marketers reckoned. Eric (ex-Engage) Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EM5q0J025566 for ietf-provreg-outgoing; Wed, 14 Feb 2001 23:05:52 +0100 (MET) Received: from rock.viagenie.qc.ca (rock.viagenie.qc.ca [206.123.31.139]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EM5pLN025561 for ; Wed, 14 Feb 2001 23:05:51 +0100 (MET) Received: from viagenie.qc.ca (localhost [127.0.0.1]) by rock.viagenie.qc.ca (8.11.1/8.11.1) with ESMTP id f1EM2ME01476; Wed, 14 Feb 2001 17:02:22 -0500 (EST) (envelope-from Andre.Cormier@viagenie.qc.ca) Message-ID: <3A8B006D.D6E7392B@viagenie.qc.ca> Date: Wed, 14 Feb 2001 17:02:21 -0500 From: Andre Cormier X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Crispin CC: ietf-provreg@cafax.se, Eric Brunner-Williams in Portland Maine Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] References: <5.0.2.1.0.20010214120909.0454aff8@mail.register.com> <200102141905.f1EJ5eC09458@nic-naa.net> <20010214125105.F7523@songbird.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here's a proposition: Lets change [3] The protocol or another layered protocol MUST provide services to negotiate an identification and authentication mechanism acceptable to both the server and the client. To [3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both the server and the client. This was more like my original idea. I had no intention of negotiating identification at this point or any policies. I only wanted to make sure that the protocol will be able handle more than one authentication/security mecanism (like SASL defines). This will ensure that those who needs privacy(TLS) and strong authentication(Certificates) will be able to get it and those who needs just plain text authentication will be able to get it too (as scary as it sounds ;-) ). SASL is very easy to implement and offer the greatest flexibility for security. So, it has nothing to do with the content, just the session. Identification can be added as an other object or wathever means that fit. André Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1ELJSTc025261 for ietf-provreg-outgoing; Wed, 14 Feb 2001 22:19:28 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1ELJQLN025252 for ; Wed, 14 Feb 2001 22:19:26 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id NAA09867 for ietf-provreg@cafax.se; Wed, 14 Feb 2001 13:10:20 -0800 Message-ID: <20010214131020.G7523@songbird.com> Date: Wed, 14 Feb 2001 13:10:20 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Mail-Followup-To: ietf-provreg@cafax.se References: <200102141905.f1EJ5eC09458@nic-naa.net> <5.0.2.1.0.20010214150906.03000160@mail.register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <5.0.2.1.0.20010214150906.03000160@mail.register.com>; from Jordyn A. Buchanan on Wed, Feb 14, 2001 at 03:32:00PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Feb 14, 2001 at 03:32:00PM -0500, Jordyn A. Buchanan wrote: [...] > I'm > prepared to acknowledge that we're not dealing with the full scope of data > policy elements, but I don't think that means we should give up on solving > the problems that we can or hastily adopting a transport mechanism that may > or may not be well suited for the protocol we develop. I'm not sure that there is any conflict here. >>Note these data collection policies are not specific to any particular datum >>(or object) within a flow between R-* entities, any more than are the A & I >>policies. > > Yes they are. A couple of examples: [examples] Granted, but I don't think this is a major point. >>How the data policies are implemented is (implementation specific). How they >>are announced, let alone "negociated" is a protocol requirement, assuming that >>policy differences do in fact exist. I think they do. > > I agree they exist, but my point is that these policies are likely to be > announced and negotiated out-of-band on a contractual or regulatory > basis. Additionally, they are unlikely to change with regularity, so > there's no need for dynamic negotiation to occur. I don't read Eric's statement above as a contradiction to that point. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EL0Lxc025138 for ietf-provreg-outgoing; Wed, 14 Feb 2001 22:00:21 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EL0HLN025133 for ; Wed, 14 Feb 2001 22:00:19 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id MAA09631 for ietf-provreg@cafax.se; Wed, 14 Feb 2001 12:51:06 -0800 Message-ID: <20010214125105.F7523@songbird.com> Date: Wed, 14 Feb 2001 12:51:05 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Mail-Followup-To: ietf-provreg@cafax.se References: <5.0.2.1.0.20010214120909.0454aff8@mail.register.com> <200102141905.f1EJ5eC09458@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200102141905.f1EJ5eC09458@nic-naa.net>; from Eric Brunner-Williams in Portland Maine on Wed, Feb 14, 2001 at 02:05:39PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Feb 14, 2001 at 02:05:39PM -0500, Eric Brunner-Williams in Portland Maine wrote: >> My guess is that many elements of data policy that you are describing will >> be implemented by the registry or registrar outside of the context of this >> protocol. > > Jordyn, > > Assume that R-* entity [i] has data collection policy A. > Assume that R-* entity [j] has data collection policy B. > > Assume also that R-* entity [i] and R-* entity [j] identify and authenticate > each other. > > May they exchange Registrant technical data? > May they exchange Registrant social data? [...] >How the data policies are implemented is (implementation specific). How they >are announced, let alone "negociated" is a protocol requirement, assuming that >policy differences do in fact exist. I think they do. In virtually all cases we can expect that policies will largely be expressed in legal documents drawn between the R-* parties. It is hard for me to imagine that we can design a protocol with sufficient power to convey any significant policy, other than identification of the particular policy. Identification of the policy in force for a particular record could be a text string identifying a contract, or some other repository of policy information. I believe that I am agreeing with both of the above posters :-) In a multiple registry environment, a single registrar could deal with multiple registries, and thus have to deal with multiple policies simultaneoulsy. This seems to indicate that registrars would in the long run tend to a least common denominator of access, because keeping track of multiple policies would be too complex. As is commonly the case in such a situation, we might expect standardization of policy terms. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EKYqwZ024962 for ietf-provreg-outgoing; Wed, 14 Feb 2001 21:34:52 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EKYpLN024957 for ; Wed, 14 Feb 2001 21:34:51 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail1 with esmtp (Exim 3.16 #2) id 14T8ck-0001P5-00; Wed, 14 Feb 2001 15:34:03 -0500 Message-Id: <5.0.2.1.0.20010214150906.03000160@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Feb 2001 15:32:00 -0500 To: Eric Brunner-Williams in Portland Maine From: "Jordyn A. Buchanan" Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Cc: Eric Brunner-Williams in Portland Maine , shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca, ietf-provreg@cafax.se, brunner@nic-naa.net In-Reply-To: <200102141905.f1EJ5eC09458@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 02:05 PM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote: >This effects "repurposing", "redistribution" or "publication", a term I can't >think of (though I know of a registry operator which claimed it had a right >to indefinite registry data retention, independent of any operational status), >and introduces inconsistent cache semantics (Registrant's write-access through >a series of R-* "caches" to a Registry). This example is worse than using the >(current) data collection statutory regime in the US for data originating in >the EC, but non-negligible differences exist, and most of the root delegations >follow the principle of political geography and delegated jurisdiction. I'm not disputing that there are differences in data policy across jurisdictions, between different registries, registrars, etc. I just don't see the need to try to accommodate the negotiation of the differences within the protocol. In your example, [i] can write [j] a letter and tell them their data policy, and vice versa. Often, the decision of whose policies will be "obeyed" by the various parties is a matter of legal or policy judgement, not a rules-based calculation of the appropriate policy based on characteristics communicated through a technical protocol. I agree with the original point you made--this group is not prepared to deal with these issues. I don't think that implies that we can't try to negotiating authentication and/or identification mechanisms, however. I'm prepared to acknowledge that we're not dealing with the full scope of data policy elements, but I don't think that means we should give up on solving the problems that we can or hastily adopting a transport mechanism that may or may not be well suited for the protocol we develop. >Note these data collection policies are not specific to any particular datum >(or object) within a flow between R-* entities, any more than are the A & I >policies. Yes they are. A couple of examples: - Name server objects may be subject to substantially different privacy restrictions than contact objects. DNS data probably needs to be generally world-readable, whereas I can certainly think of circumstances in which names, address and phone numbers should be generally not world-readable. - A country may pass a law along the lines of "no one may publish phone numbers of any citizen of our country". Presumably, phone numbers of citizens of other countries can be published, so restrictions on publication vary based on the data. Even if you're right and I'm wrong, this affects only my assertion that we solve this through extensions of object descriptions. We can solve the problem through the addition of commands later. >How the data policies are implemented is (implementation specific). How they >are announced, let alone "negociated" is a protocol requirement, assuming that >policy differences do in fact exist. I think they do. I agree they exist, but my point is that these policies are likely to be announced and negotiated out-of-band on a contractual or regulatory basis. Additionally, they are unlikely to change with regularity, so there's no need for dynamic negotiation to occur. Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EJ9URa024313 for ietf-provreg-outgoing; Wed, 14 Feb 2001 20:09:30 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EJ9RLN024308 for ; Wed, 14 Feb 2001 20:09:28 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1EJ5eC09458; Wed, 14 Feb 2001 14:05:40 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102141905.f1EJ5eC09458@nic-naa.net> To: "Jordyn A. Buchanan" cc: Eric Brunner-Williams in Portland Maine , shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca, ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] In-Reply-To: Your message of "Wed, 14 Feb 2001 12:33:13 EST." <5.0.2.1.0.20010214120909.0454aff8@mail.register.com> Date: Wed, 14 Feb 2001 14:05:39 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > My guess is that many elements of data policy that you are describing will > be implemented by the registry or registrar outside of the context of this > protocol. Jordyn, Assume that R-* entity [i] has data collection policy A. Assume that R-* entity [j] has data collection policy B. Assume also that R-* entity [i] and R-* entity [j] identify and authenticate each other. May they exchange Registrant technical data? May they exchange Registrant social data? To clairify (I hope), assume that R-* entity [i]'s data collection policy is: purpose is "current" data may be used by the service provider to complete the activity for which it was provided (registration), recipient is "ours" ourselves and/or our entities acting as our agents or entities for whom we are acting as an agent, retention is "stated-purpose" data is retained to meet the stated purpose for which it was provided (registration), discard earliest possible, and access is "all" all data may be subsequently modified by the originator (registrant modification, mentioned by paf) and assume that R-* entity [j]'s data collection policy is: purpose is "current" (above) and "telemarketing" data may be used to contact the individual via a voice telephone call for promotion of a product or service, recipient is "ours" (above) and "unrelated" or "public" legal entities whose data usage practices are not known by the original service provider, or bulletin boards, public directories, or commercial CD-ROM directories retention is "stated-purpose" (above) and "indefinitely" (obvious) and access is "none" (obvious) Assuming that [i] is "downstream" of [j] (in the no-reseller case, [i] is the RegistRAR and [j] is the RegisTRY: This effects "repurposing", "redistribution" or "publication", a term I can't think of (though I know of a registry operator which claimed it had a right to indefinite registry data retention, independent of any operational status), and introduces inconsistent cache semantics (Registrant's write-access through a series of R-* "caches" to a Registry). This example is worse than using the (current) data collection statutory regime in the US for data originating in the EC, but non-negligible differences exist, and most of the root delegations follow the principle of political geography and delegated jurisdiction. Note these data collection policies are not specific to any particular datum (or object) within a flow between R-* entities, any more than are the A & I policies. How the data policies are implemented is (implementation specific). How they are announced, let alone "negociated" is a protocol requirement, assuming that policy differences do in fact exist. I think they do. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EHaOIJ023508 for ietf-provreg-outgoing; Wed, 14 Feb 2001 18:36:24 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EHaNLN023503 for ; Wed, 14 Feb 2001 18:36:23 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail2 with esmtp (Exim 3.16 #2) id 14T5po-0002mY-00; Wed, 14 Feb 2001 12:35:21 -0500 Message-Id: <5.0.2.1.0.20010214120909.0454aff8@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Feb 2001 12:33:13 -0500 To: Eric Brunner-Williams in Portland Maine , shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca From: "Jordyn A. Buchanan" Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Cc: ietf-provreg@cafax.se, brunner@nic-naa.net In-Reply-To: <200102141655.f1EGt6C09101@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:55 AM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote: >Andre, > > >> Absent BEEP, this requirement places upon the provreg design group the > >> participant policy negociation problem. > >To my knowledge this is not a big problem since SASL describes how to do > >this and BEEP is using it. SASL = RFC 2222 > >My concern is that BEEP isn't in grrp-reqs-06, and without it (or equivalent) >provreg needs at least one participant policier negociation mechanism. I'm >quite happy with BEEP in grrp-reqs-06, but until it is I'm concerned about >the consequences of "MUST provide services to negotiate". Since we haven't seen what our protocol looks like, I think it's premature to say whether or not BEEP is a good way to transport it. I'm guessing that BEEP adds way too much overhead to be practical for high volume registries. I'm willing to concede that it's too early to say that BEEP is not appropriate, but I'd be opposed to putting BEEP into the requirements. > > I do not see a problem with this requirement. If we don't have > >a negociation mecanism, we are bound to change the protocol if we wish > >to change the authentication method. > >And identification method, and anything else which participants use to >policy data flows, e.g., data collection practices or any other policy >possibly arising from political geography or generica or R-* practical >considerations falls into the WHAT box of "MUST provide services to >negotiate [WHAT]". > >I'm concerned that Identification and Authentication do not exhaust the >criteria for provreg participants to policy data flows. I think the concern expressed above is valid, but do we really have to worry about a generic mechanism to negotiate these things? Given the general extensibility that we envision for the protocol, adding commands or extending objects to establish the appropriate policy set can be accomplished at a later time. My guess is that many elements of data policy that you are describing will be implemented by the registry or registrar outside of the context of this protocol. Jordyn Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EHYbQQ023491 for ietf-provreg-outgoing; Wed, 14 Feb 2001 18:34:37 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EHYaLN023484 for ; Wed, 14 Feb 2001 18:34:36 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA23450 for ; Wed, 14 Feb 2001 12:34:35 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9FD0>; Wed, 14 Feb 2001 12:29:11 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: grrp-reqs-06, 9. Internationalization Considerations Date: Wed, 14 Feb 2001 12:29:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, Meta-comment: I've not cited references to specific technical specifications anywhere in the requirements document because they describe _how_ the protocol must address particular issues. One going-in assumption behind the requirements is that any mention of how to address an issue would be left to the protocol specifications. There has been a consistent effort to remove indirect references to such specifications (such as the one alluded to in 3.4-[8] (which will be removed from the next version of the draft), or for IPv4, or IPv6, etc.), so I don't believe it proper to introduce new technical references in other sections. Other comments noted below, preceded with [SAH]. -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Wednesday, February 14, 2001 11:12 AM To: ietf-provreg@cafax.se Cc: deng@pier.cnnic.net.cn; zwh6810@yahoo.com Subject: grrp-reqs-06, 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. Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a. - 0-9 A-Z a-z We may as well mention ASCII case folding, 1035 has a reasonable Note at the end of 2.3.1 Preferred name syntax. [SAH] OK, I'll add this reference because it helps describe the bounds of the internationalization problem and it isn't a specific "solution" reference. 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. Awkward language, what is it that "which" refers to? The "US-ASCII" restricition, first sentence. If the subordinate clause is phrased as a sentence ... [SAH] Alternative text, please. Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for exchanging internationalized information MUST be considered during the protocol design process. Apple pie, but we don't actually state (or cite) what "internationalized" means, yet, and the jump from "host and domain names" (technical data) to social data (a subset of) "internationalized information" is left as an exercise to the reader. We could state: a. The protocol will support any encoding of technical and/or social data, (code-set independent, or csi) or b. The protocol will support some encodings (list) of technical data, and some, possibly different, encodings (list) of social data, (code-set dependent, or csd) or c. The protocol will not support some encodings (list) of technical data, and will not support some, possibly different, encodings (list) of social data, >From Deng Xiang's response we know that UTF8 encodings of technical data is a requirement of a provreg protocol deployed by the .CN ccTLD Registry and Registrars. It is possible that the range of encodings for social data includes GBK and Big5 as well as UTF8. [SAH] I don't think we should describe any particular solution to the i18n problem in this document. The current wording is deliberately vague WRT a solution so that the solution is left to the protocol designers. [2] The protocol MUST allow exchange of meta-data associated with objects in formats consistent with current internationalized character encoding and language representation standards. I honestly don't know what this means. If it means code-set identifiers or locale identifiers or something else, we should be more specific (and useful) about "metadata". Every time I hear that word I reach for my RDF. [SAH] I forget who suggested this requirement, it appears redundant after reading the last sentence in [1]. Would it be OK to strike it? [3] All date and time values specified in a generic registry-registrar protocol MUST be expressed in Universal Coordinated Time. Dates and times MUST include information to represent a four-digit calendar year, a calendar month, a calendar day, hours, minutes, seconds, fractional seconds, and the time zone for Universal Coordinated Time. I suggest we cite iso8601 and pick a specific format, b (UCT, above). I do see a problem however with any "user and/or accounting package friendly" temporal identifier (and we do use time, Scott is going to add a temporal identifer sufficient to support ordering in addition to what is in -06 at the moment). The problem is that objects have temporal properties, and these properties are passed around as operands and as identifiers in a common representation (good) but with no common synchronization mechanism (bad). Anyone for NTP (not for sorting out nano-payments) as a specific requirement for temporal consistency? How about putting an upper bound on clock deltas between provreg entities? I claim it is Feb. 14, 1901. Another possibility is seperating "meta- or technical time" from "social time". The first provreg uses, NTP-esque, the second is in provreg messages. [SAH] I'd prefer to not cite a specific technical reference for reasons noted above. I would _really_ like to avoid requiring a method of temporal synchronization in the protocol because it adds another layer of complexity that be better handled by another protocol or another protocol layer. I agree, though, that temporal synchronization can be an issue if client and server have to make independent time-based decisions that require consistency and wouldn't object to adding a requirement that says something like this (perhaps to section 8.2?): [n] Protocol clients and servers MUST maintain a consistent understanding of the current date and time to effectively manage objects with temporal properties. [snip] Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EGuiYA023180 for ietf-provreg-outgoing; Wed, 14 Feb 2001 17:56:44 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EGubLN023175 for ; Wed, 14 Feb 2001 17:56:42 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1EGt6C09101; Wed, 14 Feb 2001 11:55:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102141655.f1EGt6C09101@nic-naa.net> To: shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Date: Wed, 14 Feb 2001 11:55:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Andre, >> Absent BEEP, this requirement places upon the provreg design group the >> participant policy negociation problem. >To my knowledge this is not a big problem since SASL describes how to do >this and BEEP is using it. SASL = RFC 2222 My concern is that BEEP isn't in grrp-reqs-06, and without it (or equivalent) provreg needs at least one participant policier negociation mechanism. I'm quite happy with BEEP in grrp-reqs-06, but until it is I'm concerned about the consequences of "MUST provide services to negotiate". >As i understand it this is for Registrars authentication to the >registry. Symmetric, or rather participant indifferent, in -07. > I do not see a problem with this requirement. If we don't have >a negociation mecanism, we are bound to change the protocol if we wish >to change the authentication method. And identification method, and anything else which participants use to policy data flows, e.g., data collection practices or any other policy possibly arising from political geography or generica or R-* practical considerations falls into the WHAT box of "MUST provide services to negotiate [WHAT]". I'm concerned that Identification and Authentication do not exhaust the criteria for provreg participants to policy data flows. Cheers, Eric Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1EGCnHD022829 for ietf-provreg-outgoing; Wed, 14 Feb 2001 17:12:49 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1EGCjLN022824 for ; Wed, 14 Feb 2001 17:12:46 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1EGBaC08954; Wed, 14 Feb 2001 11:11:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102141611.f1EGBaC08954@nic-naa.net> To: ietf-provreg@cafax.se cc: deng@pier.cnnic.net.cn, zwh6810@yahoo.com Subject: grrp-reqs-06, 9. Internationalization Considerations Date: Wed, 14 Feb 2001 11:11:36 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk [1] Current Internet standards restrict the encoding of Internet host and domain names to a subset of the 7-bit US-ASCII character set. Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a. - 0-9 A-Z a-z We may as well mention ASCII case folding, 1035 has a reasonable Note at the end of 2.3.1 Preferred name syntax. 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. Awkward language, what is it that "which" refers to? The "US-ASCII" restricition, first sentence. If the subordinate clause is phrased as a sentence ... Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for exchanging internationalized information MUST be considered during the protocol design process. Apple pie, but we don't actually state (or cite) what "internationalized" means, yet, and the jump from "host and domain names" (technical data) to social data (a subset of) "internationalized information" is left as an exercise to the reader. We could state: a. The protocol will support any encoding of technical and/or social data, (code-set independent, or csi) or b. The protocol will support some encodings (list) of technical data, and some, possibly different, encodings (list) of social data, (code-set dependent, or csd) or c. The protocol will not support some encodings (list) of technical data, and will not support some, possibly different, encodings (list) of social data, >From Deng Xiang's response we know that UTF8 encodings of technical data is a requirement of a provreg protocol deployed by the .CN ccTLD Registry and Registrars. It is possible that the range of encodings for social data includes GBK and Big5 as well as UTF8. [2] The protocol MUST allow exchange of meta-data associated with objects in formats consistent with current internationalized character encoding and language representation standards. I honestly don't know what this means. If it means code-set identifiers or locale identifiers or something else, we should be more specific (and useful) about "metadata". Every time I hear that word I reach for my RDF. [3] All date and time values specified in a generic registry-registrar protocol MUST be expressed in Universal Coordinated Time. Dates and times MUST include information to represent a four-digit calendar year, a calendar month, a calendar day, hours, minutes, seconds, fractional seconds, and the time zone for Universal Coordinated Time. I suggest we cite iso8601 and pick a specific format, b (UCT, above). I do see a problem however with any "user and/or accounting package friendly" temporal identifier (and we do use time, Scott is going to add a temporal identifer sufficient to support ordering in addition to what is in -06 at the moment). The problem is that objects have temporal properties, and these properties are passed around as operands and as identifiers in a common representation (good) but with no common synchronization mechanism (bad). Anyone for NTP (not for sorting out nano-payments) as a specific requirement for temporal consistency? How about putting an upper bound on clock deltas between provreg entities? I claim it is Feb. 14, 1901. Another possibility is seperating "meta- or technical time" from "social time". The first provreg uses, NTP-esque, the second is in provreg messages. Cheers, Eric P.S. Sent only to provreg, though nominal overlap with idn & whois. References (add cite) [ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", 1988. or/and [RFC2030] "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996. and [insert one or more lists of encoding standards here] Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DL5CnF014647 for ietf-provreg-outgoing; Tue, 13 Feb 2001 22:05:12 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DL5BLN014642 for ; Tue, 13 Feb 2001 22:05:11 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14SmcL-0008UN-00 for ietf-provreg@cafax.se; Tue, 13 Feb 2001 16:04:09 -0500 Reply-To: From: "Ross Wm. Rader" Cc: Subject: RE: Definitions Merge Date: Tue, 13 Feb 2001 16:06:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200102132046.f1DKkjC03342@nic-naa.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk Consider it done... < -----Original Message----- < From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of Eric Brunner-Williams in Portland Maine < Sent: Tuesday, February 13, 2001 3:47 PM < To: Hollenbeck, Scott < Cc: 'ietf-provreg@cafax.se'; brunner@nic-naa.net < Subject: Re: Definitions Merge < < < Works for me. Since you and he are in cahoots (cut from && paste < to) can you < ask him to rename and adjust? I'll be happy to help, having < nuanced. The co-s < should sign-off on the draft going from individual submission to < WG queue. < < Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DKsUWO014529 for ietf-provreg-outgoing; Tue, 13 Feb 2001 21:54:30 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DKsSLN014524 for ; Tue, 13 Feb 2001 21:54:29 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA21245 for ; Tue, 13 Feb 2001 15:54:28 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F91TM>; Tue, 13 Feb 2001 15:49:06 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: Definitions Merge Date: Tue, 13 Feb 2001 15:49:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Sure -- Ross, are you OK with this? -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Tuesday, February 13, 2001 3:47 PM To: Hollenbeck, Scott Cc: 'ietf-provreg@cafax.se'; brunner@nic-naa.net Subject: Re: Definitions Merge Works for me. Since you and he are in cahoots (cut from && paste to) can you ask him to rename and adjust? I'll be happy to help, having nuanced. The co-s should sign-off on the draft going from individual submission to WG queue. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DKmR90014433 for ietf-provreg-outgoing; Tue, 13 Feb 2001 21:48:27 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DKmPLN014428 for ; Tue, 13 Feb 2001 21:48:25 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1DKkjC03342; Tue, 13 Feb 2001 15:46:56 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102132046.f1DKkjC03342@nic-naa.net> To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: Definitions Merge In-Reply-To: Your message of "Tue, 13 Feb 2001 15:20:58 EST." Date: Tue, 13 Feb 2001 15:46:45 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Works for me. Since you and he are in cahoots (cut from && paste to) can you ask him to rename and adjust? I'll be happy to help, having nuanced. The co-s should sign-off on the draft going from individual submission to WG queue. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DKQNnR014123 for ietf-provreg-outgoing; Tue, 13 Feb 2001 21:26:23 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DKQMLN014117 for ; Tue, 13 Feb 2001 21:26:22 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA21144 for ; Tue, 13 Feb 2001 15:26:21 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F91ST>; Tue, 13 Feb 2001 15:20:59 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: Definitions Merge Date: Tue, 13 Feb 2001 15:20:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yes, I agree. Perhaps Ross' document should be renamed (and the definitions adjusted) to make it less whois-centric, especially if it's being picked up as a provreg WG document? -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Tuesday, February 13, 2001 3:19 PM To: Hollenbeck, Scott Cc: 'ietf-provreg@cafax.se'; brunner@nic-naa.net Subject: Re: Definitions Merge Scott, There is at least one nuance which distinguishes a provreg definition of "foo" from a whois defintion of "foo", one which you captured in the distinction between "technical information" and "social information". The "thick vs thin" model is distinguished by the distribution of "social information" only, and this determines scope (end-points) for data flows for provreg. In whois, there is no "technical information" (as whois makes no known use of zone files), and I'm unclear if whois distinguishes between a registry (global) and a registrar (local) provenance of data, nor the ordering of entities between the query originator and the (eventual, not necessarily unique) reply entity (or entities). I don't mind a distinct definition-dump, I think we have at least one form of "foo (depends who's answering, provreg or whois)" definition. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DKKw3P013991 for ietf-provreg-outgoing; Tue, 13 Feb 2001 21:20:58 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DKKuLN013986 for ; Tue, 13 Feb 2001 21:20:56 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1DKJPC03109; Tue, 13 Feb 2001 15:19:35 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102132019.f1DKJPC03109@nic-naa.net> To: "Hollenbeck, Scott" cc: "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: Definitions Merge In-Reply-To: Your message of "Fri, 09 Feb 2001 13:12:59 EST." Date: Tue, 13 Feb 2001 15:19:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, There is at least one nuance which distinguishes a provreg definition of "foo" from a whois defintion of "foo", one which you captured in the distinction between "technical information" and "social information". The "thick vs thin" model is distinguished by the distribution of "social information" only, and this determines scope (end-points) for data flows for provreg. In whois, there is no "technical information" (as whois makes no known use of zone files), and I'm unclear if whois distinguishes between a registry (global) and a registrar (local) provenance of data, nor the ordering of entities between the query originator and the (eventual, not necessarily unique) reply entity (or entities). I don't mind a distinct definition-dump, I think we have at least one form of "foo (depends who's answering, provreg or whois)" definition. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1DJLXUP013518 for ietf-provreg-outgoing; Tue, 13 Feb 2001 20:21:33 +0100 (MET) Received: from rock.viagenie.qc.ca (rock.viagenie.qc.ca [206.123.31.139]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1DJLVLN013513 for ; Tue, 13 Feb 2001 20:21:32 +0100 (MET) Received: from viagenie.qc.ca (localhost [127.0.0.1]) by rock.viagenie.qc.ca (8.11.1/8.11.1) with ESMTP id f1DJIAr01676; Tue, 13 Feb 2001 14:18:10 -0500 (EST) (envelope-from Andre.Cormier@viagenie.qc.ca) Message-ID: <3A898872.9724D1E0@viagenie.qc.ca> Date: Tue, 13 Feb 2001 14:18:10 -0500 From: Andre Cormier X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Eric Brunner-Williams in Portland Maine CC: ietf-provreg@cafax.se Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] References: <200102100001.f1A01LC05996@nic-naa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric Brunner-Williams in Portland Maine wrote: > > Last December Andre Cormier (1) proposed added requirement [3], viz > > [3] The protocol or another layered protocol MUST provide services to > negotiate an identification and authentication mechanism acceptable to > both the server and the client. > > The requirement he's proposed is negociation between the server and the client > as the precondition for subsequent transactions. > > My issue with this is that the scope of R-* policied data flows is larger > than participant identification and authentication, which is distinct from > negociation proposed concerning the duration of a particular registration, > (and I suppose equivalent object-specific properties). > > As Richard Shockey noted (2), BEEP provides a negociation mechanism. > Absent BEEP, this requirement places upon the provreg design group the > participant policy negociation problem. To my knowledge this is not a big problem since SASL describes how to do this and BEEP is using it. SASL = RFC 2222 As i understand it this is for Registrars authentication to the registry. I do not see a problem with this requirement. If we don't have a negociation mecanism, we are bound to change the protocol if we wish to change the authentication method. > The specific policy I've in mind (wearing my P3P Spec hat) is neither > participant identification nor authentication, but participant data > collection policies. > > I've proposed off-list that [1] and [2] be reworded to be symmetric, so > they address server identification authentication. I propose that [3] > be dropped, least we have the situation where we can negociate a means > to identify and also authenticate any provreg participant, but can't > negociate data collection policies. > > The real throw-hands-up-in-dispair is that after two years of effort, > the P3P activity couldn't figure out how to negociate a fundamental, > and I don't want provreg to pause-to-refresh while revisiting a problem > appealing to generalist aesthetics and not present deployment schedules. > Everyone wants to negociate, and we don't really have negociated policed > flows anywhere in the internet architecture (corrections gladly paid for). > > Incidently, P3P has versioning. 1.0, ... > > Cheers, > Eric > > (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html > (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1CFwDTk025667 for ietf-provreg-outgoing; Mon, 12 Feb 2001 16:58:13 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1CFwBLN025662 for ; Mon, 12 Feb 2001 16:58:12 +0100 (MET) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id HAA17084; Mon, 12 Feb 2001 07:58:09 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010212075700.030bd730@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Mon, 12 Feb 2001 07:57:57 -0800 To: George Belotsky From: Dave Crocker Subject: Re: moving on, was Re: Fw: WG Review: ... Cc: ietf-provreg@cafax.se, Patrik Faltstrom In-Reply-To: <20010212103819.D14396@register.com> References: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> <5.1.0.7.2.20010203202358.01d8f548@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 07:38 AM 2/12/2001, George Belotsky wrote: >In response to your request for suggestions regarding the design team, >here are some notes on its possible structure and operation. IETF design teams self-organize. Their output is subject to acceptance or revision by the working group, but the working group does not manage the internals of IETF design teams. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1CFdAS2025465 for ietf-provreg-outgoing; Mon, 12 Feb 2001 16:39:10 +0100 (MET) Received: from rcommail1 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1CFd9LN025460 for ; Mon, 12 Feb 2001 16:39:10 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14SL3U-0007aN-00; Mon, 12 Feb 2001 10:38:20 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 12 Feb 2001 10:38:19 -0500 Date: Mon, 12 Feb 2001 10:38:19 -0500 From: George Belotsky To: Edward Lewis Cc: Dave Crocker , ietf-provreg@cafax.se, Patrik Faltstrom Subject: Re: moving on, was Re: Fw: WG Review: ... Message-ID: <20010212103819.D14396@register.com> References: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> <5.1.0.7.2.20010203202358.01d8f548@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Sun, Feb 04, 2001 at 12:06:42PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed: In response to your request for suggestions regarding the design team, here are some notes on its possible structure and operation. * Each team member will be assigned primary responsibility for a part of the design. The division of the overall task into these parts, as well as the assignment, shall be by unanimous consent. * Each member will focus on their area of primary responsibility. * The whole team will periodically review each member's work, but unanimous consent would not be required (i.e. in their area of primary responsibility, a member carries more weight than others on the team). The reviews would thus focus primarily on the interfaces between constituent parts of the design. Hopefully, the above arrangement will create a clear assignment of responsibilities but in a relatively informal environment -- which is conductive to the creative work of design. George. On Sun, Feb 04, 2001 at 12:06:42PM -0500, Edward Lewis wrote: > As much as I hate to cut off communication on a topic, I don't think the > revent thread on the charter is in any way is helping us arrive at > protocol. In fact, I might go so far as to say that this thread has gone > off-topic for the mailing list. > > All I can say here is that we have already had a discussion on the charter, > and it has not yet been approved by the IESG. I am waiting for feedback > from the IESG before anything else can be done on this matter. Further > discussion on this is just like spinning tires in mud. > > Let's get back to discussions on the requirements document (if there is any > more to be held). I assume there is consensus that the requirements > document should be admitted to the WG (once we are official). > > Suggestions for the Feb 20 meeting agenda are welcome. > > I'd also like to hear thoughts about organizing a design team (whether we > should, size, shape, nominees perhaps). > > I think it is about time we begin to look at the EPP document. Does the > latest EPP draft meet the latest draft of requirements? Is there an > objection to including EPP in the WG set of documents? > > If there is an alternative proposal to be considered, please identify it. > > If there are other documents that should be added to the WG, please > identify them. (The definitions document will likely be one.) > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1C9OlbR022621 for ietf-provreg-outgoing; Mon, 12 Feb 2001 10:24:47 +0100 (MET) Received: from naptop.pilsnet.sunet.se (flaptop.pilsnet.sunet.se [192.36.125.212]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1C9OeLN022616 for ; Mon, 12 Feb 2001 10:24:40 +0100 (MET) Received: by naptop.pilsnet.sunet.se (8.12.0.Beta1/8.12.0.Beta1) id f1C9NUBR000757 for ietf-provreg@cafax.se; Mon, 12 Feb 2001 10:23:30 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1ALuhLN010812 for ; Sat, 10 Feb 2001 22:56:44 +0100 (MET) Received: from jamessonyvaio (hs08140.singnet.com.sg [165.21.200.142]) by mail.i-dns.net (Postfix) with SMTP id B6966FFC0B; Sun, 11 Feb 2001 05:56:23 +0800 (SGT) Message-ID: <066e01c093ac$2af178a0$21cc15a5@jamessonyvaio> From: "James Seng" To: , "Eric Brunner-Williams in Portland Maine" Cc: References: <200102100001.f1A01LC05996@nic-naa.net> Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] Date: Sun, 11 Feb 2001 05:55:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk RFC2058. -James Seng > The real throw-hands-up-in-dispair is that after two years of effort, > the P3P activity couldn't figure out how to negociate a fundamental, > and I don't want provreg to pause-to-refresh while revisiting a problem > appealing to generalist aesthetics and not present deployment schedules. > Everyone wants to negociate, and we don't really have negociated policed > flows anywhere in the internet architecture (corrections gladly paid for). > > Incidently, P3P has versioning. 1.0, ... > > Cheers, > Eric > > (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html > (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1B4T11V013335 for ietf-provreg-outgoing; Sun, 11 Feb 2001 05:29:01 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1B4T0LN013328 for ; Sun, 11 Feb 2001 05:29:00 +0100 (MET) Received: from 207-172-149-226.s35.as7.anp.md.dialup.rcn.com ([207.172.149.226]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Ro89-0001Ae-00 for ietf-provreg@cafax.se; Sat, 10 Feb 2001 23:28:57 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Feb 2001 23:28:31 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: WG ACTION: Provisioning Registry Protocol (provreg) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Apparently, we're now legal... >From: The IESG >To: IETF-Announce:;;@tislabs.com >Subject: WG ACTION: Provisioning Registry Protocol (provreg) >Date: Sat, 10 Feb 2001 16:22:12 -0500 >Sender: scoya@cnri.reston.va.us > > >A new working group has been formed in the Applications Area of the IETF. >For additional information, contact the Area Directors >or the WG Chair. > > >Provisioning Registry Protocol (provreg) >---------------------------------------- > > Charter > Last Modified: 05-Feb-01 > > Current Status: Active Working Group > > Chair(s): > Jaap Akkerhuis > Ed Lewis > > Applications Area Director(s): > Ned Freed > Patrik Faltstrom > > Applications Area Advisor: > Patrik Faltstrom > > Mailing Lists: > General Discussion:ietf-provreg@cafax.se > To Subscribe: ietf-provreg-request@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > >Description of Working Group: > >Administration of Domain Name Service (DNS) registration increasingly >distinguishes between the operation of a "back-end" registry data base >service for registrations, versus "front-end" support services by >registrars who interact with registrants and with the registry. >Especially for various Top-Level Domains, the desire is to permit >multiple registrars to share access to the database. Conversely, there >is a desire to allow a registrar to access multiple registries via the >same protocol, even if the registries differ in operational models. > >This working group will develop a specification of the requirements and >limitations for a protocol that enables a registrar to access multiple >registries and will develop a protocol that satisfies those >requirements. The protocol will permit interaction between a >registrar's own application and registry applications. > >The initial specification will allow multiple registrars to register >and maintain domain names within multiple Top Level Domains (TLDs). The >specification should be flexible enough to support the different >operational models of registries. The specification should allow >extension to support other registration data, such as address >allocation and contact information. The working group will use as input >the "Generic Registry-Registrar Protocol Requirements" >(draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning >Protocol presentation, documented in (draft-hollenbeck-epp-nn). > >The group will consider support for multiple operational choices, such >as for transport and security; it will create no new transport or >security protocols. The group may consider use of the new protocol for >diverse registration and update scenarios, in order to understand >limitations and possible extensions that are appropriate. Specification >for user interface access, such as by a web front end, is beyond the >scope of this working group. > >Documentation from the working group will: > >* Specify the objects exchanged between the registry repository >and registrars, the relationships among the objects, and the protocol >for exchanging objects between a registrar and the registry; at a >minimum the objects will include: domain name, IP address, and contact >details for registrants > >* Describe appropriate mechanisms for security during registrar access > >* List useful examples of registrar access transactions > > Goals and Milestones: > > Feb 01 Working group agreement on functional requirements for >protocol > > Apr 01 Initial specification of provreg protocol > > > Jun 01 Second draft specification > > > Sep 01 Submit draft for standards track > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1B3610O013059 for ietf-provreg-outgoing; Sun, 11 Feb 2001 04:06:01 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1B35xLN013052 for ; Sun, 11 Feb 2001 04:06:00 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id WAA15427 for ; Sat, 10 Feb 2001 22:05:58 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9D2R>; Sat, 10 Feb 2001 22:00:42 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Transfer Notification a requirement? Date: Sat, 10 Feb 2001 22:00:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I don't have a problem with striking 3.7-[8] if no one objects. > -----Original Message----- > From: Jordyn A. Buchanan [mailto:jordyn@register.com] > Sent: Friday, February 09, 2001 12:06 PM > To: James Seng/Personal; Ayesha Damaraju; ietf-provreg@cafax.se > Subject: Re: Transfer Notification a requirement? > > > At 01:18 PM 2/9/2001 +0800, James Seng/Personal wrote: > >I would like to point out again that this is one area where specific > >design and policy which leak into requirements. > > > >The problem here is that Object Transfer must both > registrars to agree. > >And to prevent abuse, it is policy decision that such transfer who > >require giving the losing registrar to stop the transfer. (In other > >words, it is the SERVER which is suppose to keep track of > this, not the > >protocol). > > I agree with James that 3.7 still contains some policy > language. Can we > just lose 3.7 [8]? That's a policy issue. Everything else > just describes > capabilities that the protocol should have. The protocol > *should* include > a capability for the losing registrar to stop the transfer > because some > registries do this. If your registry doesn't act this way, > then you don't > have to pay attention. > > >This problem _could_ be solved in another way, ie, by having > >authorization access directly on objects. This allows the > >owner/registrant to do whatever he wants with the object including > >transfer so long he can provide the appropriate authorization. > > This is already handled. Everything is extensible and 3.7 > [4] says "The > protocol MUST provide services to confirm registrar authorization to > transfer an object." It's up to the registry to determine what that > authorization is. > > >There are many ways to solve a problem. IMHO, requirements should be > >independent of any design. > > True. I think we should lose 3.7 [8]. Then there's no policy in 3.7. > > Jordyn > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1AM6JXv010896 for ietf-provreg-outgoing; Sat, 10 Feb 2001 23:06:19 +0100 (MET) Received: from mail.2day.net.nz (handel.2day.com [202.37.240.29]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1AM6GLN010891 for ; Sat, 10 Feb 2001 23:06:17 +0100 (MET) Received: from cdt5 (unverified [202.37.240.38]) by mail.2day.net.nz (Rockliffe SMTPRA 4.5.4) with SMTP id ; Sun, 11 Feb 2001 11:06:13 +1300 From: "Peter Mott" To: "Eric Brunner-Williams in Portland Maine" , Cc: Subject: RE: grrp-reqs-06, 3.2 Object Registration [2] Date: Sun, 11 Feb 2001 11:06:05 +1300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200102102116.f1ALGBC13428@nic-naa.net> Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The temporal properties of domain name object registration needs > clarification. > The -06 text in [2] originates from a proposal by Geva Patz [1] > who sought to > remove arbitrary restrictions, as domain names then (circa -03) > had fixed time > associations. There will be some ccTLD's whose interest in storing the registration expiration date in the shared register is simply to publish the fact a registrar/registrant contract is due to expire on that day/hour. In such a model, the registry will charge the registrar for access to the register, and a fee that relates to the number of records associated with the registrar. This sensible model has the registry send a two line invoice to each registrar every month, and registrars pay a single bill each month. Please do build as much complexity into the protocol you like, but lets make sure it can also function without the need for the registry company to have an interest in the domain name registration business. There is a possibility some registry operators have an interest in providing services that meet the needs of registrars rather than acting as a bus conductor with a very busy ticket clicker. > Comments on the backs of $5 bills (larger is OK, but a minimum granularity > is required). Thanks. Sorry, I only pay by credit card on the net :-) Peter Mott .aq .tk .pn -/- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1ALHVIv010635 for ietf-provreg-outgoing; Sat, 10 Feb 2001 22:17:31 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1ALHTLN010630 for ; Sat, 10 Feb 2001 22:17:30 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1ALGBC13428; Sat, 10 Feb 2001 16:16:11 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102102116.f1ALGBC13428@nic-naa.net> To: geva@bbn.com cc: ietf-provreg@cafax.se Subject: grrp-reqs-06, 3.2 Object Registration [2] Date: Sat, 10 Feb 2001 16:16:10 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk The temporal properties of domain name object registration needs clarification. The -06 text in [2] originates from a proposal by Geva Patz [1] who sought to remove arbitrary restrictions, as domain names then (circa -03) had fixed time associations. I believe the problem Geva was concerned with was the upper-bound for domain name object registration. A difficulty arises from this very lack of arbitrary restriction as no lower bound requirement is available to the protocol designers, and we clearly do not, in the case of fee-for-service regimes, want to move from existing forms of fee recovery (credit card based is a common, though not universal model) to "micro-payment" regimes. The issues which need to be addressed by this requirment are accounting, granularity of the units used to measure validity periods (where definite temporal properties exist), etc. Current -06 text: ... Registries SHOULD be allowed to accept indefinitely 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. ... Proposed text: ... Registries SHOULD be allowed to accept indefinitely 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. Registries MUST be allowed to specify minimal validity periods consistent with the prevailing or preferred practice for fee-for-service recovery. ... If anyone cares to observe that this is policy (micro-payment depricating, macro-payment preferential), they are of course correct, and I don't want to even think of importation of the requirement expressed in [2] into the provreg system. Comments on the backs of $5 bills (larger is OK, but a minimum granularity is required). Thanks. Cheers, Eric [1] http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00026.html [2] rfc2870, Root Name Server Operational Requirements, Section 3.2.5. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1AGpSpk009294 for ietf-provreg-outgoing; Sat, 10 Feb 2001 17:51:28 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1AGpMLN009289 for ; Sat, 10 Feb 2001 17:51:22 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1AGo3C10711; Sat, 10 Feb 2001 11:50:03 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102101650.f1AGo3C10711@nic-naa.net> To: ietf-idna@mail.apps.ietf.org, ietf-provreg@cafax.se cc: idn@ops.ietf.org, duerst@w3.org, misha.wolf@reuters.com, cnnic-staff@cnnic.net.cn Subject: FYI: CNNIC services GBK, Big5, and UTF8 encodings Date: Sat, 10 Feb 2001 11:49:58 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk [Please trim the cc if replying!] Announced Monday, February 5th, at the following URL: http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html My understanding is that CNNIC does or will provide a resolver which has support for these three encodings within the .cn ccTLD, defaults (like AOL keywords) any FQDN to FQDN.cn, supports these three encodings within the the DNS root, at least for some set of iso3166 labels, e.g., cn, and possibly tw and probably does more than the peopledaily writer describes. These aren't ASCII Compatible Extension (ACE) encoding mechanisms, and differ from the iDNS/NSI mechanism deployment of last November, which is ACE-based. For those familiar with either GBK or Big5, feel free to ignore the next two paras. For those unfamiliar with the GB series, GBK is the MS Windows PRC version (K == kuozhan "extension"), see also GB 1390.1-93 and GB 2312-80, and for the EUC-centric (me, other Unix i18n weenies), overlaps EUC-CN, and encodes the Chinese subset of ISO 10646-1:1993. For those unfamiliar with Big5, it is the de facto standard in Taiwan (Mac and Windows) and is equivalent to the first two planes of CNS 11643-1992, and for the EUC-centric, differs from EUC-TW code sets 0 and 1 mainly in having an additional encoding block. The CNNIC's approach appears to be at odds with a recent IDN WG I-D [1], which observed: > Note also that because modern OS are Unicode based and have network- > downloadable IMEs, "interoperability" is becoming less equivalent to > "use BIG5 characters only" or "use GB2312 character only" or "use > Shift-JIS characters only". What appears to be the case is CNNIC is offering network-downloadable code-set-specific resolvers, independent of (native) Unicode deployment in OS products and input method extension delivery mechanisms. Incidently, the January edition of the CNNIC semiannual data is available. Semiannual Survey Report on the Development of China's Internet (Jan. 2001) http://www.cnnic.cn/develst/e-cnnic200101.shtml Corrections and additional comments welcome, Maine is a ways from Beijing. Eric [1] "Han Ideograph (CJK) for Internationalized Domain Names", Seng et al., http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1A03mQ7004013 for ietf-provreg-outgoing; Sat, 10 Feb 2001 01:03:48 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1A03lLN004008 for ; Sat, 10 Feb 2001 01:03:47 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1A01LC05996; Fri, 9 Feb 2001 19:01:42 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102100001.f1A01LC05996@nic-naa.net> To: Andre.Cormier@viagenie.qc.ca cc: ietf-provreg@cafax.se Subject: grrp-reqs-06, 3.2 Identification and Authentication [3] Date: Fri, 09 Feb 2001 19:01:21 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Last December Andre Cormier (1) proposed added requirement [3], viz [3] The protocol or another layered protocol MUST provide services to negotiate an identification and authentication mechanism acceptable to both the server and the client. The requirement he's proposed is negociation between the server and the client as the precondition for subsequent transactions. My issue with this is that the scope of R-* policied data flows is larger than participant identification and authentication, which is distinct from negociation proposed concerning the duration of a particular registration, (and I suppose equivalent object-specific properties). As Richard Shockey noted (2), BEEP provides a negociation mechanism. Absent BEEP, this requirement places upon the provreg design group the participant policy negociation problem. The specific policy I've in mind (wearing my P3P Spec hat) is neither participant identification nor authentication, but participant data collection policies. I've proposed off-list that [1] and [2] be reworded to be symmetric, so they address server identification authentication. I propose that [3] be dropped, least we have the situation where we can negociate a means to identify and also authenticate any provreg participant, but can't negociate data collection policies. The real throw-hands-up-in-dispair is that after two years of effort, the P3P activity couldn't figure out how to negociate a fundamental, and I don't want provreg to pause-to-refresh while revisiting a problem appealing to generalist aesthetics and not present deployment schedules. Everyone wants to negociate, and we don't really have negociated policed flows anywhere in the internet architecture (corrections gladly paid for). Incidently, P3P has versioning. 1.0, ... Cheers, Eric (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f19IIK5j001789 for ietf-provreg-outgoing; Fri, 9 Feb 2001 19:18:20 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f19IIILN001784 for ; Fri, 9 Feb 2001 19:18:19 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA13800 for ; Fri, 9 Feb 2001 13:18:14 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9C8D>; Fri, 9 Feb 2001 13:13:00 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Definitions Merge Date: Fri, 9 Feb 2001 13:12:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ross Rader and I have been talking about moving definitions from the GRRP requirements draft to his definitions draft so that we have a single definitions reference. The acronym explanations found in the GRRP draft will stay; the definitions will be replaced with a reference to Ross' draft. Any objections? Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f19HAoEB001162 for ietf-provreg-outgoing; Fri, 9 Feb 2001 18:10:50 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f19HAnLN001157 for ; Fri, 9 Feb 2001 18:10:50 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail2 with esmtp (Exim 3.16 #2) id 14RH3l-0002Zr-00; Fri, 09 Feb 2001 12:10:13 -0500 Message-Id: <5.0.2.1.0.20010209120012.03dafc30@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 09 Feb 2001 12:05:55 -0500 To: "James Seng/Personal" , "Ayesha Damaraju" , From: "Jordyn A. Buchanan" Subject: Re: Transfer Notification a requirement? In-Reply-To: <00b001c0926e$11bd9970$11daa5d2@jamessonyvaio> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 01:18 PM 2/9/2001 +0800, James Seng/Personal wrote: >I would like to point out again that this is one area where specific >design and policy which leak into requirements. > >The problem here is that Object Transfer must both registrars to agree. >And to prevent abuse, it is policy decision that such transfer who >require giving the losing registrar to stop the transfer. (In other >words, it is the SERVER which is suppose to keep track of this, not the >protocol). I agree with James that 3.7 still contains some policy language. Can we just lose 3.7 [8]? That's a policy issue. Everything else just describes capabilities that the protocol should have. The protocol *should* include a capability for the losing registrar to stop the transfer because some registries do this. If your registry doesn't act this way, then you don't have to pay attention. >This problem _could_ be solved in another way, ie, by having >authorization access directly on objects. This allows the >owner/registrant to do whatever he wants with the object including >transfer so long he can provide the appropriate authorization. This is already handled. Everything is extensible and 3.7 [4] says "The protocol MUST provide services to confirm registrar authorization to transfer an object." It's up to the registry to determine what that authorization is. >There are many ways to solve a problem. IMHO, requirements should be >independent of any design. True. I think we should lose 3.7 [8]. Then there's no policy in 3.7. Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f19FSVXG029660 for ietf-provreg-outgoing; Fri, 9 Feb 2001 16:28:31 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f19FSULN029655 for ; Fri, 9 Feb 2001 16:28:30 +0100 (MET) Received: by sentry.gw.tislabs.com; id KAA28758; Fri, 9 Feb 2001 10:31:49 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma028756; Fri, 9 Feb 01 10:31:06 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Feb 2001 10:24:49 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: Agenda for Interim Meeting Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 1:31 PM -0500 2/8/01, Hollenbeck, Scott wrote: >I can probably get the room for an earlier start if our chairs wish to do >so. Scott is getting the room for 9am. Those who want to gather early can do so - to discuss issues, prepare agenda suggestions, gather volunteers for scribe duties, etc. But the meeting won't officially begin until about 10 so those arriving that morning can make it in. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f19DAYsV028504 for ietf-provreg-outgoing; Fri, 9 Feb 2001 14:10:34 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f19DAVLN028499 for ; Fri, 9 Feb 2001 14:10:32 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f19D90C04190; Fri, 9 Feb 2001 08:09:00 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102091309.f19D90C04190@nic-naa.net> To: "James Seng/Personal" cc: "Ayesha Damaraju" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Transfer Notification a requirement? In-Reply-To: Your message of "Fri, 09 Feb 2001 13:18:45 +0800." <00b001c0926e$11bd9970$11daa5d2@jamessonyvaio> Date: Fri, 09 Feb 2001 08:09:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Mr. Seng, Your (repeated) suggestion that the scope of the working group extend to encompass the functionality of registrANT operations (below) has not yet addressed the mechanism(s) by which the provreg protocol's authentication, authorization, and presumably accounting activities scale. > This problem _could_ be solved in another way, ie, by having > authorization access directly on objects. This allows the > owner/registrant to do whatever he wants with the object including > transfer so long he can provide the appropriate authorization. Do you have any suggestions in this area at this time? Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f199WkpT027262 for ietf-provreg-outgoing; Fri, 9 Feb 2001 10:32:46 +0100 (MET) Received: from bureau.sidn.nl (bureau.domeinnaam-jurisprudentie.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f199WiLN027257 for ; Fri, 9 Feb 2001 10:32:45 +0100 (MET) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id KAA16063; Fri, 9 Feb 2001 10:32:44 +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 KAA19491; Fri, 9 Feb 2001 10:32:44 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102090932.KAA19491@bartok.sidn.nl> To: Ayesha Damaraju cc: ietf-provreg@cafax.se Subject: Re: Transfer Notification a requirement? In-reply-to: Your message of Thu, 08 Feb 2001 11:59:59 -0600. Date: Fri, 09 Feb 2001 10:32:44 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk 3.7 Object Transfer [6] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. ............... ........... [8] Object Transfer requests MUST NOT be acted upon without giving the losing registrar an opportunity to respond to the request... Unless [8] implies that a notification needs to be sent to the losing registrar to approve or reject giving them an opportunity - In which case i t needs to be clear, even otherwise notifying the sponsoring registrar to approve or reject the transfer should be a requirement. Note that the protocol MUST provide this service. However, it is a policy decision whether the registry actually implements this. As said before, the Dutch domain registry doesn't allow this. The old (or ``loosing registar'') has some time to comment on the transfer, but when there is no adequate reason to halt the transfer, it will happen anyway. This to prevent a registrar taking a domain hostage, because there is a conflict between registrar and registrant. Something that happened a lot when we allowed the old regsitrar to veto any transfer. jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1981PFC026701 for ietf-provreg-outgoing; Fri, 9 Feb 2001 09:01:25 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f197xrLN026685 for ; Fri, 9 Feb 2001 09:00:08 +0100 (MET) Received: from jamessonyvaio (pl017.nas112.narita.nttpc.ne.jp [210.165.218.17]) by mail.i-dns.net (Postfix) with SMTP id D8849FFC16; Fri, 9 Feb 2001 15:59:23 +0800 (SGT) Message-ID: <00b001c0926e$11bd9970$11daa5d2@jamessonyvaio> From: "James Seng/Personal" To: "Ayesha Damaraju" , References: Subject: Re: Transfer Notification a requirement? Date: Fri, 9 Feb 2001 13:18:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I would like to point out again that this is one area where specific design and policy which leak into requirements. The problem here is that Object Transfer must both registrars to agree. And to prevent abuse, it is policy decision that such transfer who require giving the losing registrar to stop the transfer. (In other words, it is the SERVER which is suppose to keep track of this, not the protocol). This problem _could_ be solved in another way, ie, by having authorization access directly on objects. This allows the owner/registrant to do whatever he wants with the object including transfer so long he can provide the appropriate authorization. There are many ways to solve a problem. IMHO, requirements should be independent of any design. -James Seng ----- Original Message ----- From: "Ayesha Damaraju" To: Sent: Friday, February 09, 2001 1:59 AM Subject: Transfer Notification a requirement? > > Considering below two requirements from GRRP_reqs_06 > > 3.7 Object Transfer > > [6] The protocol MUST provide services that allow the original > sponsoring registrar to approve or reject a requested object transfer. > ............... > ........... > > [8] Object Transfer requests MUST NOT be acted upon without giving the > losing registrar an opportunity to respond to the request... > > > Unless [8] implies that a notification needs to be sent to the losing > registrar to approve or reject giving them an opportunity - In which case it > > needs to be clear, even otherwise notifying the sponsoring registrar to > approve or reject the transfer should be a requirement. > > -Ayesha > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18LPi81021707 for ietf-provreg-outgoing; Thu, 8 Feb 2001 22:25:44 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18LPhLN021702 for ; Thu, 8 Feb 2001 22:25:43 +0100 (MET) Received: from urs.dial.switch.ch ([130.59.25.244]) by central.switch.ch with esmtp (Exim 3.15 #3) id 14QyZM-0000eF-00 for ietf-provreg@cafax.se; Thu, 08 Feb 2001 22:25:37 +0100 Date: Thu, 08 Feb 2001 14:02:41 +0100 From: Urs Eppenberger To: ietf-provreg@cafax.se Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <113718.981640961@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On Mittwoch, 7. Februar 2001 10:26 Uhr -0500 "Hollenbeck, Scott" wrote: > [11] The protocol MUST provide services to manage name servers associated > with multiple domains. No name server data SHOULD exist in the registry > without an associated parent domain. The first sentence is OK. It talks about protocol level. The second sentence is about what a registry is allowed to store, and this does not make sense here. At SWITCH we register nameserver objects without checking if they are 'used'. We register the corresponding IP addresses and a contact person. (Often fetching the e-mail address from the SOA record does not help in case of misconfigurations, because e-mail just does not work anymore. For this we keep a more or less complete set of contact information for the hostmaster of the nameserver. He is the owner of the object and has the right to change attribute values like IP adresses.) We allow certain changes at a specific date, for example the replacement of nameservers for a domain. For this you need to register the nameservers first, without the connection to the domain. And at the agreed date the old nameserver are replaced. Therefore to require that 'no nameservers SHOULD exist' does not make sense for me. Urs. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18JAah5020257 for ietf-provreg-outgoing; Thu, 8 Feb 2001 20:10:36 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18JAZLN020252 for ; Thu, 8 Feb 2001 20:10:35 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA11191 for ; Thu, 8 Feb 2001 14:10:34 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9CKL>; Thu, 8 Feb 2001 14:05:23 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Transfer Notification a requirement? Date: Thu, 8 Feb 2001 14:05:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Requirement 3.7-[7] was intended to address registrar/client awareness of transfers: [7] The protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to monitor the status of both pending and completed transfer requests. I didn't want to get more specific about how the monitoring or notification facilities should look. > -----Original Message----- > From: Ayesha Damaraju [mailto:ayesha.damaraju@neustar.com] > Sent: Thursday, February 08, 2001 1:00 PM > To: ietf-provreg@cafax.se > Subject: Transfer Notification a requirement? > > > > Considering below two requirements from GRRP_reqs_06 > > 3.7 Object Transfer > > [6] The protocol MUST provide services that allow the original > sponsoring registrar to approve or reject a requested object transfer. > ............... > ........... > > [8] Object Transfer requests MUST NOT be acted upon without giving the > losing registrar an opportunity to respond to the request... > > > Unless [8] implies that a notification needs to be sent to the losing > registrar to approve or reject giving them an opportunity - > In which case it > > needs to be clear, even otherwise notifying the sponsoring > registrar to > approve or reject the transfer should be a requirement. > > -Ayesha > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18J3TnV020204 for ietf-provreg-outgoing; Thu, 8 Feb 2001 20:03:29 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18J3SLN020199 for ; Thu, 8 Feb 2001 20:03:28 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA11155 for ; Thu, 8 Feb 2001 14:03:27 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9CKC>; Thu, 8 Feb 2001 13:58:15 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Generalizing the terminology Date: Thu, 8 Feb 2001 13:58:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks for your detailed comments, Catherine. While I understand people's comments about the requirements draft being very domain name centric, it was explicitly done that way to define requirements for a specific, narrow, manageable initial focus: domain names and data associated with domain names. As-is, I don't think there's anything in the draft that precludes protocol extension to non-domain resources (to use Catherine's term). Not too long ago the idea of developing new requirements drafts for non-domain resources was suggested by someone. I'd much prefer that route over trying to make the current requirements draft into something that it wasn't meant to be from the start. I agree that it would be a good idea to define the term "status" in the context of a domain name before using it elsewhere in the document. > -----Original Message----- > From: Catherine Murphy [mailto:cathym@arin.net] > Sent: Thursday, February 08, 2001 12:44 PM > To: ietf-provreg@cafax.se > Subject: Generalizing the terminology > > > > I would like to offer the following specific revisions in an > attempt to > reduce the domain name emphasis of the draft. I know that some of the > recent discussion has already affected the draft, but this > mark-up goes > against the most recent posting of > draft-hollenbeck-grrp-reqs-06.txt. As > a general comment, I think the document is well thought out and very > thorough. Scott has done a great job getting this started. I > also realize > that some of my points have already been made. My goal is to offer > specific alternatives to the existing text. Only the text containing > proposed changes is included below; everything else has been > . > > --------------------------------------------- > Cathy Murphy > Principal Software Engineer > American Registry for Internet Numbers (ARIN) > +1 703 227 9875 > > << Based on draft-hollenbeck-grrp-reqs-06.txt (January 19, 2001) >> > > 1.1 Definitions, Acronyms, and Abbreviations > > [NEW] Resource: A generic term used to describe an object that is > the primary focus of a registration process. An example of a > resource is a domain name or an IP address block. Supporting > objects such as contact information are not resources. > > << If you don't agree with having something along the lines > of this new definition, don't bother reading further. > Most of the changes revolve around this specific term. >> > > Registrant: An entity that registers resources in a registry > ^^^^^^^^^ > through the services provided by a registrar. Registrants include > individuals, organizations, and corporations. > > Registrar: An entity that provides front-end resource registration > ^^^^^^^^ > services to registrants, providing a public interface to registry > services. > > Registry: An entity that provides back-end resource registration > ^^^^^^^^ > services to registrars, managing a central repository of information > for a specific portion of that resource, e.g., a given TLD. > A domain > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^ > name registry is typically responsible for publication and > distribution > ^^^^ > of TLD zone files used by the Domain Name System. > > 2.2 System Functions > > Registrars access a registry through a protocol to register objects > and perform object management functions. Required functions include > session management; object creation, update, renewal, and deletion; > object query; and object transfer. > > A domain name registry generates DNS zone files for the > TLDs it serves. > ^^^^^^^^^^^^^ > These zone files are created and distributed to a series of > name servers > that provide the foundation for the domain name system. > > Registries MUST provide a whois search capability that > provides basic > ^^^^ > query services for the objects managed by the registry. ... > > 3.4 Object Registration > > [1] The protocol MUST provide services to register Internet domain > names. > > << Why? If the protocol is being used for non-domain name resources, > this particular requirement seems excessively > restrictive, perhaps > appropriate for a domain name extension to the "generic" RRP. >> > > [2] The protocol MUST permit a starting and ending time for a > resource registration to be negotiated, thereby ... > ^^^^^^^^ > > [3] When a resource has been successfully registered, ... > ^^^^^^^^ > > [5] If the resource being registered is a domain name, the protocol > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > MUST provide services to register name servers. ... > > << Since there has already been extensive discussion about > nameservers being objects versus attributes, I will not > comment further here except to re-iterate that this > portion of the protocol is somewhat distinct to domain > name registries. >> > > 3.5 Object Association > > [3] The protocol MUST provide services to associate contacts with > resources. Associated contacts name MUST be identified by type. > ^^^^^^^^^ > Contact types that MAY be associated with a resource include > ^^^^^^^^ > "registrant", "technical", "administrative", and "billing". A > registry MAY support a subset of these contact types. > > << Also, "abuse" >> > > 3.6 Object Update > > [1] The protocol MUST provide services to update information > associated with registered resources. Resource update > ^^^^^^^^^ ^^^^^^^^ > services MUST allow changes to status, associated name servers, and > associated contacts. > > << As far as I can tell, this is the first mention of status. > I would like to see the definition of status, which is not > defined until 3.12, either moved up or explicitly referenced. > When I first read this, my immediate thought was "Huh? Did I > miss something? What's a status?" >> > > [2] If the registry includes registration of associated > nameservers, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the protocol MUST provide services to update information > associated with registered name servers. Name server > update services > MUST allow change to IP addresses and server name. > > 3.7 Object Transfer > > << A general comment about object transfer: this entire section is > very specific to how domain names are transferred and does not > relate well at all to when and how IP networks may be > transferred. > I cannot speak to how other possible users of the GRRP might work > transfers, but I will propose other, more generic text for this > section in another message thread. Or, this section > could be left > in the protocol but identified as being domain name specific > requirements only. >> > > 3.8 Object Renewal/Extension > > [1] The protocol MUST provide services to renew or extend > the validity > period of registered resources. If applicable, ... > ^^^^^^^^^ > > 3.9 Object Deletion > > [1] The protocol MUST provide services to remove a resource from > the registry. ^^^^^^^^ > > [2] If the registry contains nameserver objects, the protocol MUST > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > provide services to remove a name server from the registry. > > << A nit: since this is the protocol, shouldn't these say something > like "An implementation of the protocol MUST provide"... >> > > 3.10 Object Existence Query > > [1] The protocol MUST provide services to determine if a resource > exists in the registry. ... ^^^^^^^^ > > 3.11 Object Information Query > > [1] The protocol MUST provide services to retrieve information > describing a resource from the registry. Returned information MUST > ^^^^^^^^ > include the identifier of the current sponsoring registrar, the > identifier of the registrar that originally registered the > resource, > ^^^^^^^^ > the creation date and time, the expiration date and time > (if any), the > date and time of the last successful update (if any), the identifier > of the registrar that performed the last update, the date > and time of > last successful transfer request or completed transfer (if any), the > current status of the resource, the most recent authorization > ^^^^^^^^ > << another pesky status reference w/o definition yet >> > > identifier, contact identifiers associated with the resource, and, > ^^^^^^^^ ^ > if applicable, the associated name servers registered to > the resource. > ^^^^^^^^^^^^^^ ^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > The most recent authorization identifier MUST be returned > only to the > current sponsoring registrar. > > 3.12 Domain Status Indicators > > [1] The protocol MUST provide status indicators that identify the > operational state of a resource. ... > ^^^^^^^^ > [3] A resource MAY have multiple statuses at any given time. Some > ^^^^^^^^ > statuses MAY be mutually exclusive. > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18IeQU2020047 for ietf-provreg-outgoing; Thu, 8 Feb 2001 19:40:26 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18IePLN020042 for ; Thu, 8 Feb 2001 19:40:25 +0100 (MET) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14QvyK-0000wQ-00; Thu, 08 Feb 2001 13:39:12 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Thu, 8 Feb 2001 13:39:13 -0500 Date: Thu, 8 Feb 2001 13:39:13 -0500 From: George Belotsky To: "Jordyn A. Buchanan" Cc: Catherine Murphy , Kent Crispin , Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se Subject: Re: Nameserver as object/entity or not ? Message-ID: <20010208133913.J9111@register.com> References: <5.0.2.1.0.20010208125807.0293db70@mail.register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.0.20010208125807.0293db70@mail.register.com>; from jordyn@register.com on Thu, Feb 08, 2001 at 12:58:35PM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk As can be seen from Jordyn's post, domains can be treated as objects and still maintain the policy semantics that Catherine finds desirable. Once again, it is important not to confuse policy and mechanism. In an object oriented system, attributes of objects may be objects in their own right. This is a design issue that is part of the mechanism. We are unlikely to totally agree on a set of policies. Policies will also change over time, and will be influenced by many factors -- including legislative choices made in various jurisdictions. Members of this group can hope to have some input towards such legislative choices, but will almost certainly not be in a position to make them. It would thus be helpful to identify the policy problem space, rather than try to finalize detailed policy decisions. By correctly identifying this space, we will build something long lasting and truly valuable -- something that can outlive the policies of today and adapt to the policies of the future. George. On Thu, Feb 08, 2001 at 12:58:35PM -0500, Jordyn A. Buchanan wrote: > At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote: > > >IP registries are a case in point. While I can see where some domain > >registries will want to treat nameservers as objects, we can not. The > >nameserver information that ARIN receives for in-addr nameservers is an > >attribute (or dependent object) of the IP network object. Kent's point of > >potentially conflicting ownership/authentication would also hold true for > >us. Since we are receiving the information from a particular network > >registrant, the nameserver information only extends to the scope of his > >authority, i.e., that network. The same nameservers could quite possibly > >be listed for other networks, but the authority to change a nameserver is > >limited. There is not inherent "ownership" of the nameserver information. > >If both Network A and Network B list ns1.foobar.net as its in-addr > >nameserver, Network A could not come to us and say, change all instances > >of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that > >change against its network; ns1.foobar.net would remain on network B. > > I think that there are two separate issues here: > > 1) Should name servers be treated as objects or as attributes of other objects? > > 2) If nameservers are objects, how do we manage ownership of these objects? > > Issue #2 seems to me to be mostly a matter of registry policy. Some > registries may want to say that the owner of a domain implicitly owns all > nameservers within that domain. Others may not, but may want to verify > that the owner of the domain approves of someone else having a nameserver > in their domain. Others may not care at all. The requirement should be > for an approach that accommodates these various policies. > > If we look at our objects as being "pointers to nameservers" with the > possibility of multiple pointers to the same actual nameserver, I think we > can achieve a solution that achieves many of the benefits of the > nameserver-as-object approach without the inherent ownership issue. Such > an approach allows a registrant to use a common name server object across > many domains (or IP blocks), but doesn't imply that the registrant "owns" > the name server or that changes made to the object changes the name server > for other people. > > For example, both BigISP and SmallCo may use BigISP's nameserver, > NS1.BIGISP.NET. BigISP creates an object in the database pointing to the > nameserver and names it "NS1-BIGISP". SmallCo has a lot of domains and > realizes that they may want to get their own name servers later on, so they > create a new object pointing to the same nameserver and call it > "NS1-SMALLCO". Later on, SmallCo does in fact get their own nameservers, > so they point "NS1-SMALLCO" at their new nameserver, > TINY.SMALLCO.COM. This allows them to modify the nameserver information on > all of their domain names by making a simple modification to the nameserver > object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way. > > If registries or registrars want to make each nameserver an attribute of a > domain that doesn't apply to any other domains, they can simply create a > new nameserver object for each domain. This is slightly inefficient, but I > don't know why this is a desirable goal in and of it self in the first place. > > >We also differ in that we will be tracking no other data about the > >nameserver except for the nameserver itself, e.g., ns1.foobar.net. > >(Currently, we receive the IP address of the nameserver, which is > >displayed in whois, but is not used to produce glue records. Since we are > >not authoritative for these nameservers, it does not make sense for us to > >maintain the IP address.) > > This is already dealt with by the existing requirements. The IP address of > a name server is only required (indeed, is only allowed) if the name server > is "registered within the registry's authoritative TLDs". So, only the > .NET registry needs to worry about the IP address of NS1.BIGISP.NET. In my > scheme, we'd only want one version of the name server to actually have an > IP address to avoid states where multiple pointers have the same name but > different IP addresses. > > Jordyn > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18IbAxY020013 for ietf-provreg-outgoing; Thu, 8 Feb 2001 19:37:10 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18Ib9LN020008 for ; Thu, 8 Feb 2001 19:37:09 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA11037 for ; Thu, 8 Feb 2001 13:37:08 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9CJF>; Thu, 8 Feb 2001 13:31:56 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Agenda for Interim Meeting Date: Thu, 8 Feb 2001 13:31:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk I can probably get the room for an earlier start if our chairs wish to do so. > -----Original Message----- > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > Sent: Thursday, February 08, 2001 10:54 AM > To: ietf-provreg@cafax.se > Subject: Re: Agenda for Interim Meeting > > > Any chance we can start at 9am or even 8:30? > > No doubt some people would arrive a bit later, just as some > people will > have to leave a bit early. However traveling that far for > such a short > meeting makes extending the hours appropriate. > > d/ > > ---------- > Dave Crocker > Brandenburg Consulting > tel: +1.408.246.8253; fax: +1.408.273.6464 > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18I5Z5d019801 for ietf-provreg-outgoing; Thu, 8 Feb 2001 19:05:35 +0100 (MET) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18I5YLN019796 for ; Thu, 8 Feb 2001 19:05:34 +0100 (MET) Received: from [192.168.2.222] (helo=tech146-jordyn.register.com) by rcommail2 with esmtp (Exim 3.16 #2) id 14QvQe-0003gK-00; Thu, 08 Feb 2001 13:04:24 -0500 Message-Id: <5.0.2.1.0.20010208125807.0293db70@mail.register.com> X-Sender: jbuchanan@mail.register.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 08 Feb 2001 12:58:35 -0500 To: Catherine Murphy , Kent Crispin , Eric Brunner-Williams in Portland Maine From: "Jordyn A. Buchanan" Subject: Re: Nameserver as object/entity or not ? Cc: ietf-provreg@cafax.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote: >IP registries are a case in point. While I can see where some domain >registries will want to treat nameservers as objects, we can not. The >nameserver information that ARIN receives for in-addr nameservers is an >attribute (or dependent object) of the IP network object. Kent's point of >potentially conflicting ownership/authentication would also hold true for >us. Since we are receiving the information from a particular network >registrant, the nameserver information only extends to the scope of his >authority, i.e., that network. The same nameservers could quite possibly >be listed for other networks, but the authority to change a nameserver is >limited. There is not inherent "ownership" of the nameserver information. >If both Network A and Network B list ns1.foobar.net as its in-addr >nameserver, Network A could not come to us and say, change all instances >of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that >change against its network; ns1.foobar.net would remain on network B. I think that there are two separate issues here: 1) Should name servers be treated as objects or as attributes of other objects? 2) If nameservers are objects, how do we manage ownership of these objects? Issue #2 seems to me to be mostly a matter of registry policy. Some registries may want to say that the owner of a domain implicitly owns all nameservers within that domain. Others may not, but may want to verify that the owner of the domain approves of someone else having a nameserver in their domain. Others may not care at all. The requirement should be for an approach that accommodates these various policies. If we look at our objects as being "pointers to nameservers" with the possibility of multiple pointers to the same actual nameserver, I think we can achieve a solution that achieves many of the benefits of the nameserver-as-object approach without the inherent ownership issue. Such an approach allows a registrant to use a common name server object across many domains (or IP blocks), but doesn't imply that the registrant "owns" the name server or that changes made to the object changes the name server for other people. For example, both BigISP and SmallCo may use BigISP's nameserver, NS1.BIGISP.NET. BigISP creates an object in the database pointing to the nameserver and names it "NS1-BIGISP". SmallCo has a lot of domains and realizes that they may want to get their own name servers later on, so they create a new object pointing to the same nameserver and call it "NS1-SMALLCO". Later on, SmallCo does in fact get their own nameservers, so they point "NS1-SMALLCO" at their new nameserver, TINY.SMALLCO.COM. This allows them to modify the nameserver information on all of their domain names by making a simple modification to the nameserver object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way. If registries or registrars want to make each nameserver an attribute of a domain that doesn't apply to any other domains, they can simply create a new nameserver object for each domain. This is slightly inefficient, but I don't know why this is a desirable goal in and of it self in the first place. >We also differ in that we will be tracking no other data about the >nameserver except for the nameserver itself, e.g., ns1.foobar.net. >(Currently, we receive the IP address of the nameserver, which is >displayed in whois, but is not used to produce glue records. Since we are >not authoritative for these nameservers, it does not make sense for us to >maintain the IP address.) This is already dealt with by the existing requirements. The IP address of a name server is only required (indeed, is only allowed) if the name server is "registered within the registry's authoritative TLDs". So, only the .NET registry needs to worry about the IP address of NS1.BIGISP.NET. In my scheme, we'd only want one version of the name server to actually have an IP address to avoid states where multiple pointers have the same name but different IP addresses. Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18I5AFO019789 for ietf-provreg-outgoing; Thu, 8 Feb 2001 19:05:10 +0100 (MET) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18I58LN019784 for ; Thu, 8 Feb 2001 19:05:09 +0100 (MET) Received: by dnspri.npac.com; id MAA18489; Thu, 8 Feb 2001 12:05:06 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma018390; Thu, 8 Feb 01 12:04:14 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 12:04:03 -0600 Message-ID: From: Ayesha Damaraju To: ietf-provreg@cafax.se Subject: Transfer Notification a requirement? Date: Thu, 8 Feb 2001 11:59:59 -0600 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 Considering below two requirements from GRRP_reqs_06 3.7 Object Transfer [6] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. ............... ........... [8] Object Transfer requests MUST NOT be acted upon without giving the losing registrar an opportunity to respond to the request... Unless [8] implies that a notification needs to be sent to the losing registrar to approve or reject giving them an opportunity - In which case it needs to be clear, even otherwise notifying the sponsoring registrar to approve or reject the transfer should be a requirement. -Ayesha Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18HiaGJ019625 for ietf-provreg-outgoing; Thu, 8 Feb 2001 18:44:36 +0100 (MET) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18HiZLN019620 for ; Thu, 8 Feb 2001 18:44:35 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id MAA22461 for ; Thu, 8 Feb 2001 12:44:27 -0500 (EST) Received: from localhost (cathym@localhost) by ops.arin.net (8.9.0/8.9.0) with SMTP id MAA15176 for ; Thu, 8 Feb 2001 12:44:26 -0500 (EST) Date: Thu, 8 Feb 2001 12:44:26 -0500 (EST) From: Catherine Murphy To: ietf-provreg@cafax.se Subject: Generalizing the terminology Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk I would like to offer the following specific revisions in an attempt to reduce the domain name emphasis of the draft. I know that some of the recent discussion has already affected the draft, but this mark-up goes against the most recent posting of draft-hollenbeck-grrp-reqs-06.txt. As a general comment, I think the document is well thought out and very thorough. Scott has done a great job getting this started. I also realize that some of my points have already been made. My goal is to offer specific alternatives to the existing text. Only the text containing proposed changes is included below; everything else has been . --------------------------------------------- Cathy Murphy Principal Software Engineer American Registry for Internet Numbers (ARIN) +1 703 227 9875 << Based on draft-hollenbeck-grrp-reqs-06.txt (January 19, 2001) >> 1.1 Definitions, Acronyms, and Abbreviations [NEW] Resource: A generic term used to describe an object that is the primary focus of a registration process. An example of a resource is a domain name or an IP address block. Supporting objects such as contact information are not resources. << If you don't agree with having something along the lines of this new definition, don't bother reading further. Most of the changes revolve around this specific term. >> Registrant: An entity that registers resources in a registry ^^^^^^^^^ through the services provided by a registrar. Registrants include individuals, organizations, and corporations. Registrar: An entity that provides front-end resource registration ^^^^^^^^ services to registrants, providing a public interface to registry services. Registry: An entity that provides back-end resource registration ^^^^^^^^ services to registrars, managing a central repository of information for a specific portion of that resource, e.g., a given TLD. A domain ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^ name registry is typically responsible for publication and distribution ^^^^ of TLD zone files used by the Domain Name System. 2.2 System Functions Registrars access a registry through a protocol to register objects and perform object management functions. Required functions include session management; object creation, update, renewal, and deletion; object query; and object transfer. A domain name registry generates DNS zone files for the TLDs it serves. ^^^^^^^^^^^^^ These zone files are created and distributed to a series of name servers that provide the foundation for the domain name system. Registries MUST provide a whois search capability that provides basic ^^^^ query services for the objects managed by the registry. ... 3.4 Object Registration [1] The protocol MUST provide services to register Internet domain names. << Why? If the protocol is being used for non-domain name resources, this particular requirement seems excessively restrictive, perhaps appropriate for a domain name extension to the "generic" RRP. >> [2] The protocol MUST permit a starting and ending time for a resource registration to be negotiated, thereby ... ^^^^^^^^ [3] When a resource has been successfully registered, ... ^^^^^^^^ [5] If the resource being registered is a domain name, the protocol ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MUST provide services to register name servers. ... << Since there has already been extensive discussion about nameservers being objects versus attributes, I will not comment further here except to re-iterate that this portion of the protocol is somewhat distinct to domain name registries. >> 3.5 Object Association [3] The protocol MUST provide services to associate contacts with resources. Associated contacts name MUST be identified by type. ^^^^^^^^^ Contact types that MAY be associated with a resource include ^^^^^^^^ "registrant", "technical", "administrative", and "billing". A registry MAY support a subset of these contact types. << Also, "abuse" >> 3.6 Object Update [1] The protocol MUST provide services to update information associated with registered resources. Resource update ^^^^^^^^^ ^^^^^^^^ services MUST allow changes to status, associated name servers, and associated contacts. << As far as I can tell, this is the first mention of status. I would like to see the definition of status, which is not defined until 3.12, either moved up or explicitly referenced. When I first read this, my immediate thought was "Huh? Did I miss something? What's a status?" >> [2] If the registry includes registration of associated nameservers, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the protocol MUST provide services to update information associated with registered name servers. Name server update services MUST allow change to IP addresses and server name. 3.7 Object Transfer << A general comment about object transfer: this entire section is very specific to how domain names are transferred and does not relate well at all to when and how IP networks may be transferred. I cannot speak to how other possible users of the GRRP might work transfers, but I will propose other, more generic text for this section in another message thread. Or, this section could be left in the protocol but identified as being domain name specific requirements only. >> 3.8 Object Renewal/Extension [1] The protocol MUST provide services to renew or extend the validity period of registered resources. If applicable, ... ^^^^^^^^^ 3.9 Object Deletion [1] The protocol MUST provide services to remove a resource from the registry. ^^^^^^^^ [2] If the registry contains nameserver objects, the protocol MUST ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ provide services to remove a name server from the registry. << A nit: since this is the protocol, shouldn't these say something like "An implementation of the protocol MUST provide"... >> 3.10 Object Existence Query [1] The protocol MUST provide services to determine if a resource exists in the registry. ... ^^^^^^^^ 3.11 Object Information Query [1] The protocol MUST provide services to retrieve information describing a resource from the registry. Returned information MUST ^^^^^^^^ include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the resource, ^^^^^^^^ the creation date and time, the expiration date and time (if any), the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), the current status of the resource, the most recent authorization ^^^^^^^^ << another pesky status reference w/o definition yet >> identifier, contact identifiers associated with the resource, and, ^^^^^^^^ ^ if applicable, the associated name servers registered to the resource. ^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^ The most recent authorization identifier MUST be returned only to the current sponsoring registrar. 3.12 Domain Status Indicators [1] The protocol MUST provide status indicators that identify the operational state of a resource. ... ^^^^^^^^ [3] A resource MAY have multiple statuses at any given time. Some ^^^^^^^^ statuses MAY be mutually exclusive. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18FvuNI018463 for ietf-provreg-outgoing; Thu, 8 Feb 2001 16:57:56 +0100 (MET) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18FvhLN018454 for ; Thu, 8 Feb 2001 16:57:51 +0100 (MET) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id KAA14889; Thu, 8 Feb 2001 10:57:35 -0500 (EST) Received: from localhost (cathym@localhost) by ops.arin.net (8.9.0/8.9.0) with SMTP id KAA02099; Thu, 8 Feb 2001 10:57:23 -0500 (EST) Date: Thu, 8 Feb 2001 10:57:18 -0500 (EST) From: Catherine Murphy Reply-To: Catherine Murphy To: Kent Crispin , Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se Subject: Re: Nameserver as object/entity or not ? In-Reply-To: <200102062113.f16LDEt02026@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'd like to chime in. Both Eric and Kent state the problem well: Eric Brunner-Williams in Portland Maine wrote: > Making nameservers into first class objects isn't a given, as > the dependency relationship between nameservers objects and domain objects > mandates a contention mechanism. Kent Crispin wrote: > If you have nameserver objects, then you have in effect created > potentially conflicting ownership/authentication domains, and this > seems to me a very fundamental problem. (That is, a domain can be "owned" > by A, while the nameservers for the domain may be owned by "B".) If > only domains can be owned objects, then there are no possible conflicts > (at least in the registry DB). If the GRRP is to be used for something other than domain name registration down the road, e.g., IP address registration, the protocol should leave this characterization aside. IP registries are a case in point. While I can see where some domain registries will want to treat nameservers as objects, we can not. The nameserver information that ARIN receives for in-addr nameservers is an attribute (or dependent object) of the IP network object. Kent's point of potentially conflicting ownership/authentication would also hold true for us. Since we are receiving the information from a particular network registrant, the nameserver information only extends to the scope of his authority, i.e., that network. The same nameservers could quite possibly be listed for other networks, but the authority to change a nameserver is limited. There is not inherent "ownership" of the nameserver information. If both Network A and Network B list ns1.foobar.net as its in-addr nameserver, Network A could not come to us and say, change all instances of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that change against its network; ns1.foobar.net would remain on network B. We also differ in that we will be tracking no other data about the nameserver except for the nameserver itself, e.g., ns1.foobar.net. (Currently, we receive the IP address of the nameserver, which is displayed in whois, but is not used to produce glue records. Since we are not authoritative for these nameservers, it does not make sense for us to maintain the IP address.) Cathy --------------------------------------------- Cathy Murphy Principal Software Engineer American Registry for Internet Numbers (ARIN) +1 703 227 9875 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18FrqmB018403 for ietf-provreg-outgoing; Thu, 8 Feb 2001 16:53:52 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18FroLN018398 for ; Thu, 8 Feb 2001 16:53:50 +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 HAA19677 for ; Thu, 8 Feb 2001 07:53:49 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010208075145.01d62ad8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Thu, 08 Feb 2001 07:53:44 -0800 To: From: Dave Crocker Subject: Re: Agenda for Interim Meeting In-Reply-To: References: <01f901c08f9f$2f18cb60$0a01a8c0@ambler.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Any chance we can start at 9am or even 8:30? No doubt some people would arrive a bit later, just as some people will have to leave a bit early. However traveling that far for such a short meeting makes extending the hours appropriate. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18Ex4kg017706 for ietf-provreg-outgoing; Thu, 8 Feb 2001 15:59:04 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18Ex3LN017701 for ; Thu, 8 Feb 2001 15:59:03 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA10358 for ; Thu, 8 Feb 2001 09:59:02 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9C1A>; Thu, 8 Feb 2001 09:53:51 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Agenda for Interim Meeting Date: Thu, 8 Feb 2001 09:53:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Salon D. There is a directory listing rooms and users in/near the lobby (we will be identified as "IETF provreg Working Group"). Check that directory upon arrival for any unforeseen changes. > -----Original Message----- > From: Christopher Ambler [mailto:cambler-ietf@iodesign.com] > Sent: Wednesday, February 07, 2001 7:28 PM > To: ietf-provreg@cafax.se > Subject: Re: Agenda for Interim Meeting > > > What room will the meeting be in? Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18DenDB017005 for ietf-provreg-outgoing; Thu, 8 Feb 2001 14:40:49 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18DemLN017000 for ; Thu, 8 Feb 2001 14:40:48 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA10046 for ; Thu, 8 Feb 2001 08:40:47 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9CBT>; Thu, 8 Feb 2001 08:35:36 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: 2 points Date: Thu, 8 Feb 2001 08:35:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk OK, I'll strike the proposed second sentence if no one else has any arguments to the contrary. > -----Original Message----- > From: Bill Manning [mailto:bmanning@zed.isi.edu] > Sent: Wednesday, February 07, 2001 10:47 PM > To: shollenbeck@verisign.com > Cc: ietf-provreg@cafax.se > Subject: Re: 2 points > > > % > % [11] The protocol MUST provide services to manage name > % > servers associated > % > % with multiple domains. No name server data SHOULD exist in > % > the registry > % > % without an associated parent domain. > % > > % > I'd loose the second sentence. > % > % Why? The functional implication is that you can end up > with A records in a > % zone without NS records that refer to those A records. > I've been told that > % this won't cause server software like BIND to choke, but > it's not optimal. > % > % > > Hum... > First off, can we "loose" the term domain? Or at least > the concept of "parent"? I am really trying hard to > make this generic. So that the "backend" database and > its administration et.al. that we are talking about has > three generic components: > The delegation point particulars, e.g. the domain > The description of the publication method, e.g. > nameservers > Authorized contacts for each. > > Because the situation is covered in the first sentence. Or there is > an implied linkage in the second. Either the protocol will be able > to "manage" nameservers, regardless of delegation data Or, > you are mandating > that "orpahn" nameserver data SHOULD exist w/o an associated > delegation > data. I would expect that, operationally, there would be times when > namserver data would exist w/o any association to other delegation > information. (Very temporary) At no time should delegation > particulars or > nameserver data exist without accompanying authorized contact data. > > > --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18BJ43r015907 for ietf-provreg-outgoing; Thu, 8 Feb 2001 12:19:04 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18BJ3LN015902 for ; Thu, 8 Feb 2001 12:19:03 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f18BHv5R009030 for ietf-provreg@cafax.se; Thu, 8 Feb 2001 12:17:57 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f183mvLN013294 for ; Thu, 8 Feb 2001 04:48:57 +0100 (MET) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id f183kwX05401; Wed, 7 Feb 2001 19:46:58 -0800 From: Bill Manning Message-Id: <200102080346.f183kwX05401@zed.isi.edu> Subject: Re: 2 points To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 7 Feb 2001 19:46:58 -0800 (PST) Cc: ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Feb 07, 2001 10:17:37 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % > % [11] The protocol MUST provide services to manage name % > servers associated % > % with multiple domains. No name server data SHOULD exist in % > the registry % > % without an associated parent domain. % > % > I'd loose the second sentence. % % Why? The functional implication is that you can end up with A records in a % zone without NS records that refer to those A records. I've been told that % this won't cause server software like BIND to choke, but it's not optimal. % % Hum... First off, can we "loose" the term domain? Or at least the concept of "parent"? I am really trying hard to make this generic. So that the "backend" database and its administration et.al. that we are talking about has three generic components: The delegation point particulars, e.g. the domain The description of the publication method, e.g. nameservers Authorized contacts for each. Because the situation is covered in the first sentence. Or there is an implied linkage in the second. Either the protocol will be able to "manage" nameservers, regardless of delegation data Or, you are mandating that "orpahn" nameserver data SHOULD exist w/o an associated delegation data. I would expect that, operationally, there would be times when namserver data would exist w/o any association to other delegation information. (Very temporary) At no time should delegation particulars or nameserver data exist without accompanying authorized contact data. --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18BItRn015897 for ietf-provreg-outgoing; Thu, 8 Feb 2001 12:18:55 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18BIqLN015892 for ; Thu, 8 Feb 2001 12:18:53 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f18BHlE5009022 for ietf-provreg@cafax.se; Thu, 8 Feb 2001 12:17:47 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f183B5LN013112 for ; Thu, 8 Feb 2001 04:11:06 +0100 (MET) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id f183AsD05309; Wed, 7 Feb 2001 19:10:54 -0800 From: Bill Manning Message-Id: <200102080310.f183AsD05309@zed.isi.edu> Subject: 2 points To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 7 Feb 2001 19:10:54 -0800 (PST) Cc: ietf-provreg@cafax.se ('ietf-provreg@cafax.se') In-Reply-To: from "Hollenbeck, Scott" at Feb 07, 2001 12:13:12 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % [10] All registrars MUST be authorized to register objects in the registry. All registrars % [11] The protocol MUST provide services to manage name servers associated % with multiple domains. No name server data SHOULD exist in the registry % without an associated parent domain. I'd loose the second sentence. % % -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18BIBkQ015877 for ietf-provreg-outgoing; Thu, 8 Feb 2001 12:18:11 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18BI8LN015872 for ; Thu, 8 Feb 2001 12:18:09 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f18BH213008978 for ietf-provreg@cafax.se; Thu, 8 Feb 2001 12:17:02 +0100 (MET) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17HYRLN007791 for ; Wed, 7 Feb 2001 18:34:27 +0100 (MET) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id f17GZWR03811; Wed, 7 Feb 2001 08:35:32 -0800 From: Bill Manning Message-Id: <200102071635.f17GZWR03811@zed.isi.edu> Subject: draft-ops-ip-config-management-reqmnts-00.txt To: ietf-provreg@cafax.se, nanog@merit.edu Date: Wed, 7 Feb 2001 08:35:32 -0800 (PST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Burt just raised this expired draft in the IETF policy working group. He is intending to make this an Informational RFC... so, if folks think this is important, they might want to comment to Burt &/or the Authors. ------------------------------------------------------ Requirements for Configuration Management of IP-based networks ... 1.1 Motivation, Scope and Goals of this document Over the past several months, a number of IETF working groups have introduced new technologies which offer integrated and differentiated services. To support these new technologies, working group members found that they had new requirements for configuration of these technologies. One of these new requirements was for the provisioning (configuration) of behavior at the network level ... -- --bill Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f18Aetvl015605 for ietf-provreg-outgoing; Thu, 8 Feb 2001 11:40:55 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f18AeeLN015600 for ; Thu, 8 Feb 2001 11:40:40 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f18AdYSG008149 for ietf-provreg@cafax.se; Thu, 8 Feb 2001 11:39:34 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16HfN6V025872 for ; Tue, 6 Feb 2001 18:41:25 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f16HZeZ09221; Tue, 6 Feb 2001 12:35:41 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Tue, 6 Feb 2001 12:35:40 -0500 (EST) From: Sheer El-Showk To: =?iso-8859-2?q?J=F6rg_Bauer=2FDenic?= cc: "Brian W. Spolarich" , ietf-provreg@cafax.se, James@Seng.cc, kent@songbird.com, patrick@gandi.net Subject: Re: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id f16HfQ6V025873 Sender: owner-ietf-provreg@cafax.se Precedence: bulk There are several (in my opinion, good) reasons that nameservers are considered seperate entities from the domains in which they are registered. The first is related to the way DNS works. In the zone files of the TLDs there are entries for each name server (I don't work for any TLD mind you ... I'm just saying this from what I know of DNS, and the details may be inaccurate) which serve as glue records so that each TLD name server can find authortiative access for subdomains (the SLDs that actually have real entries for each domain). These glue records are non-authoritative, but necassary and make DNS pretty messy (annoying things can happen if a TLD glue record is out of sync with the authoritative record of the real name servers). Thus it makes sense to have nameservers recorded at the same level as the domains themselves so that there is a more natural mapping from the registry to the zone files. Second, is the requirements registries often put on a domain (at least the way NSI was). For a domain to be registered requires at least two valid nameservers. This means the nameservers have to be registered before the domain itself is (as seperate entities). A third, less technical, reason is minimizing data redundancy and simplifying domain administration. As a registrant I may want to register 10,000 domains all on the same physical DNS server. Rather than registering 10,000 (or 20,000 for each domain) name servers, I just register two for my two main name servers under one of the domains and then register all the domains under these name servers. Of course this can be done if name servers are a domain attribute (you just set the attributes all to be those two name servers); this is just an argument for why the domain and the nameserver are not as closely coupled as being a domain attribute would suggest (and its much more natural for a domain to refer to another DB entity as an attribute, than to refer to an attribute of another domain as one of its attributes -- this would be analogous to refering to another record in a table through a key rather than refering to a sub-record in another record -- sorry if my convoluted language has gotten out of hand). Regards, Sheer On Tue, 6 Feb 2001, [iso-8859-2] Jörg Bauer/Denic wrote: > On 05.02.2001 20:29 "Brian W. Spolarich" wrote: > > > > As a registrant, the thing that I care about is that the nameservers > that > > I registered with my domain don't change unless I explicity authorize the > > change. > > > > I'm wondering if the problem here is the idea of having separate > > nameserver and domain objects. In my mind, the nameserver is an > attribute > > of the domain, and doesn't have any independent identity. What problem > does > > having the nameservers as separate entities solve? > > > > That´s exact the way we do it here in Germany. > We dont´t know anything about Nameserver Objects and i still can´t see it > as a requirement. > > -- > ----------------------------------+------------------------------------------- > > Joerg Bauer | eMail : Joerg.Bauer@denic.de > DENIC eG | Fon : +49 69 272 35 180 > Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 > D-60329 Frankfurt | > ----------------------------------+------------------------------------------- > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f183Mor3013188 for ietf-provreg-outgoing; Thu, 8 Feb 2001 04:22:50 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f183MnLN013183 for ; Thu, 8 Feb 2001 04:22:50 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id WAA09704 for ; Wed, 7 Feb 2001 22:22:48 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1QGTJ3W7>; Wed, 7 Feb 2001 22:17:38 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: 2 points Date: Wed, 7 Feb 2001 22:17:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Bill Manning [mailto:bmanning@zed.isi.edu] > Sent: Wednesday, February 07, 2001 10:11 PM > To: shollenbeck@verisign.com > Cc: ietf-provreg@cafax.se > Subject: 2 points > > > % [10] All registrars MUST be authorized to register objects > in the registry. > > All registrars > > % [11] The protocol MUST provide services to manage name > servers associated > % with multiple domains. No name server data SHOULD exist in > the registry > % without an associated parent domain. > > I'd loose the second sentence. Why? The functional implication is that you can end up with A records in a zone without NS records that refer to those A records. I've been told that this won't cause server software like BIND to choke, but it's not optimal. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1823HjG011948 for ietf-provreg-outgoing; Thu, 8 Feb 2001 03:03:17 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1823GLN011943 for ; Thu, 8 Feb 2001 03:03:16 +0100 (MET) Received: from pentium3 (ppp28d.dialin.elga.net.id [202.173.64.156]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id UAA19107 for ; Wed, 7 Feb 2001 20:54:02 -0600 Message-Id: <200102080254.UAA19107@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Thu, 8 Feb 2001 09:05:56 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-reply-to: <005e01c0912a$c112e9b0$96811c3f@jamessonyvaio> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk As somebody (James?) has pointed out, there are many applications of this protocol. It is not a good idea to restrict the protocol for DNS *only*. For example, the protocol can be used to provide information such as: - cell phone database - URL redirection, Web site directory - SMS - paging - etc. etc. However, if we go for broader term/application, we may not get this protocol up and running quickly. How about if DNS is used as a case/example of this protocol usage? -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f180TmmI011343 for ietf-provreg-outgoing; Thu, 8 Feb 2001 01:29:48 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f180TkLN011337 for ; Thu, 8 Feb 2001 01:29:47 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWG2V; Wed, 7 Feb 2001 16:46:37 -0800 Message-ID: <015d01c09165$f7ee7c20$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: Subject: Re: Agenda for Interim Meeting Date: Wed, 7 Feb 2001 16:27:42 -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 f180TlLN011339 Sender: owner-ietf-provreg@cafax.se Precedence: bulk What room will the meeting be in? -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Wednesday, February 07, 2001 5:11 AM Subject: RE: Agenda for Interim Meeting > This looks reasonable. With limited time it might be wise to identify a set > of macro-level EPP discussion topics before the meeting. > > > > > -----Original Message----- > > From: Edward Lewis [mailto:lewis@tislabs.com] > > Sent: Monday, February 05, 2001 11:17 AM > > To: ietf-provreg@cafax.se > > Cc: lewis@tislabs.com > > Subject: Agenda for Interim Meeting > > > > > > Here's the proposal I sent earlier: > > > > Agenda bashing: (short) > > WG status: (short) > > The EPP proposal > > Other proposals > > Discussion of forming a design team > > > > Comments? > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f180GOSu011239 for ietf-provreg-outgoing; Thu, 8 Feb 2001 01:16:24 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f180GNLN011234 for ; Thu, 8 Feb 2001 01:16:23 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA08558 for ; Wed, 7 Feb 2001 19:16:22 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1QGTJ3LL>; Wed, 7 Feb 2001 19:07:48 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 12:13:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk (Sorry if this is a duplicate message for anyone -- I sent it to the list earlier today, but it doesn't appear to have been redistributed yet.) Good point. I'd like to keep the first sentence of the current wording in it's own requirement, though, because it deals with client privileges. I'd also like to suggest a rewording of your rewording because the "MUST be able to track changes" phrase sounds (to me) like a requirement for keeping state information in the protocol. Would you (and everyone else) be OK with this: [10] All registrars MUST be authorized to register objects in the registry. [11] The protocol MUST provide services to manage name servers associated with multiple domains. No name server data SHOULD exist in the registry without an associated parent domain. > -----Original Message----- > From: James Seng/Personal [mailto:James@Seng.cc] > Sent: Wednesday, February 07, 2001 9:28 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > > Well, when you face with a problem like this such as > > a) Mass changing of IP of Nameservers > b) Consistency of Name servers > c) Delete of parent Domain Name > etc > > Rather than publishing the design (ie nameserver object + name object > and their relationship), you could specify the problem and > make that as > a requirement. > > In this case, this requirement > > [10] All registrars MUST be authorized to register objects in the > registry. Name server registration MUST be limited to the registrar > of the name server's parent domain. Unauthorized attempts > to register > a name server in a parent domain administered by another registrar > MUST be explicitly rejected. > > would become > > [10] The Protocol MUST be able to track changes in > nameservers across > all domain names which is associated with it. No nameserver data > SHOULD exist in the registry if the parent domain names has cease to > exist. > > -James Seng > > ----- Original Message ----- > From: "Hollenbeck, Scott" > To: > Sent: Wednesday, February 07, 2001 6:15 AM > Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > > > FWIW we had quite a lengthy name server management discussion on the > old RRP > > list some months ago, and truth be told we never came to complete > agreement. > > There are positive and negative aspects of managing name servers as > either > > top-level objects or as attributes of other objects, such > as domains. > > > > The attribute idea makes sense in the context of managing a small > number of > > domains, but it gets unwieldy from a management perspective when a > name > > server is hosting thousands or millions of domains. Cross-registrar > > coordination is also tricky if top level server objects and domain > objects > > can be managed by different registrars -- how do things > work if domain > > foo.com must be deleted by one registrar, but another registrar has > > management authority for ns1.foo.com? If domain foo.com > gets deleted, > is it > > a good idea to publish an "orphan" glue record for ns1.foo.com? > > > > Anyway, the current requirements language was thought by me > to be the > most > > reasonable compromise based on operational experience. > > > > > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f180FRqS011223 for ietf-provreg-outgoing; Thu, 8 Feb 2001 01:15:27 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f180FPLN011218 for ; Thu, 8 Feb 2001 01:15:26 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA08181 for ; Wed, 7 Feb 2001 19:15:24 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1QGTJ32P>; Wed, 7 Feb 2001 19:07:43 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 10:26:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Good point. I'd like to keep the first sentence of the current wording in it's own requirement, though, because it deals with client privileges. I'd also like to suggest a rewording of your rewording because the "MUST be able to track changes" phrase sounds (to me) like a requirement for keeping state information in the protocol. Would you (and everyone else) be OK with this: [10] All registrars MUST be authorized to register objects in the registry. [11] The protocol MUST provide services to manage name servers associated with multiple domains. No name server data SHOULD exist in the registry without an associated parent domain. > -----Original Message----- > From: James Seng/Personal [mailto:James@Seng.cc] > Sent: Wednesday, February 07, 2001 9:28 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > > Well, when you face with a problem like this such as > > a) Mass changing of IP of Nameservers > b) Consistency of Name servers > c) Delete of parent Domain Name > etc > > Rather than publishing the design (ie nameserver object + name object > and their relationship), you could specify the problem and > make that as > a requirement. > > In this case, this requirement > > [10] All registrars MUST be authorized to register objects in the > registry. Name server registration MUST be limited to the registrar > of the name server's parent domain. Unauthorized attempts > to register > a name server in a parent domain administered by another registrar > MUST be explicitly rejected. > > would become > > [10] The Protocol MUST be able to track changes in > nameservers across > all domain names which is associated with it. No nameserver data > SHOULD exist in the registry if the parent domain names has cease to > exist. > > -James Seng > > ----- Original Message ----- > From: "Hollenbeck, Scott" > To: > Sent: Wednesday, February 07, 2001 6:15 AM > Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > > > FWIW we had quite a lengthy name server management discussion on the > old RRP > > list some months ago, and truth be told we never came to complete > agreement. > > There are positive and negative aspects of managing name servers as > either > > top-level objects or as attributes of other objects, such > as domains. > > > > The attribute idea makes sense in the context of managing a small > number of > > domains, but it gets unwieldy from a management perspective when a > name > > server is hosting thousands or millions of domains. Cross-registrar > > coordination is also tricky if top level server objects and domain > objects > > can be managed by different registrars -- how do things > work if domain > > foo.com must be deleted by one registrar, but another registrar has > > management authority for ns1.foo.com? If domain foo.com > gets deleted, > is it > > a good idea to publish an "orphan" glue record for ns1.foo.com? > > > > Anyway, the current requirements language was thought by me > to be the > most > > reasonable compromise based on operational experience. > > > > > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f180E3rF011201 for ietf-provreg-outgoing; Thu, 8 Feb 2001 01:14:03 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f180E2LN011196 for ; Thu, 8 Feb 2001 01:14:02 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA07816 for ; Wed, 7 Feb 2001 19:14:00 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1QGTJ316>; Wed, 7 Feb 2001 19:07:39 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Agenda for Interim Meeting Date: Wed, 7 Feb 2001 08:11:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This looks reasonable. With limited time it might be wise to identify a set of macro-level EPP discussion topics before the meeting. > -----Original Message----- > From: Edward Lewis [mailto:lewis@tislabs.com] > Sent: Monday, February 05, 2001 11:17 AM > To: ietf-provreg@cafax.se > Cc: lewis@tislabs.com > Subject: Agenda for Interim Meeting > > > Here's the proposal I sent earlier: > > Agenda bashing: (short) > WG status: (short) > The EPP proposal > Other proposals > Discussion of forming a design team > > Comments? Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17HPMbj007703 for ietf-provreg-outgoing; Wed, 7 Feb 2001 18:25:22 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17HPJLN007698 for ; Wed, 7 Feb 2001 18:25:20 +0100 (MET) Received: from jamessonyvaio (1Cust150.tnt19.tpa2.da.uu.net [63.28.129.150]) by mail.i-dns.net (Postfix) with SMTP id E4B3BFFC01; Thu, 8 Feb 2001 01:25:00 +0800 (SGT) Message-ID: <005e01c0912a$c112e9b0$96811c3f@jamessonyvaio> From: "James Seng/Personal" To: "Mike Lampson" , References: <02e801c09113$a58c37d0$6800a8c0@jamessonyvaio> <016801c0911a$cc16d700$5591a6a5@IS.INFOAVE.NET> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Thu, 8 Feb 2001 01:23:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk In my previous life, I work on BioInformatics Technology. We deal with large amount of data generated from genome project. Unfortunately, these data are scattered in all over the network, university network, commerical network, using varity of database backend, providing different kind of interface, using varity of data schema. No one can agree. Yes, it is kind of nightmare. But if you think about it, it is no different from the problem we facing now, with domain names object scattered in various registries, no standard interface, no fix data schema etc. No one can agree. We probably not qualified to solve their problems. But do not think only Domain Names have these problem. The implication of this provreg could be very little or very huge. ps: Looking back..Imaging if HTTP/HTML is design with requirements that "URL MUST reference to physic information"...I wonder how Internet would look like now. -James Seng ----- Original Message ----- From: "Mike Lampson" To: Sent: Wednesday, February 07, 2001 11:29 PM Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > I am suggesting that > > > > a. Quite a lot of other domain names registries have not read it. > > b. It is probably still incomplete and need more work. > > This is likely true. However, do we care as long as we consider that: > > 1) It is only useful for Registries who want an API for Registrants, > Registrars or Resellers? (Registries with only a single GUI and/or web page > interface won't care.) > > 2) It is truly extensible and enhancements can be added as these other > Registries seek to adopt a common data management model and discover > limitations in this interface? > > I'm not saying we shouldn't build as much capability into this system from > day 1. However, we should work with the specific requirements identified by > those with the most interest and need for a common protocol -- namely the > existing participants on this list. > > By the way, keep YOUR comments coming. Let's just make sure that this > process continues to move forward as quickly as possible. > > Cheers, > > _Mike > -- > Mike Lampson > The Registry at Info Avenue, LLC > (803) 802-6584 > > ----- Original Message ----- > From: "James Seng/Personal" > To: "Sheer El-Showk" ; "Brian W Spolarich" > > Cc: "Patrick" ; "Kent Crispin" ; > > Sent: Wednesday, February 07, 2001 9:38 AM > Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > > > > Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I > > never objected to Scott's GRRP Requirements I-D as a starting group. So > > I make it in plain English: It is a good start. > > > > I am suggesting that > > > > a. Quite a lot of other domain names registries have not read it. > > b. It is probably still incomplete and need more work. > > > > -James Seng > > > > > If it is, then I am definately in agreement with the general > > sentiment. I > > > don't think we should leave domain name authority in the hands of the > > > registrars ... that's an implementation issue (ie per registry) and > > > should certainly not be enforced by the protocol. I don't think, > > however, > > > that this is enough ground to say that Scott's doc is a bad basis for > > a WG > > > (I havn't actually looked over the revised version enough to say > > whether I > > > like it or not). > > > > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17FX7Ht006513 for ietf-provreg-outgoing; Wed, 7 Feb 2001 16:33:07 +0100 (MET) Received: from smtp01.infoave.net (smtp01.infoave.net [165.166.0.26]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17FX6LN006508 for ; Wed, 7 Feb 2001 16:33:06 +0100 (MET) Received: from KR ([165.166.145.85]) by SMTP00.InfoAve.Net (PMDF V6.0-24 #45321) with SMTP id <01JZTQC0EURW8WWPEW@SMTP00.InfoAve.Net> for ietf-provreg@cafax.se; Wed, 07 Feb 2001 10:29:45 -0500 (EST) Date: Wed, 07 Feb 2001 10:29:44 -0500 From: Mike Lampson Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] To: ietf-provreg@cafax.se Message-id: <016801c0911a$cc16d700$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: <02e801c09113$a58c37d0$6800a8c0@jamessonyvaio> Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I am suggesting that > > a. Quite a lot of other domain names registries have not read it. > b. It is probably still incomplete and need more work. This is likely true. However, do we care as long as we consider that: 1) It is only useful for Registries who want an API for Registrants, Registrars or Resellers? (Registries with only a single GUI and/or web page interface won't care.) 2) It is truly extensible and enhancements can be added as these other Registries seek to adopt a common data management model and discover limitations in this interface? I'm not saying we shouldn't build as much capability into this system from day 1. However, we should work with the specific requirements identified by those with the most interest and need for a common protocol -- namely the existing participants on this list. By the way, keep YOUR comments coming. Let's just make sure that this process continues to move forward as quickly as possible. Cheers, _Mike -- Mike Lampson The Registry at Info Avenue, LLC (803) 802-6584 ----- Original Message ----- From: "James Seng/Personal" To: "Sheer El-Showk" ; "Brian W Spolarich" Cc: "Patrick" ; "Kent Crispin" ; Sent: Wednesday, February 07, 2001 9:38 AM Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I > never objected to Scott's GRRP Requirements I-D as a starting group. So > I make it in plain English: It is a good start. > > I am suggesting that > > a. Quite a lot of other domain names registries have not read it. > b. It is probably still incomplete and need more work. > > -James Seng > > > If it is, then I am definately in agreement with the general > sentiment. I > > don't think we should leave domain name authority in the hands of the > > registrars ... that's an implementation issue (ie per registry) and > > should certainly not be enforced by the protocol. I don't think, > however, > > that this is enough ground to say that Scott's doc is a bad basis for > a WG > > (I havn't actually looked over the revised version enough to say > whether I > > like it or not). > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17FSIvj006467 for ietf-provreg-outgoing; Wed, 7 Feb 2001 16:28:18 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17FSHLN006462 for ; Wed, 7 Feb 2001 16:28:17 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f17FQFt04757; Wed, 7 Feb 2001 10:26:15 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102071526.f17FQFt04757@nic-naa.net> To: "James Seng/Personal" cc: "Sheer El-Showk" , "Brian W. Spolarich" , "Patrick" , "Kent Crispin" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: Your message of "Wed, 07 Feb 2001 22:38:27 +0800." <02e801c09113$a58c37d0$6800a8c0@jamessonyvaio> Date: Wed, 07 Feb 2001 10:26:15 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I > never objected to Scott's GRRP Requirements I-D as a starting group. So > I make it in plain English: It is a good start. Progress. Late, after significant smoke and little light, but an improvement. > I am suggesting that > > a. Quite a lot of other domain names registries have not read it. So? The readership levels for the alternatives is even less compelling. > b. It is probably still incomplete and need more work. A given, which could have been verified by writing Scott, or any AD who didn't last-call it on first reading. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17EdvJd006009 for ietf-provreg-outgoing; Wed, 7 Feb 2001 15:39:57 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17EduLN006003 for ; Wed, 7 Feb 2001 15:39:56 +0100 (MET) Received: from jamessonyvaio (3Cust227.tnt18.tpa2.da.uu.net [63.21.176.227]) by mail.i-dns.net (Postfix) with SMTP id 3B339FFC01; Wed, 7 Feb 2001 22:39:36 +0800 (SGT) Message-ID: <02e801c09113$a58c37d0$6800a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Sheer El-Showk" , "Brian W. Spolarich" Cc: "Patrick" , "Kent Crispin" , References: Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 22:38:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I never objected to Scott's GRRP Requirements I-D as a starting group. So I make it in plain English: It is a good start. I am suggesting that a. Quite a lot of other domain names registries have not read it. b. It is probably still incomplete and need more work. -James Seng > If it is, then I am definately in agreement with the general sentiment. I > don't think we should leave domain name authority in the hands of the > registrars ... that's an implementation issue (ie per registry) and > should certainly not be enforced by the protocol. I don't think, however, > that this is enough ground to say that Scott's doc is a bad basis for a WG > (I havn't actually looked over the revised version enough to say whether I > like it or not). Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17EVYjn005912 for ietf-provreg-outgoing; Wed, 7 Feb 2001 15:31:34 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17EVVLN005907 for ; Wed, 7 Feb 2001 15:31:32 +0100 (MET) Received: from jamessonyvaio (3Cust227.tnt18.tpa2.da.uu.net [63.21.176.227]) by mail.i-dns.net (Postfix) with SMTP id 12E4AFFC05; Wed, 7 Feb 2001 22:31:13 +0800 (SGT) Message-ID: <02bc01c09112$78ed9990$6800a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Patrick" , "Urs Eppenberger" Cc: References: <20010205200537.W1113@nohope.patoche.org> <20010205203815.Z1113@nohope.patoche.org> <2846336.981536253@pbue.switch.ch> <20010207112411.B27379@nohope.patoche.org> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 22:28:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk objects may have kind of "ownership". Who has the right to say who owns what object and how it is been used? By associating with parent object may be one a good idea but it does not really work when the child object may have multiple parent object (as in this case of nameserver object). IMHO, authentication are needed for each different objects for different purposes (read, write, reference etc). irregardless whether you refer to domain names, nameservers, contact etc. each of them probably have very funny relationship and ownership. No, this is not a requirement. It is a design approach to the same problem. -James Seng > I'm sorry, maybe because i'm not English, but I do not understand > this. > > The problem remains in my POV : if someone claims to ``own'' a > nameserver, how do you authentify that claim ? > You do a reverse lookup on the name, and obtain an IP. And then ? > How do you know it is correct or not ? > > Sorry for asking, I just do not understand. > But it is true that the hostname can be the key. Still we need > attributes attached to it I think. > > Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17EVT0q005906 for ietf-provreg-outgoing; Wed, 7 Feb 2001 15:31:29 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17EVQLN005901 for ; Wed, 7 Feb 2001 15:31:27 +0100 (MET) Received: from jamessonyvaio (3Cust227.tnt18.tpa2.da.uu.net [63.21.176.227]) by mail.i-dns.net (Postfix) with SMTP id 89E56FFC01; Wed, 7 Feb 2001 22:31:08 +0800 (SGT) Message-ID: <02bb01c09112$75e6e940$6800a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Hollenbeck, Scott" , References: Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 22:28:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Well, when you face with a problem like this such as a) Mass changing of IP of Nameservers b) Consistency of Name servers c) Delete of parent Domain Name etc Rather than publishing the design (ie nameserver object + name object and their relationship), you could specify the problem and make that as a requirement. In this case, this requirement [10] All registrars MUST be authorized to register objects in the registry. Name server registration MUST be limited to the registrar of the name server's parent domain. Unauthorized attempts to register a name server in a parent domain administered by another registrar MUST be explicitly rejected. would become [10] The Protocol MUST be able to track changes in nameservers across all domain names which is associated with it. No nameserver data SHOULD exist in the registry if the parent domain names has cease to exist. -James Seng ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Wednesday, February 07, 2001 6:15 AM Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > FWIW we had quite a lengthy name server management discussion on the old RRP > list some months ago, and truth be told we never came to complete agreement. > There are positive and negative aspects of managing name servers as either > top-level objects or as attributes of other objects, such as domains. > > The attribute idea makes sense in the context of managing a small number of > domains, but it gets unwieldy from a management perspective when a name > server is hosting thousands or millions of domains. Cross-registrar > coordination is also tricky if top level server objects and domain objects > can be managed by different registrars -- how do things work if domain > foo.com must be deleted by one registrar, but another registrar has > management authority for ns1.foo.com? If domain foo.com gets deleted, is it > a good idea to publish an "orphan" glue record for ns1.foo.com? > > Anyway, the current requirements language was thought by me to be the most > reasonable compromise based on operational experience. > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17Aa4gC004039 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:36:04 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17Aa3LN004034 for ; Wed, 7 Feb 2001 11:36:04 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA27778; Wed, 7 Feb 2001 11:36:03 +0100 Date: Wed, 7 Feb 2001 11:36:03 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Nameserver as object/entity or not ? Message-ID: <20010207113603.D27379@nohope.patoche.org> References: <20010206151806.L16273@nohope.patoche.org> <20010206091959.C21451@songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010206091959.C21451@songbird.com>; from kent@songbird.com on Tue, Feb 06, 2001 at 09:19:59AM -0800 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Feb 06, 2001 at 09:19:59AM -0800, Kent Crispin took time to write: > If you have nameserver objects, then you have in effect created > potentially conflicting ownership/authentication domains, and this > seems to me a very fundamental problem. (That is, a domain can be "owned" > by A, while the nameservers for the domain may be owned by "B".) If > only domains can be owned objects, then there are no possible conflicts > (at least in the registry DB). You have the exact same problems in other cases too, like for contacts (handle) : domain owned by A who uses contact owned by B. Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17AY4hI003967 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:34:04 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17AY3LN003962 for ; Wed, 7 Feb 2001 11:34:03 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA27732; Wed, 7 Feb 2001 11:32:10 +0100 Date: Wed, 7 Feb 2001 11:32:10 +0100 From: Patrick To: Sheer El-Showk Cc: "Brian W. Spolarich" , James Seng/Personal , Kent Crispin , ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <20010207113210.C27379@nohope.patoche.org> 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 sheer@saraf.com on Tue, Feb 06, 2001 at 10:17:38AM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Feb 06, 2001 at 10:17:38AM -0500, Sheer El-Showk took time to write: > posting. What he was complaining about was that the authority to register > a nameserver under a domain resided with the Registrar which held the > domain, not the registrant. As a registrant I may register domain D1 with Like the authority to change nameservers of a domain resides with (through) the Registrar used to register the domain name. > registrar R1, but want to register nameserver N1 within D1 (this is an > important distinction -- the domain of nameservers for a particular > domain is not restricted, eg foobar.com can have ns1.foobar.tv as its > nameserver, but any nameservers being registered _within_ a domain > must be registered by the source of authority for the domain -- the > registrant or the registrar, eg only the owner of foobar.com should be > able to register the nameserver ns1.foobar.com as a nameserver) with That is exactly what needs to be done, I agree. > registrar R2. James was saying that there should be some kind of token of > authority (a PGP key?? ;->) that allows me as a registrant to do > authoritative things for my domain (like register a nameserver under > it) through any registrar, not just the one with which I registered the > domain. I do not understand why here we try to let the registrant do things wirthout going through a Registrar. Why make the registration of nameserver a different case ? The same problem exist in other part : like for contacts in the thick registry. How do you handle them ? Someone register a contact through a given Registrar. To help avoid the actual handle problems (each different for a Registrar), they should be unique. Who can change them ? Through wich Registrar ? > If it is, then I am definately in agreement with the general sentiment. I > don't think we should leave domain name authority in the hands of the > registrars ... that's an implementation issue (ie per registry) and Other than that I really welcome a global setup where registrant could make changes directly, without going through a Registrar, or using whatever Registrar they want. But if you go that route, you must consider all cases (change of ownership, change of contacts, change of Registar, change of nameservers, etc...). It seems to me a difficult case, but really interesting. However going that way can really fast lead to this question : what purpose has the Registrar if a Registrant can do anything he wants directly to the Registry without using a Registrar ? Or by choosing any Registrar to do modifications by himself. Would RRP (or its successor) be also a RegisTRANT-RegisTRY protocol ? Regards, Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17AOEea003874 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:24:14 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17AODLN003869 for ; Wed, 7 Feb 2001 11:24:13 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA27642; Wed, 7 Feb 2001 11:24:11 +0100 Date: Wed, 7 Feb 2001 11:24:11 +0100 From: Patrick To: Urs Eppenberger Cc: ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <20010207112411.B27379@nohope.patoche.org> References: <20010205200537.W1113@nohope.patoche.org> <20010205203815.Z1113@nohope.patoche.org> <2846336.981536253@pbue.switch.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2846336.981536253@pbue.switch.ch>; from urs.eppenberger@switch.ch on Wed, Feb 07, 2001 at 08:57:33AM +0100 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Feb 07, 2001 at 08:57:33AM +0100, Urs Eppenberger took time to write: > --On Montag, 5. Februar 2001 20:38 Uhr +0100 Patrick > wrote: > > > Right... because you do not use ns1.foobar.com and ns2.foobar.com as > > nameserver. In your case, someone just polluted the database. > > As soon as your domain use ns{1,2}.foobar.com, you are hijacked... > > > > That is inconvenient, since when the true owner will want to register > > them for its true use, the Registry might not allow him, since they > > already exist (with bogus data). How do you control who can change > > the IP ? > > You can get easy around this hijack problem. Just use the host name as the > object handle (or database key). Reverselookup must work. In such a case > you as holder of foobar.com has authority over *.foobar.com, generally you > can walk over to that guy and knock him. So, if a 'wrong' owner registered ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what does that mean ? > a bogus hijack-nameserver, that wrong owner sits close. You most probably > have administrative control in your company over such a situation and there > is no need for the registry or for the protocol to ensure a correct > behaviour inside third party organisations. I'm sorry, maybe because i'm not English, but I do not understand this. The problem remains in my POV : if someone claims to ``own'' a nameserver, how do you authentify that claim ? You do a reverse lookup on the name, and obtain an IP. And then ? How do you know it is correct or not ? Sorry for asking, I just do not understand. But it is true that the hostname can be the key. Still we need attributes attached to it I think. Patrick. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17A6Hp4003780 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:06:17 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17A6FLN003775 for ; Wed, 7 Feb 2001 11:06:16 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f17A5KdN000859 for ietf-provreg@cafax.se; Wed, 7 Feb 2001 11:05:20 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16HfN6V025872 for ; Tue, 6 Feb 2001 18:41:25 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f16HZeZ09221; Tue, 6 Feb 2001 12:35:41 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Tue, 6 Feb 2001 12:35:40 -0500 (EST) From: Sheer El-Showk To: =?iso-8859-2?q?J=F6rg_Bauer=2FDenic?= cc: "Brian W. Spolarich" , ietf-provreg@cafax.se, James@Seng.cc, kent@songbird.com, patrick@gandi.net Subject: Re: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id f16HfQ6V025873 Sender: owner-ietf-provreg@cafax.se Precedence: bulk There are several (in my opinion, good) reasons that nameservers are considered seperate entities from the domains in which they are registered. The first is related to the way DNS works. In the zone files of the TLDs there are entries for each name server (I don't work for any TLD mind you ... I'm just saying this from what I know of DNS, and the details may be inaccurate) which serve as glue records so that each TLD name server can find authortiative access for subdomains (the SLDs that actually have real entries for each domain). These glue records are non-authoritative, but necassary and make DNS pretty messy (annoying things can happen if a TLD glue record is out of sync with the authoritative record of the real name servers). Thus it makes sense to have nameservers recorded at the same level as the domains themselves so that there is a more natural mapping from the registry to the zone files. Second, is the requirements registries often put on a domain (at least the way NSI was). For a domain to be registered requires at least two valid nameservers. This means the nameservers have to be registered before the domain itself is (as seperate entities). A third, less technical, reason is minimizing data redundancy and simplifying domain administration. As a registrant I may want to register 10,000 domains all on the same physical DNS server. Rather than registering 10,000 (or 20,000 for each domain) name servers, I just register two for my two main name servers under one of the domains and then register all the domains under these name servers. Of course this can be done if name servers are a domain attribute (you just set the attributes all to be those two name servers); this is just an argument for why the domain and the nameserver are not as closely coupled as being a domain attribute would suggest (and its much more natural for a domain to refer to another DB entity as an attribute, than to refer to an attribute of another domain as one of its attributes -- this would be analogous to refering to another record in a table through a key rather than refering to a sub-record in another record -- sorry if my convoluted language has gotten out of hand). Regards, Sheer On Tue, 6 Feb 2001, [iso-8859-2] Jörg Bauer/Denic wrote: > On 05.02.2001 20:29 "Brian W. Spolarich" wrote: > > > > As a registrant, the thing that I care about is that the nameservers > that > > I registered with my domain don't change unless I explicity authorize the > > change. > > > > I'm wondering if the problem here is the idea of having separate > > nameserver and domain objects. In my mind, the nameserver is an > attribute > > of the domain, and doesn't have any independent identity. What problem > does > > having the nameservers as separate entities solve? > > > > That´s exact the way we do it here in Germany. > We dont´t know anything about Nameserver Objects and i still can´t see it > as a requirement. > > -- > ----------------------------------+------------------------------------------- > > Joerg Bauer | eMail : Joerg.Bauer@denic.de > DENIC eG | Fon : +49 69 272 35 180 > Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 > D-60329 Frankfurt | > ----------------------------------+------------------------------------------- > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17A5Grh003770 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:05:16 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17A59LN003765 for ; Wed, 7 Feb 2001 11:05:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f17A4E3C000811 for ietf-provreg@cafax.se; Wed, 7 Feb 2001 11:04:14 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16FNn6V024174 for ; Tue, 6 Feb 2001 16:23:50 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f16FHcw08781; Tue, 6 Feb 2001 10:17:38 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Tue, 6 Feb 2001 10:17:38 -0500 (EST) From: Sheer El-Showk To: "Brian W. Spolarich" cc: Patrick , James Seng/Personal , Kent Crispin , ietf-provreg@cafax.se Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Actually, all this is missing the point of (James') the original posting. What he was complaining about was that the authority to register a nameserver under a domain resided with the Registrar which held the domain, not the registrant. As a registrant I may register domain D1 with registrar R1, but want to register nameserver N1 within D1 (this is an important distinction -- the domain of nameservers for a particular domain is not restricted, eg foobar.com can have ns1.foobar.tv as its nameserver, but any nameservers being registered _within_ a domain must be registered by the source of authority for the domain -- the registrant or the registrar, eg only the owner of foobar.com should be able to register the nameserver ns1.foobar.com as a nameserver) with registrar R2. James was saying that there should be some kind of token of authority (a PGP key?? ;->) that allows me as a registrant to do authoritative things for my domain (like register a nameserver under it) through any registrar, not just the one with which I registered the domain. James, is that right? If it is, then I am definately in agreement with the general sentiment. I don't think we should leave domain name authority in the hands of the registrars ... that's an implementation issue (ie per registry) and should certainly not be enforced by the protocol. I don't think, however, that this is enough ground to say that Scott's doc is a bad basis for a WG (I havn't actually looked over the revised version enough to say whether I like it or not). Sorry for that complex clarification. Hope it helps. Regards, Sheer On Mon, 5 Feb 2001, Brian W. Spolarich wrote: > | If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then > | basically anyone can hijack my domain (pointing www.foobar.com to > | whatever IP, etc...) > | > | Thus the nameservers must be only registered by the Registrar who has > | registered foobar.com, and the Registrar must ensure that only > | someone with authority on foobar.com (contacts) can create > | *.foobar.com > | > | There is no conflict possible in that case. > | A given nameserver can only be registered once (even if it is used in > | many domains) through only a given Registrar. > > Okay, I get it. :-) I figured it was something like that, but was having > a hard time with the language. > > I don't see as strong of a coupling between the hostnames associated with > the authoritative nameservers for a domain and the hijacking problem. It is > ultimately what shows up in the NS records associated with the domain that > matters. I might choose to delegate foobar.com to ns1.myisp.net and > ns2.myisp.net. If someone registers nameservers ns1.foobar.com and > ns2.foobar.com in the registry this is inconvenient and annoying, but not > really a hijcaking issue. > > In addition, I'm not sure that this coupling will work well in a very > distributed context. Lets say that I own 'foobar.com' today, registered > through registrar 'spumco' and I have two nameservers running, > ns1.foobar.com and ns2.foobar.com. I want to register 'foobar.biz' and > 'foobar.info', using my current nameservers, ns{1,2}.foobar.com. > > In order to complete the domain registration I'll have to register my > nameservers into the .biz and .info registries. Registrar 'spumco', who > performed the 'foobar.com' registration, doesn't offer registrations with > .biz and .info, so I go to registrar 'blammo'. > > Does this mean that I cannot register my nameservers through 'blammo' with > .biz because 'spumco' holds the registration for 'foobar' in .com? > > This seems problematic. > > As a registrant, the thing that I care about is that the nameservers that > I registered with my domain don't change unless I explicity authorize the > change. > > I'm wondering if the problem here is the idea of having separate > nameserver and domain objects. In my mind, the nameserver is an attribute > of the domain, and doesn't have any independent identity. What problem does > having the nameservers as separate entities solve? > > -bws > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17A2SAB003733 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:02:28 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17A2RLN003728 for ; Wed, 7 Feb 2001 11:02:27 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f17A1WMC000735 for ietf-provreg@cafax.se; Wed, 7 Feb 2001 11:01:32 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16EIo6V023621 for ; Tue, 6 Feb 2001 15:18:50 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id PAA18629; Tue, 6 Feb 2001 15:18:06 +0100 Date: Tue, 6 Feb 2001 15:18:06 +0100 From: Patrick To: "Brian W. Spolarich" Cc: J?rg Bauer/Denic , ietf-provreg@cafax.se, James@Seng.cc, kent@songbird.com Subject: Nameserver as object/entity or not ? Message-ID: <20010206151806.L16273@nohope.patoche.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from briansp@walid.com on Tue, Feb 06, 2001 at 08:58:03AM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Feb 06, 2001 at 08:58:03AM -0500, Brian W. Spolarich took time to write: > > | That´s exact the way we do it here in Germany. > | We dont´t know anything about Nameserver Objects and i still can´t see it > | as a requirement. > > As Patrick pointed out, one advantage to keeping separate NS objects is that > if one needs to change the address of a given server, only one record needs to be > updated (i.e. normalization). It would be interesting to know how often this is > used. >From experience, I can tell you that it is used. I was working before in an ISP. One day we had to change our Internet connexion, which changed the IP of our nameservers, thus the need to change the properties of all domains using these nameservers. I'm working in a Registrar now, and it happens that customer ask us to change 50 or 100 domains at the same time because they change nameservers or they change IP of one nameserver. Let me give also another attribute that we can have for a nameserver : the property, ie who owns it. It happens that sometimes people are using nameservers for a domain by mistake (ie not the correct nameserver). Then the given nameserver, not configured for the domain, is still asked for information by other nameservers around the world. That is lame delegation, ok, no big deal. But like one of our customer asked some times ago, there can be a lot of things like that, putting charge on the nameserver. The customer wanted to know if we (the Registrar) could remove the given nameserver from the list of nameserver used by domains they do not handle. Problem : how do we authentify a request like that ? The customer in question wanted just to give us a fax on company letterhead stating : such and such nameserver are ours, please be sure they are only used for domains such and such. However we have no (easy/automated/foolproof) way of verifying that was is written on the document is true. I do not know if it is useful, but having an attribute 'owned by' might be of interest. It strikes me that there is also the whole thing with DNSSEC. AFAIK (which is little) about that, nameserver have keys, and other must know them. How do you distribute keys ? If the nameserver is in object in the Registry database, you can associate with it its key to be used by whoever needs them. Just an idea. -- Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f17A2A1f003722 for ietf-provreg-outgoing; Wed, 7 Feb 2001 11:02:10 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f17A1pLN003715 for ; Wed, 7 Feb 2001 11:01:51 +0100 (MET) Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f17A0tcg000723 for ietf-provreg@cafax.se; Wed, 7 Feb 2001 11:00:55 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16Dum6V023461 for ; Tue, 6 Feb 2001 14:56:49 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id NAA11218; Tue, 6 Feb 2001 13:53:48 GMT From: "Brian W. Spolarich" To: =?utf-8?Q?J=C3=B6rg_Bauer/Denic?= Cc: , , , Subject: RE: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Tue, 6 Feb 2001 08:58:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f16Dun6V023462 Sender: owner-ietf-provreg@cafax.se Precedence: bulk | That´s exact the way we do it here in Germany. | We dont´t know anything about Nameserver Objects and i still can´t see it | as a requirement. As Patrick pointed out, one advantage to keeping separate NS objects is that if one needs to change the address of a given server, only one record needs to be updated (i.e. normalization). It would be interesting to know how often this is used. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f177vW07002944 for ietf-provreg-outgoing; Wed, 7 Feb 2001 08:57:32 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f177vVLN002939 for ; Wed, 7 Feb 2001 08:57:31 +0100 (MET) Received: from pbue.switch.ch ([130.59.4.112]) by central.switch.ch with esmtp (Exim 3.15 #3) id 14QPTm-0007hx-00 for ietf-provreg@cafax.se; Wed, 07 Feb 2001 08:57:30 +0100 Date: Wed, 07 Feb 2001 08:57:33 +0100 From: Urs Eppenberger To: ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <2846336.981536253@pbue.switch.ch> In-Reply-To: <20010205203815.Z1113@nohope.patoche.org> References: <20010205200537.W1113@nohope.patoche.org> <20010205203815.Z1113@nohope.patoche.org> X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On Montag, 5. Februar 2001 20:38 Uhr +0100 Patrick wrote: > Right... because you do not use ns1.foobar.com and ns2.foobar.com as > nameserver. In your case, someone just polluted the database. > As soon as your domain use ns{1,2}.foobar.com, you are hijacked... > > That is inconvenient, since when the true owner will want to register > them for its true use, the Registry might not allow him, since they > already exist (with bogus data). How do you control who can change > the IP ? You can get easy around this hijack problem. Just use the host name as the object handle (or database key). Reverselookup must work. In such a case you as holder of foobar.com has authority over *.foobar.com, generally you can walk over to that guy and knock him. So, if a 'wrong' owner registered a bogus hijack-nameserver, that wrong owner sits close. You most probably have administrative control in your company over such a situation and there is no need for the registry or for the protocol to ensure a correct behaviour inside third party organisations. Urs. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1777Xr5002678 for ietf-provreg-outgoing; Wed, 7 Feb 2001 08:07:33 +0100 (MET) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1777WLN002673 for ; Wed, 7 Feb 2001 08:07:32 +0100 (MET) Received: from pbue.switch.ch ([130.59.4.112]) by central.switch.ch with esmtp (Exim 3.15 #3) id 14QOhP-0007J8-01 for ietf-provreg@cafax.se; Wed, 07 Feb 2001 08:07:31 +0100 Date: Wed, 07 Feb 2001 07:55:54 +0100 From: Urs Eppenberger To: ietf-provreg@cafax.se Subject: Re: Nameserver as object/entity or not ? Message-ID: <2660393.981532554@localhost> In-Reply-To: <20010206091959.C21451@songbird.com> References: <20010206151806.L16273@nohope.patoche.org> <20010206091959.C21451@songbird.com> X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On Dienstag, 6. Februar 2001 9:19 Uhr -0800 Kent Crispin wrote: > If you have nameserver objects, then you have in effect created > potentially conflicting ownership/authentication domains, and this > seems to me a very fundamental problem. (That is, a domain can be "owned" > by A, while the nameservers for the domain may be owned by "B".) If > only domains can be owned objects, then there are no possible conflicts > (at least in the registry DB). Hello Kent et al We at SWITCH (registry for TLD .ch and .li) have three objects: contact, domain and host. See www.nic.ch/batch for a manual which has a nicer picture with the data model. As Bill pointed out, having these three objects makes changes easier, because in many cases you need only change one single object (IP Adress of a host, Fax Number of a contact). Kent wrote about 'ownership' of these objects. We handle it like this: object contains owned by contact person data (name, e-mail,...) the person itself domain pointers to holder/hosts holder host hostmaster,IP adresses (if needed) hostmaster The owner has the right to change attributes. This works quite well. It hasa drawbacks, especially in the case of domains, where the holder often just does not care since a ISP does all the work for him. But many domain holders are very happy to be in full control. PROVREG should support such a data model. Scotts proposal does. Urs. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16ML6MT028525 for ietf-provreg-outgoing; Tue, 6 Feb 2001 23:21:06 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16ML5LN028520 for ; Tue, 6 Feb 2001 23:21:05 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA07036 for ; Tue, 6 Feb 2001 17:21:04 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Feb 2001 17:15:56 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Tue, 6 Feb 2001 17:15:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk FWIW we had quite a lengthy name server management discussion on the old RRP list some months ago, and truth be told we never came to complete agreement. There are positive and negative aspects of managing name servers as either top-level objects or as attributes of other objects, such as domains. The attribute idea makes sense in the context of managing a small number of domains, but it gets unwieldy from a management perspective when a name server is hosting thousands or millions of domains. Cross-registrar coordination is also tricky if top level server objects and domain objects can be managed by different registrars -- how do things work if domain foo.com must be deleted by one registrar, but another registrar has management authority for ns1.foo.com? If domain foo.com gets deleted, is it a good idea to publish an "orphan" glue record for ns1.foo.com? Anyway, the current requirements language was thought by me to be the most reasonable compromise based on operational experience. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16LJCJ6028001 for ietf-provreg-outgoing; Tue, 6 Feb 2001 22:19:12 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16LJBLN027996 for ; Tue, 6 Feb 2001 22:19:11 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f16LDEt02026; Tue, 6 Feb 2001 16:13:14 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102062113.f16LDEt02026@nic-naa.net> To: Kent Crispin cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Nameserver as object/entity or not ? In-Reply-To: Your message of "Tue, 06 Feb 2001 09:19:59 PST." <20010206091959.C21451@songbird.com> Date: Tue, 06 Feb 2001 16:13:14 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Kent, I concure. Making nameservers into first class objects isn't a given, as the dependency relationship between nameservers objects and domain objects mandates a contention mechanism. Performing bulk ops on domain objects using a nameserver object as a key is a convience funtion, nice but no more necesary than any other built-in iterator/aggregator operator. The edge cases that occur to me are deletion, when a nameserver object has no domains object dependencies, and creation. Neither special case requires a general promotion of the nameserver object to a first class object. Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16KtoGC027668 for ietf-provreg-outgoing; Tue, 6 Feb 2001 21:55:50 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16Ktm6V027662 for ; Tue, 6 Feb 2001 21:55:49 +0100 (MET) Received: from jamessonyvaio (adsl-63-206-116-141.dsl.snfc21.pacbell.net [63.206.116.141]) by mail.i-dns.net (Postfix) with SMTP id D3116FFC01; Wed, 7 Feb 2001 04:55:30 +0800 (SGT) Message-ID: <00bc01c0907e$fdc81080$6800a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Bill Manning" , "Brian W. Spolarich" Cc: "Patrick" , References: <200102061557.f16FvVw18778@zed.isi.edu> Subject: Re: Nameserver as object/entity or not ? Date: Wed, 7 Feb 2001 04:54:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a very reasonable requirement. If the original requirement is to overcome this problem, then I suggest rewording it to something like what Bill said below. -James Seng ----- Original Message ----- From: "Bill Manning" To: "Brian W. Spolarich" Cc: "Patrick" ; Sent: Tuesday, February 06, 2001 11:57 PM Subject: Re: Nameserver as object/entity or not ? > % > % | >From experience, I can tell you that it is used. I was working before > % | in an ISP. One day we had to change our Internet connexion, which > % | changed the IP of our nameservers, thus the need to change the > % | properties of all domains using these nameservers. > % | I'm working in a Registrar now, and it happens that customer ask us > % | to change 50 or 100 domains at the same time because they change > % | nameservers or they change IP of one nameserver. > > A case in point. A server was recently renumbered and the host record > at the registrar was modified. This server was/is hosting a number > of distinct zone entries. Apparently the internal protocol tracked > the new number at a number of levels but did not work across the board. > This server also serves as a server for a number of ccTLDs and the "glue" > records for this server at those ccTLDs was -NOT- automatically updated... > leading to "lame" server indications. So the protocol ought to ensure > that when a "host" record is modified, that it can be tracked throughout > the system. > > -- > --bill Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16Kqs8K027611 for ietf-provreg-outgoing; Tue, 6 Feb 2001 21:52:54 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16Kqp6V027604 for ; Tue, 6 Feb 2001 21:52:52 +0100 (MET) Received: from jamessonyvaio (adsl-63-206-116-141.dsl.snfc21.pacbell.net [63.206.116.141]) by mail.i-dns.net (Postfix) with SMTP id E23FBFFC04; Wed, 7 Feb 2001 04:52:31 +0800 (SGT) Message-ID: <00b001c0907e$9349a4d0$6800a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Sheer El-Showk" , "Brian W. Spolarich" Cc: "Patrick" , "Kent Crispin" , References: Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Wed, 7 Feb 2001 04:51:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Actually I was watching this lively discussion so I didnt want to interrupt. :-) But yea, Sheer got the my point. This is one place whereby certain policy (however reasonable it seem) leak into the requirements/protocols. -James Seng ----- Original Message ----- From: "Sheer El-Showk" To: "Brian W. Spolarich" Cc: "Patrick" ; "James Seng/Personal" ; "Kent Crispin" ; Sent: Tuesday, February 06, 2001 11:17 PM Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] > Actually, all this is missing the point of (James') the original > posting. What he was complaining about was that the authority to register > a nameserver under a domain resided with the Registrar which held the > domain, not the registrant. As a registrant I may register domain D1 with > registrar R1, but want to register nameserver N1 within D1 (this is an > important distinction -- the domain of nameservers for a particular > domain is not restricted, eg foobar.com can have ns1.foobar.tv as its > nameserver, but any nameservers being registered _within_ a domain > must be registered by the source of authority for the domain -- the > registrant or the registrar, eg only the owner of foobar.com should be > able to register the nameserver ns1.foobar.com as a nameserver) with > registrar R2. James was saying that there should be some kind of token of > authority (a PGP key?? ;->) that allows me as a registrant to do > authoritative things for my domain (like register a nameserver under > it) through any registrar, not just the one with which I registered the > domain. > > James, is that right? > > If it is, then I am definately in agreement with the general sentiment. I > don't think we should leave domain name authority in the hands of the > registrars ... that's an implementation issue (ie per registry) and > should certainly not be enforced by the protocol. I don't think, however, > that this is enough ground to say that Scott's doc is a bad basis for a WG > (I havn't actually looked over the revised version enough to say whether I > like it or not). > > Sorry for that complex clarification. Hope it helps. > > Regards, > Sheer > > On Mon, 5 Feb 2001, Brian W. Spolarich wrote: > > > | If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then > > | basically anyone can hijack my domain (pointing www.foobar.com to > > | whatever IP, etc...) > > | > > | Thus the nameservers must be only registered by the Registrar who has > > | registered foobar.com, and the Registrar must ensure that only > > | someone with authority on foobar.com (contacts) can create > > | *.foobar.com > > | > > | There is no conflict possible in that case. > > | A given nameserver can only be registered once (even if it is used in > > | many domains) through only a given Registrar. > > > > Okay, I get it. :-) I figured it was something like that, but was having > > a hard time with the language. > > > > I don't see as strong of a coupling between the hostnames associated with > > the authoritative nameservers for a domain and the hijacking problem. It is > > ultimately what shows up in the NS records associated with the domain that > > matters. I might choose to delegate foobar.com to ns1.myisp.net and > > ns2.myisp.net. If someone registers nameservers ns1.foobar.com and > > ns2.foobar.com in the registry this is inconvenient and annoying, but not > > really a hijcaking issue. > > > > In addition, I'm not sure that this coupling will work well in a very > > distributed context. Lets say that I own 'foobar.com' today, registered > > through registrar 'spumco' and I have two nameservers running, > > ns1.foobar.com and ns2.foobar.com. I want to register 'foobar.biz' and > > 'foobar.info', using my current nameservers, ns{1,2}.foobar.com. > > > > In order to complete the domain registration I'll have to register my > > nameservers into the .biz and .info registries. Registrar 'spumco', who > > performed the 'foobar.com' registration, doesn't offer registrations with > > .biz and .info, so I go to registrar 'blammo'. > > > > Does this mean that I cannot register my nameservers through 'blammo' with > > .biz because 'spumco' holds the registration for 'foobar' in .com? > > > > This seems problematic. > > > > As a registrant, the thing that I care about is that the nameservers that > > I registered with my domain don't change unless I explicity authorize the > > change. > > > > I'm wondering if the problem here is the idea of having separate > > nameserver and domain objects. In my mind, the nameserver is an attribute > > of the domain, and doesn't have any independent identity. What problem does > > having the nameservers as separate entities solve? > > > > -bws > > > > > > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16HSfoc025748 for ietf-provreg-outgoing; Tue, 6 Feb 2001 18:28:41 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16HSd6V025743 for ; Tue, 6 Feb 2001 18:28:40 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id JAA27036 for ietf-provreg@cafax.se; Tue, 6 Feb 2001 09:19:59 -0800 Message-ID: <20010206091959.C21451@songbird.com> Date: Tue, 6 Feb 2001 09:19:59 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Nameserver as object/entity or not ? Mail-Followup-To: ietf-provreg@cafax.se References: <20010206151806.L16273@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Brian W. Spolarich on Tue, Feb 06, 2001 at 10:02:47AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Feb 06, 2001 at 10:02:47AM -0500, Brian W. Spolarich wrote: > | I'm working in a Registrar now, and it happens that customer ask us > | to change 50 or 100 domains at the same time because they change > | nameservers or they change IP of one nameserver. > > This is a good point, and my mindset tends to not be focused on > service-provider concerns as much as registrant concerns (somewhat ironic > given I used to work for a rather large ISP). ISPs who renumbered would > have an impossible time if they had to coordinate a massive batch of updates > to the registration entries for all of their customer domains for which they > were providing nameservice. > > I would say that this concern alone would warrant a requirement that the > nameserver entities be managed separately. Though apparently there are registries that do not provide this service, and things seem to work... In any case, what you describe is a requirement that there be a way to manipulate all records that include a particular nameserver. It is not a requirement that nameserver objects should exist -- that is an implementation detail. If you have nameserver objects, then you have in effect created potentially conflicting ownership/authentication domains, and this seems to me a very fundamental problem. (That is, a domain can be "owned" by A, while the nameservers for the domain may be owned by "B".) If only domains can be owned objects, then there are no possible conflicts (at least in the registry DB). -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16GuiS2025443 for ietf-provreg-outgoing; Tue, 6 Feb 2001 17:56:44 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16Guh6V025438 for ; Tue, 6 Feb 2001 17:56:43 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f16GuQU24562; Tue, 6 Feb 2001 08:56:26 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f16FvVw18778; Tue, 6 Feb 2001 07:57:31 -0800 Message-Id: <200102061557.f16FvVw18778@zed.isi.edu> Subject: Re: Nameserver as object/entity or not ? To: briansp@walid.com (Brian W. Spolarich) Date: Tue, 6 Feb 2001 07:57:30 -0800 (PST) Cc: patrick@gandi.net (Patrick), ietf-provreg@cafax.se In-Reply-To: from "Brian W. Spolarich" at Feb 06, 2001 10:02:47 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % % | >From experience, I can tell you that it is used. I was working before % | in an ISP. One day we had to change our Internet connexion, which % | changed the IP of our nameservers, thus the need to change the % | properties of all domains using these nameservers. % | I'm working in a Registrar now, and it happens that customer ask us % | to change 50 or 100 domains at the same time because they change % | nameservers or they change IP of one nameserver. A case in point. A server was recently renumbered and the host record at the registrar was modified. This server was/is hosting a number of distinct zone entries. Apparently the internal protocol tracked the new number at a number of levels but did not work across the board. This server also serves as a server for a number of ccTLDs and the "glue" records for this server at those ccTLDs was -NOT- automatically updated... leading to "lame" server indications. So the protocol ought to ensure that when a "host" record is modified, that it can be tracked throughout the system. -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16F1X7i023973 for ietf-provreg-outgoing; Tue, 6 Feb 2001 16:01:33 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f16F1W6V023968 for ; Tue, 6 Feb 2001 16:01:32 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id OAA12200; Tue, 6 Feb 2001 14:58:33 GMT From: "Brian W. Spolarich" To: "Patrick" Cc: Subject: RE: Nameserver as object/entity or not ? Date: Tue, 6 Feb 2001 10:02:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010206151806.L16273@nohope.patoche.org> Sender: owner-ietf-provreg@cafax.se Precedence: bulk | >From experience, I can tell you that it is used. I was working before | in an ISP. One day we had to change our Internet connexion, which | changed the IP of our nameservers, thus the need to change the | properties of all domains using these nameservers. | I'm working in a Registrar now, and it happens that customer ask us | to change 50 or 100 domains at the same time because they change | nameservers or they change IP of one nameserver. This is a good point, and my mindset tends to not be focused on service-provider concerns as much as registrant concerns (somewhat ironic given I used to work for a rather large ISP). ISPs who renumbered would have an impossible time if they had to coordinate a massive batch of updates to the registration entries for all of their customer domains for which they were providing nameservice. I would say that this concern alone would warrant a requirement that the nameserver entities be managed separately. | I do not know if it is useful, but having an attribute 'owned by' | might be of interest. | | It strikes me that there is also the whole thing with DNSSEC. | AFAIK (which is little) about that, nameserver have keys, and other | must know them. How do you distribute keys ? If the nameserver is | in object in the Registry database, you can associate with it its key | to be used by whoever needs them. Just an idea. This is a good point and I think raises an important larger question: is the goal of this WG to _only_ develop an interoperability platform for registrar and registry interactions using existing techniques and models, or to perhaps improve upon those models and techniques? -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f16D4Ev8022983 for ietf-provreg-outgoing; Tue, 6 Feb 2001 14:04:14 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f16D4D6V022978 for ; Tue, 6 Feb 2001 14:04:13 +0100 (MET) Received: (qmail 8060 invoked from network); 6 Feb 2001 13:07:47 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 6 Feb 2001 13:07:47 -0000 From: "Paul George" To: Subject: RE: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Tue, 6 Feb 2001 08:04:01 -0500 Message-ID: <000901c0903d$46f351d0$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk Is it safe to say that Name Servers are being discussed in two different roles here? 1- As a domain to be registered, and 2- As an attribute of a different domain being registered. ??? So in the requirement that we are discussing: | [10] All registrars MUST be authorized to register objects in the | registry. Name server registration MUST be limited to the registrar | of the name server's parent domain. Unauthorized attempts to register | a name server in a parent domain administered by another registrar | MUST be explicitly rejected. This is really talking about role # 1. And role # 2 happens when I already have the "handle" of the domain (which happens to be the Name Server) when I register a different domain. For example, I register a new domain: foo.biz. When I do that, I specify ns(1,2).old-domain.com as the name servers. Now only *I* can register ns(1,2).foo.biz as new domains, which will BTW be my new name servers. Now my friend "Bob" wants to register foo.info, he registers it using ns(1,2).foo.biz as the name servers, which I say is okay. Here, he using the name servers as attributes of his new domain, he certainly is allowed to use them in this fashion. He is not allowed to register a new domain : bob.foo.biz - that's what [10] is trying to prevent (I think). I hope this is right, if not, I need further explaination. Thanks! Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Jörg Bauer/Denic Sent: Tuesday, February 06, 2001 4:28 AM To: Brian W. Spolarich Cc: ietf-provreg@cafax.se; James@Seng.cc; kent@songbird.com; patrick@gandi.net Subject: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] On 05.02.2001 20:29 "Brian W. Spolarich" wrote: > > As a registrant, the thing that I care about is that the nameservers that > I registered with my domain don't change unless I explicity authorize the > change. > > I'm wondering if the problem here is the idea of having separate > nameserver and domain objects. In my mind, the nameserver is an attribute > of the domain, and doesn't have any independent identity. What problem does > having the nameservers as separate entities solve? > That´s exact the way we do it here in Germany. We dont´t know anything about Nameserver Objects and i still can´t see it as a requirement. -- ----------------------------------+----------------------------------------- -- Joerg Bauer | eMail : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+----------------------------------------- -- Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f169RR1J021742 for ietf-provreg-outgoing; Tue, 6 Feb 2001 10:27:27 +0100 (MET) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f169RP6V021737 for ; Tue, 6 Feb 2001 10:27:25 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14Q4OX-00024g-00; Tue, 6 Feb 2001 10:26:41 +0100 Subject: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] To: "Brian W. Spolarich" Cc: ietf-provreg@cafax.se, James@Seng.cc, kent@songbird.com, patrick@gandi.net X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Tue, 6 Feb 2001 10:27:37 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 06.02.2001 10:27:01 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-2 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 05.02.2001 20:29 "Brian W. Spolarich" wrote: > > As a registrant, the thing that I care about is that the nameservers that > I registered with my domain don't change unless I explicity authorize the > change. > > I'm wondering if the problem here is the idea of having separate > nameserver and domain objects. In my mind, the nameserver is an attribute > of the domain, and doesn't have any independent identity. What problem does > having the nameservers as separate entities solve? > That´s exact the way we do it here in Germany. We dont´t know anything about Nameserver Objects and i still can´t see it as a requirement. -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15JduRO016121 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:39:56 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15Jdt6V016116 for ; Mon, 5 Feb 2001 20:39:56 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA08239; Mon, 5 Feb 2001 20:38:15 +0100 Date: Mon, 5 Feb 2001 20:38:15 +0100 From: Patrick To: "Brian W. Spolarich" Cc: James Seng/Personal , Kent Crispin , ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <20010205203815.Z1113@nohope.patoche.org> References: <20010205200537.W1113@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from briansp@walid.com on Mon, Feb 05, 2001 at 02:29:58PM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Feb 05, 2001 at 02:29:58PM -0500, Brian W. Spolarich took time to write: > I don't see as strong of a coupling between the hostnames associated with > the authoritative nameservers for a domain and the hijacking problem. It is > ultimately what shows up in the NS records associated with the domain that > matters. I might choose to delegate foobar.com to ns1.myisp.net and > ns2.myisp.net. If someone registers nameservers ns1.foobar.com and > ns2.foobar.com in the registry this is inconvenient and annoying, but not > really a hijcaking issue. Right... because you do not use ns1.foobar.com and ns2.foobar.com as nameserver. In your case, someone just polluted the database. As soon as your domain use ns{1,2}.foobar.com, you are hijacked... That is inconvenient, since when the true owner will want to register them for its true use, the Registry might not allow him, since they already exist (with bogus data). How do you control who can change the IP ? > In addition, I'm not sure that this coupling will work well in a very > distributed context. Lets say that I own 'foobar.com' today, registered > through registrar 'spumco' and I have two nameservers running, > ns1.foobar.com and ns2.foobar.com. I want to register 'foobar.biz' and > 'foobar.info', using my current nameservers, ns{1,2}.foobar.com. > > In order to complete the domain registration I'll have to register my > nameservers into the .biz and .info registries. Registrar 'spumco', who No. You register nameserver with IP in Registry only for nameserver in the TLDs handled by Registry. That is Registry for .biz SHOULD not have IP of ns1.foobar.com In your case you do not have to register ns{1,2}.foobar.com into .biz and .info Registries. You can merely register them if the registry has nameserver handle, but you specifically DO NOT assign an IP address to them (the Registrar should take care of that) > As a registrant, the thing that I care about is that the nameservers that > I registered with my domain don't change unless I explicity authorize the > change. That is the case, since you can register nameserver only in a given TLD and only through a given Registrar. That is once only in all cases. > I'm wondering if the problem here is the idea of having separate > nameserver and domain objects. In my mind, the nameserver is an attribute > of the domain, and doesn't have any independent identity. What problem does > having the nameservers as separate entities solve? If you use nameserver in the domain, you need glue records, ie the Registry needs to know the IP address of these nameservers. If you consider the nameserver as an object (attributes : a name and many IP), with an handle for example (like at NSI now), many domains can use the same nameserver object. If its IP change you have one change to do (in the nameserver object). Otherwise you will need to change the IP of the nameserver in all domain names using this nameserver. That is why things are separate I think. Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15JTw48016036 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:29:58 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15JTu6V016031 for ; Mon, 5 Feb 2001 20:29:57 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id TAA12869; Mon, 5 Feb 2001 19:25:47 GMT From: "Brian W. Spolarich" To: "Patrick" Cc: "James Seng/Personal" , "Kent Crispin" , Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Mon, 5 Feb 2001 14:29:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010205200537.W1113@nohope.patoche.org> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk | If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then | basically anyone can hijack my domain (pointing www.foobar.com to | whatever IP, etc...) | | Thus the nameservers must be only registered by the Registrar who has | registered foobar.com, and the Registrar must ensure that only | someone with authority on foobar.com (contacts) can create | *.foobar.com | | There is no conflict possible in that case. | A given nameserver can only be registered once (even if it is used in | many domains) through only a given Registrar. Okay, I get it. :-) I figured it was something like that, but was having a hard time with the language. I don't see as strong of a coupling between the hostnames associated with the authoritative nameservers for a domain and the hijacking problem. It is ultimately what shows up in the NS records associated with the domain that matters. I might choose to delegate foobar.com to ns1.myisp.net and ns2.myisp.net. If someone registers nameservers ns1.foobar.com and ns2.foobar.com in the registry this is inconvenient and annoying, but not really a hijcaking issue. In addition, I'm not sure that this coupling will work well in a very distributed context. Lets say that I own 'foobar.com' today, registered through registrar 'spumco' and I have two nameservers running, ns1.foobar.com and ns2.foobar.com. I want to register 'foobar.biz' and 'foobar.info', using my current nameservers, ns{1,2}.foobar.com. In order to complete the domain registration I'll have to register my nameservers into the .biz and .info registries. Registrar 'spumco', who performed the 'foobar.com' registration, doesn't offer registrations with .biz and .info, so I go to registrar 'blammo'. Does this mean that I cannot register my nameservers through 'blammo' with .biz because 'spumco' holds the registration for 'foobar' in .com? This seems problematic. As a registrant, the thing that I care about is that the nameservers that I registered with my domain don't change unless I explicity authorize the change. I'm wondering if the problem here is the idea of having separate nameserver and domain objects. In my mind, the nameserver is an attribute of the domain, and doesn't have any independent identity. What problem does having the nameservers as separate entities solve? -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15JIOOo015936 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:18:24 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15JIM6V015931 for ; Mon, 5 Feb 2001 20:18:23 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id TAA12725; Mon, 5 Feb 2001 19:13:52 GMT From: "Brian W. Spolarich" To: "Martin Oldfield" Cc: "James Seng/Personal" , "Kent Crispin" , Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Mon, 5 Feb 2001 14:18:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <14974.63729.551543.889067@joanna.william.org> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk | I think saying objects here is a great improvement. However, to be | pedantic if I wanted to set up a registry for pet registrations then I | wouldn't want it to include any domain names. | | Would it be possible to explicitly cast the thing in two halves: the | one is general and says `Protocol MUST support registration of objects | of multiple types'; the other is domain specific and says `The objects | supported must include domain names, nameservers, and domain | contacts'. You're correct, but I think there's a difference between the protocol specification and the capabilities of a given registry. That is: - The protocol MUST support registrations of domain name objects. - A particular server implementing the protocol MAY provide domain name registration services. Whatever else the thing does, it better do domain names. :-) -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15JB1T9015868 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:11:01 +0100 (MET) Received: from joanna.william.org (joanna.william.org [195.153.6.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15JB06V015861 for ; Mon, 5 Feb 2001 20:11:00 +0100 (MET) Received: from mjo by joanna.william.org with local (Exim 3.16 #1 (Debian)) id 14Pr24-0002nR-00; Mon, 05 Feb 2001 19:10:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Feb 2001 19:10:36 +0000 (GMT) To: "Brian W. Spolarich" Cc: "James Seng/Personal" , "Kent Crispin" , Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] In-Reply-To: References: <038801c08ec4$982946b0$aa2bd63f@jamessonyvaio> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14974.63729.551543.889067@joanna.william.org> From: Martin Oldfield Sender: owner-ietf-provreg@cafax.se Precedence: bulk >>>>> "Brian" == Brian W Spolarich writes: --> snip <-- Brian> 3.4 Object Registration Brian> [1] Protocol MUST support registration of objects of Brian> multiple types, Brian> including domain names, nameservers, and domain contacts. I think saying objects here is a great improvement. However, to be pedantic if I wanted to set up a registry for pet registrations then I wouldn't want it to include any domain names. Would it be possible to explicitly cast the thing in two halves: the one is general and says `Protocol MUST support registration of objects of multiple types'; the other is domain specific and says `The objects supported must include domain names, nameservers, and domain contacts'. Then if people want to set up all sorts of other crazy registries there's a clear point-of-departure. --> snip <-- Cheers, -- Martin Oldfield, AdamsNames Ltd. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15J7RFN015830 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:07:27 +0100 (MET) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15J7Q6V015825 for ; Mon, 5 Feb 2001 20:07:26 +0100 (MET) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA07956; Mon, 5 Feb 2001 20:05:37 +0100 Date: Mon, 5 Feb 2001 20:05:37 +0100 From: Patrick To: "Brian W. Spolarich" Cc: James Seng/Personal , Kent Crispin , ietf-provreg@cafax.se Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Message-ID: <20010205200537.W1113@nohope.patoche.org> References: <038801c08ec4$982946b0$aa2bd63f@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from briansp@walid.com on Mon, Feb 05, 2001 at 01:55:20PM -0500 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Feb 05, 2001 at 01:55:20PM -0500, Brian W. Spolarich took time to write: > | [10] All registrars MUST be authorized to register objects in the > | registry. Name server registration MUST be limited to the registrar > | of the name server's parent domain. Unauthorized attempts to register > | a name server in a parent domain administered by another registrar > | MUST be explicitly rejected. > | > | One of the conflicting Reqs which I am sure Scott understand. Conflict > | Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1 > | and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar > | R2? And who to say that the ISP must and only must use one registrar to > | work around this? > > I guess I'm dense, but I don't understand requirement 3.4[10] or James' > response. Can someone provide a concrete example of the problem that this > requirement is trying to avoid? Here is my try : I register domain foobar.com handled by nameserver ns1.foobar.com and ns2.foobar.com (note : nameserver in domain name) If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then basically anyone can hijack my domain (pointing www.foobar.com to whatever IP, etc...) Thus the nameservers must be only registered by the Registrar who has registered foobar.com, and the Registrar must ensure that only someone with authority on foobar.com (contacts) can create *.foobar.com There is no conflict possible in that case. A given nameserver can only be registered once (even if it is used in many domains) through only a given Registrar. Patrick. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15J0RuB015771 for ietf-provreg-outgoing; Mon, 5 Feb 2001 20:00:27 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15J0P6V015766 for ; Mon, 5 Feb 2001 20:00:26 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id KAA13562 for ietf-provreg@cafax.se; Mon, 5 Feb 2001 10:51:44 -0800 Message-ID: <20010205105144.A13329@songbird.com> Date: Mon, 5 Feb 2001 10:51:44 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: WG starting point - WG query Mail-Followup-To: ietf-provreg@cafax.se References: <5.1.0.7.2.20010204091746.01d0bcf0@brandenburg.com> <200102051607.f15G76n68805@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200102051607.f15G76n68805@nic-naa.net>; from Eric Brunner-Williams in Portland Maine on Mon, Feb 05, 2001 at 11:07:06AM -0500 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Feb 05, 2001 at 11:07:06AM -0500, Eric Brunner-Williams in Portland Maine wrote: [...] >> 1. Shall the working group take Scott's Requirements document and >> Scott's protocol specification is direct input, and then seek to refine them? > > Hum. Hum also. > > Or: > > > > 2. Shall the working group start from scratch and seek full > > development of Requirements and full development of a protocol > > specification, including possible choice among competing specifications? > > Non-hum. Non-hum, also. I hate to be a "me-too", but even if it turns out that there are significant changes to Scott's draft, we are still miles ahead to start from there. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15ItN17015709 for ietf-provreg-outgoing; Mon, 5 Feb 2001 19:55:23 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15ItM6V015704 for ; Mon, 5 Feb 2001 19:55:22 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id SAA12260; Mon, 5 Feb 2001 18:51:10 GMT From: "Brian W. Spolarich" To: "James Seng/Personal" , "Kent Crispin" , Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] Date: Mon, 5 Feb 2001 13:55:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <038801c08ec4$982946b0$aa2bd63f@jamessonyvaio> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk | [1] The protocol MUST provide services to register Internet domain | names. | | Cool, suppose I dont use it for DNS? (Some of the registration we doing | are not DNS based). And I believe Verisign/NSI _may_ consider using this | for their PKI and ENUM stuff. Scott may confirm or deny (or remain | silence) on this. This doesn't preclude the protocol from providing services to register other kinds of objects. :-) As I read the requirements document 7.5[1,2] does encompass this need, although the document places less emphasis on this than the MUSTs associated with DNS registrations. I don't see why the specification and implementation cannot be generic enough to encompass registration and association of other objects. I think its important that schema extensibility should be part of an initial specification and implementations, and I can buy the argument that the draft is a bit too DNS-focused (although in reality the problem that this protocol is initially trying to solve is related to interoperability for DNS registries and registrars. How about an organization like this: 3.4 Object Registration [1] Protocol MUST support registration of objects of multiple types, including domain names, nameservers, and domain contacts. [2] Protocol MUST permit a starting and ending time, and SHOULD support indefinite object registrations. [3] When an object has been successfully registered, protocol MAY return an expiration date. [4] Per-registry unique TX ids and OIDs. [5] Object attributes which are telephone numbers must conform to international standards. 3.4.1 DNS-Related Objects One thing that seems to be missing from the reqs is a description of the non-object-related operations, such as protocol version, server information, etc. In the context of registering multiple object types you'd probably want to also have an operation that would list the available classes of objects that one can register and their attributes. | [5] 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 version 4 (IPv4) or | version 6 (IPv6) 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. | | Supposing I am a DNS registry who accepts names but associate it with | something else rather than DNS? (e.g. I only do URL forwarding?) There | are registries out that who is doing so. If you're doing URL forwarding then you (as the registrar) are providing authoriative DNS for the domain holder, and you're going to have to register name servers. Or am I missing something here? | [10] All registrars MUST be authorized to register objects in the | registry. Name server registration MUST be limited to the registrar | of the name server's parent domain. Unauthorized attempts to register | a name server in a parent domain administered by another registrar | MUST be explicitly rejected. | | One of the conflicting Reqs which I am sure Scott understand. Conflict | Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1 | and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar | R2? And who to say that the ISP must and only must use one registrar to | work around this? I guess I'm dense, but I don't understand requirement 3.4[10] or James' response. Can someone provide a concrete example of the problem that this requirement is trying to avoid? -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15IbVEp015561 for ietf-provreg-outgoing; Mon, 5 Feb 2001 19:37:31 +0100 (MET) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15IbR6V015556 for ; Mon, 5 Feb 2001 19:37:29 +0100 (MET) Received: from 207-172-174-241.s50.as17.anp.md.dialup.rcn.com ([207.172.174.241]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PqVw-0001qu-00 ; Mon, 05 Feb 2001 13:37:25 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <01f901c08f9f$2f18cb60$0a01a8c0@ambler.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 2001 13:35:08 -0500 To: "Christopher Ambler" From: Edward Lewis Subject: Re: Agenda for Interim Meeting Cc: Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 1:12 PM -0500 2/5/01, Christopher Ambler wrote: >May I presume that the design team is not limited to those who >show up for the meeting? This is correct. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15IEFfX015378 for ietf-provreg-outgoing; Mon, 5 Feb 2001 19:14:15 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15IED6V015373 for ; Mon, 5 Feb 2001 19:14:14 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWD95; Mon, 5 Feb 2001 10:30:31 -0800 Message-ID: <01f901c08f9f$2f18cb60$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: Subject: Re: Agenda for Interim Meeting Date: Mon, 5 Feb 2001 10:12:21 -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 f15IEE6V015374 Sender: owner-ietf-provreg@cafax.se Precedence: bulk May I presume that the design team is not limited to those who show up for the meeting? -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web ----- Original Message ----- From: "Edward Lewis" To: Cc: Sent: Monday, February 05, 2001 8:16 AM Subject: Agenda for Interim Meeting > Here's the proposal I sent earlier: > > Agenda bashing: (short) > WG status: (short) > The EPP proposal > Other proposals > Discussion of forming a design team > > Comments? > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15I7tCg015258 for ietf-provreg-outgoing; Mon, 5 Feb 2001 19:07:55 +0100 (MET) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15I7r6V015253 for ; Mon, 5 Feb 2001 19:07:54 +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 KAA10756; Mon, 5 Feb 2001 10:07:50 -0800 (PST) Date: Mon, 5 Feb 2001 10:07:50 -0800 (PST) From: Rick H Wesson To: Edward Lewis cc: Subject: Re: Agenda for Interim Meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, I won't be at the interm meeting but I would like to be on a design team if one is formed. I have been owrking on implementing scott's epp drafts. -rick > Discussion of forming a design team Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15HVTvX014920 for ietf-provreg-outgoing; Mon, 5 Feb 2001 18:31:29 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15HVR6V014915 for ; Mon, 5 Feb 2001 18:31:28 +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 JAA02529; Mon, 5 Feb 2001 09:31:26 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010205091742.01bca600@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Mon, 05 Feb 2001 09:31:21 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Agenda for Interim Meeting Cc: ietf-provreg@cafax.se, lewis@tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:16 AM 2/5/2001 -0500, Edward Lewis wrote: >Here's the proposal I sent earlier: > > Agenda bashing: (short) > WG status: (short) > The EPP proposal > Other proposals > Discussion of forming a design team Typically, design teams form themselves. They are homogeneous, with closed membership. I suggest that the mailing list try to develop a list of concerns about the EPP proposal, before the meeting, so that the meeting can focus on discussing ways to resolve the concerns. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15HEBYt014793 for ietf-provreg-outgoing; Mon, 5 Feb 2001 18:14:11 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15HE96V014788 for ; Mon, 5 Feb 2001 18:14:10 +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 JAA02149; Mon, 5 Feb 2001 09:14:06 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010205084257.01c04008@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Mon, 05 Feb 2001 09:13:56 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: ietf-provreg@cafax.se In-Reply-To: References: <200102051547.f15FlPn68738@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:23 AM 2/5/2001 -0500, Edward Lewis wrote: >I've spent quite a few hours on email this weekend just on this topic. I >fail to see how this discussion is helping us get to the protocol. The failure to see is the concern. The change to the charter was substantive. The material removed was put into the draft charter based on considerable IETF experience, SPECIFICALLY BECAUSE IT HELPS THE WORKING GROUP PRODUCE A PROTOCOL and IN A TIMELY FASHION. The matter of ensuring working group focus is not a small point. It is at least as important as ensuring proper consensus processes. In my opinion it is, in fact, more difficult! Had you gotten feedback from Patrik to make the change, that would be another matter. Instead you got private statements of concern, did not consult the mailing list, and reacted to other people's fears, making a change in spite of this being contrary to a reasonable consensus on this list. I fully appreciate and respect the concerns you felt about the private comments and about expediting the IESG consideration. I even encourage you to keep them. The question is what was done with the concerns. Given the timing you were faced with, trying to expedite matters is laudable. However the changes were really contrary to the history of the list discussion. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15GcdQS014500 for ietf-provreg-outgoing; Mon, 5 Feb 2001 17:38:39 +0100 (MET) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15Gca6V014490 for ; Mon, 5 Feb 2001 17:38:38 +0100 (MET) Received: from 207-172-150-204.s13.as11.anp.md.dialup.rcn.com ([207.172.150.204]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Poen-0002zz-00 ; Mon, 05 Feb 2001 11:38:25 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200102051547.f15FlPn68738@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 2001 11:23:54 -0500 To: Eric Brunner-Williams in Portland Maine From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: lewis@tislabs.com, ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk I would like this to be the last discussion on this prior an IESG action/reponse on this. (I appologize in advance for being testy about this.) First - why is there a second draft. On Jan 17th or so, I was talking to an IESG member at a workshop and found out that the IESG hadn't seen the charter yet. The following day was a one-week- before-meeting deadline to have IESG members submit items for discussion at the next meeting. As a result of this I pinged Patrik about our charter. I also mentioned that some other feedback I received questioning the mention of drafts and coverage about security. I promised Patrik an alternate charter in case it was needed. Once I got to a place where I could work and get net access (a few days later), I made three changes - one to remove the mention of the drafts by name, one to put "extensibility" in to the charter, and one to beef up the security. I wanted to get this to Patrik in time for the IESG meeting. At that point there wasn't time to get mail list comments on what I consider three small changes. (Please don't reply to complain that I shouldn't just go on my considerations - evidently the inclusion/exclusion of the names of the drafts is a big deal to some.) I sent the second charter to Patrik (and copied Jaap). The next thing I see is the first charter on ietf-announce. I haven't heard directly from Patrik on this, it is possible he has already thrown out the second charter. I don't know. At worst, he has both. Second - what's next. It's in the IESG's hands. I've gotten no indications about the next step. When I know, the mail list will know. Third - why I'm tiring on this. I've spent quite a few hours on email this weekend just on this topic. I fail to see how this discussion is helping us get to the protocol. We already have a requirements document that seems to satisfy list participants. If we were a WG, then it would be in last call by now - but we are not a WG. There are two items now for us. One is to start consideration of the protocol. The other is to make sure we have as wide-spread consensus as we can get. At 10:47 AM -0500 2/5/01, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >Responding to several of your issues raised over the weekend: > >> The charter mentions DNS administration to set the context of the work, it >> itself is not a work item. > >This is what I assumed. > >> The reason I removed the mention of the draft is that we are not here to >> bless a particular protocol generated outside the working group, but rather >> to generate a protocol in full view of the IETF. > >I see two issues here -- agency and process. > >Agency -- The draft charter shows two co-chairs, Ed and Jaap. Was this >change of draft charter discussed by both? The draft charter was discussed >at San Diego and references to Scott's prior drafts were present then, and >not remarkable. What changed? > >Process -- This has been covered by others, unlike another activity for >which a NDA existed, Scott's drafts have been in full public view. > >> Right now I am basically waiting for feedback from the IESG. > >The scope of IESG review is limited, as is its effect. I'll crawl out on a >limb and _predict_ the IESG reviewer(s) won't: > a) require folding whois and provreg (despite the superficial > appearence of common underlying data and access mechanisms), > b) require an ab initio folding of DNS provreg with other possible > provregs, (despite the superficial appearence of common underlying > data types and access mechanisms), and > c) require cosmetic rewriting of self-evident existing requirements. > >Cheers, >Eric -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15Gcb78014495 for ietf-provreg-outgoing; Mon, 5 Feb 2001 17:38:37 +0100 (MET) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15GcZ6V014489 for ; Mon, 5 Feb 2001 17:38:36 +0100 (MET) Received: from 207-172-150-204.s13.as11.anp.md.dialup.rcn.com ([207.172.150.204]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Poeq-0002zz-00 ; Mon, 05 Feb 2001 11:38:28 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Feb 2001 11:16:46 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Agenda for Interim Meeting Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here's the proposal I sent earlier: Agenda bashing: (short) WG status: (short) The EPP proposal Other proposals Discussion of forming a design team Comments? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15G7b9X014207 for ietf-provreg-outgoing; Mon, 5 Feb 2001 17:07:37 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15G7Z6V014202 for ; Mon, 5 Feb 2001 17:07:36 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f15G76n68805; Mon, 5 Feb 2001 11:07:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102051607.f15G76n68805@nic-naa.net> To: Dave Crocker cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: WG starting point - WG query In-Reply-To: Your message of "Sun, 04 Feb 2001 09:39:42 PST." <5.1.0.7.2.20010204091746.01d0bcf0@brandenburg.com> Date: Mon, 05 Feb 2001 11:07:06 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > So I am personally requesting feedback from the others on this list, > concerning consensus about use of Scott's existing work: I concur with the proposition that extensive community review has taken place (since -43 for some, since -48 for others, and at -49 and on -announce and now -provreg), and with the proposition that Scott's requirements and protocol drafts have general support. > The terms of a working group charter need to have consensus of the > proto-working group. In other words, it is not just produced by the chair > and the IESG. It has to have support by those who will be participating in > the working group. If it were otherwise there would be an action item to the poisson list. [necessity and authority to make WG work-product alterations from any initial text, deleted for space.] > So my question to the working group: > > 1. Shall the working group take Scott's Requirements document and > Scott's protocol specification is direct input, and then seek to refine them? Hum. > Or: > > 2. Shall the working group start from scratch and seek full > development of Requirements and full development of a protocol > specification, including possible choice among competing specifications? Non-hum. > In my opinion, alternative #2 usually costs a working group no less than > 6-12 months EXTRA. Taking as much as 2 years EXTRA is not unusual! Possibly understated, given the uniqueness of working in a politicised area. It took the W3C's P3P activity the first two+ years of its life to scope "privacy" and "preferences", and its third year to deliver a very modest work. Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15Flav8028676 for ietf-provreg-outgoing; Mon, 5 Feb 2001 16:47:36 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f15FlY6V028222 for ; Mon, 5 Feb 2001 16:47:34 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f15FlPn68738; Mon, 5 Feb 2001 10:47:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102051547.f15FlPn68738@nic-naa.net> To: lewis@tislabs.com cc: ietf-provreg@cafax.se Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Mon, 05 Feb 2001 10:47:24 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, Responding to several of your issues raised over the weekend: > The charter mentions DNS administration to set the context of the work, it > itself is not a work item. This is what I assumed. > The reason I removed the mention of the draft is that we are not here to > bless a particular protocol generated outside the working group, but rather > to generate a protocol in full view of the IETF. I see two issues here -- agency and process. Agency -- The draft charter shows two co-chairs, Ed and Jaap. Was this change of draft charter discussed by both? The draft charter was discussed at San Diego and references to Scott's prior drafts were present then, and not remarkable. What changed? Process -- This has been covered by others, unlike another activity for which a NDA existed, Scott's drafts have been in full public view. > Right now I am basically waiting for feedback from the IESG. The scope of IESG review is limited, as is its effect. I'll crawl out on a limb and _predict_ the IESG reviewer(s) won't: a) require folding whois and provreg (despite the superficial appearence of common underlying data and access mechanisms), b) require an ab initio folding of DNS provreg with other possible provregs, (despite the superficial appearence of common underlying data types and access mechanisms), and c) require cosmetic rewriting of self-evident existing requirements. Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15Dmcfn028592 for ietf-provreg-outgoing; Mon, 5 Feb 2001 14:48:38 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f15Dma6V028584 for ; Mon, 5 Feb 2001 14:48:37 +0100 (MET) Received: (qmail 21744 invoked from network); 5 Feb 2001 13:52:10 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 5 Feb 2001 13:52:10 -0000 From: "Paul George" To: Subject: RE: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Mon, 5 Feb 2001 08:48:30 -0500 Message-ID: <000d01c08f7a$5334df90$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.7.2.20010202175454.01d0ddb8@brandenburg.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk >That has been discussed before. Existing and >new registries and registrars want this NOW. I agree with Dave. There is a need to get this nailed down quickly, and not just from the Registries and Registrars point of view. What about all those poor product development teams trying to create a product that implements this protocol? It's like shooting at a target that is over the horizon (you can do it, but it's real hard). Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Dave Crocker Sent: Friday, February 02, 2001 9:00 PM To: James Seng/Personal Cc: ietf-provreg@cafax.se; Patrik Faltstrom Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote: >Dave, > > > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote: > > >I would like to object this proposed charter for provreg. Its scope >has > > >been so specific defined for DNS only and has no mention of anything > > >beyond DNS. > > > > feature, not bug. > >It depends who you speaking to...To me, it is a bug. My statement is based on experience with IETF processes, observation of other standards processes and experience with product development. It seems to be one of the empirical truths about project success, especially when an open group process is involved. Start with the simplest, most specific deliverable that will be useful. Then evolve. >However, I can not understand is what is the hurry for the WG to get >this out quickly? That has been discussed before. Existing and new registries and registrars want this NOW. >If it is about new gTLD registry, any of the new gTLD registry who have >not started work implementing their system now is crazy. I dont think >any of them will wait for the result of the WG (Sept?) before starting >work. For this, we are already too late. For their initial use, yes. But some of them have already spoken, here, to validate the urgency of their need. >Either way, IMHO, we are already too late in a non-standardised world. James, unfortunately that is one of the usual argument for taking forever. >Hence, it is better to work on a GOOD and long term technical solution Again, that is unfortunately a frequently-heard comment in standards arenas that is obviously well-intentioned, but turns out to be counter-productive. It is one of the ironies of this sort of standards work. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f15DiYGt028558 for ietf-provreg-outgoing; Mon, 5 Feb 2001 14:44:34 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f15DiW6V028553 for ; Mon, 5 Feb 2001 14:44:33 +0100 (MET) Received: (qmail 21678 invoked from network); 5 Feb 2001 13:48:03 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 5 Feb 2001 13:48:03 -0000 From: "Paul George" To: Subject: RE: WG starting point - WG query Date: Mon, 5 Feb 2001 08:44:23 -0500 Message-ID: <000c01c08f79$c0369030$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.7.2.20010204091746.01d0bcf0@brandenburg.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk > 1. Shall the working group take Scott's Requirements > document and Scott's protocol specification is > direct input, and then seek to refine them? I have no problems with going forward with Scott's input. Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of Dave Crocker Sent: Sunday, February 04, 2001 12:40 PM To: ietf-provreg@cafax.se Subject: WG starting point - WG query Importance: High At 10:40 AM 2/4/2001 -0500, Hollenbeck, Scott wrote: >Let me be clear about what I mean: the requirements draft has been out for >broad IETF review for 10+ months. If people are only now taking notice >because we are forming a WG, it would be more productive to stop complaining >and get comments in _now_ than to insist that there hasn't been ample time >for review. And let ME underscore that the Requirements document very much HAS been reviewed by others. When it came out, did many people assume that it was biased towards NSI? Yes. When they read it did they change their minds? Yes. Did the same thing happen with the protocol specification? Yes. Does this mean that starting with those documents means that the working group would have no work to do? Not at all. The philosophical difference that is creating the current set of tensions is whether this IETF working group should a) move very aggressively, and b) whether it can take advantage of pre-existing work by Scott to finish much more quickly would otherwise be possible. ----- So I am personally requesting feedback from the others on this list, concerning consensus about use of Scott's existing work: My sense is that the Requirements document has already received extensive community review and has general support. My sense is that Scott's protocol specification has already received extensive community review and has general support. The terms of a working group charter need to have consensus of the proto-working group. In other words, it is not just produced by the chair and the IESG. It has to have support by those who will be participating in the working group. Taking existing documents as a starting point for a working group is an entirely acceptable practise in the IETF... IF there is consensus to do so. The benefit is making progress MUCH more quickly. This does not prevent making changes. When taking existing documents, the point of the working group is to REFINE things. Hence, the working group takes over the document(s) and may make whatever changes it deems appropriate. Language in the charter often specifically cites such documents and limits the nature of the changes, in order to ensure better WG focus. Hence, the charter language is intended to create a bias against big changes. However let me repeat that strong working group consensus retains authority to make whatever changes the working group deems appropriate. So my question to the working group: 1. Shall the working group take Scott's Requirements document and Scott's protocol specification is direct input, and then seek to refine them? Or: 2. Shall the working group start from scratch and seek full development of Requirements and full development of a protocol specification, including possible choice among competing specifications? In my opinion, alternative #2 usually costs a working group no less than 6-12 months EXTRA. Taking as much as 2 years EXTRA is not unusual! d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14MOeYO023139 for ietf-provreg-outgoing; Sun, 4 Feb 2001 23:24:40 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14MOd6V023134 for ; Sun, 4 Feb 2001 23:24:39 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA01992 for ; Sun, 4 Feb 2001 17:24:38 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Feb 2001 17:19:34 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Interim Meeting Date: Sun, 4 Feb 2001 17:19:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is the last opportunity I'll have to respond for what may be a few days. I'm in the middle of a home move, and I have to take myself offline for a while. I don't understand why my position is unclear. It's included in the thread below. -----Original Message----- From: James Seng/Personal [mailto:James@Seng.cc] Sent: Sunday, February 04, 2001 10:58 AM To: Hollenbeck, Scott; ietf-provreg@cafax.se Subject: Re: Interim Meeting Scott, Claim what you like about the IETF process. I cannot deny that you have follow the process and I thank you for that. But the facts remains that a lot of registries have not read your I-D. So the question is "Are you interested in their feedback?" or "Are you more interested to follow process and get your I-D thru?" -James Seng ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Sunday, February 04, 2001 11:40 PM Subject: RE: Interim Meeting > James, > > The fact that the requirements document was published as an I-D speaks for > itself WRT the intended review community. If my desire was for review only > by the customers of VeriSign-GRS it wouldn't have been published as an I-D. > > > What I have said is that this document has been available for review to the > IETF community at large since March 2000. It is completely incorrect for > anyone to say that they haven't had an opportunity to review this draft. > Assertions to the contrary are baseless. > > Let me be clear about what I mean: the requirements draft has been out for > broad IETF review for 10+ months. If people are only now taking notice > because we are forming a WG, it would be more productive to stop complaining > and get comments in _now_ than to insist that there hasn't been ample time > for review. > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14Hk1xx021553 for ietf-provreg-outgoing; Sun, 4 Feb 2001 18:46:01 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14Hk06V021546 for ; Sun, 4 Feb 2001 18:46:00 +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 JAA14942 for ; Sun, 4 Feb 2001 09:45:59 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010204091746.01d0bcf0@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) X-Priority: 2 (High) Date: Sun, 04 Feb 2001 09:39:42 -0800 To: ietf-provreg@cafax.se From: Dave Crocker Subject: WG starting point - WG query 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 10:40 AM 2/4/2001 -0500, Hollenbeck, Scott wrote: >Let me be clear about what I mean: the requirements draft has been out for >broad IETF review for 10+ months. If people are only now taking notice >because we are forming a WG, it would be more productive to stop complaining >and get comments in _now_ than to insist that there hasn't been ample time >for review. And let ME underscore that the Requirements document very much HAS been reviewed by others. When it came out, did many people assume that it was biased towards NSI? Yes. When they read it did they change their minds? Yes. Did the same thing happen with the protocol specification? Yes. Does this mean that starting with those documents means that the working group would have no work to do? Not at all. The philosophical difference that is creating the current set of tensions is whether this IETF working group should a) move very aggressively, and b) whether it can take advantage of pre-existing work by Scott to finish much more quickly would otherwise be possible. ----- So I am personally requesting feedback from the others on this list, concerning consensus about use of Scott's existing work: My sense is that the Requirements document has already received extensive community review and has general support. My sense is that Scott's protocol specification has already received extensive community review and has general support. The terms of a working group charter need to have consensus of the proto-working group. In other words, it is not just produced by the chair and the IESG. It has to have support by those who will be participating in the working group. Taking existing documents as a starting point for a working group is an entirely acceptable practise in the IETF... IF there is consensus to do so. The benefit is making progress MUCH more quickly. This does not prevent making changes. When taking existing documents, the point of the working group is to REFINE things. Hence, the working group takes over the document(s) and may make whatever changes it deems appropriate. Language in the charter often specifically cites such documents and limits the nature of the changes, in order to ensure better WG focus. Hence, the charter language is intended to create a bias against big changes. However let me repeat that strong working group consensus retains authority to make whatever changes the working group deems appropriate. So my question to the working group: 1. Shall the working group take Scott's Requirements document and Scott's protocol specification is direct input, and then seek to refine them? Or: 2. Shall the working group start from scratch and seek full development of Requirements and full development of a protocol specification, including possible choice among competing specifications? In my opinion, alternative #2 usually costs a working group no less than 6-12 months EXTRA. Taking as much as 2 years EXTRA is not unusual! d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14HWxLJ021470 for ietf-provreg-outgoing; Sun, 4 Feb 2001 18:32:59 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14HWv6V021463 for ; Sun, 4 Feb 2001 18:32:58 +0100 (MET) Received: from 207-172-191-22.s22.as14.anp.md.dialup.rcn.com ([207.172.191.22]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PT1z-0006Iz-00 ; Sun, 04 Feb 2001 12:32:55 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <038501c08ec3$4324b560$aa2bd63f@jamessonyvaio> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 4 Feb 2001 12:30:34 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: Interim Meeting Cc: Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:58 AM -0500 2/4/01, James Seng/Personal wrote: >But the facts remains that a lot of registries have not read your I-D. >So the question is "Are you interested in their feedback?" or "Are you >more interested to follow process and get your I-D thru?" Once the WG is formed, I plan to wait at least two weeks after we are official before issueing a WG last call - which lasts two weeks itself. (For folks worried about delays, there is no need for the requirements document to be "official" before progress on the protocol can be made.) As far as getting registries and registrars involved, this is not *just* an IETF or provreg responsibility. I am making sure we make every effort to be as open as possible about the activities as we can be. I am also trying to get as many folks aware of this work as I can. If anyone is afraid that there is an entity that should be involved in provreg, but is not paying attention to provreg, there are two things you can do. One is to contact that entity and tell them of provreg. The other is to bring it to my attention and I'll see if I can get a message to the entity. PS - Regarding "getting feedback" versus "getting the ID thru", please look in the archives for the thread "Draft provreg charter", starting "Tue, 26 Dec 2000 09:28:34 -0800." We've hashed this issue a couple of times already. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14HWvwS021464 for ietf-provreg-outgoing; Sun, 4 Feb 2001 18:32:57 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14HWs6V021453 for ; Sun, 4 Feb 2001 18:32:55 +0100 (MET) Received: from 207-172-191-22.s22.as14.anp.md.dialup.rcn.com ([207.172.191.22]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PT1v-0006Iz-00 ; Sun, 04 Feb 2001 12:32:51 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.1.0.7.2.20010203202358.01d8f548@brandenburg.com> References: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 4 Feb 2001 12:06:42 -0500 To: Dave Crocker From: Edward Lewis Subject: moving on, was Re: Fw: WG Review: ... Cc: Edward Lewis , , "Patrik Faltstrom" Sender: owner-ietf-provreg@cafax.se Precedence: bulk As much as I hate to cut off communication on a topic, I don't think the revent thread on the charter is in any way is helping us arrive at protocol. In fact, I might go so far as to say that this thread has gone off-topic for the mailing list. All I can say here is that we have already had a discussion on the charter, and it has not yet been approved by the IESG. I am waiting for feedback from the IESG before anything else can be done on this matter. Further discussion on this is just like spinning tires in mud. Let's get back to discussions on the requirements document (if there is any more to be held). I assume there is consensus that the requirements document should be admitted to the WG (once we are official). Suggestions for the Feb 20 meeting agenda are welcome. I'd also like to hear thoughts about organizing a design team (whether we should, size, shape, nominees perhaps). I think it is about time we begin to look at the EPP document. Does the latest EPP draft meet the latest draft of requirements? Is there an objection to including EPP in the WG set of documents? If there is an alternative proposal to be considered, please identify it. If there are other documents that should be added to the WG, please identify them. (The definitions document will likely be one.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14HWv0p021465 for ietf-provreg-outgoing; Sun, 4 Feb 2001 18:32:57 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14HWt6V021454 for ; Sun, 4 Feb 2001 18:32:56 +0100 (MET) Received: from 207-172-191-22.s22.as14.anp.md.dialup.rcn.com ([207.172.191.22]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PT1x-0006Iz-00 ; Sun, 04 Feb 2001 12:32:54 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <005d01c08ea3$3e8e23d0$aa2bd63f@jamessonyvaio> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 4 Feb 2001 12:14:16 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: Interim Meeting Cc: "'provreg List'" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 7:08 AM -0500 2/4/01, James Seng/Personal wrote: >20th Feb is an interim meeting, not IETF meeting. Interim meetings for >WG are not encouraged but not against the rules if approved by the ADs. I finally located the following URL (I was looking in the wrong place) that should be read by anyone with questions about the form of the interim meeting: http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt I should have included this in my previous message ('scheduling challenged') as the basis for my words. We do have AD permission to hold the meeting. Without that I would not have been able to have the announcement appear on ietf-announce. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14G9fau021083 for ietf-provreg-outgoing; Sun, 4 Feb 2001 17:09:41 +0100 (MET) Received: from nychoteldns01.stsn.com (p5.usnyc1.stsn.com [199.106.216.5]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14G9e6V021078 for ; Sun, 4 Feb 2001 17:09:40 +0100 (MET) Received: from jamessonyvaio ([10.0.208.56]) by nychoteldns01.stsn.com (8.11.0/8.11.0) with SMTP id f14GAOn12298; Sun, 4 Feb 2001 11:10:25 -0500 Message-ID: <038801c08ec4$982946b0$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Kent Crispin" , References: <021d01c08ebe$6841b140$aa2bd63f@jamessonyvaio> <20010204073432.C19335@songbird.com> Subject: Re: Interim Meeting Date: Mon, 5 Feb 2001 00:07:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Scott said: > > "If anyone has issues with it I wish they would make them known..." > > What, specifically, are your issues with it? As I said, I rather the individual registries bring this to the WG rather than myself since my views may not accurately reflects their needs. But since you asked, here are some issues. 3.4 Object Registration [1] The protocol MUST provide services to register Internet domain names. Cool, suppose I dont use it for DNS? (Some of the registration we doing are not DNS based). And I believe Verisign/NSI _may_ consider using this for their PKI and ENUM stuff. Scott may confirm or deny (or remain silence) on this. [5] 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 version 4 (IPv4) or version 6 (IPv6) 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. Supposing I am a DNS registry who accepts names but associate it with something else rather than DNS? (e.g. I only do URL forwarding?) There are registries out that who is doing so. [10] All registrars MUST be authorized to register objects in the registry. Name server registration MUST be limited to the registrar of the name server's parent domain. Unauthorized attempts to register a name server in a parent domain administered by another registrar MUST be explicitly rejected. One of the conflicting Reqs which I am sure Scott understand. Conflict Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1 and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar R2? And who to say that the ISP must and only must use one registrar to work around this? IMHO, it is better to define an "authorization access" to an object rather than putting explicit work around. Okay..more fun in object association but I wont go on...till next time. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14Fxw8F021026 for ietf-provreg-outgoing; Sun, 4 Feb 2001 16:59:58 +0100 (MET) Received: from nychoteldns01.stsn.com (p5.usnyc1.stsn.com [199.106.216.5]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14Fxv6V021021 for ; Sun, 4 Feb 2001 16:59:58 +0100 (MET) Received: from jamessonyvaio ([10.0.208.56]) by nychoteldns01.stsn.com (8.11.0/8.11.0) with SMTP id f14G0qn12148; Sun, 4 Feb 2001 11:00:53 -0500 Message-ID: <038501c08ec3$4324b560$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Hollenbeck, Scott" , References: Subject: Re: Interim Meeting Date: Sun, 4 Feb 2001 23:58:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, Claim what you like about the IETF process. I cannot deny that you have follow the process and I thank you for that. But the facts remains that a lot of registries have not read your I-D. So the question is "Are you interested in their feedback?" or "Are you more interested to follow process and get your I-D thru?" -James Seng ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Sunday, February 04, 2001 11:40 PM Subject: RE: Interim Meeting > James, > > The fact that the requirements document was published as an I-D speaks for > itself WRT the intended review community. If my desire was for review only > by the customers of VeriSign-GRS it wouldn't have been published as an I-D. > > > What I have said is that this document has been available for review to the > IETF community at large since March 2000. It is completely incorrect for > anyone to say that they haven't had an opportunity to review this draft. > Assertions to the contrary are baseless. > > Let me be clear about what I mean: the requirements draft has been out for > broad IETF review for 10+ months. If people are only now taking notice > because we are forming a WG, it would be more productive to stop complaining > and get comments in _now_ than to insist that there hasn't been ample time > for review. > > > > -----Original Message----- > From: James Seng/Personal [mailto:James@Seng.cc] > Sent: Sunday, February 04, 2001 10:23 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > Subject: Re: Interim Meeting > > > Scott, > > I am not against the interim meeting and in fact, I think it is a good > idea. It is a pity (or perhaps lucky) I wont be able to attend it. > > Your reqs spec has been published as an individual I-D, largely ignored > by the other community because they see it as primarly NSI focus with > your registrars. I know you it wasnt meant to be but that is the > perspective share by others. > > Now, if it is a WG I-D, i think we need to go out and correct the > perspection that it is not just an NSI I-D. It is beyond that and it is > going to come back haunt them if they dont take note now. > > Your I-D will make great input to this going-to-be WG. But as an WG I-D, > I think it is safe to safe to say that we need more reviews beyond your > registrars. I am sure the other registries have their comments too so > why not hear them out? > > Unless of course you mean you couldnt care less about what the rest of > the registries thinks...in that case, I shall rest my case. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14FjaYL020953 for ietf-provreg-outgoing; Sun, 4 Feb 2001 16:45:36 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14FjZ6V020948 for ; Sun, 4 Feb 2001 16:45:35 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA01845 for ; Sun, 4 Feb 2001 10:45:34 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Feb 2001 10:40:31 -0500 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Interim Meeting Date: Sun, 4 Feb 2001 10:40:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk James, The fact that the requirements document was published as an I-D speaks for itself WRT the intended review community. If my desire was for review only by the customers of VeriSign-GRS it wouldn't have been published as an I-D. What I have said is that this document has been available for review to the IETF community at large since March 2000. It is completely incorrect for anyone to say that they haven't had an opportunity to review this draft. Assertions to the contrary are baseless. Let me be clear about what I mean: the requirements draft has been out for broad IETF review for 10+ months. If people are only now taking notice because we are forming a WG, it would be more productive to stop complaining and get comments in _now_ than to insist that there hasn't been ample time for review. -----Original Message----- From: James Seng/Personal [mailto:James@Seng.cc] Sent: Sunday, February 04, 2001 10:23 AM To: Hollenbeck, Scott; ietf-provreg@cafax.se Subject: Re: Interim Meeting Scott, I am not against the interim meeting and in fact, I think it is a good idea. It is a pity (or perhaps lucky) I wont be able to attend it. Your reqs spec has been published as an individual I-D, largely ignored by the other community because they see it as primarly NSI focus with your registrars. I know you it wasnt meant to be but that is the perspective share by others. Now, if it is a WG I-D, i think we need to go out and correct the perspection that it is not just an NSI I-D. It is beyond that and it is going to come back haunt them if they dont take note now. Your I-D will make great input to this going-to-be WG. But as an WG I-D, I think it is safe to safe to say that we need more reviews beyond your registrars. I am sure the other registries have their comments too so why not hear them out? Unless of course you mean you couldnt care less about what the rest of the registries thinks...in that case, I shall rest my case. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14Fh7JM020919 for ietf-provreg-outgoing; Sun, 4 Feb 2001 16:43:07 +0100 (MET) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14Fh56V020914 for ; Sun, 4 Feb 2001 16:43:05 +0100 (MET) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id HAA31218 for ietf-provreg@cafax.se; Sun, 4 Feb 2001 07:34:32 -0800 Message-ID: <20010204073432.C19335@songbird.com> Date: Sun, 4 Feb 2001 07:34:32 -0800 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Interim Meeting Mail-Followup-To: ietf-provreg@cafax.se References: <021d01c08ebe$6841b140$aa2bd63f@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <021d01c08ebe$6841b140$aa2bd63f@jamessonyvaio>; from James Seng/Personal on Sun, Feb 04, 2001 at 11:23:19PM +0800 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Sun, Feb 04, 2001 at 11:23:19PM +0800, James Seng/Personal wrote: [...] > Your reqs spec has been published as an individual I-D, largely ignored > by the other community because they see it as primarly NSI focus with > your registrars. I know you it wasnt meant to be but that is the > perspective share by others. That is probably true. > Now, if it is a WG I-D, i think we need to go out and correct the > perspection that it is not just an NSI I-D. It is beyond that and it is > going to come back haunt them if they dont take note now. > > Your I-D will make great input to this going-to-be WG. But as an WG I-D, > I think it is safe to safe to say that we need more reviews beyond your > registrars. I am sure the other registries have their comments too so > why not hear them out? Scott said: "If anyone has issues with it I wish they would make them known..." What, specifically, are your issues with it? -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14FPKdg020780 for ietf-provreg-outgoing; Sun, 4 Feb 2001 16:25:20 +0100 (MET) Received: from nychoteldns01.stsn.com (p5.usnyc1.stsn.com [199.106.216.5]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14FPJ6V020775 for ; Sun, 4 Feb 2001 16:25:20 +0100 (MET) Received: from jamessonyvaio ([10.0.208.56]) by nychoteldns01.stsn.com (8.11.0/8.11.0) with SMTP id f14FQ7n11603; Sun, 4 Feb 2001 10:26:07 -0500 Message-ID: <021d01c08ebe$6841b140$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Hollenbeck, Scott" , References: Subject: Re: Interim Meeting Date: Sun, 4 Feb 2001 23:23:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I am not against the interim meeting and in fact, I think it is a good idea. It is a pity (or perhaps lucky) I wont be able to attend it. Your reqs spec has been published as an individual I-D, largely ignored by the other community because they see it as primarly NSI focus with your registrars. I know you it wasnt meant to be but that is the perspective share by others. Now, if it is a WG I-D, i think we need to go out and correct the perspection that it is not just an NSI I-D. It is beyond that and it is going to come back haunt them if they dont take note now. Your I-D will make great input to this going-to-be WG. But as an WG I-D, I think it is safe to safe to say that we need more reviews beyond your registrars. I am sure the other registries have their comments too so why not hear them out? Unless of course you mean you couldnt care less about what the rest of the registries thinks...in that case, I shall rest my case. -James Seng ----- Original Message ----- From: "Hollenbeck, Scott" To: Sent: Sunday, February 04, 2001 10:13 PM Subject: RE: Interim Meeting > James, > > I know full well when the next IETF meeting is scheduled. Our interim WG > (even proto-WG) meeting will be held under IETF guidelines, making it an > IETF-affiliated meeting. > > The requirements draft has now been published for 10+ months in complete > conformance with IETF policies. If anyone has issues with it I wish they > would make them known, for there's surely been plenty of time available. > > > > -----Original Message----- > From: James Seng/Personal [mailto:James@Seng.cc] > Sent: Sunday, February 04, 2001 7:09 AM > To: Hollenbeck, Scott; 'provreg List' > Subject: Re: Interim Meeting > > > > Nothing is ever decided with finality at face-to-face IETF meetings -- > > consensus decisions are made using mailing lists like this one. Those > of us > > who have asked for an interim meeting want to get down to critical > review of > > the EPP proposals, and to that end I think we need to do the following > > between now and 21+ February: > > 20th Feb is an interim meeting, not IETF meeting. Interim meetings for > WG are not encouraged but not against the rules if approved by the ADs. > > > 1. We come to some semblance of closure on the requirements. The > updated > > draft was posted almost two weeks ago, and I haven't seen any > discussion > > since. Does that mean I got it right this time? ;-) > > I think the right answer is people are still coming to terms with this > WG and trying to understand the consequences. It would be too early to > say that you got it right. > > RIPE have done a good job promoting this in Amsterdam to the European > NICs. There would be a APRICOT meeting end of Feb where Asia NICs would > usually attend. I will try do some "awareness promotion" there so we > could get Asia NICs to join the work here. Their feedback is equally > important. > > Yes, this means I wont be able to attend to interim meeting because of > APRICOT. Guess this means one less 'trouble-maker' there. How lucky :-) > > ps: The current requirements probably not suitable for them but I shall > leave it to them to explain why. > > pss: There are other kind of registries who would be interested in this > work. They should be appropriately be informed. IP, keywords and URN > comes to mind immediately. And probably ENUM/E164, if ITU could get > their head around to understand it. > > -James Seng > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14EJ5m4020510 for ietf-provreg-outgoing; Sun, 4 Feb 2001 15:19:05 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14EJ46V020505 for ; Sun, 4 Feb 2001 15:19:04 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA01800 for ; Sun, 4 Feb 2001 09:19:03 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Feb 2001 09:14:00 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: RE: Interim Meeting Date: Sun, 4 Feb 2001 09:13:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk James, I know full well when the next IETF meeting is scheduled. Our interim WG (even proto-WG) meeting will be held under IETF guidelines, making it an IETF-affiliated meeting. The requirements draft has now been published for 10+ months in complete conformance with IETF policies. If anyone has issues with it I wish they would make them known, for there's surely been plenty of time available. -----Original Message----- From: James Seng/Personal [mailto:James@Seng.cc] Sent: Sunday, February 04, 2001 7:09 AM To: Hollenbeck, Scott; 'provreg List' Subject: Re: Interim Meeting > Nothing is ever decided with finality at face-to-face IETF meetings -- > consensus decisions are made using mailing lists like this one. Those of us > who have asked for an interim meeting want to get down to critical review of > the EPP proposals, and to that end I think we need to do the following > between now and 21+ February: 20th Feb is an interim meeting, not IETF meeting. Interim meetings for WG are not encouraged but not against the rules if approved by the ADs. > 1. We come to some semblance of closure on the requirements. The updated > draft was posted almost two weeks ago, and I haven't seen any discussion > since. Does that mean I got it right this time? ;-) I think the right answer is people are still coming to terms with this WG and trying to understand the consequences. It would be too early to say that you got it right. RIPE have done a good job promoting this in Amsterdam to the European NICs. There would be a APRICOT meeting end of Feb where Asia NICs would usually attend. I will try do some "awareness promotion" there so we could get Asia NICs to join the work here. Their feedback is equally important. Yes, this means I wont be able to attend to interim meeting because of APRICOT. Guess this means one less 'trouble-maker' there. How lucky :-) ps: The current requirements probably not suitable for them but I shall leave it to them to explain why. pss: There are other kind of registries who would be interested in this work. They should be appropriately be informed. IP, keywords and URN comes to mind immediately. And probably ENUM/E164, if ITU could get their head around to understand it. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14CAQV6020035 for ietf-provreg-outgoing; Sun, 4 Feb 2001 13:10:26 +0100 (MET) Received: from i1.i-dns.com (i1.idns.org [209.249.141.24]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14CAO6V020030 for ; Sun, 4 Feb 2001 13:10:25 +0100 (MET) Received: from jamessonyvaio (PPPa21-ResaleDialinx80015-3R7409.dialinx.net [4.16.206.242]) by i1.i-dns.com (8.9.3/8.9.1) with SMTP id EAA06003; Sun, 4 Feb 2001 04:10:16 -0800 Message-ID: <005d01c08ea3$3e8e23d0$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Hollenbeck, Scott" , "'provreg List'" References: Subject: Re: Interim Meeting Date: Sun, 4 Feb 2001 20:08:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Nothing is ever decided with finality at face-to-face IETF meetings -- > consensus decisions are made using mailing lists like this one. Those of us > who have asked for an interim meeting want to get down to critical review of > the EPP proposals, and to that end I think we need to do the following > between now and 21+ February: 20th Feb is an interim meeting, not IETF meeting. Interim meetings for WG are not encouraged but not against the rules if approved by the ADs. > 1. We come to some semblance of closure on the requirements. The updated > draft was posted almost two weeks ago, and I haven't seen any discussion > since. Does that mean I got it right this time? ;-) I think the right answer is people are still coming to terms with this WG and trying to understand the consequences. It would be too early to say that you got it right. RIPE have done a good job promoting this in Amsterdam to the European NICs. There would be a APRICOT meeting end of Feb where Asia NICs would usually attend. I will try do some "awareness promotion" there so we could get Asia NICs to join the work here. Their feedback is equally important. Yes, this means I wont be able to attend to interim meeting because of APRICOT. Guess this means one less 'trouble-maker' there. How lucky :-) ps: The current requirements probably not suitable for them but I shall leave it to them to explain why. pss: There are other kind of registries who would be interested in this work. They should be appropriately be informed. IP, keywords and URN comes to mind immediately. And probably ENUM/E164, if ITU could get their head around to understand it. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f14C9UJp020019 for ietf-provreg-outgoing; Sun, 4 Feb 2001 13:09:30 +0100 (MET) Received: from i1.i-dns.com (i1.idns.org [209.249.141.24]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f14C9S6V020014 for ; Sun, 4 Feb 2001 13:09:29 +0100 (MET) Received: from jamessonyvaio (PPPa21-ResaleDialinx80015-3R7409.dialinx.net [4.16.206.242]) by i1.i-dns.com (8.9.3/8.9.1) with SMTP id EAA05993; Sun, 4 Feb 2001 04:09:12 -0800 Message-ID: <004301c08ea3$18f337a0$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Edward Lewis" , "Dave Crocker" Cc: , "Patrik Faltstrom" References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Sun, 4 Feb 2001 20:07:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dave, > At 05:17 PM 2/3/2001 -0500, Edward Lewis wrote: > >The reason I removed the mention of the draft is that we are not here to > >bless a particular protocol generated outside the working group, but rather > >to generate a protocol in full view of the IETF. Scott's proposals are > >fine starting points, but if there happens to be a better proposal out > >there, we aren't going to stop it. > > 1. If there happened to be a better proposal, then we would have heard > about it by now. I really really have to disagree with you here as much as I hate to do so. There is definately other proposal out there. There is no such thing as one solution for a particular problem. If the intention of this WG is to make Scott I-D into an RFC, honestly, there is *NO NEED* for the WG. All Scott needs to do is to submit it to the IESG for review. There is no better proposal now, yes. But there is none other either which makes the choice scarely. It is like voting for the president with one candidate. And there are no other proposal now because others who may be interested in this area either (a) have not heard of it (b) trying to look for it (i have to hunt for it. for goodness sake, i cant even find the archive until someone else posted it), (c) they may be still drafting it. And yes, i am writing a proposal. But I like to see if we can get any consensus on the requirements first. -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f144YMAd018282 for ietf-provreg-outgoing; Sun, 4 Feb 2001 05:34:22 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f144YK6V018277 for ; Sun, 4 Feb 2001 05:34:21 +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 UAA05121; Sat, 3 Feb 2001 20:34:18 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010203202358.01d8f548@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Sat, 03 Feb 2001 20:31:51 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: Edward Lewis , , "Patrik Faltstrom" In-Reply-To: References: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:19 PM 2/3/2001 -0500, Edward Lewis wrote: >I don't know if the IESG would rather us be starting >from documents existing prior to the WG formation, or would rather us have >a charter indicating a clean slate. Typically the IESG reacts to choices by the working group, rather than attempting to do proactive management. This involves a precept of the IETF, which is that working groups are largely expected to know what is needed for them to accomplish their tasks. I do not recall seeing any traffic on the list that objected to citing the document. As I noted, in fact the document has substantial support. (I'll be more explicit: I know of folks who would have been delighted to shoot it down. They studied the thing carefully and decided that it was fine.) So was the removal based on feedback from the AD, IESG, or what? >I am doing the best I can to make sure we don't jump the gun on the >process, fail to invite as much comment on this protocol as is needed, and >yet still get a timely specification done within the IETF. One cannot fault such sentiments. They are entirely appropriate. The reason I am pursuing this, however, is that IETF fairness and openness permit more management flexibility than is often appreciated, and the reason for the flexibility is to assist in making forward progress, especially when there is a sense of urgency. As I've noted, there is nothing unusual or inappropriate about citing a particular draft as a basis, given good support and a clear understanding that the working group is ultimately empowered to make whatever changes it deems appropriate. This does not fail to invite comment. Rather, it focuses it. At any rate, we have both stated our views thoroughly. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f144LXDG018233 for ietf-provreg-outgoing; Sun, 4 Feb 2001 05:21:33 +0100 (MET) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f144LV6V018228 for ; Sun, 4 Feb 2001 05:21:32 +0100 (MET) Received: from 207-172-150-143.s16.as10.anp.md.dialup.rcn.com ([207.172.150.143]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PGg5-0002u6-00 ; Sat, 03 Feb 2001 23:21:29 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Feb 2001 23:19:11 -0500 To: Dave Crocker From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: Edward Lewis , , "Patrik Faltstrom" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 6:20 PM -0500 2/3/01, Dave Crocker wrote: >What changed? Right now I am basically waiting for feedback from the IESG. I see the point of having documents by name and I see the point of not having the documents by name. I don't know if the IESG would rather us be starting from documents existing prior to the WG formation, or would rather us have a charter indicating a clean slate. In either case, I have a charter written. In my mail on the topic of the charter and meeting schedule, I am trying to lay out the possibilities. There has been no other proposal and I know of no other proposal. I don't expect there to be another proposal. The urgency for a quickly defined protocol has always been there, has been discussed ad infinitum, and is still recognized. There is no reason to think anyone wants to draw out the process. I am doing the best I can to make sure we don't jump the gun on the process, fail to invite as much comment on this protocol as is needed, and yet still get a timely specification done within the IETF. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13NOBWx016171 for ietf-provreg-outgoing; Sun, 4 Feb 2001 00:24:11 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13NO96V016166 for ; Sun, 4 Feb 2001 00:24:09 +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 PAA00837; Sat, 3 Feb 2001 15:23:33 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010203150003.02ead4c0@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Sat, 03 Feb 2001 15:20:22 -0800 To: Edward Lewis From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: , "Patrik Faltstrom" In-Reply-To: References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edward, At 05:17 PM 2/3/2001 -0500, Edward Lewis wrote: >The reason I removed the mention of the draft is that we are not here to >bless a particular protocol generated outside the working group, but rather >to generate a protocol in full view of the IETF. Scott's proposals are >fine starting points, but if there happens to be a better proposal out >there, we aren't going to stop it. 1. If there happened to be a better proposal, then we would have heard about it by now. 2. As I noted earlier, the existing specification has already received quite a bit of diverse review... and support. That does not mean it needs no changes. Rather it means that there is good reason to believe that it is a solid base, from which relatively minor changes are likely. Yes, this all depends upon group consensus, but there is good evidence that consensus exists for using it as the base. 3. There is extensive history with having an IETF working group charter explicitly cite that a particular draft proposal will be used as a base. Yes, there are times when a working group starts with an empty slate and does all the work from scratch; but it is often true that a detailed proposal exists and has strong enough support to be used as the base. This is one of those cases. That was why I put the language in the original draft charter. 4. So as I noted earlier, inviting proposals now is going to have only the effect of adding delay. >Yes, there exists the possibility that other proposals may come along. "May" come along. If there were a raging debate about paradigms and choices and if there were multiple detailed specifications, citing one in the charter would be inappropriate. That is not the case, here. >But if the consensus is that there is a deadline 1. I thought that we had seen multiple confirmations on the list of some urgency. 2. The milestone dates were chosen to be aggressive, based both on the sense of urgency and the sense that Scott's proposal had strong support as a base. What changed? > >In point of fact, Scott's proposal has already received quite extensive > >review from, from very different perspectives, and the consensus seems to > >be that it is an excellent starting point. > >This makes it (the requirements draft) a shoo-in as a WG document. It is >also less likely that there will be an alternative requirements draft >coming in that could delay consensus on the requirements. I am pressing this issue forcefully for a basic concern about working group management. The charter is a contract and the language of the charter is often very useful for helping to eliminate distracting discussion. Hence, the charter can be very useful for ensuring group focus. By eliminating the citation of Scott's draft as the base you are inviting several months of design theory debates. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13N8KBS016097 for ietf-provreg-outgoing; Sun, 4 Feb 2001 00:08:20 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13N8J6V016092 for ; Sun, 4 Feb 2001 00:08:19 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCZQ; Sat, 3 Feb 2001 15:24:11 -0800 Message-ID: <008301c08e35$ed128a40$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Dave Crocker" Cc: "'provreg List'" , "Edward Lewis" References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> <5.1.0.7.2.20010203145815.01be7410@brandenburg.com> Subject: Re: Interim Meeting Date: Sat, 3 Feb 2001 15:06:22 -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 f13N8K6V016093 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > >I said it before, and I'll say it again - I want a travel assistant! :-) > > You already have one. ITN, Travelocity, etc. Not the same as, "Hey, Fred, I need to be at Dulles for a meeting on the 20th, bracket it by a day on either side, would you, and I'd like to come back in the late afternoon if possible?" Sure, it's decadent, but I can dream... Christopher Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13N250o016062 for ietf-provreg-outgoing; Sun, 4 Feb 2001 00:02:05 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13N236V016057 for ; Sun, 4 Feb 2001 00:02:04 +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 PAA00553; Sat, 3 Feb 2001 15:02:02 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010203145815.01be7410@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Sat, 03 Feb 2001 14:59:35 -0800 To: "Christopher Ambler" From: Dave Crocker Subject: Re: Interim Meeting Cc: "'provreg List'" , "Edward Lewis" In-Reply-To: <006e01c08e2d$876cc960$0a01a8c0@ambler.net> References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 02:06 PM 2/3/2001 -0800, Christopher Ambler wrote: >What's BWI? Baltimore? Baltimore/Washington International. Perhaps halfway between the two cities. Effectively the same distance, to the east of Washington, as Dulles is to the West. In other words, a pain, but viable. By contrast, the fare I quoted earlier goes into Dulles. >I said it before, and I'll say it again - I want a travel assistant! :-) You already have one. ITN, Travelocity, etc. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13MPgtm015879 for ietf-provreg-outgoing; Sat, 3 Feb 2001 23:25:42 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13MPe6V015874 for ; Sat, 3 Feb 2001 23:25:41 +0100 (MET) Received: from 207-172-157-136.s65.as6.anp.md.dialup.rcn.com ([207.172.157.136]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PB7j-0003Ax-00 ; Sat, 03 Feb 2001 17:25:39 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <006e01c08e2d$876cc960$0a01a8c0@ambler.net> References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Feb 2001 17:23:17 -0500 To: "Christopher Ambler" From: Edward Lewis Subject: Re: Interim Meeting Cc: "'provreg List'" , "Edward Lewis" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 5:06 PM -0500 2/3/01, Christopher Ambler wrote: >What's BWI? Baltimore? BWI is Baltimore/Washington International. If you use the airport designation "WAS" for WashingtonDC, you get three airports - Dulles, BWI, and National/Reagan. Others may find that some routes are much cheaper to one of the three than the others. In particular, BWI is a main airport for Southwest and as a result (of competition) generally has lower fares within the US than Dulles. For those overseas, Southwest flies only within the US and has no international (to us) partners. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13MLDcv015837 for ietf-provreg-outgoing; Sat, 3 Feb 2001 23:21:13 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13MLB6V015832 for ; Sat, 3 Feb 2001 23:21:12 +0100 (MET) Received: from 207-172-157-136.s65.as6.anp.md.dialup.rcn.com ([207.172.157.136]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PB3F-0002QO-00 ; Sat, 03 Feb 2001 17:21:01 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200102022241.f12Mf1303704@zed.isi.edu> References: <200102022315.f12NFWn57877@nic-naa.net> from "Eric Brunner-Williams in Portland Maine" at Feb 02, 2001 06:15:32 PM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Feb 2001 17:18:31 -0500 To: Bill Manning From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: brunner@nic-naa.net (Eric Brunner-Williams in Portland Maine), lewis@tislabs.com, ietf-provreg@cafax.se, paf@cisco.com (Patrik Faltstrom) Sender: owner-ietf-provreg@cafax.se Precedence: bulk The charter mentions DNS administration to set the context of the work, it itself is not a work item. At 5:41 PM -0500 2/2/01, Bill Manning wrote: >% Ed, >% >% The scope expressed in this charter draft mentions: >% administration of the DNS, DNS Registries, Registrars, Registrants, >% plurality of mid-level access modes (multiple DNS registries, and >% multiple DNS registrars), R2R application interaction and other >% rational boilerplate, >% >% and fails to mention: >% whois (any varient) >% >% and declines to put non-DNS registration interests ahead of DNS >registration. >% >% In my view these are attractive features of this charter, and I understand >% from Mr. Seng's earlier repeated comments that he does not. >% >% If anything, the focus of the work will be sharpened by having to recharter >% upon completion of DNS Registrataion work, if in fact there is a need for a >% standard in some related or extended area(s). >% >% Cheers, >% Eric > > Hum... perhaps the charter is a bit too broad. IMHO, > "administration of the DNS" is way outside a registration > protocol. DNS has an existing OPS wg (DNSOPS) and has existing > protocols for performing DNS administration... > > > >-- >--bill -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13ML2sG015829 for ietf-provreg-outgoing; Sat, 3 Feb 2001 23:21:02 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13ML06V015823 for ; Sat, 3 Feb 2001 23:21:01 +0100 (MET) Received: from 207-172-157-136.s65.as6.anp.md.dialup.rcn.com ([207.172.157.136]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PB3C-0002QO-00 ; Sat, 03 Feb 2001 17:20:58 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> References: <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Feb 2001 17:17:08 -0500 To: Dave Crocker From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: , "Patrik Faltstrom" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 5:59 PM -0500 2/2/01, Dave Crocker wrote: >Removing the reference to Scott's draft is a very serious mistake, >PRECISELY for the reason noted above: If someone has an alternative draft, >they have not come forward with it. Inviting people to START on new drafts >is an excellent way to ensure that this working group take MUCH longer to >do something useful. The reason I removed the mention of the draft is that we are not here to bless a particular protocol generated outside the working group, but rather to generate a protocol in full view of the IETF. Scott's proposals are fine starting points, but if there happens to be a better proposal out there, we aren't going to stop it. Yes, there exists the possibility that other proposals may come along. But if the consensus is that there is a deadline and there is an acceptable proposal available, a "promising" future proposal may be dismissed if it will not meet the deadline. >In point of fact, Scott's proposal has already received quite extensive >review from, from very different perspectives, and the consensus seems to >be that it is an excellent starting point. This makes it (the requirements draft) a shoo-in as a WG document. It is also less likely that there will be an alternative requirements draft coming in that could delay consensus on the requirements. The WG discussion on it will likely be quick. It is possible that we could go to last call within a month of being a WG (allowing time for any other input to be made under the mantle of a WG). I haven't seen nearly as much consensus on EPP yet, but at least Scott has a laid out plan. We have a good starting point. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13M8ESa015754 for ietf-provreg-outgoing; Sat, 3 Feb 2001 23:08:14 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13M8C6V015749 for ; Sat, 3 Feb 2001 23:08:13 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCYJ; Sat, 3 Feb 2001 14:24:04 -0800 Message-ID: <006e01c08e2d$876cc960$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "'provreg List'" , "Edward Lewis" References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> Subject: Re: Interim Meeting Date: Sat, 3 Feb 2001 14:06:15 -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 f13M8D6V015750 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > As far as airfare from Seattle (sorry, Chris, I couldn't resist the challenge): > > Southwest air flights: > 244/133 on Feb 19 (leaves SeaTac 1pm, change in KC, lands BWI 10:45pm) > 113/2359 on Feb 21 (leaves BWI 7:55am, change in Phoenix, lands S/T 3:40pm) > > Total cost: $431 (including taxes), no Sat stayover needed. (I just got > these prices on there web site.) BWI is about 60 miles from the meeting. Challenges rock, no apology necessary. I found a convoluted fare that would take me from my meeting in LA directly to DC (just not taking the trip home to Seattle first) a day early, and put in for it. We shall see. What's BWI? Baltimore? I said it before, and I'll say it again - I want a travel assistant! :-) Christopher Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13LxIdc015695 for ietf-provreg-outgoing; Sat, 3 Feb 2001 22:59:18 +0100 (MET) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13LxG6V015690 for ; Sat, 3 Feb 2001 22:59:17 +0100 (MET) Received: from 207-172-157-136.s65.as6.anp.md.dialup.rcn.com ([207.172.157.136]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PAiA-000735-00 ; Sat, 03 Feb 2001 16:59:14 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <004501c08e17$4eae1f40$0a01a8c0@ambler.net> References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Feb 2001 16:56:37 -0500 To: "'provreg List'" From: Edward Lewis Subject: Re: Interim Meeting Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk I want to emphasize what Scott posted on this thread: > Nothing is ever decided with finality at face-to-face IETF meetings -- > consensus decisions are made using mailing lists like this one. The meeting will have a posted agenda, one has already been proposed on the list (check the archives). The meeting will also have minutes, just as all regular IETF meetings do. Recall that we are 'calendar squeezed' for this meeting. Many of us are involved in other activities - ICANN and APRICOT meet between now and the IETF. As far as scheduling the meeting - The DC location was chosen after consideration in a thread. (Again, check the archives.) I started the motion to set the meeting in place on Jan. 20, the first day after I heard that our charter had been sent to the IESG. The latest we would be allowed to hold a meeting would be Feb 23, or we'd be running to close to the IETF main meeting (not to mention APRICOT and ICANN conflicts). Given that we wanted as much notice possible, that pretty much put us around Feb 20. As far as airfare from Seattle (sorry, Chris, I couldn't resist the challenge): Southwest air flights: 244/133 on Feb 19 (leaves SeaTac 1pm, change in KC, lands BWI 10:45pm) 113/2359 on Feb 21 (leaves BWI 7:55am, change in Phoenix, lands S/T 3:40pm) Total cost: $431 (including taxes), no Sat stayover needed. (I just got these prices on there web site.) BWI is about 60 miles from the meeting. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13JTABT014955 for ietf-provreg-outgoing; Sat, 3 Feb 2001 20:29:10 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13JT96V014950 for ; Sat, 3 Feb 2001 20:29:09 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCVX; Sat, 3 Feb 2001 11:44:59 -0800 Message-ID: <004501c08e17$4eae1f40$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Jaap Akkerhuis" , "Dave Crocker" Cc: "'provreg List'" References: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> Subject: Re: Interim Meeting Date: Sat, 3 Feb 2001 11:27:02 -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 f13JT96V014951 Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is one of those rare times that I agree with Dave. (my availability for extra days notwithstanding, as my time is almost 100% booked these days, Dave's point to add an extra day is, I believe, spot on). -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web > (And apologies to one and all for this extended thread. Obviously it is a > pet topic of mine and I am trying to promote it more broadly.) Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13JCItl014876 for ietf-provreg-outgoing; Sat, 3 Feb 2001 20:12:18 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13JCH6V014871 for ; Sat, 3 Feb 2001 20:12:17 +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 LAA29317; Sat, 3 Feb 2001 11:12:07 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010203104148.01c7ccd8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Sat, 03 Feb 2001 11:09:38 -0800 To: Jaap Akkerhuis From: Dave Crocker Subject: Re: Interim Meeting Cc: "'provreg List'" In-Reply-To: <200102031630.RAA19538@bartok.sidn.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 05:30 PM 2/3/2001 +0100, Jaap Akkerhuis wrote: > I managed to find a United $500 fare from san jose, but it took > some digging. > >You don't want ty know about prices in Europe. Although the current event is not a counter-example example, it is often true that prices between Europe (or even Asia) and the US are cheaper than WITHIN the U.S! Market forces can be SO interesting sometimes. But more generally, I would have wished that the meeting were at least 2 days, simply because the travel time and money are so expensive. Again, it is far too late to change the current plans, but it is worth remembering. > Yes, we DO need an agenda. In addition, I suggest that the > cost of attending the meeting is high enough to warrant working > a longer day. So I suggest changing the time from 10-5 to be > 9-6 or 8:30-6pm (or even 6:30pm.) > >For people from Europe, this is too late. My flight leaves around >18:00 (6 pm for americans). We could have a (informal) session the >eveming beforea allthough the jet-lag might be a problem... Departure times vary. While it is important that the schedule not exclude people excessively, it is frequently true that some people arrive late or leave early. Many flights to Europe depart at 8-10pm, for example. (Hmmm. That might not be true from Chicago, or Dallas, it occurs to me. I am probably remember Easter U.S.) So, your point is well taken. In any event, I was simply trying to suggest that we extend the hours as much as we can. The group needs consensus on the specific choices for starting and stopping. Your suggestion that the current meeting hold an informal discussion the night before is excellent! > If we do an interim meeting in the US again, I'll suggest that > we meet in Chicago or Dallas, starting at 1:30pm, and all of > >For non-American attendees this might not be an option. We should >minimize on interim meetings anyway. We should, indeed. I have done enough long-haul flight to be entirely empathetic with your concerns. (But then, flying long-haul for a one-day meeting is quite daunting, since I prefer a few days to adjust, before doing real work.) However, long-haul flights usually arrive in the morning, with customs, etc., usually meaning that one is free of the airport no later than about 11am. That would leave enough time to check into the hotel and take a break, before the meeting. (And apologies to one and all for this extended thread. Obviously it is a pet topic of mine and I am trying to promote it more broadly.) d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f13GUjN9014205 for ietf-provreg-outgoing; Sat, 3 Feb 2001 17:30:45 +0100 (MET) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f13GUh6V014200 for ; Sat, 3 Feb 2001 17:30:44 +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 RAA32677; Sat, 3 Feb 2001 17:30:41 +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 RAA19538; Sat, 3 Feb 2001 17:30:36 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200102031630.RAA19538@bartok.sidn.nl> To: Dave Crocker cc: "Christopher Ambler" , "'provreg List'" Subject: Re: Interim Meeting In-reply-to: Your message of Fri, 02 Feb 2001 16:01:18 -0800. <5.1.0.7.2.20010202155657.01d54ea0@brandenburg.com> Date: Sat, 03 Feb 2001 17:30:36 +0100 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk I managed to find a United $500 fare from san jose, but it took some digging. You don't want ty know about prices in Europe. Yes, we DO need an agenda. In addition, I suggest that the cost of attending the meeting is high enough to warrant working a longer day. So I suggest changing the time from 10-5 to be 9-6 or 8:30-6pm (or even 6:30pm.) For people from Europe, this is too late. My flight leaves around 18:00 (6 pm for americans). We could have a (informal) session the eveming beforea allthough the jet-lag might be a problem... If we do an interim meeting in the US again, I'll suggest that we meet in Chicago or Dallas, starting at 1:30pm, and all of the following day. That will give almost 2 full days of meeting, for the cost of one over-night, to North American-based attendees. However folks will mostly already have their tickets, so I won't suggest making a change for the 20 Feb. meeting. For non-American attendees this might not be an option. We should minimize on interim meetings anyway. jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f135wZnN011932 for ietf-provreg-outgoing; Sat, 3 Feb 2001 06:58:35 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f135wY6V011927 for ; Sat, 3 Feb 2001 06:58:34 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCNJ; Fri, 2 Feb 2001 22:14:16 -0800 Message-ID: <001601c08da6$1192e120$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Dave Crocker" Cc: "'provreg List'" References: <5.1.0.7.2.20010202155657.01d54ea0@brandenburg.com> <5.1.0.7.2.20010202214236.01d8e6d8@brandenburg.com> Subject: Re: Interim Meeting Date: Fri, 2 Feb 2001 21:56:24 -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 f135wZ6V011928 Sender: owner-ietf-provreg@cafax.se Precedence: bulk As we all know, airfares change, literally, every minute. $1100 is still pretty steep, but more manageable. I've been checking online (as well as asking my mother, a travel agent, to monitor for me) every couple of hours or so. One more reason to hire an assistant... looking for a job, Dave? :-) -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web ----- Original Message ----- From: "Dave Crocker" To: "Christopher Ambler" Cc: "'provreg List'" Sent: Friday, February 02, 2001 9:47 PM Subject: Re: Interim Meeting > At 04:46 PM 2/2/2001 -0800, Christopher Ambler wrote: > >The best I found from other west coast cities (LA, SFO) was $555, but none > >of the iteneraries matched up on a commuter hop from Seattle when I checked, > >and by the time I found one, the fare was gone. Such is life. > > > >The laughter from our CFO when I told her the fare was $2300 was just a > >bit embarrassing :-) > > > As it should have been. > > The following took about 5 minutes to uncover at itn.net, using Instant > Itinerary: > > > Seattle (SEA) to Washington (IAD) Monday, Feb 19 > > United Airlines 736 Boeing 757-200 > Feb 19 6:00 am SEA Feb 19 9:31 am DEN > > United Airlines 970 Boeing 777 > Feb 19 10:30 am DEN Feb 19 3:36 pm IAD > > > Washington (IAD) to Seattle (SEA) Wednesday, Feb 21 > > United Airlines 435 Boeing 737-300 > Feb 21 2:05 pm IAD Feb 21 4:02 pm DEN > > United Airlines 291 Boeing 737-300 > Feb 21 5:05 pm DEN Feb 21 6:59 pm SEA > > > Total Airfare (including taxes) USD 1171.00 > > > > > > > ---------- > Dave Crocker > Brandenburg Consulting > tel: +1.408.246.8253; fax: +1.408.273.6464 > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f135pZ3s011886 for ietf-provreg-outgoing; Sat, 3 Feb 2001 06:51:35 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f135pX6V011881 for ; Sat, 3 Feb 2001 06:51:34 +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 VAA19672; Fri, 2 Feb 2001 21:51:32 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010202214236.01d8e6d8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 21:47:15 -0800 To: "Christopher Ambler" From: Dave Crocker Subject: Re: Interim Meeting Cc: "'provreg List'" In-Reply-To: <00f701c08d7a$bf09f040$0a01a8c0@ambler.net> References: <5.1.0.7.2.20010202155657.01d54ea0@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 04:46 PM 2/2/2001 -0800, Christopher Ambler wrote: >The best I found from other west coast cities (LA, SFO) was $555, but none >of the iteneraries matched up on a commuter hop from Seattle when I checked, >and by the time I found one, the fare was gone. Such is life. > >The laughter from our CFO when I told her the fare was $2300 was just a >bit embarrassing :-) As it should have been. The following took about 5 minutes to uncover at itn.net, using Instant Itinerary: Seattle (SEA) to Washington (IAD) Monday, Feb 19 United Airlines 736 Boeing 757-200 Feb 19 6:00 am SEA Feb 19 9:31 am DEN United Airlines 970 Boeing 777 Feb 19 10:30 am DEN Feb 19 3:36 pm IAD Washington (IAD) to Seattle (SEA) Wednesday, Feb 21 United Airlines 435 Boeing 737-300 Feb 21 2:05 pm IAD Feb 21 4:02 pm DEN United Airlines 291 Boeing 737-300 Feb 21 5:05 pm DEN Feb 21 6:59 pm SEA Total Airfare (including taxes) USD 1171.00 ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f132cPXZ011012 for ietf-provreg-outgoing; Sat, 3 Feb 2001 03:38:25 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f132cN6V011007 for ; Sat, 3 Feb 2001 03:38:24 +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 SAA16910; Fri, 2 Feb 2001 18:38:21 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010202183512.02f8bdd0@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 18:35:54 -0800 To: "James Seng/Personal" From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: , "Patrik Faltstrom" In-Reply-To: <086101c08d86$5c70bc00$84411004@jamessonyvaio> References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <5.1.0.7.2.20010202175454.01d0ddb8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:09 AM 2/3/2001 +0800, James Seng/Personal wrote: >You know, it is very difficult to disagree with you :-) oh?. i need to get you to talk with some people involved with the ICANN process... d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f132B5Rq010040 for ietf-provreg-outgoing; Sat, 3 Feb 2001 03:11:05 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f132B36V010035 for ; Sat, 3 Feb 2001 03:11:04 +0100 (MET) Received: from jamessonyvaio (PPPa85-ResaleDialinx80013-4R7207.dialinx.net [4.54.159.146]) by mail.i-dns.net (Postfix) with SMTP id 6ED6EFFC0E; Sat, 3 Feb 2001 10:10:45 +0800 (SGT) Message-ID: <086101c08d86$5c70bc00$84411004@jamessonyvaio> From: "James Seng/Personal" To: "Dave Crocker" Cc: , "Patrik Faltstrom" References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> <5.1.0.7.2.20010202175454.01d0ddb8@brandenburg.com> Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Sat, 3 Feb 2001 10:09:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dave, You know, it is very difficult to disagree with you :-) -James Seng ----- Original Message ----- From: "Dave Crocker" To: "James Seng/Personal" Cc: ; "Patrik Faltstrom" Sent: Saturday, February 03, 2001 10:00 AM Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) > At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote: > >Dave, > > > > > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote: > > > >I would like to object this proposed charter for provreg. Its scope > >has > > > >been so specific defined for DNS only and has no mention of anything > > > >beyond DNS. > > > > > > feature, not bug. > > > >It depends who you speaking to...To me, it is a bug. > > My statement is based on experience with IETF processes, observation of > other standards processes and experience with product development. It > seems to be one of the empirical truths about project success, especially > when an open group process is involved. > > Start with the simplest, most specific deliverable that will be > useful. Then evolve. > > > >However, I can not understand is what is the hurry for the WG to get > >this out quickly? > > That has been discussed before. Existing and new registries and registrars > want this NOW. > > > >If it is about new gTLD registry, any of the new gTLD registry who have > >not started work implementing their system now is crazy. I dont think > >any of them will wait for the result of the WG (Sept?) before starting > >work. For this, we are already too late. > > For their initial use, yes. But some of them have already spoken, here, to > validate the urgency of their need. > > > >Either way, IMHO, we are already too late in a non-standardised world. > > James, unfortunately that is one of the usual argument for taking forever. > > >Hence, it is better to work on a GOOD and long term technical solution > > Again, that is unfortunately a frequently-heard comment in standards arenas > that is obviously well-intentioned, but turns out to be > counter-productive. It is one of the ironies of this sort of standards work. > > d/ > > ---------- > Dave Crocker > Brandenburg Consulting > tel: +1.408.246.8253; fax: +1.408.273.6464 > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1323YYh009995 for ietf-provreg-outgoing; Sat, 3 Feb 2001 03:03:34 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1323W6V009990 for ; Sat, 3 Feb 2001 03:03:33 +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 SAA16428; Fri, 2 Feb 2001 18:03:30 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010202175454.01d0ddb8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 18:00:12 -0800 To: "James Seng/Personal" From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: , "Patrik Faltstrom" In-Reply-To: <077301c08d81$95404a50$84411004@jamessonyvaio> References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote: >Dave, > > > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote: > > >I would like to object this proposed charter for provreg. Its scope >has > > >been so specific defined for DNS only and has no mention of anything > > >beyond DNS. > > > > feature, not bug. > >It depends who you speaking to...To me, it is a bug. My statement is based on experience with IETF processes, observation of other standards processes and experience with product development. It seems to be one of the empirical truths about project success, especially when an open group process is involved. Start with the simplest, most specific deliverable that will be useful. Then evolve. >However, I can not understand is what is the hurry for the WG to get >this out quickly? That has been discussed before. Existing and new registries and registrars want this NOW. >If it is about new gTLD registry, any of the new gTLD registry who have >not started work implementing their system now is crazy. I dont think >any of them will wait for the result of the WG (Sept?) before starting >work. For this, we are already too late. For their initial use, yes. But some of them have already spoken, here, to validate the urgency of their need. >Either way, IMHO, we are already too late in a non-standardised world. James, unfortunately that is one of the usual argument for taking forever. >Hence, it is better to work on a GOOD and long term technical solution Again, that is unfortunately a frequently-heard comment in standards arenas that is obviously well-intentioned, but turns out to be counter-productive. It is one of the ironies of this sort of standards work. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f131jRKt009909 for ietf-provreg-outgoing; Sat, 3 Feb 2001 02:45:27 +0100 (MET) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f131jQ6V009904 for ; Sat, 3 Feb 2001 02:45:27 +0100 (MET) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA01065 for ; Fri, 2 Feb 2001 20:45:26 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Feb 2001 20:40:25 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'provreg List'" Subject: RE: Interim Meeting Date: Fri, 2 Feb 2001 20:40:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Nothing is ever decided with finality at face-to-face IETF meetings -- consensus decisions are made using mailing lists like this one. Those of us who have asked for an interim meeting want to get down to critical review of the EPP proposals, and to that end I think we need to do the following between now and 21+ February: 1. We come to some semblance of closure on the requirements. The updated draft was posted almost two weeks ago, and I haven't seen any discussion since. Does that mean I got it right this time? ;-) 2. We identify macro issues with the base EPP specification (based on the requirements and whatever else matters), and maybe the domain, host, and contact specifications. There are some things that I want to change based on our requirements discussions, such as transaction identifiers and domain expiration. If we can reach quick agreement on any issues before the meeting, that's great. Issues that need more in-depth discussion get tabled for discussion at the interim meeting. 3. We produce a concise list of issues to be discussed at the interim meeting to form the bulk of the agenda. 4. We hold the meeting, and discuss each issue until we reach some logical conclusion (I can probably hold the room for more time if needed, but I would need to know that pretty soon). Depending on how things go we make some tentative decisions about next steps. 5. Meeting notes and next step thoughts are posted to this list ASAP after we finish (will someone volunteer to take and post detailed notes?). 6. Document editing starts on 21 February based on interim meeting discussions, and the new draft(s) are published ASAP. 7. We discuss the results of the interim meeting, the new drafts, and next steps on this list. -----Original Message----- From: Christopher Ambler [mailto:cambler-ietf@iodesign.com] Sent: Friday, February 02, 2001 6:45 PM To: 'provreg List' Subject: Re: Interim Meeting [snip] What is the agenda for this meeting, will anything be decided (I suspect not)? Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f131arhm009855 for ietf-provreg-outgoing; Sat, 3 Feb 2001 02:36:53 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f131ao6V009850 for ; Sat, 3 Feb 2001 02:36:51 +0100 (MET) Received: from jamessonyvaio (PPPa32-ResaleDialinx80024-4R7337.dialinx.net [4.16.67.93]) by mail.i-dns.net (Postfix) with SMTP id 3F6A1FFC0F; Sat, 3 Feb 2001 09:36:33 +0800 (SGT) Message-ID: <077301c08d81$95404a50$84411004@jamessonyvaio> From: "James Seng/Personal" To: , "Dave Crocker" Cc: "Patrik Faltstrom" References: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Sat, 3 Feb 2001 09:35:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dave, > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote: > >I would like to object this proposed charter for provreg. Its scope has > >been so specific defined for DNS only and has no mention of anything > >beyond DNS. > > feature, not bug. It depends who you speaking to...To me, it is a bug. > start with a narrow focus. do something useful quickly. then come back > and expand the scope. > > The more general the scope, the longer the cycle to delivery something useful. I agree. However, I can not understand is what is the hurry for the WG to get this out quickly? If it is about new gTLD registry, any of the new gTLD registry who have not started work implementing their system now is crazy. I dont think any of them will wait for the result of the WG (Sept?) before starting work. For this, we are already too late. If it is just pure market pressure to have this, well, the answer is fairly simple. Different registries are already using different system ranging from taking it via by hand, by email, by webpage, to more automated one, RRP or some variant of RRP. For those high-tech ones which uses automated system, moving to a new standard takes a lot of time so it wont happen overnight. For those still on low-tech, investment to create whatever specify here is going be very high for them which means potential opportunity for those who can get a solution to them. Either way, IMHO, we are already too late in a non-standardised world. Hence, it is better to work on a GOOD and long term technical solution then something half-baked push out quickly for an immediated need which no longer exist. Am I missing something? -James Seng Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f131PKoN009794 for ietf-provreg-outgoing; Sat, 3 Feb 2001 02:25:20 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f131PI6V009789 for ; Sat, 3 Feb 2001 02:25:19 +0100 (MET) Received: from jamessonyvaio (PPPa32-ResaleDialinx80024-4R7337.dialinx.net [4.16.67.93]) by mail.i-dns.net (Postfix) with SMTP id 6F5BBFFC0E; Sat, 3 Feb 2001 09:25:01 +0800 (SGT) Message-ID: <075701c08d7f$f8e5b2e0$84411004@jamessonyvaio> From: "James Seng/Personal" To: "Edward Lewis" Cc: "Paul George" , References: <000301c08d5b$08ae12a0$73bdd93f@PGEORGE> Subject: Re: WG Review: Provisioning Registry Protocol (provreg) Date: Sat, 3 Feb 2001 09:23:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yes, you may say you have generally agreement in this mailing list, apparently comprises of a lot of people in the domain names industry (me included). However, I do wish to state my position that I still think the charter focus is too focus on domain names registration only. But one person should not stop you from submitting it to the IESG. -James Seng ----- Original Message ----- From: "Edward Lewis" To: "James Seng/Personal" Cc: "Paul George" ; Sent: Saturday, February 03, 2001 6:07 AM Subject: Re: WG Review: Provisioning Registry Protocol (provreg) > In summary - let's say we are in raging agreement as far as what the > charter should be. As far as what was put into the ietf-announce message, > that will be fixed one way or another. (I may have sent the updated one in > too close to the conference call, so the older one was processed.) Keep in > mind that the IESG has the last say, so I can't guarantee anything, but at > this point I am willing to trust that the IESG will "do the right thing > (tm)." > > At 4:08 PM -0500 2/2/01, James Seng/Personal wrote: > >Go take a look at the annoucement made by the IESG. It is obviously not > >there so somehow, somewhere, someone make a mistake. > > > >No, it is not too late to give them an update copy. In fact, there is no > >such thing as too late. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f130mNxU009577 for ietf-provreg-outgoing; Sat, 3 Feb 2001 01:48:23 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f130mM6V009572 for ; Sat, 3 Feb 2001 01:48:22 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCFQ; Fri, 2 Feb 2001 17:04:01 -0800 Message-ID: <00f701c08d7a$bf09f040$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Dave Crocker" Cc: "'provreg List'" References: <5.1.0.7.2.20010202155657.01d54ea0@brandenburg.com> Subject: Re: Interim Meeting Date: Fri, 2 Feb 2001 16:46:28 -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 f130mN6V009573 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I managed to find a United $500 fare from san jose, but it took some digging. The best I found from other west coast cities (LA, SFO) was $555, but none of the iteneraries matched up on a commuter hop from Seattle when I checked, and by the time I found one, the fare was gone. Such is life. > If we do an interim meeting in the US again, I'll suggest that we meet in > Chicago or Dallas, starting at 1:30pm, and all of the following day. That > will give almost 2 full days of meeting, for the cost of one over-night, to > North American-based attendees. However folks will mostly already have > their tickets, so I won't suggest making a change for the 20 Feb. meeting. Chicago, being a hub, would be most excellent. And please, let's try to make it at least 45 days advance notice, if at all possible? The laughter from our CFO when I told her the fare was $2300 was just a bit embarrassing :-) Christopher Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f1304Jmr009334 for ietf-provreg-outgoing; Sat, 3 Feb 2001 01:04:19 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f1304H6V009329 for ; Sat, 3 Feb 2001 01:04:18 +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 QAA14291; Fri, 2 Feb 2001 16:04:16 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010202155657.01d54ea0@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 16:01:18 -0800 To: "Christopher Ambler" From: Dave Crocker Subject: Re: Interim Meeting Cc: "'provreg List'" In-Reply-To: <002f01c08d72$2bbf0120$0a01a8c0@ambler.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 03:45 PM 2/2/2001 -0800, Christopher Ambler wrote: >As of that date, the best air fare from the west coast (Seattle) was >$1400. It is >now $2300, and there is little chance of a fare sale. I managed to find a United $500 fare from san jose, but it took some digging. >What is the agenda for this meeting, will anything be decided (I suspect not)? Yes, we DO need an agenda. In addition, I suggest that the cost of attending the meeting is high enough to warrant working a longer day. So I suggest changing the time from 10-5 to be 9-6 or 8:30-6pm (or even 6:30pm.) If we do an interim meeting in the US again, I'll suggest that we meet in Chicago or Dallas, starting at 1:30pm, and all of the following day. That will give almost 2 full days of meeting, for the cost of one over-night, to North American-based attendees. However folks will mostly already have their tickets, so I won't suggest making a change for the 20 Feb. meeting. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12Nl1Nw009223 for ietf-provreg-outgoing; Sat, 3 Feb 2001 00:47:01 +0100 (MET) Received: from exchangemail.iodesign.com (exchangemail.iodesign.com [206.190.80.251]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12Nl06V009216 for ; Sat, 3 Feb 2001 00:47:00 +0100 (MET) Received: from vulcan (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by exchangemail.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CFQRWCC0; Fri, 2 Feb 2001 16:02:37 -0800 Message-ID: <002f01c08d72$2bbf0120$0a01a8c0@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "'provreg List'" References: Subject: Re: Interim Meeting Date: Fri, 2 Feb 2001 15:45:06 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 f12Nl06V009219 Sender: owner-ietf-provreg@cafax.se Precedence: bulk As of that date, the best air fare from the west coast (Seattle) was $1400. It is now $2300, and there is little chance of a fare sale. Often, 30 days is not sufficient for a reasonable air fare, especially when there's no Saturday stay involved. What is the agenda for this meeting, will anything be decided (I suspect not)? -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Jörg Bauer/Denic'" ; Sent: Wednesday, January 31, 2001 3:56 AM Subject: RE: Interim Meeting Meeting details were sent to this list on Monday 22 January: http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00188.html > -----Original Message----- > From: Jörg Bauer/Denic [mailto:bauer@denic.de] > Sent: Wednesday, January 31, 2001 4:01 AM > To: ietf-provreg@cafax.se > Subject: Interim Meeting > > > > Are we having a interim Meeting at 20.Feb. ??? > > Could anybody post exact Place/Date ???? Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12NeJoW009148 for ietf-provreg-outgoing; Sat, 3 Feb 2001 00:40:19 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12NeH6V009143 for ; Sat, 3 Feb 2001 00:40:18 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f12NdwU10266; Fri, 2 Feb 2001 15:39:58 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f12Mf1303704; Fri, 2 Feb 2001 14:41:01 -0800 Message-Id: <200102022241.f12Mf1303704@zed.isi.edu> Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) To: brunner@nic-naa.net (Eric Brunner-Williams in Portland Maine) Date: Fri, 2 Feb 2001 14:41:01 -0800 (PST) Cc: lewis@tislabs.com, ietf-provreg@cafax.se, paf@cisco.com (Patrik Faltstrom), brunner@nic-naa.net In-Reply-To: <200102022315.f12NFWn57877@nic-naa.net> from "Eric Brunner-Williams in Portland Maine" at Feb 02, 2001 06:15:32 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % Ed, % % The scope expressed in this charter draft mentions: % administration of the DNS, DNS Registries, Registrars, Registrants, % plurality of mid-level access modes (multiple DNS registries, and % multiple DNS registrars), R2R application interaction and other % rational boilerplate, % % and fails to mention: % whois (any varient) % % and declines to put non-DNS registration interests ahead of DNS registration. % % In my view these are attractive features of this charter, and I understand % from Mr. Seng's earlier repeated comments that he does not. % % If anything, the focus of the work will be sharpened by having to recharter % upon completion of DNS Registrataion work, if in fact there is a need for a % standard in some related or extended area(s). % % Cheers, % Eric Hum... perhaps the charter is a bit too broad. IMHO, "administration of the DNS" is way outside a registration protocol. DNS has an existing OPS wg (DNSOPS) and has existing protocols for performing DNS administration... -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12NFtWc009006 for ietf-provreg-outgoing; Sat, 3 Feb 2001 00:15:55 +0100 (MET) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12NFs6V009001 for ; Sat, 3 Feb 2001 00:15:54 +0100 (MET) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f12NFWn57877; Fri, 2 Feb 2001 18:15:32 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102022315.f12NFWn57877@nic-naa.net> To: lewis@tislabs.com cc: ietf-provreg@cafax.se, "Patrik Faltstrom" , brunner@nic-naa.net Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Fri, 02 Feb 2001 18:15:32 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, The scope expressed in this charter draft mentions: administration of the DNS, DNS Registries, Registrars, Registrants, plurality of mid-level access modes (multiple DNS registries, and multiple DNS registrars), R2R application interaction and other rational boilerplate, and fails to mention: whois (any varient) and declines to put non-DNS registration interests ahead of DNS registration. In my view these are attractive features of this charter, and I understand from Mr. Seng's earlier repeated comments that he does not. If anything, the focus of the work will be sharpened by having to recharter upon completion of DNS Registrataion work, if in fact there is a need for a standard in some related or extended area(s). Cheers, Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12NBJ3N008951 for ietf-provreg-outgoing; Sat, 3 Feb 2001 00:11:19 +0100 (MET) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12NBH6V008946 for ; Sat, 3 Feb 2001 00:11:18 +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 PAA13262; Fri, 2 Feb 2001 15:11:16 -0800 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.7.2.20010202144732.01c700d8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 14:59:47 -0800 To: From: Dave Crocker Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: "Patrik Faltstrom" In-Reply-To: <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote: >I would like to object this proposed charter for provreg. Its scope has >been so specific defined for DNS only and has no mention of anything >beyond DNS. feature, not bug. start with a narrow focus. do something useful quickly. then come back and expand the scope. The more general the scope, the longer the cycle to delivery something useful. At 03:22 PM 2/2/2001 -0500, Edward Lewis wrote: >At 3:02 PM -0500 2/2/01, James Seng wrote: > >It also have references to Scott Hollenback I-Ds. While Scott have good > >I-Ds, referencing it to the WG charter is IMHO a bad idea. It will > >discourage others to come forward with their proposal. > >The updated charter does not reference the drafts. Below is the latest >one. I don't know whether the charter below will replace the one on the >ietf-announce list, but in any case, I certainly agree that the references >to the drafts should be removed. Removing the reference to Scott's draft is a very serious mistake, PRECISELY for the reason noted above: If someone has an alternative draft, they have not come forward with it. Inviting people to START on new drafts is an excellent way to ensure that this working group take MUCH longer to do something useful. In point of fact, Scott's proposal has already received quite extensive review from, from very different perspectives, and the consensus seems to be that it is an excellent starting point. More strangely, the published draft has prose that restricts the work to requirements, but specifies deliverables as specification of data objects, and the like. It also does not have milestone dates. Having the charter focus on requirements is another good way to ensure that the useful work of producing a protocol will take longer. d/ ---------- Dave Crocker Brandenburg Consulting tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12MGTt9008598 for ietf-provreg-outgoing; Fri, 2 Feb 2001 23:16:29 +0100 (MET) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12MGQ6V008593 for ; Fri, 2 Feb 2001 23:16:27 +0100 (MET) Received: by sentry.gw.tislabs.com; id RAA03516; Fri, 2 Feb 2001 17:19:44 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma003505; Fri, 2 Feb 01 17:19:23 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <064c01c08d5c$40a7a490$84411004@jamessonyvaio> References: <000301c08d5b$08ae12a0$73bdd93f@PGEORGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Feb 2001 17:07:34 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: WG Review: Provisioning Registry Protocol (provreg) Cc: "Paul George" , Sender: owner-ietf-provreg@cafax.se Precedence: bulk In summary - let's say we are in raging agreement as far as what the charter should be. As far as what was put into the ietf-announce message, that will be fixed one way or another. (I may have sent the updated one in too close to the conference call, so the older one was processed.) Keep in mind that the IESG has the last say, so I can't guarantee anything, but at this point I am willing to trust that the IESG will "do the right thing (tm)." At 4:08 PM -0500 2/2/01, James Seng/Personal wrote: >Go take a look at the annoucement made by the IESG. It is obviously not >there so somehow, somewhere, someone make a mistake. > >No, it is not too late to give them an update copy. In fact, there is no >such thing as too late. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12L9gFD008109 for ietf-provreg-outgoing; Fri, 2 Feb 2001 22:09:42 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12L9e6V008104 for ; Fri, 2 Feb 2001 22:09:41 +0100 (MET) Received: from jamessonyvaio (PPPa19-ResaleDialinx80018-1R7282.dialinx.net [4.48.36.80]) by mail.i-dns.net (Postfix) with SMTP id 8C2D0FFC0E; Sat, 3 Feb 2001 05:09:20 +0800 (SGT) Message-ID: <064c01c08d5c$40a7a490$84411004@jamessonyvaio> From: "James Seng/Personal" To: "Paul George" , References: <000301c08d5b$08ae12a0$73bdd93f@PGEORGE> Subject: Re: WG Review: Provisioning Registry Protocol (provreg) Date: Sat, 3 Feb 2001 05:08:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Go take a look at the annoucement made by the IESG. It is obviously not there so somehow, somewhere, someone make a mistake. No, it is not too late to give them an update copy. In fact, there is no such thing as too late. -James Seng ----- Original Message ----- From: "Paul George" To: Sent: Saturday, February 03, 2001 4:59 AM Subject: RE: WG Review: Provisioning Registry Protocol (provreg) > Okay, so why are there differences? Are they looking at an older version? > Is there a problem with giving them the new version? Please forgive my > ignorance, I thought this one was the version they were considering..... > > Paul George > SARAF Software Solutions > > > -----Original Message----- > From: James Seng/Personal [mailto:James@Seng.cc] > Sent: Friday, February 02, 2001 3:53 PM > To: Paul George; ietf-provreg@cafax.se > Subject: Re: WG Review: Provisioning Registry Protocol (provreg) > > > Not in the charter published by the IESG. > > -James Seng > > ----- Original Message ----- > From: "Paul George" > To: > Sent: Saturday, February 03, 2001 4:38 AM > Subject: RE: WG Review: Provisioning Registry Protocol (provreg) > > > > James, I don't understand. The charter states: > > > > > > "Subsequent versions of the specification will > > extend the protocol to exchange other > > information needed to organize the Internet, > > such as IP address allocations." > > > > > > I think we are merely *starting* with DNS because of the time > constraints of > > the new TLDs, but the protocol can clearly be extended at a later time > to > > include all kinds of registration environments. I don't see the > problem. > > (?) > > > > Paul George > > SARAF Software Solutions > > > > > > > > -----Original Message----- > > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se]On > > Behalf Of James Seng/Personal > > Sent: Friday, February 02, 2001 7:42 AM > > To: ietf-provreg@cafax.se > > Cc: Patrik Faltstrom > > Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) > > > > > > I would like to object this proposed charter for provreg. Its scope > has > > been so specific defined for DNS only and has no mention of anything > > beyond DNS. > > > > I propose shortening the charter and balancing it slightly. If it is > out > > of line, feel free to shoot it. > > > > --- > > Registration of Domain Names Service (DNS) involves various objects > > transfer from multiple Registrars to a back-end Registry database. > > Conversely, there is a desire to standardized the process allowing > > multiple Registrars to access multiple Registries database which may > > differ in operational models. Such registration procotcol has many > > benefits which may tranverse beyond domain names objects. > > > > This working group will investigate the requirements for a > registration > > protocol of objects between two or more entities and to developed such > a > > provision protocol that satisfied these requirements. > > > > The group will consider support for multiple operational choices, such > > as for transport and security; it will create no new transport or > > security protocols. The group may consider use of the new protocol > for > > diverse registration and update scenarios, in order to understand > > limitations and possible extensions that are appropriate. > Specification > > for user interface access, such as by a web front end, is beyond the > > scope of this working group. > > > > The Action Item(s) for the Working Group are > > > > 1. An Informational RFC specifying the requirements of the Provision > > Registration protocol. > > > > 2. An Informational RFC specifying the objects exchange during the > > registration process for the Domain Name; at a minimum includes: > > domain names, IP address and contact details for registrant. > > > > 3. A Standard RFC specifying the Provision Registration Protocol. > > This document should have specification for domain names > > object registration but also include extension capability for > > non-domain names objects. > > > > Goals and Milestones: > > > > .... > > > > -James Seng > > > > --- Original Message --- > > A new IETF working group has been proposed in the Applications Area. > > The IESG has not made any determination as yet. > > > > The following Description was submitted, and is provided for > > informational purposes only: > > > > Provisioning Registry Protocol (provreg) > > ---------------------------------------- > > > > Current Status: Proposed Working Group > > > > > > Mailing Lists: > > General Discussion:ietf-provreg@cafax.se > > To Subscribe: ietf-provreg-request@cafax.se > > In Body: subscribe ietf-provreg > > Archive: http://www.cafax.se/ietf-provreg/maillist/ > > > > Description of Working Group: > > > > Administration of Domain Name Service (DNS) registration increasingly > > distinguishes between the operation of a "back-end" registry data base > > service for registrations, versus "front-end" support services by > > registrars who interact with registrants and with the registry. > > Especially for various Top-Level Domains, the desire is to permit > > multiple registrars to share access to the database. Conversely, > there > > is a desire to allow a registrar to access multiple registries via the > > same protocol, even if the registries differ in operational models. > > > > This working group will develop a specification of the requirements > and > > limitations for a protocol that enables a registrar to access multiple > > registries and will develop a protocol that satisfies those > > requirements. The protocol will permit interaction between a > > registrar's own application and registry applications. > > > > The initial specification will allow multiple registrars to register > > and maintain domain names within multiple Top Level Domains (TLDs). > The > > specification should be flexible enough to support the different > > operational models of registries. The specification should allow > > extension to support other registration data, such as address > > allocation and contact information. The working group will use as > input > > the "Generic Registry-Registrar Protocol Requirements" > > (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning > > Protocol presentation, documented in (draft-hollenbeck-epp-nn). > > > > The group will consider support for multiple operational choices, such > > as for transport and security; it will create no new transport or > > security protocols. The group may consider use of the new protocol > for > > diverse registration and update scenarios, in order to understand > > limitations and possible extensions that are appropriate. > Specification > > for user interface access, such as by a web front end, is beyond the > > scope of this working group. > > > > Documentation from the working group will: > > > > * Specify the objects exchanged between the registry repository > > and registrars, the relationships among the objects, and the protocol > > for exchanging objects between a registrar and the registry; at a > > minimum the objects will include: domain name, IP address, and > contact > > details for registrants > > > > * Describe appropriate mechanisms for security during registrar access > > > > * List useful examples of registrar access transactions > > > > > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12KxUNm008018 for ietf-provreg-outgoing; Fri, 2 Feb 2001 21:59:30 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f12KxT6V008013 for ; Fri, 2 Feb 2001 21:59:29 +0100 (MET) Received: (qmail 29798 invoked from network); 2 Feb 2001 21:02:52 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 2 Feb 2001 21:02:52 -0000 From: "Paul George" To: Subject: RE: WG Review: Provisioning Registry Protocol (provreg) Date: Fri, 2 Feb 2001 15:59:28 -0500 Message-ID: <000301c08d5b$08ae12a0$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <062e01c08d5a$1e843dd0$84411004@jamessonyvaio> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Okay, so why are there differences? Are they looking at an older version? Is there a problem with giving them the new version? Please forgive my ignorance, I thought this one was the version they were considering..... Paul George SARAF Software Solutions -----Original Message----- From: James Seng/Personal [mailto:James@Seng.cc] Sent: Friday, February 02, 2001 3:53 PM To: Paul George; ietf-provreg@cafax.se Subject: Re: WG Review: Provisioning Registry Protocol (provreg) Not in the charter published by the IESG. -James Seng ----- Original Message ----- From: "Paul George" To: Sent: Saturday, February 03, 2001 4:38 AM Subject: RE: WG Review: Provisioning Registry Protocol (provreg) > James, I don't understand. The charter states: > > > "Subsequent versions of the specification will > extend the protocol to exchange other > information needed to organize the Internet, > such as IP address allocations." > > > I think we are merely *starting* with DNS because of the time constraints of > the new TLDs, but the protocol can clearly be extended at a later time to > include all kinds of registration environments. I don't see the problem. > (?) > > Paul George > SARAF Software Solutions > > > > -----Original Message----- > From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of James Seng/Personal > Sent: Friday, February 02, 2001 7:42 AM > To: ietf-provreg@cafax.se > Cc: Patrik Faltstrom > Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) > > > I would like to object this proposed charter for provreg. Its scope has > been so specific defined for DNS only and has no mention of anything > beyond DNS. > > I propose shortening the charter and balancing it slightly. If it is out > of line, feel free to shoot it. > > --- > Registration of Domain Names Service (DNS) involves various objects > transfer from multiple Registrars to a back-end Registry database. > Conversely, there is a desire to standardized the process allowing > multiple Registrars to access multiple Registries database which may > differ in operational models. Such registration procotcol has many > benefits which may tranverse beyond domain names objects. > > This working group will investigate the requirements for a registration > protocol of objects between two or more entities and to developed such a > provision protocol that satisfied these requirements. > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > The Action Item(s) for the Working Group are > > 1. An Informational RFC specifying the requirements of the Provision > Registration protocol. > > 2. An Informational RFC specifying the objects exchange during the > registration process for the Domain Name; at a minimum includes: > domain names, IP address and contact details for registrant. > > 3. A Standard RFC specifying the Provision Registration Protocol. > This document should have specification for domain names > object registration but also include extension capability for > non-domain names objects. > > Goals and Milestones: > > .... > > -James Seng > > --- Original Message --- > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes only: > > Provisioning Registry Protocol (provreg) > ---------------------------------------- > > Current Status: Proposed Working Group > > > Mailing Lists: > General Discussion:ietf-provreg@cafax.se > To Subscribe: ietf-provreg-request@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > > Description of Working Group: > > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. > Especially for various Top-Level Domains, the desire is to permit > multiple registrars to share access to the database. Conversely, there > is a desire to allow a registrar to access multiple registries via the > same protocol, even if the registries differ in operational models. > > This working group will develop a specification of the requirements and > limitations for a protocol that enables a registrar to access multiple > registries and will develop a protocol that satisfies those > requirements. The protocol will permit interaction between a > registrar's own application and registry applications. > > The initial specification will allow multiple registrars to register > and maintain domain names within multiple Top Level Domains (TLDs). The > specification should be flexible enough to support the different > operational models of registries. The specification should allow > extension to support other registration data, such as address > allocation and contact information. The working group will use as input > the "Generic Registry-Registrar Protocol Requirements" > (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning > Protocol presentation, documented in (draft-hollenbeck-epp-nn). > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > Documentation from the working group will: > > * Specify the objects exchanged between the registry repository > and registrars, the relationships among the objects, and the protocol > for exchanging objects between a registrar and the registry; at a > minimum the objects will include: domain name, IP address, and contact > details for registrants > > * Describe appropriate mechanisms for security during registrar access > > * List useful examples of registrar access transactions > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12Kvw8w008006 for ietf-provreg-outgoing; Fri, 2 Feb 2001 21:57:58 +0100 (MET) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12Kvv6V008001 for ; Fri, 2 Feb 2001 21:57:57 +0100 (MET) Received: from nat2.tucows.com ([207.136.98.12] helo=rraderlap) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 14OnGG-0005ZR-00; Fri, 02 Feb 2001 15:56:52 -0500 Reply-To: From: "Ross Wm. Rader" To: "Paul George" , Subject: RE: WG Review: Provisioning Registry Protocol (provreg) Date: Fri, 2 Feb 2001 15:58:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <000201c08d58$10ad5f90$73bdd93f@PGEORGE> Sender: owner-ietf-provreg@cafax.se Precedence: bulk I too am left scratching my head. < -----Original Message----- < From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of Paul George < Sent: Friday, February 02, 2001 3:38 PM < To: ietf-provreg@cafax.se < Subject: RE: WG Review: Provisioning Registry Protocol (provreg) < < < James, I don't understand. The charter states: < < < "Subsequent versions of the specification will < extend the protocol to exchange other < information needed to organize the Internet, < such as IP address allocations." < < < I think we are merely *starting* with DNS because of the time < constraints of < the new TLDs, but the protocol can clearly be extended at a later time to < include all kinds of registration environments. I don't see the problem. < (?) < < Paul George < SARAF Software Solutions < < < < -----Original Message----- < From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of James Seng/Personal < Sent: Friday, February 02, 2001 7:42 AM < To: ietf-provreg@cafax.se < Cc: Patrik Faltstrom < Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) < < < I would like to object this proposed charter for provreg. Its scope has < been so specific defined for DNS only and has no mention of anything < beyond DNS. < < I propose shortening the charter and balancing it slightly. If it is out < of line, feel free to shoot it. < < --- < Registration of Domain Names Service (DNS) involves various objects < transfer from multiple Registrars to a back-end Registry database. < Conversely, there is a desire to standardized the process allowing < multiple Registrars to access multiple Registries database which may < differ in operational models. Such registration procotcol has many < benefits which may tranverse beyond domain names objects. < < This working group will investigate the requirements for a registration < protocol of objects between two or more entities and to developed such a < provision protocol that satisfied these requirements. < < The group will consider support for multiple operational choices, such < as for transport and security; it will create no new transport or < security protocols. The group may consider use of the new protocol for < diverse registration and update scenarios, in order to understand < limitations and possible extensions that are appropriate. Specification < for user interface access, such as by a web front end, is beyond the < scope of this working group. < < The Action Item(s) for the Working Group are < < 1. An Informational RFC specifying the requirements of the Provision < Registration protocol. < < 2. An Informational RFC specifying the objects exchange during the < registration process for the Domain Name; at a minimum includes: < domain names, IP address and contact details for registrant. < < 3. A Standard RFC specifying the Provision Registration Protocol. < This document should have specification for domain names < object registration but also include extension capability for < non-domain names objects. < < Goals and Milestones: < < .... < < -James Seng < < --- Original Message --- < A new IETF working group has been proposed in the Applications Area. < The IESG has not made any determination as yet. < < The following Description was submitted, and is provided for < informational purposes only: < < Provisioning Registry Protocol (provreg) < ---------------------------------------- < < Current Status: Proposed Working Group < < < Mailing Lists: < General Discussion:ietf-provreg@cafax.se < To Subscribe: ietf-provreg-request@cafax.se < In Body: subscribe ietf-provreg < Archive: http://www.cafax.se/ietf-provreg/maillist/ < < Description of Working Group: < < Administration of Domain Name Service (DNS) registration increasingly < distinguishes between the operation of a "back-end" registry data base < service for registrations, versus "front-end" support services by < registrars who interact with registrants and with the registry. < Especially for various Top-Level Domains, the desire is to permit < multiple registrars to share access to the database. Conversely, there < is a desire to allow a registrar to access multiple registries via the < same protocol, even if the registries differ in operational models. < < This working group will develop a specification of the requirements and < limitations for a protocol that enables a registrar to access multiple < registries and will develop a protocol that satisfies those < requirements. The protocol will permit interaction between a < registrar's own application and registry applications. < < The initial specification will allow multiple registrars to register < and maintain domain names within multiple Top Level Domains (TLDs). The < specification should be flexible enough to support the different < operational models of registries. The specification should allow < extension to support other registration data, such as address < allocation and contact information. The working group will use as input < the "Generic Registry-Registrar Protocol Requirements" < (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning < Protocol presentation, documented in (draft-hollenbeck-epp-nn). < < The group will consider support for multiple operational choices, such < as for transport and security; it will create no new transport or < security protocols. The group may consider use of the new protocol for < diverse registration and update scenarios, in order to understand < limitations and possible extensions that are appropriate. Specification < for user interface access, such as by a web front end, is beyond the < scope of this working group. < < Documentation from the working group will: < < * Specify the objects exchanged between the registry repository < and registrars, the relationships among the objects, and the protocol < for exchanging objects between a registrar and the registry; at a < minimum the objects will include: domain name, IP address, and contact < details for registrants < < * Describe appropriate mechanisms for security during registrar access < < * List useful examples of registrar access transactions < < Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12KsP83007964 for ietf-provreg-outgoing; Fri, 2 Feb 2001 21:54:25 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12KsM6V007959 for ; Fri, 2 Feb 2001 21:54:23 +0100 (MET) Received: from jamessonyvaio (PPPa19-ResaleDialinx80018-1R7282.dialinx.net [4.48.36.80]) by mail.i-dns.net (Postfix) with SMTP id 44CE4FFC0E; Sat, 3 Feb 2001 04:54:04 +0800 (SGT) Message-ID: <062e01c08d5a$1e843dd0$84411004@jamessonyvaio> From: "James Seng/Personal" To: "Paul George" , References: <000201c08d58$10ad5f90$73bdd93f@PGEORGE> Subject: Re: WG Review: Provisioning Registry Protocol (provreg) Date: Sat, 3 Feb 2001 04:52:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Not in the charter published by the IESG. -James Seng ----- Original Message ----- From: "Paul George" To: Sent: Saturday, February 03, 2001 4:38 AM Subject: RE: WG Review: Provisioning Registry Protocol (provreg) > James, I don't understand. The charter states: > > > "Subsequent versions of the specification will > extend the protocol to exchange other > information needed to organize the Internet, > such as IP address allocations." > > > I think we are merely *starting* with DNS because of the time constraints of > the new TLDs, but the protocol can clearly be extended at a later time to > include all kinds of registration environments. I don't see the problem. > (?) > > Paul George > SARAF Software Solutions > > > > -----Original Message----- > From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On > Behalf Of James Seng/Personal > Sent: Friday, February 02, 2001 7:42 AM > To: ietf-provreg@cafax.se > Cc: Patrik Faltstrom > Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) > > > I would like to object this proposed charter for provreg. Its scope has > been so specific defined for DNS only and has no mention of anything > beyond DNS. > > I propose shortening the charter and balancing it slightly. If it is out > of line, feel free to shoot it. > > --- > Registration of Domain Names Service (DNS) involves various objects > transfer from multiple Registrars to a back-end Registry database. > Conversely, there is a desire to standardized the process allowing > multiple Registrars to access multiple Registries database which may > differ in operational models. Such registration procotcol has many > benefits which may tranverse beyond domain names objects. > > This working group will investigate the requirements for a registration > protocol of objects between two or more entities and to developed such a > provision protocol that satisfied these requirements. > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > The Action Item(s) for the Working Group are > > 1. An Informational RFC specifying the requirements of the Provision > Registration protocol. > > 2. An Informational RFC specifying the objects exchange during the > registration process for the Domain Name; at a minimum includes: > domain names, IP address and contact details for registrant. > > 3. A Standard RFC specifying the Provision Registration Protocol. > This document should have specification for domain names > object registration but also include extension capability for > non-domain names objects. > > Goals and Milestones: > > .... > > -James Seng > > --- Original Message --- > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes only: > > Provisioning Registry Protocol (provreg) > ---------------------------------------- > > Current Status: Proposed Working Group > > > Mailing Lists: > General Discussion:ietf-provreg@cafax.se > To Subscribe: ietf-provreg-request@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > > Description of Working Group: > > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. > Especially for various Top-Level Domains, the desire is to permit > multiple registrars to share access to the database. Conversely, there > is a desire to allow a registrar to access multiple registries via the > same protocol, even if the registries differ in operational models. > > This working group will develop a specification of the requirements and > limitations for a protocol that enables a registrar to access multiple > registries and will develop a protocol that satisfies those > requirements. The protocol will permit interaction between a > registrar's own application and registry applications. > > The initial specification will allow multiple registrars to register > and maintain domain names within multiple Top Level Domains (TLDs). The > specification should be flexible enough to support the different > operational models of registries. The specification should allow > extension to support other registration data, such as address > allocation and contact information. The working group will use as input > the "Generic Registry-Registrar Protocol Requirements" > (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning > Protocol presentation, documented in (draft-hollenbeck-epp-nn). > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > Documentation from the working group will: > > * Specify the objects exchanged between the registry repository > and registrars, the relationships among the objects, and the protocol > for exchanging objects between a registrar and the registry; at a > minimum the objects will include: domain name, IP address, and contact > details for registrants > > * Describe appropriate mechanisms for security during registrar access > > * List useful examples of registrar access transactions > > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12KcGTq007863 for ietf-provreg-outgoing; Fri, 2 Feb 2001 21:38:16 +0100 (MET) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with SMTP id f12KcE6V007858 for ; Fri, 2 Feb 2001 21:38:15 +0100 (MET) Received: (qmail 29463 invoked from network); 2 Feb 2001 20:41:37 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 2 Feb 2001 20:41:37 -0000 From: "Paul George" To: Subject: RE: WG Review: Provisioning Registry Protocol (provreg) Date: Fri, 2 Feb 2001 15:38:13 -0500 Message-ID: <000201c08d58$10ad5f90$73bdd93f@PGEORGE> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <005001c08d15$89aa4180$84411004@jamessonyvaio> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk James, I don't understand. The charter states: "Subsequent versions of the specification will extend the protocol to exchange other information needed to organize the Internet, such as IP address allocations." I think we are merely *starting* with DNS because of the time constraints of the new TLDs, but the protocol can clearly be extended at a later time to include all kinds of registration environments. I don't see the problem. (?) Paul George SARAF Software Solutions -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of James Seng/Personal Sent: Friday, February 02, 2001 7:42 AM To: ietf-provreg@cafax.se Cc: Patrik Faltstrom Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) I would like to object this proposed charter for provreg. Its scope has been so specific defined for DNS only and has no mention of anything beyond DNS. I propose shortening the charter and balancing it slightly. If it is out of line, feel free to shoot it. --- Registration of Domain Names Service (DNS) involves various objects transfer from multiple Registrars to a back-end Registry database. Conversely, there is a desire to standardized the process allowing multiple Registrars to access multiple Registries database which may differ in operational models. Such registration procotcol has many benefits which may tranverse beyond domain names objects. This working group will investigate the requirements for a registration protocol of objects between two or more entities and to developed such a provision protocol that satisfied these requirements. The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. The Action Item(s) for the Working Group are 1. An Informational RFC specifying the requirements of the Provision Registration protocol. 2. An Informational RFC specifying the objects exchange during the registration process for the Domain Name; at a minimum includes: domain names, IP address and contact details for registrant. 3. A Standard RFC specifying the Provision Registration Protocol. This document should have specification for domain names object registration but also include extension capability for non-domain names objects. Goals and Milestones: .... -James Seng --- Original Message --- A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Provisioning Registry Protocol (provreg) ---------------------------------------- Current Status: Proposed Working Group Mailing Lists: General Discussion:ietf-provreg@cafax.se To Subscribe: ietf-provreg-request@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ Description of Working Group: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models. This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn). The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. Documentation from the working group will: * Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants * Describe appropriate mechanisms for security during registrar access * List useful examples of registrar access transactions Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12KQJ8e007748 for ietf-provreg-outgoing; Fri, 2 Feb 2001 21:26:19 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12KQI6V007743 for ; Fri, 2 Feb 2001 21:26:18 +0100 (MET) Received: by sentry.gw.tislabs.com; id PAA01733; Fri, 2 Feb 2001 15:29:33 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xma001720; Fri, 2 Feb 01 15:28:57 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <056a01c08d53$260d4620$84411004@jamessonyvaio> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 2 Feb 2001 15:22:21 -0500 To: "James Seng" From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: "Edward Lewis" , , "Patrik Faltstrom" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f12KQJ6V007744 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 3:02 PM -0500 2/2/01, James Seng wrote: >It also have references to Scott Hollenback I-Ds. While Scott have good >I-Ds, referencing it to the WG charter is IMHO a bad idea. It will >discourage others to come forward with their proposal. The updated charter does not reference the drafts. Below is the latest one. I don't know whether the charter below will replace the one on the ietf-announce list, but in any case, I certainly agree that the references to the drafts should be removed. >If the WG intention is only to reach a point whereby it is a DNS >specific registration protocol, as description in the charter which you >submit to the IESG, I will put up a motion *AGAINST* the formation of >this WG at all. I doubt that the intention of the participants in the WG is to only go so far as a DNS registration protocol. I was just mentioning that as a possibility. The IESG has final say on the scope of the WG. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Provisioning Registry Protocol (ProvReg) ------------------------------- CHAIR(S): Edward Lewis Jaap Akkerhuis APPLICATIONS AREA DIRECTOR(S): Patrik Fältström Ned Freed AREA ADVISOR: Patrik Fältström MAILING LISTS: General Discussion: ietf-provreg@cafax.se To Subscribe: majordomo@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ DESCRIPTION OF WORKING GROUP: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models. This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). Subsequent versions of the specification will extend the protocol to exchange other information needed to organize the Internet, such as IP address allocations. The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. Documentation from the working group will: * Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants * Describe appropriate mechanisms for security during registrar access, including authentication and authoriztion of the participants, confidentiality of data where needed and allowed * List useful examples of registrar access transactions GOALS AND MILESTONES: Jan, 2001 WG charter Feb, 2001 Working group agreement on functional requirements for protocol Apr, 2001 Initial specification of provreg protocol Jun, 2001 Second draft specification Sep, 2001 Submit draft for standards track -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12JsIbj007498 for ietf-provreg-outgoing; Fri, 2 Feb 2001 20:54:18 +0100 (MET) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12JsF6V007493 for ; Fri, 2 Feb 2001 20:54:16 +0100 (MET) Received: by sentry.gw.tislabs.com; id OAA01009; Fri, 2 Feb 2001 14:57:29 -0500 (EST) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xmaa01001; Fri, 2 Feb 01 14:57:27 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <005001c08d15$89aa4180$84411004@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Feb 2001 14:50:58 -0500 To: "James Seng/Personal" From: Edward Lewis Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) Cc: , "Patrik Faltstrom" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 7:41 AM -0500 2/2/01, James Seng/Personal wrote: >I would like to object this proposed charter for provreg. Its scope has >been so specific defined for DNS only and has no mention of anything >beyond DNS. The most recent charter I sent upwards is slightly different than that distributed. In particular, the newer charter has this text: >The initial specification will allow multiple registrars to register and >maintain domain names within multiple Top Level Domains (TLDs). Subsequent >versions of the specification will extend the protocol to exchange other >information needed to organize the Internet, such as IP address allocations. The first sentence is old, I left it in for context. The second sentence should already address your concerns. I think that there are a few goals of the proposed WG: 1) Make a mechanism for registrar-registry exchange of domain name info in the short term. 2) Make the mechanism extensible for other regsitration information. I think the agenda before the IESG already addresses these issues. A note on charters. The purpose of the charter is to set the scope of the effort, not to judge the quality of the effort. It is possible that this WG only arrives at the initial specification, that is a mechanism that is DNS specific (but extensible). A follow-on working group might be formed to handle the next set of specifications. It is also possible this proto-WG's charter is amended as we approach the initial goal to include the extensions. IETF WG's are not intended to be long term. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12FwkOb005507 for ietf-provreg-outgoing; Fri, 2 Feb 2001 16:58:46 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12FwU6V005502 for ; Fri, 2 Feb 2001 16:58:30 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f12FvYZC000632 for ietf-provreg@cafax.se; Fri, 2 Feb 2001 16:57:34 +0100 (MET) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12Et36V004941 for ; Fri, 2 Feb 2001 15:55:04 +0100 (MET) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f12Eabd04299; Fri, 2 Feb 2001 09:36:37 -0500 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Fri, 2 Feb 2001 09:36:37 -0500 (EST) From: Sheer El-Showk To: James Seng/Personal cc: ietf-provreg@cafax.se, Patrik Faltstrom Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) In-Reply-To: <005001c08d15$89aa4180$84411004@jamessonyvaio> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk I like this new charter; I think it is more clear than the original and more readable. Aren't we too far along in the process (ie we've already submitted the charter to IETF for approval) to try and change the charter now? Sheer On Fri, 2 Feb 2001, James Seng/Personal wrote: > I would like to object this proposed charter for provreg. Its scope has > been so specific defined for DNS only and has no mention of anything > beyond DNS. > > I propose shortening the charter and balancing it slightly. If it is out > of line, feel free to shoot it. > > --- > Registration of Domain Names Service (DNS) involves various objects > transfer from multiple Registrars to a back-end Registry database. > Conversely, there is a desire to standardized the process allowing > multiple Registrars to access multiple Registries database which may > differ in operational models. Such registration procotcol has many > benefits which may tranverse beyond domain names objects. > > This working group will investigate the requirements for a registration > protocol of objects between two or more entities and to developed such a > provision protocol that satisfied these requirements. > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > The Action Item(s) for the Working Group are > > 1. An Informational RFC specifying the requirements of the Provision > Registration protocol. > > 2. An Informational RFC specifying the objects exchange during the > registration process for the Domain Name; at a minimum includes: > domain names, IP address and contact details for registrant. > > 3. A Standard RFC specifying the Provision Registration Protocol. > This document should have specification for domain names > object registration but also include extension capability for > non-domain names objects. > > Goals and Milestones: > > .... > > -James Seng > > --- Original Message --- > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes only: > > Provisioning Registry Protocol (provreg) > ---------------------------------------- > > Current Status: Proposed Working Group > > > Mailing Lists: > General Discussion:ietf-provreg@cafax.se > To Subscribe: ietf-provreg-request@cafax.se > In Body: subscribe ietf-provreg > Archive: http://www.cafax.se/ietf-provreg/maillist/ > > Description of Working Group: > > Administration of Domain Name Service (DNS) registration increasingly > distinguishes between the operation of a "back-end" registry data base > service for registrations, versus "front-end" support services by > registrars who interact with registrants and with the registry. > Especially for various Top-Level Domains, the desire is to permit > multiple registrars to share access to the database. Conversely, there > is a desire to allow a registrar to access multiple registries via the > same protocol, even if the registries differ in operational models. > > This working group will develop a specification of the requirements and > limitations for a protocol that enables a registrar to access multiple > registries and will develop a protocol that satisfies those > requirements. The protocol will permit interaction between a > registrar's own application and registry applications. > > The initial specification will allow multiple registrars to register > and maintain domain names within multiple Top Level Domains (TLDs). The > specification should be flexible enough to support the different > operational models of registries. The specification should allow > extension to support other registration data, such as address > allocation and contact information. The working group will use as input > the "Generic Registry-Registrar Protocol Requirements" > (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning > Protocol presentation, documented in (draft-hollenbeck-epp-nn). > > The group will consider support for multiple operational choices, such > as for transport and security; it will create no new transport or > security protocols. The group may consider use of the new protocol for > diverse registration and update scenarios, in order to understand > limitations and possible extensions that are appropriate. Specification > for user interface access, such as by a web front end, is beyond the > scope of this working group. > > Documentation from the working group will: > > * Specify the objects exchanged between the registry repository > and registrars, the relationships among the objects, and the protocol > for exchanging objects between a registrar and the registry; at a > minimum the objects will include: domain name, IP address, and contact > details for registrants > > * Describe appropriate mechanisms for security during registrar access > > * List useful examples of registrar access transactions > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12ChRiM003802 for ietf-provreg-outgoing; Fri, 2 Feb 2001 13:43:27 +0100 (MET) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12ChP6V003797 for ; Fri, 2 Feb 2001 13:43:26 +0100 (MET) Received: from jamessonyvaio (PPPa39-ResaleDialinx80019-4R7336.dialinx.net [4.16.65.132]) by mail.i-dns.net (Postfix) with SMTP id A953EFFC0B; Fri, 2 Feb 2001 20:43:08 +0800 (SGT) Message-ID: <005001c08d15$89aa4180$84411004@jamessonyvaio> From: "James Seng/Personal" To: Cc: "Patrik Faltstrom" Subject: Fw: WG Review: Provisioning Registry Protocol (provreg) Date: Fri, 2 Feb 2001 20:41:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk I would like to object this proposed charter for provreg. Its scope has been so specific defined for DNS only and has no mention of anything beyond DNS. I propose shortening the charter and balancing it slightly. If it is out of line, feel free to shoot it. --- Registration of Domain Names Service (DNS) involves various objects transfer from multiple Registrars to a back-end Registry database. Conversely, there is a desire to standardized the process allowing multiple Registrars to access multiple Registries database which may differ in operational models. Such registration procotcol has many benefits which may tranverse beyond domain names objects. This working group will investigate the requirements for a registration protocol of objects between two or more entities and to developed such a provision protocol that satisfied these requirements. The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. The Action Item(s) for the Working Group are 1. An Informational RFC specifying the requirements of the Provision Registration protocol. 2. An Informational RFC specifying the objects exchange during the registration process for the Domain Name; at a minimum includes: domain names, IP address and contact details for registrant. 3. A Standard RFC specifying the Provision Registration Protocol. This document should have specification for domain names object registration but also include extension capability for non-domain names objects. Goals and Milestones: .... -James Seng --- Original Message --- A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Provisioning Registry Protocol (provreg) ---------------------------------------- Current Status: Proposed Working Group Mailing Lists: General Discussion:ietf-provreg@cafax.se To Subscribe: ietf-provreg-request@cafax.se In Body: subscribe ietf-provreg Archive: http://www.cafax.se/ietf-provreg/maillist/ Description of Working Group: Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models. This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn). The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group. Documentation from the working group will: * Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants * Describe appropriate mechanisms for security during registrar access * List useful examples of registrar access transactions Return-Path: Received: by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) id f12BfA3X003463 for ietf-provreg-outgoing; Fri, 2 Feb 2001 12:41:10 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12Bf96V003458 for ; Fri, 2 Feb 2001 12:41:09 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f12BeAno007026 for ; Fri, 2 Feb 2001 12:40:14 +0100 (MET) To: ietf-provreg@cafax.se Subject: Mail bounces. 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: <20010202124010W.liman@autonomica.se> Date: Fri, 02 Feb 2001 12:40:10 +0100 X-Dispatcher: imput version 990905(IM130) Lines: 17 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Due to a new kind of paranoia in the latest version of sendmail, the mailserver for the DNSOP maillist bounced a few messages during the last 24 h. If you sent a message, and either received a bounce message, or can't find it in the mail archive http://www.cafax.se/ietf-provreg/maillist/, then please re-send. Sorry. Best regards, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f11E7tH19546 for ietf-provreg-outgoing; Thu, 1 Feb 2001 15:07:55 +0100 (MET) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f11E7rA19541 for ; Thu, 1 Feb 2001 15:07:53 +0100 (MET) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id OAA06180; Thu, 1 Feb 2001 14:04:19 GMT From: "Brian W. Spolarich" To: , Subject: RE: Unique handle (was RE: Merging RRP and Whois) Date: Thu, 1 Feb 2001 09:08:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200101312347.RAA26494@alliance.globalnetlink.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk | > Dumb question: Instead of inventing new identifiers or bending | > existing ones in perhaps ungraceful ways, why not use a URL as the | > identifier? | | As with email, I've had URL which is not active anymore. | (Actually, it is now owned by somebody else!) | How do you authenticate the owner of a URL? | I have a domain (thus the URL) that does not belong to me | anymore. Sorry if I was unclear. I wasn't talking about a URL in the sense of something you (necessarily) type in your web browser. I was thinking a bit more generically of using an existing identifier scheme instead of inventing a new one. If you were do to provreg on top of LDAP you could do something like: ldap://registry.internic.net/cn=Brian%20W.%20Spolarich,o=WALID,%20Inc.,c=US according to RFC2255. The escaped spaces are ugly, but ohwell. Authenticating to the provreg service can be handled by any of the established means: x.509 certs, PGP keys, passwords, or whatever. As Bill Manning points out, there are a lot of broad shoulders to stand on here. -bws Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f11CXWD18516 for ietf-provreg-outgoing; Thu, 1 Feb 2001 13:33:32 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f11CXTA18511 for ; Thu, 1 Feb 2001 13:33:30 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f11CWhe00887 for ietf-provreg@cafax.se; Thu, 1 Feb 2001 13:32:43 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VN6oA11670 for ; Thu, 1 Feb 2001 00:06:50 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0VN6mU19228; Wed, 31 Jan 2001 15:06:48 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0VN5Rp28980; Wed, 31 Jan 2001 15:05:27 -0800 Message-Id: <200101312305.f0VN5Rp28980@zed.isi.edu> Subject: Re: Unique "Handles"? To: budi@alliance.globalnetlink.com Date: Wed, 31 Jan 2001 15:05:27 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <200101312346.RAA26477@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Feb 01, 2001 06:07:49 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % % On 30 Jan 01, at 15:42, Bill Manning wrote: % % > Er... not really. I've had email addresses that % > have been revolked and reassigned to new people. % > Email addresses are not the persistant indentifer % > you are looking for. % % That's ok, Bill. All you have to do is change/modify/ % update your (nic) handle / identifier. % (Just like updating a host/NS record in the database.) % Note: how long does it have to be presistant? Er, how does the registrar know that I am me if I can't validate myself since the email "handle" no longer works? % Or... we can go with a digital certificate. % (That may be too complicate since some countries may % restrict access to certain cryptography algorithms.) % % Or ... find something else. Like a PGP key... :) % % % -- budi % -- % Homepage: % my presentation materials, papers, scrapbook, ... and more % What's your "web.id"? Register your web.id @ http://www.idnic.net.id % -- --bill Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f11CXGd18500 for ietf-provreg-outgoing; Thu, 1 Feb 2001 13:33:16 +0100 (MET) Received: from naptop.autonomica.se (johani.iku.sunet.se [193.10.90.130]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f11CXBA18495 for ; Thu, 1 Feb 2001 13:33:11 +0100 (MET) Received: by naptop.autonomica.se (8.11.2.Beta0/8.11.2.Beta0) id f11CWOh00875 for ietf-provreg@cafax.se; Thu, 1 Feb 2001 13:32:24 +0100 (MET) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VLadA10543 for ; Wed, 31 Jan 2001 22:36:39 +0100 (MET) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0VLaaU03139; Wed, 31 Jan 2001 13:36:36 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0VLZFk28851; Wed, 31 Jan 2001 13:35:15 -0800 Message-Id: <200101312135.f0VLZFk28851@zed.isi.edu> Subject: Re: Interim Meeting Reminder To: lewis@tislabs.com (Edward Lewis) Date: Wed, 31 Jan 2001 13:35:15 -0800 (PST) Cc: ietf-provreg@cafax.se ('ietf-provreg@cafax.se'), lewis@tislabs.com In-Reply-To: from "Edward Lewis" at Jan 31, 2001 01:28:34 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk As long as we are still very much in the requirements definition phases of this stuff, I'd like to think that we can "stand on the shoulders" of others prior art. NSIs work (Thanks Scott) The RIPE/RA work (cast'o'hundreds) rwhois (thanks scott & mark) dns (cast'o'thousands) and perhaps some stuff folks have not considered: rescap idn (dns-wise) Just a couple of thoughts. -- --bill Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f119Yf317074 for ietf-provreg-outgoing; Thu, 1 Feb 2001 10:34:41 +0100 (MET) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f119YeA17069 for ; Thu, 1 Feb 2001 10:34:40 +0100 (MET) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14OG69-0003EK-00; Thu, 1 Feb 2001 10:32:13 +0100 Subject: Antwort: Unique handle (was RE: Merging RRP and Whois) To: ietf-provreg@cafax.se X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Thu, 1 Feb 2001 10:33:03 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 01.02.2001 10:32:23 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-2 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 01.02.2001 00:07 budi@alliance.globalnetlink.com wrote: > > > Dumb question: Instead of inventing new identifiers or bending > > existing ones in perhaps ungraceful ways, why not use a URL as the > > identifier? > > As with email, I've had URL which is not active anymore. > (Actually, it is now owned by somebody else!) > How do you authenticate the owner of a URL? > I have a domain (thus the URL) that does not belong to me > anymore. What do you thinks of URN´s (not yet a full standart, as far as i know) something like urn:registry:whois.denic.de:person:joerg_bauer with the following meenings: urn:registry: Namespace for registries whois.denic.de: Whois information to the object person: type of object joerg_bauer: identifier inside the registry I know that with this approach i´m again mixing rrp and whois. Maybe it is an better idea to say rrp.denic.de for an interface to rrp. -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0VN5Iq11640 for ietf-provreg-outgoing; Thu, 1 Feb 2001 00:05:18 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VN5HA11635 for ; Thu, 1 Feb 2001 00:05:17 +0100 (MET) Received: from pentium3 (ppp6.bdg.melsa.net.id [202.138.227.6]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id RAA26494 for ; Wed, 31 Jan 2001 17:47:42 -0600 Message-Id: <200101312347.RAA26494@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Date: Thu, 1 Feb 2001 06:07:49 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Unique handle (was RE: Merging RRP and Whois) In-reply-to: References: <200101302258.QAA21440@alliance.globalnetlink.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Dumb question: Instead of inventing new identifiers or bending > existing ones in perhaps ungraceful ways, why not use a URL as the > identifier? As with email, I've had URL which is not active anymore. (Actually, it is now owned by somebody else!) How do you authenticate the owner of a URL? I have a domain (thus the URL) that does not belong to me anymore. I still think that using email address as *part of* [NIC] handle (not the whole handle) is a good idea. If you change your email address, that's ok as long as that handle is associated with the new address. It's just a string right? -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id Return-Path: Received: by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0VN4fT11612 for ietf-provreg-outgoing; Thu, 1 Feb 2001 00:04:41 +0100 (MET) Received: from alliance.globalnetlink.com (alliance.globalnetlink.com [208.185.70.11]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id f0VN4eA11607 for ; Thu, 1 Feb 2001 00:04:40 +0100 (MET) Received: from pentium3 (ppp6.bdg.melsa.net.id [202.138.227.6]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id RAA26477; Wed, 31 Jan 2001 17:46:59 -0600 Message-Id: <200101312346.RAA26477@alliance.globalnetlink.com> From: budi@alliance.globalnetlink.com To: Bill Manning Date: Thu, 1 Feb 2001 06:07:49 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique "Handles"? CC: ietf-provreg@cafax.se, ietf-whois@imc.org In-reply-to: <200101302342.f0UNg8426756@zed.isi.edu> References: <200101302258.QAA21440@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Jan 31, 2001 05:19:35 AM X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 30 Jan 01, at 15:42, Bill Manning wrote: > Er... not really. I've had email addresses that > have been revolked and reassigned to new people. > Email addresses are not the persistant indentifer > you are looking for. That's ok, Bill. All you have to do is change/modify/ update your (nic) handle / identifier. (Just like updating a host/NS record in the database.) Note: how long does it have to be presistant? If you are acting as a role, eg. using hostmaster@some.domain then you want to delegate the role to the new hostmaster, don't you? Our original concern was to have a unique identifier that spans to many databases (so that we avoid clashes), no? The possibility to have identifiers clash can be reduced. So my unique handle maybe "budi.alliance.globalnetlink.com.budi.rahardjo.indonesia" (email adress is *part of* unique handle) My beef...: it's too long! But then again, it might be easier to memorize than BR#72X%$@! ;-) Maybe we don't have to memorize it either. Or... we can go with a digital certificate. (That may be too complicate since some countries may restrict access to certain cryptography algorithms.) Or ... find something else. -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id