Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SMtpOh021404 for ; Thu, 28 Feb 2002 23:55:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1SMtp6x021403 for ietf-provreg-outgoing; Thu, 28 Feb 2002 23:55:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from leda.mit (king22.MelbourneIT.com.au [203.31.198.22]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SMtlOh021397 for ; Thu, 28 Feb 2002 23:55:49 +0100 (MET) Received: from mercury.mit (mercury.mit [192.168.80.36]) by leda.mit (8.9.3/8.9.3) with ESMTP id JAA17731; Fri, 1 Mar 2002 09:55:11 +1100 Received: by mercury.mit with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 09:55:11 +1100 Message-ID: <1595534C9032D411AECE00508BC766FB028E553E@mercury.mit> From: Bruce Tonkin To: "'Hollenbeck, Scott'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Pending Update Date: Fri, 1 Mar 2002 09:55:11 +1100 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 Hello Scott, This make sense to me. We have the equivalent of this in the current ".au" registry, where a domain name is listed as pending in the registry (thus preventing someone else registering it), while policy compliance is checked. In the new ".au" registry, the plan was for the registrars to manually check the name before it gets to the registry. However I could see that for some circumstances you might want a registry staff member to manually check some information before a action is completed. Regards, Bruce Tonkin > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Friday, March 01, 2002 1:39 AM > To: 'Liu, Hong'; 'ietf-provreg@cafax.se' > Subject: RE: Pending Update > > > Hong, > > There's a somewhat analogous situation related to creating > domain names in > that sometimes the object really shouldn't be instantiated > until after some > manual process determines that the domain is "valid". Right > now the specs > include a domain status of "pendingVerification" to note that a domain > object create command has been processed, but the action > hasn't yet really > be completed. > > As for the discussion requested below, I think it might be > helpful to add a > response code that says something like "Command completed > successfully; > action pending". We have to separate command completion from back-end > processing such that we maintain the OLTP ACID properties > (basically that > commands have no partial success or partial failure), so we > need to note > that the command has been received and processed but that > something else > needs to happen before some back-end stuff completes. We > could also add a > "pendingVerification" status to the host mapping to note the > situation in > subsequent command responses. > > I'm not going to touch the documents again until we get some > feedback from > the IESG, but adding a new response code and a new host > status could well be > done when dealing with IESG comments. > > -Scott- > > > -----Original Message----- > > From: Liu, Hong [mailto:Hong.Liu@neustar.biz] > > Sent: Wednesday, February 27, 2002 12:53 PM > > To: 'ietf-provreg@cafax.se' > > Subject: Pending Update > > > > > > The current update operation defined in EPP is basically a > > two step process: > > First, an update request is made by the registrar to the > > registry. Second, > > the registry either rejects the request or performs the > > operation; and a > > response is sent back to the registrar. > > > > A pending update refers to a four step process: First, an > > update request is > > made by the registrar to the registry. Second, the registry > > acknowledges the > > request to the registrar but does not take action for the > > moment, i.e., the > > update is pending. Third, upon further authorization, the > > registry either > > rejects the request or performs the operation; then posts the > > result to the > > message queue. Fourth, the registrar polls the message queue > > to retrieve the > > result of the operation. > > > > Conceptually, pending update is very similar to the > transfer operation > > currently defined in EPP. > > > > I would like to hear from the list how such operation is > > supported by EPP. > > If this topic has been discussed before on the mailing list, I would > > appreciate pointers to the previous discussions. > > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SJeAOh020274 for ; Thu, 28 Feb 2002 20:40:10 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1SJeAbp020273 for ietf-provreg-outgoing; Thu, 28 Feb 2002 20:40:10 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SJe9Oh020268 for ; Thu, 28 Feb 2002 20:40:09 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1SJdo804770; Thu, 28 Feb 2002 14:39:50 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 13:39:42 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AFE@dc02.npac.com> From: "Liu, Hong" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'Hollenbeck, Scott'" , "'ietf-provreg@cafax.se'" Subject: RE: Pending Update Date: Thu, 28 Feb 2002 13:39:39 -0600 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, Thanks for the input. Please see my comments in line marked as . Regards, --Hong -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Thursday, February 28, 2002 1:08 PM To: Liu, Hong Cc: 'Hollenbeck, Scott'; 'ietf-provreg@cafax.se'; brunner@nic-naa.net Subject: Re: Pending Update > Another issue that arises in the context of asynchrony is the notification > mechansim ... push vs poll. For some reason, and we are indifferent to which, the state of a datum in the registrar-registry "shared data" is inconsistent, and the instance of the datum in the registry is later than the instance of the datum in the (sponsoring) registrar, and we believe that time goes forward most of the time. Certainly, having a push in place will be of great help. However, my previous email was based on the current EPP-06, where push is not avaialble. In fact, what I implied in the email is that it would be nice to return the snapshot of the object state (not status) for the asynchronous update right after the operation is completed. Whether that information is put into the queue (i.e., poll) or pushed to the requesting registrar, is a matter of messaging. If we do it right, the information returned should be the same one way or the other. Of course, push seems to be more natural in this context if it is available. > Is this an implementation issue or an EPP issue? I would like to hear from > you and others on the list. Thanks! push vs poll. Covered in _extensive_ detail in this list. [HL] I am aware of that. Again, I am working under the assumption that push is not available, at least not yet. See above. > ... multiple asynchronous update operations on the same object. How does this condition non-trivially arise? Depending on the how often updates are made, how long the time interval is between the request is received and the operation is performed, and how soon the requesting registrar inquires the result of the operation. The registrar may not serilize the update operations on an object, i.e., wait for the first update to be completed before requesting another. At least we are not making such an assumption. Is the registry providing synchronization services for a registrar that is making multiple writes against an object it sponsors, or is this some form of "dualing registrars" and non-sponsored objects? Please clarify. In this context, I am talking about the sponsoring registrar only. If by registry synchronization service, you meant that the backend serilizes the write operations against the same object, then my asnwer is yes as most databases will do the same. I am not saying it is trivial, but it can be done. Do we need more information from EPP, such as time-stamp, to make it easier for the registry? It certainly would help in the long run as we expand the usage to EPP to areas other than registry-registrar. I leave it to the WG to decide whether we want to do it now or later. Maybe the transaction ID can serve the purpose for now. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SIAsOh019499 for ; Thu, 28 Feb 2002 19:10:54 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1SIAsZx019498 for ietf-provreg-outgoing; Thu, 28 Feb 2002 19:10:54 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SIArOh019490 for ; Thu, 28 Feb 2002 19:10:53 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1SI7s133011; Thu, 28 Feb 2002 10:07:54 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202281807.g1SI7s133011@nic-naa.net> To: "Liu, Hong" cc: "'Hollenbeck, Scott'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: Pending Update In-Reply-To: Your message of "Thu, 28 Feb 2002 11:03:49 CST." <23309E398D84D5119D0F00306E07513901181AFB@dc02.npac.com> Date: Thu, 28 Feb 2002 13:07:54 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Another issue that arises in the context of asynchrony is the notification > mechansim ... push vs poll. For some reason, and we are indifferent to which, the state of a datum in the registrar-registry "shared data" is inconsistent, and the instance of the datum in the registry is later than the instance of the datum in the (sponsoring) registrar, and we believe that time goes forward most of the time. > Is this an implementation issue or an EPP issue? I would like to hear from > you and others on the list. Thanks! push vs poll. Covered in _extensive_ detail in this list. > ... multiple asynchronous update operations on the same object. How does this condition non-trivially arise? Is the registry providing synchronization services for a registrar that is making multiple writes against an object it sponsors, or is this some form of "dualing registrars" and non-sponsored objects? Please clarify. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SH43Oh019129 for ; Thu, 28 Feb 2002 18:04:03 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1SH43m0019128 for ietf-provreg-outgoing; Thu, 28 Feb 2002 18:04:03 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SH42Oh019123 for ; Thu, 28 Feb 2002 18:04:02 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1SH3vS25448; Thu, 28 Feb 2002 11:03:57 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 11:03:52 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AFB@dc02.npac.com> From: "Liu, Hong" To: "'Hollenbeck, Scott'" , "'ietf-provreg@cafax.se'" Subject: RE: Pending Update Date: Thu, 28 Feb 2002 11:03:49 -0600 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 Scott, Thanks for suggesting a solution to this problem. I like your proposal for adding a new response code "Command completed successfully; action pending" and adding a new status "pendingVerification" to the host object. Just to push this a bit further. It would be nice that EPP provides generic mechanisms for asynchronous operations for object creation/update/deletion. (Whether such mechanisms will be used is a matter of registry policy, which is outside of the scope of EPP.) For example, your proposal can also be applied to the contact object. In this case, the new status code will have to be defined in the contact object as well. Another issue that arises in the context of asynchrony is the notification mechansim after the operation is indeed completed by the registry backend. For create and delete, a simple yes or no answer may suffice. For update, the situation is a bit more complex. The registrar may want to know more about whether the changes are made correctly according to the request. Of course, it can use the command. But doing so may generate unnecessary traffics and place burden on the backend database. More importantly, it may not get the correct snapshot of the object state in the database in the face of multiple asynchronous update operations on the same object. Is this an implementation issue or an EPP issue? I would like to hear from you and others on the list. Thanks! Cheers, --Hong -----Original Message----- From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: Thursday, February 28, 2002 9:39 AM To: 'Liu, Hong'; 'ietf-provreg@cafax.se' Subject: RE: Pending Update Hong, There's a somewhat analogous situation related to creating domain names in that sometimes the object really shouldn't be instantiated until after some manual process determines that the domain is "valid". Right now the specs include a domain status of "pendingVerification" to note that a domain object create command has been processed, but the action hasn't yet really be completed. As for the discussion requested below, I think it might be helpful to add a response code that says something like "Command completed successfully; action pending". We have to separate command completion from back-end processing such that we maintain the OLTP ACID properties (basically that commands have no partial success or partial failure), so we need to note that the command has been received and processed but that something else needs to happen before some back-end stuff completes. We could also add a "pendingVerification" status to the host mapping to note the situation in subsequent command responses. I'm not going to touch the documents again until we get some feedback from the IESG, but adding a new response code and a new host status could well be done when dealing with IESG comments. -Scott- > -----Original Message----- > From: Liu, Hong [mailto:Hong.Liu@neustar.biz] > Sent: Wednesday, February 27, 2002 12:53 PM > To: 'ietf-provreg@cafax.se' > Subject: Pending Update > > > The current update operation defined in EPP is basically a > two step process: > First, an update request is made by the registrar to the > registry. Second, > the registry either rejects the request or performs the > operation; and a > response is sent back to the registrar. > > A pending update refers to a four step process: First, an > update request is > made by the registrar to the registry. Second, the registry > acknowledges the > request to the registrar but does not take action for the > moment, i.e., the > update is pending. Third, upon further authorization, the > registry either > rejects the request or performs the operation; then posts the > result to the > message queue. Fourth, the registrar polls the message queue > to retrieve the > result of the operation. > > Conceptually, pending update is very similar to the transfer operation > currently defined in EPP. > > I would like to hear from the list how such operation is > supported by EPP. > If this topic has been discussed before on the mailing list, I would > appreciate pointers to the previous discussions. > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SEd1Oh018403 for ; Thu, 28 Feb 2002 15:39:01 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1SEd1tw018402 for ietf-provreg-outgoing; Thu, 28 Feb 2002 15:39:01 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1SEd0Oh018397 for ; Thu, 28 Feb 2002 15:39:00 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA27686; Thu, 28 Feb 2002 09:38:48 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJ4HFT>; Thu, 28 Feb 2002 09:38:48 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B730@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Liu, Hong'" , "'ietf-provreg@cafax.se'" Subject: RE: Pending Update Date: Thu, 28 Feb 2002 09:38:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hong, There's a somewhat analogous situation related to creating domain names in that sometimes the object really shouldn't be instantiated until after some manual process determines that the domain is "valid". Right now the specs include a domain status of "pendingVerification" to note that a domain object create command has been processed, but the action hasn't yet really be completed. As for the discussion requested below, I think it might be helpful to add a response code that says something like "Command completed successfully; action pending". We have to separate command completion from back-end processing such that we maintain the OLTP ACID properties (basically that commands have no partial success or partial failure), so we need to note that the command has been received and processed but that something else needs to happen before some back-end stuff completes. We could also add a "pendingVerification" status to the host mapping to note the situation in subsequent command responses. I'm not going to touch the documents again until we get some feedback from the IESG, but adding a new response code and a new host status could well be done when dealing with IESG comments. -Scott- > -----Original Message----- > From: Liu, Hong [mailto:Hong.Liu@neustar.biz] > Sent: Wednesday, February 27, 2002 12:53 PM > To: 'ietf-provreg@cafax.se' > Subject: Pending Update > > > The current update operation defined in EPP is basically a > two step process: > First, an update request is made by the registrar to the > registry. Second, > the registry either rejects the request or performs the > operation; and a > response is sent back to the registrar. > > A pending update refers to a four step process: First, an > update request is > made by the registrar to the registry. Second, the registry > acknowledges the > request to the registrar but does not take action for the > moment, i.e., the > update is pending. Third, upon further authorization, the > registry either > rejects the request or performs the operation; then posts the > result to the > message queue. Fourth, the registrar polls the message queue > to retrieve the > result of the operation. > > Conceptually, pending update is very similar to the transfer operation > currently defined in EPP. > > I would like to hear from the list how such operation is > supported by EPP. > If this topic has been discussed before on the mailing list, I would > appreciate pointers to the previous discussions. > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1S049Oh014790 for ; Thu, 28 Feb 2002 01:04:09 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1S049Lc014789 for ietf-provreg-outgoing; Thu, 28 Feb 2002 01:04:09 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx.insan.co.id (mx.insan.co.id [202.138.230.11] (may be forged)) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1S043Oh014783 for ; Thu, 28 Feb 2002 01:04:06 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mx.insan.co.id (Postfix) with ESMTP id 84A7E1491A for ; Thu, 28 Feb 2002 07:03:56 +0700 (JAVT) Received: from pentium3 (bojong.indocisc.com [202.138.228.8]) by mx.insan.co.id (Postfix) with ESMTP id 328E9148DF for ; Thu, 28 Feb 2002 07:03:55 +0700 (JAVT) From: budi@alliance.globalnetlink.com To: ietf-provreg@cafax.se Date: Thu, 28 Feb 2002 07:04:02 +0700 MIME-Version: 1.0 Subject: Re: Mapping IP Addresses to Geographic Location Message-ID: <3C7DD662.7655.6DB90D@localhost> In-reply-to: <200202272048.g1RKmH123922@nic-naa.net> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 27 Feb 2002 at 15:48, Eric Brunner-Williams in Portland Maine wrote: > host-by-addr (an instance of object-by-attribute) raises two issues: > > o existance and relevenacy of object-by-attribute mechanism, a > general question of specification scope, and data specification, > and > o reverse lookup, mapping ip addresses to geographic location, a > specific question of relevance where locality of reference is > not casual. Not sure whether that's going to be popular. I don't put exact geographical location (or info about OS of our names servers) in our DNS record. For security/privacy reasons. I suspect others would do the same. But there are times (actually numerous) that I want to find the geographical location of an intruder (for example). Frequently I use to find out where the attacker/intruder came from. Of course, it doesn't give the *exact* geographical location. But close enough. And still preserves privacy. (I think.) my 2 cents. -- budi Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RKovOh013933 for ; Wed, 27 Feb 2002 21:50:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RKovme013932 for ietf-provreg-outgoing; Wed, 27 Feb 2002 21:50:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RKouOh013927 for ; Wed, 27 Feb 2002 21:50:56 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1RKmH123922 for ; Wed, 27 Feb 2002 12:48:17 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202272048.g1RKmH123922@nic-naa.net> To: ietf-provreg@cafax.se Subject: Mapping IP Addresses to Geographic Location Date: Wed, 27 Feb 2002 15:48:17 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk host-by-addr (an instance of object-by-attribute) raises two issues: o existance and relevenacy of object-by-attribute mechanism, a general question of specification scope, and data specification, and o reverse lookup, mapping ip addresses to geographic location, a specific question of relevance where locality of reference is not casual. Scott Hollenbeck has responded to the first issue, I agree with Scott. About 18 months ago, the W3C's Technology and Society Domain's Privay Activity's, P3P Project's Specification Working Group (P3P Spec WG) hit on the problem of reverse lookup -- mapping addresses to locations. I happen to know this fairly well as it came down to two positions: the first, articulated by Martin Presler-Marshall of IBM, was that a /24 (old Class C) mask on ip addresses captured by data collectors was sufficient to provide a reasonable degree of privacy. The second was that RIR and LIR masks were trivially accessible, that looking beyond the ISP to the end-point (or /24 of theoretically simultanious active dhcp end-points) was intrusive on the ISP's business model, in addition to the end-user expectation of privacy (from provider/location/timeofday/demographic based profiling). I articulated the second view, working at the tim to enable statistical, not deterministic, profiling, and avoid "over-capture". Martin's point of view prevailed, /24 is in the P3P spec, not /. Other data points (pun intended) Akamai's address space data base (EdgeScape db) provides, for an IP address (effectively a CIDR block): Country, State (US), City, Phone Area Code, Country, Latitude, Longitude, Time Zone, Network Type (Dialup/DSL/Cable) DMA: Designated Marketing Areas MSA: Metropolitan Statistical Areas PMSA: Primary Metropolitan Statistical Areas see: http://www.akamai.com/en/html/services/ct_how_it_works.html Quova's address space data base provides more or less the same thing. see: http://www.quova.com/service.htm They're not alone, I'm just not interested in calling an analyst for a competitive analysis summary off of someone's SEC filings. Having written portions of NeuStar's .US proposal, and having done all of the research prior to November on the transition, I sympathize with the incumbent operator. However, adding reverse lookup in any guise to EPP is asking for trouble. There are registry operators who sell bulk registrant data (to SPAMers). There are registrars who sell bulk registrant data (to SPAMers). There are whois "miners" who sell bulk registrant data (to ... SPAMers). This isn't a feature to add to the protocol core without due reflection. Inverting nameserver addresses (EPP hosts) to registrar and/or registrant identities meets no obvious need, except in amazingly bad edge cases like the .US TLD. It sets a precident for other forms of object-by-attribute, which get bad really quick, and it is subject to misuse by design. This is one of those places where locality of reference is not casual -- in fact, the whole .US is currently laid out (and squatted upon) along locality lines. Mechanism can not correct for a policy of laisse faire (par la lachete). Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RHr3Oh012487 for ; Wed, 27 Feb 2002 18:53:03 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RHr3Z3012486 for ietf-provreg-outgoing; Wed, 27 Feb 2002 18:53:03 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RHr2Oh012479 for ; Wed, 27 Feb 2002 18:53:02 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1RHr1807087 for ; Wed, 27 Feb 2002 12:53:01 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 11:52:56 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AF4@dc02.npac.com> From: "Liu, Hong" To: "'ietf-provreg@cafax.se'" Subject: Pending Update Date: Wed, 27 Feb 2002 11:52:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk The current update operation defined in EPP is basically a two step process: First, an update request is made by the registrar to the registry. Second, the registry either rejects the request or performs the operation; and a response is sent back to the registrar. A pending update refers to a four step process: First, an update request is made by the registrar to the registry. Second, the registry acknowledges the request to the registrar but does not take action for the moment, i.e., the update is pending. Third, upon further authorization, the registry either rejects the request or performs the operation; then posts the result to the message queue. Fourth, the registrar polls the message queue to retrieve the result of the operation. Conceptually, pending update is very similar to the transfer operation currently defined in EPP. I would like to hear from the list how such operation is supported by EPP. If this topic has been discussed before on the mailing list, I would appreciate pointers to the previous discussions. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RFumOh011453 for ; Wed, 27 Feb 2002 16:56:48 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RFumSh011452 for ietf-provreg-outgoing; Wed, 27 Feb 2002 16:56:48 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RFukOh011447 for ; Wed, 27 Feb 2002 16:56:47 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1RFuiS07070 for ; Wed, 27 Feb 2002 09:56:44 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 09:56:39 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AF1@dc02.npac.com> From: "Liu, Hong" To: ietf-provreg@cafax.se Subject: RE: Reverse Lookup using IP Address in EPP? Date: Wed, 27 Feb 2002 09:56:37 -0600 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 Asbjorn, Scott and Patrik, Thanks for providing comments to this thread. To come to a closure on this thread, I would like to summarize what I gathered from the list: The question posted was: how can one find out the corresponding host object(s) given an IP address, i.e., reverse lookup? There are three methods suggested: (1) Use whois query. This requires that all host objects be stored in the whois database. It may or may not be the case depending on registry policy. (2) Return the list of host objects currently using the IP address during the creation of a new host object for the same IP address. This requires extension to be defined in EPP for the response message of command. (3) Extend to allow query host objects based on an IP address. This entails that the command and response be modified. (1) is out-of-band while (2) and (3) are in-band. Each has pros and cons. In terms of the degree of changes required for EPP, (2) seems to be simpler and less painful. Comments? --Hong Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1REMoOh010823 for ; Wed, 27 Feb 2002 15:22:50 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1REMov2010822 for ietf-provreg-outgoing; Wed, 27 Feb 2002 15:22:50 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1REMnOh010817 for ; Wed, 27 Feb 2002 15:22:49 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA09005; Wed, 27 Feb 2002 09:22:47 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YHX3XP>; Wed, 27 Feb 2002 09:22:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B71F@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'asbjorn.rrp@theglobalname.org'" , ietf-provreg@cafax.se Subject: RE: statusResultDataType Date: Wed, 27 Feb 2002 09:22:42 -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: asbjorn.rrp@theglobalname.org > [mailto:asbjorn.rrp@theglobalname.org] > Sent: Wednesday, February 27, 2002 8:58 AM > To: ietf-provreg@cafax.se > Subject: statusResultDataType > > > Hi, > > reading through the 05/06 drafts, I found the following: > > > > minOccurs="0"/> > > > > In the 06-draft (Page 32) it states: > > "Multiple elements MAY be returned if the server recognizes > the identifier and > the client does not enforce identifier uniqueness." > > Am I missing something, or doesn't this mean that the element > should have a > maxOccurs="unbounded"? Asbjorn, Yes, someone else brought that error to my attention off-list. It should have a maxOccurs="unbounded" attribute, and it'll be added at the next editing opportunity - most likely to deal with IESG or IETF last call comments. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RDwJOh010548 for ; Wed, 27 Feb 2002 14:58:19 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RDwJbp010547 for ietf-provreg-outgoing; Wed, 27 Feb 2002 14:58:19 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx11.nameplanet.com (mx11.nameplanet.com [62.70.3.41]) by nic.cafax.se (8.12.2/8.12.2) with SMTP id g1RDwIOh010542 for ; Wed, 27 Feb 2002 14:58:18 +0100 (MET) Received: 27 Feb 2002 13:58:18 -0000 Received: from unknown (HELO www3.nameplanet.com) (192.168.2.43) by mx11 with SMTP; 27 Feb 2002 13:58:18 -0000 Received: (qmail 11112 invoked by uid 400); 27 Feb 2002 13:58:18 -0000 Date: 27 Feb 2002 13:58:14 -0000 Message-ID: <20020227135814.11037.qmail@www3.nameplanet.com> From: asbjorn.rrp@theglobalname.org To: ietf-provreg@cafax.se MIME-Version: 1.0 Subject: statusResultDataType Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, reading through the 05/06 drafts, I found the following: In the 06-draft (Page 32) it states: "Multiple elements MAY be returned if the server recognizes the identifier and the client does not enforce identifier uniqueness." Am I missing something, or doesn't this mean that the element should have a maxOccurs="unbounded"? Regards, Asbjorn -- The information transmitted in this email is intended only for the person(s) or entity to which it is addressed and may contain proprietary, confidential and/or privileged material. If you have received this email in error, please contact the sender by replying and delete this email so that it is not recoverable. If you are not the intended recipient(s), any retention, review, disclosure, distribution, copying, printing, dissemination, or other use of, or taking of any action in reliance upon, this information is strictly prohibited and without liability on our part. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RDMkOh010347 for ; Wed, 27 Feb 2002 14:22:46 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RDMkmU010346 for ietf-provreg-outgoing; Wed, 27 Feb 2002 14:22:46 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RDMjOh010341 for ; Wed, 27 Feb 2002 14:22:45 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1RDJe122288; Wed, 27 Feb 2002 05:19:40 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202271319.g1RDJe122288@nic-naa.net> To: "Tomas Mackus" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Is this correct ? In-Reply-To: Your message of "Wed, 27 Feb 2002 14:57:18 +0200." <029101c1bf8e$4a6f1660$153ddbc1@scuni.ktu.lt> Date: Wed, 27 Feb 2002 08:19:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Tomas, RRP questions can (should) be addressed directly to its authors, and to its user community. This list is for collaborative specification of another registry provisioning protocol, EPP. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RCvMOh010223 for ; Wed, 27 Feb 2002 13:57:22 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1RCvM0L010222 for ietf-provreg-outgoing; Wed, 27 Feb 2002 13:57:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sc-uni.ktu.lt (nemunas.sc-uni.ktu.lt [193.219.32.13]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1RCvKOh010217 for ; Wed, 27 Feb 2002 13:57:21 +0100 (MET) Received: from naras (naras.sc-uni.ktu.lt [193.219.61.21]) by sc-uni.ktu.lt (8.9.0/8.9.0) with SMTP id OAA06059 for ; Wed, 27 Feb 2002 14:57:19 +0200 (STD) Message-ID: <029101c1bf8e$4a6f1660$153ddbc1@scuni.ktu.lt> From: "Tomas Mackus" To: References: <200202270300.g1R30l120707@nic-naa.net> Subject: Is this correct ? Date: Wed, 27 Feb 2002 14:57:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" 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 Hello, Just want to ask about domain name creation process in RRP. For example registrar on behalf of registrant want to create: domain: foo.tld ns: ns1.foo.tld ns: ns2.foo.tld Then registrar have to make 4 actions ? Am I right ? Create foo.tld with 0 ns associated (because ns1.foo.tld and ns2.foo.tld are not registered and can't be registered without foo.tld) Create ns1.foo.tld Create ns2.foo.tld Update foo.tld with registered name servers ns1 and ns2 ? Best Regards, Tomas Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1R9s6Oh009582 for ; Wed, 27 Feb 2002 10:54:06 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1R9s6YU009581 for ietf-provreg-outgoing; Wed, 27 Feb 2002 10:54:06 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mx14.nameplanet.com (mx14.nameplanet.com [62.70.3.44]) by nic.cafax.se (8.12.2/8.12.2) with SMTP id g1R9s5Oh009576 for ; Wed, 27 Feb 2002 10:54:05 +0100 (MET) Received: 27 Feb 2002 09:54:05 -0000 Received: from unknown (HELO www3.nameplanet.com) (192.168.2.43) by mx14 with SMTP; 27 Feb 2002 09:54:05 -0000 Received: (qmail 8647 invoked by uid 400); 27 Feb 2002 09:54:05 -0000 Date: 27 Feb 2002 09:54:05 -0000 Message-ID: <20020227095405.8640.qmail@www3.nameplanet.com> From: asbjorn.rrp@theglobalname.org To: Hong.Liu@neustar.biz Cc: ietf-provreg@cafax.se MIME-Version: 1.0 Subject: RE: Reverse Lookup using IP Address in EPP? Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, 26 Feb 2002 16:49:43 -0600 "Liu, Hong" wrote: >> The second question has to do with whois. > >[HL] I asked the question because whois was suggested by Scott and Patrik as >out-of-band means to getting the job done. What I want to make sure is that >whether ALL host objects created in the registry are available for query in >the whois database. As far as I can remember, nothing is mentioned in the EPP drafts about whois. Whereas you can be pretty sure that in-zone nameservers would always be in whois (due to the IP-information), I guess it would be Registry Policy whether or not to include non-nameserver hosts as well... Asbjorn -- The information transmitted in this email is intended only for the person(s) or entity to which it is addressed and may contain proprietary, confidential and/or privileged material. If you have received this email in error, please contact the sender by replying and delete this email so that it is not recoverable. If you are not the intended recipient(s), any retention, review, disclosure, distribution, copying, printing, dissemination, or other use of, or taking of any action in reliance upon, this information is strictly prohibited and without liability on our part. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1R33POh008411 for ; Wed, 27 Feb 2002 04:03:25 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1R33PYb008410 for ietf-provreg-outgoing; Wed, 27 Feb 2002 04:03:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1R33MOh008405 for ; Wed, 27 Feb 2002 04:03:22 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1R30l120707; Tue, 26 Feb 2002 19:00:47 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202270300.g1R30l120707@nic-naa.net> To: "Liu, Hong" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Reverse Lookup using IP Address in EPP? In-Reply-To: Your message of "Tue, 26 Feb 2002 16:49:43 CST." <23309E398D84D5119D0F00306E07513901181AEA@dc02.npac.com> Date: Tue, 26 Feb 2002 22:00:47 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk >> Is "company Y" [and X] a registrar? > > Both X and Y are registrants. I thought as much. Seng wanted to stretch the AAA envelope out to the edge (registrants), cutting the registrars out of the AAA problem, and also out of a constructive role in registry provisioning. >>> ... how can the registry prevent IP address hijacking ... >> >> Let's clear up the first set of issues and identify who the actors are, then >> see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature. > > I don't think the last part of the sentence is of relevance to this > discussion. OK. Then ".US" It appears to me that you are trying to map EPP, which assumes some set of boundary conditions, such as ICANN accredited, or similarly situated (read "responsible") registrars, onto the .US booby hatch, where five fun lovin' guys-n-gals "own" 40% of the metro areas. You've got registrars (presumptive clue) bagging each other's registrants' nameservers, and absent a pre-existing policy venue, you seem to be looking for a technical mechanism to discover and/or cure bad acts. To stretch the authentication envelope out to the registrants, you may as well revisit James' issues. > If that was discussed before, I would like to know the result of the > discussion. Any pointer would be appreciated. 1 02/05 Patrick Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 2 02/05 "Brian W. Spolari RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 3 02/05 Patrick Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 4 02/06 Sheer El-Showk RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 5 02/07 "James Seng/Perso Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 6 02/07 Urs Eppenberger Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter 7 02/07 Patrick Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter All dates are 2001. I suggest a look at the London notes as well. >>> The second question has to do with whois. >> >> This isn't an EPP issue. > > I asked the question because whois was suggested by Scott and Patrik as > out-of-band means to getting the job done. What I want to make sure is that > whether ALL host objects created in the registry are available for query in > the whois database. It is a reasonable question to ask a registry operator -- is the data stream sunk by a protocol A server provably consistent with and exhaustive of some subsequent access method of some possibly other protocol B server. EPP is protocol A. It isn't protocol B. I know the .US roll-out has to do better -- a lot better -- than the .biz roll-out. The $20M figure has been public for ages, hence the 1M registrant requirement just to make debt. But this isn't this WG's problem, it isn't a protocol problem. If the .US cyber-squatters are converted into registrars, they win the business proposition, and that's fine. If the gTLD registrars peel 1M off of .com, they win the churn, and that's fine too. Either way (assumptions being true by desire alone) and a operator avoids failure. But your registry's business model validation isn't this WG's problem. The US, and a company, aren't the controlling interests today, just as they weren't the controlling interests when it was another DoC problem and another company. Feel free to ignore the following: o go back to the req draft, and _liberally_ wack out anything that looks and feels "normal" (.com aka "gTLD" mindset), then o summarize the actual situation of your ccTLD, then o pretend its the Falkland Islands, not the US, and try to find the bits that are common to both the .US zoo and the Falkland sheep, and then o conservatively extend EPP (or vary from EPP/RRP/SRS/...) to the core problem you are trying to solve (which may be very close to the problem James was trying to solve). o drop this WG a note that explains most (maybe not #2) of the above. or o go forth and specify the non-EPP registry-registrar protocol for .US and/or the Falkland Islands or where ever. Cheers, Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QMnqOh006826 for ; Tue, 26 Feb 2002 23:49:52 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QMnqte006825 for ietf-provreg-outgoing; Tue, 26 Feb 2002 23:49:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QMnpOh006820 for ; Tue, 26 Feb 2002 23:49:51 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1QMno821493 for ; Tue, 26 Feb 2002 17:49:50 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 16:49:45 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AEA@dc02.npac.com> From: "Liu, Hong" To: ietf-provreg@cafax.se Subject: RE: Reverse Lookup using IP Address in EPP? Date: Tue, 26 Feb 2002 16:49:43 -0600 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: Tuesday, February 26, 2002 4:34 PM To: Liu, Hong Cc: ietf-provreg@cafax.se; brunner@nic-naa.net Subject: Re: Reverse Lookup using IP Address in EPP? > Suppose company X has created a host object ... Is "company X" a registrar? > Now company Y, who has the IP address ... Is "company Y" a registrar? [HL] Both X and Y are registrants. Their respective registrars act on their behalf to create the host objects. > ... how can the registry prevent IP address hijacking ... Let's clear up the first set of issues and identify who the actors are, then see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature. [HL] I don't think the last part of the sentence is of relevance to this discussion. James Seng raised this issue a year ago (Feb 7), if I understand the problem posed. [HL] If that was discussed before, I would like to know the result of the discussion. Any pointer would be appreciated. > The second question has to do with whois. This isn't an EPP issue. [HL] I asked the question because whois was suggested by Scott and Patrik as out-of-band means to getting the job done. What I want to make sure is that whether ALL host objects created in the registry are available for query in the whois database. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QLapOh006565 for ; Tue, 26 Feb 2002 22:36:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QLapQf006564 for ietf-provreg-outgoing; Tue, 26 Feb 2002 22:36:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QLanOh006559 for ; Tue, 26 Feb 2002 22:36:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1QLYC119824; Tue, 26 Feb 2002 13:34:12 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202262134.g1QLYC119824@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Liu, Hong" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Reverse Lookup using IP Address in EPP? In-Reply-To: Message from "Liu, Hong" of "Tue, 26 Feb 2002 14:52:33 CST." <23309E398D84D5119D0F00306E07513901181AE8@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Feb 2002 16:34:12 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Suppose company X has created a host object ... Is "company X" a registrar? > Now company Y, who has the IP address ... Is "company Y" a registrar? > ... how can the registry prevent IP address hijacking ... Let's clear up the first set of issues and identify who the actors are, then see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature. James Seng raised this issue a year ago (Feb 7), if I understand the problem posed. > The second question has to do with whois. This isn't an EPP issue. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QKqgOh006386 for ; Tue, 26 Feb 2002 21:52:42 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QKqgQn006385 for ietf-provreg-outgoing; Tue, 26 Feb 2002 21:52:42 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QKqfOh006380 for ; Tue, 26 Feb 2002 21:52:41 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1QKqeS08351 for ; Tue, 26 Feb 2002 14:52:40 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 14:52:35 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AE8@dc02.npac.com> From: "Liu, Hong" To: ietf-provreg@cafax.se Subject: RE: Reverse Lookup using IP Address in EPP? Date: Tue, 26 Feb 2002 14:52:33 -0600 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 would like to back off a bit to talk about the problems before jumping on solutions. Specifically, I have two questions to the list: The first question has to do with 1 IP address. Suppose company X has created a host object fake.x.foo using IP address 1.2.3.4, which is NOT the IP address that X is allocated to use. This host object is NOT being used as a nameserver for x.foo. Now company Y, who has the IP address, is trying to create a host object real.y.foo. - If the 1 IP address policy is imposed, then the creation of real.y.foo will be rejected. Company Y wants to find out why this is the case. The question is how. - If no such policy is in place, how can the registry prevent IP address hijacking from company X (intentionally or un-intentionally)? The second question has to do with whois. Since not all host objects are nameservers, they are not necessarily associated with registered domains. Are those non-NS host objects also stored in the whois database? Your comments are much appreciated. --Hong Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QIm8Oh005830 for ; Tue, 26 Feb 2002 19:48:08 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QIm8Fc005829 for ietf-provreg-outgoing; Tue, 26 Feb 2002 19:48:08 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QIm6Oh005824 for ; Tue, 26 Feb 2002 19:48:07 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1QIja118983; Tue, 26 Feb 2002 10:45:36 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202261845.g1QIja118983@nic-naa.net> To: "Liu, Hong" cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Reverse Lookup using IP Address in EPP? In-Reply-To: Your message of "Tue, 26 Feb 2002 11:42:44 CST." <23309E398D84D5119D0F00306E07513901181AE4@dc02.npac.com> Date: Tue, 26 Feb 2002 13:45:36 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > ... an unique IP address be assigned > to each name server ... Is substance of this claimed to be a protocol issue or a registry practices issue? Scott observed: > ... doing object lookup using an object attribute as a key, > which is out of place in a provisioning protocol. Agreed. And: > I would also like to hear other alternatives for > solving this problem. There doesn't yet appear to be a problem statement. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QIHaOh005694 for ; Tue, 26 Feb 2002 19:17:36 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QIHaZH005693 for ietf-provreg-outgoing; Tue, 26 Feb 2002 19:17:36 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QIHZOh005685 for ; Tue, 26 Feb 2002 19:17:35 +0100 (MET) Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id g1QIHVG5019290 for ; Tue, 26 Feb 2002 19:17:32 +0100 Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id g1QIHVKc019287 for ietf-provreg@cafax.se; Tue, 26 Feb 2002 19:17:31 +0100 Date: Tue, 26 Feb 2002 19:17:31 +0100 From: Patrick To: ietf-provreg@cafax.se Subject: Re: Reverse Lookup using IP Address in EPP? Message-ID: <20020226181731.GS11876@nohope.patoche.org> References: <23309E398D84D5119D0F00306E07513901181AE4@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23309E398D84D5119D0F00306E07513901181AE4@dc02.npac.com> User-Agent: Mutt/1.3.24i X-PGP-KeyID: A241FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Feb 26, 2002 at 11:42:44AM -0600, Liu, Hong took time to write: > The current registry practice requires that an unique IP address be assigned > to each name server in the same name space. That is, if an IP address is It seems not to be true anymore for Verisign. > already used by an NS, it cannot be used for another NS. It is very > difficult to find out which host has used the IP address, without looking at > the zone file, or calling customer support. Even zone files may not contain > the host if it is an orphan NS in the registry. This is the out-of-band > method. There is no need to. whois (Registry) is sufficient, as long as it contains data about nameservers and that it can be queried by nameserver's name or by IP. This is the current case of whois.Verisign-grs.net > One possible way to resolve this issue is to provide reverse lookup based on > an IP address via the registrar-registry interface, i.e., in-band method. > Based on the returned host name, the requesting party knows whether that > host is still in use as an NS or not. In the case of an orphan NS, the > requesting party can tell the registry to remove the A RR for the host. I would suggest something simpler if you really want the restriction of 1 IP : when you create a nameserer and that fails because the IP is already used, put the nameserver already registered with the given IP in the error message of the creation. Patrick. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QI4vOh005598 for ; Tue, 26 Feb 2002 19:04:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QI4vbe005597 for ietf-provreg-outgoing; Tue, 26 Feb 2002 19:04:57 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QI4uOh005592 for ; Tue, 26 Feb 2002 19:04:56 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA08879; Tue, 26 Feb 2002 13:04:50 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YHWX47>; Tue, 26 Feb 2002 13:04:49 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B715@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Liu, Hong'" , ietf-provreg@cafax.se Subject: RE: Reverse Lookup using IP Address in EPP? Date: Tue, 26 Feb 2002 13:04:42 -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: Liu, Hong [mailto:Hong.Liu@neustar.biz] > Sent: Tuesday, February 26, 2002 12:43 PM > To: ietf-provreg@cafax.se > Subject: Reverse Lookup using IP Address in EPP? > > > The current registry practice requires that an unique IP > address be assigned > to each name server in the same name space. That is, if an IP > address is > already used by an NS, it cannot be used for another NS. It is very > difficult to find out which host has used the IP address, > without looking at > the zone file, or calling customer support. Even zone files > may not contain > the host if it is an orphan NS in the registry. This is the > out-of-band > method. FWIW our requirements draft specifically says (see 3.4.2-[3]) that an IP address can be associated with multiple registered hosts. EPP doesn't include any restrictions in this regard. > One possible way to resolve this issue is to provide reverse > lookup based on > an IP address via the registrar-registry interface, i.e., > in-band method. > Based on the returned host name, the requesting party knows > whether that > host is still in use as an NS or not. In the case of an orphan NS, the > requesting party can tell the registry to remove the A RR for > the host. > > However, this requires that the current EPP protocol be > extended to include > such capability in the host mapping part. I would like to > know how the WG > feels about this issue. I would also like to hear other > alternatives for > solving this problem. We talked about this some time ago. My argument against it at the time was that it involves doing object lookup using an object attribute as a key, which is out of place in a provisioning protocol. As far as I know most operators make it possible to use whois to find hosts by IP address. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHpbOh005508 for ; Tue, 26 Feb 2002 18:51:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QHpbxH005507 for ietf-provreg-outgoing; Tue, 26 Feb 2002 18:51:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bean.ar.com (66.123.187.68.ar.com [66.123.187.68] (may be forged)) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHpZOh005502 for ; Tue, 26 Feb 2002 18:51:36 +0100 (MET) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g1QHpYdR029224; Tue, 26 Feb 2002 09:51:34 -0800 (PST) Date: Tue, 26 Feb 2002 09:51:33 -0800 (PST) From: Rick H Wesson To: "Liu, Hong" cc: Subject: Re: Reverse Lookup using IP Address in EPP? In-Reply-To: <23309E398D84D5119D0F00306E07513901181AE4@dc02.npac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk good suggestion. I can see the benifit of leverse lookups of name servers within the spec. -rick On Tue, 26 Feb 2002, Liu, Hong wrote: > The current registry practice requires that an unique IP address be assigned > to each name server in the same name space. That is, if an IP address is > already used by an NS, it cannot be used for another NS. It is very > difficult to find out which host has used the IP address, without looking at > the zone file, or calling customer support. Even zone files may not contain > the host if it is an orphan NS in the registry. This is the out-of-band > method. > > One possible way to resolve this issue is to provide reverse lookup based on > an IP address via the registrar-registry interface, i.e., in-band method. > Based on the returned host name, the requesting party knows whether that > host is still in use as an NS or not. In the case of an orphan NS, the > requesting party can tell the registry to remove the A RR for the host. > > However, this requires that the current EPP protocol be extended to include > such capability in the host mapping part. I would like to know how the WG > feels about this issue. I would also like to hear other alternatives for > solving this problem. > > Cheers, > > --Hong > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHgrOh005442 for ; Tue, 26 Feb 2002 18:42:53 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QHgqmL005441 for ietf-provreg-outgoing; Tue, 26 Feb 2002 18:42:52 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHgpOh005436 for ; Tue, 26 Feb 2002 18:42:52 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1QHgpS31734 for ; Tue, 26 Feb 2002 11:42:51 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 11:42:46 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AE4@dc02.npac.com> From: "Liu, Hong" To: ietf-provreg@cafax.se Subject: Reverse Lookup using IP Address in EPP? Date: Tue, 26 Feb 2002 11:42:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk The current registry practice requires that an unique IP address be assigned to each name server in the same name space. That is, if an IP address is already used by an NS, it cannot be used for another NS. It is very difficult to find out which host has used the IP address, without looking at the zone file, or calling customer support. Even zone files may not contain the host if it is an orphan NS in the registry. This is the out-of-band method. One possible way to resolve this issue is to provide reverse lookup based on an IP address via the registrar-registry interface, i.e., in-band method. Based on the returned host name, the requesting party knows whether that host is still in use as an NS or not. In the case of an orphan NS, the requesting party can tell the registry to remove the A RR for the host. However, this requires that the current EPP protocol be extended to include such capability in the host mapping part. I would like to know how the WG feels about this issue. I would also like to hear other alternatives for solving this problem. Cheers, --Hong Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHQROh005362 for ; Tue, 26 Feb 2002 18:26:27 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QHQR1v005361 for ietf-provreg-outgoing; Tue, 26 Feb 2002 18:26:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QHQPOh005356 for ; Tue, 26 Feb 2002 18:26:26 +0100 (MET) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1QHQPS30916 for ; Tue, 26 Feb 2002 11:26:25 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 11:26:20 -0600 Message-ID: <23309E398D84D5119D0F00306E07513901181AE3@dc02.npac.com> From: "Liu, Hong" To: "'ietf-provreg@cafax.se'" Subject: test Date: Tue, 26 Feb 2002 11:26:17 -0600 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 a test. Please ignore. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QGrCOh005114 for ; Tue, 26 Feb 2002 17:53:12 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QGrB53005113 for ietf-provreg-outgoing; Tue, 26 Feb 2002 17:53:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QGrAOh005108 for ; Tue, 26 Feb 2002 17:53:10 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1QGoh118629; Tue, 26 Feb 2002 08:50:43 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202261650.g1QGoh118629@nic-naa.net> To: Edward Lewis cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Call for agenda items for Minneapolis In-Reply-To: Your message of "Mon, 25 Feb 2002 20:45:06 EST." Date: Tue, 26 Feb 2002 11:50:43 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, The WG has an interest, if only to prevent "end-runs" that the IESG may not catch, in any draft that purports to be proximal to, or responsive to, the requirements draft. The better interest is that the draft may be of general interest to the implementors. A long-winded "agree" to the point that "the WG is [not] limited to just the core/standard documents". The operation of a registry, in the abstract, isn't something that admits "interoperation", unless the registy has more than one operator, either concurrently or (proximally) consequetively. The policy of of a ccTLD delegation, in the abstract, isn't something that admits "interoperation", unless delegation is multiply concurrently or (proximally) consequetively instantiated. In short, if we close our eyes to the fact that this is a specific operator and a specific ccTLD, it is difficult to find where a second implementation that could be interoperable, or not, is technically [1] feasible. If it makes a difference that the delegation is ".US", or the operator favored as "second after Verisign", then the WG is (temporarily) embarked on some national or marketing detour. We adopted XML. This is one of the distinguishing features of EPP. There are alternatives: o RRP (versions 1.0 and version 1.1) uses name-value pairs, o SRS (versions 1.0, 1999 and version 2.0, 2001) uses name-value pairs [2], o others, specifications not generally available For reasons others can enquire into, the authors of this draft chose not to use a schema, and opted out of XML as a design constraint. I noted earlier that a name-value space similar to that proposed in this draft has been investigated in the W3C PICS activity. It is hard to describe relationships using this techniques [3], as most everyone involved, including the current IAB chair, knows. We could, without prejudice to the draft, consensus that name-value pairs are out-of-scope for the PROVREG WG. I think we did this some (long) time ago, but maybe not. Well, I've got to go pick up kids. Eric [1] Any of these -- a partitioned .US registry (or a competitive registry), multiple applicable policies for .US registries, registrars, and registrants, and (to be sure) a non-unique delegation, would be interesting, and novel. None is proposed. [2] Elmar Knipp December 10, 2001. [3] http://www.w3.org/2001/Talks/09xx-semwai/all Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QC5QOh003701 for ; Tue, 26 Feb 2002 13:05:26 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1QC5QEx003700 for ietf-provreg-outgoing; Tue, 26 Feb 2002 13:05:26 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1QC5OOh003695 for ; Tue, 26 Feb 2002 13:05:25 +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 HAA24710; Tue, 26 Feb 2002 07:05:17 -0500 (EST) Message-Id: <200202261205.HAA24710@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-06.txt Date: Tue, 26 Feb 2002 07:05:16 -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-06.txt Pages : 24 Date : 25-Feb-02 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-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-06.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-06.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: <20020225143300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143300.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8hJOh002971 for ; Tue, 26 Feb 2002 09:43:19 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1Q8hJSm002970 for ietf-provreg-outgoing; Tue, 26 Feb 2002 09:43:19 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8hHOh002965 for ; Tue, 26 Feb 2002 09:43:18 +0100 (MET) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id AAA01214; Tue, 26 Feb 2002 00:43:14 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020226004119.02028480@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 00:43:04 -0800 To: Edward Lewis From: Dave Crocker Subject: RE: Call for agenda items for Minneapolis Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60189B6CB@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 08:45 PM 2/25/2002 -0500, Edward Lewis wrote: >Hmmmm. I am unsure of this but I think the WG is permitted to review >extenstions that benefit a minority of of users (in this case, specifically >registries). This would demontrate the "extensibility" of the base and >encourage safe extenstions. For a protocol expected to be used in many environments that will want local tailoring, there is quite a bit of benefit in considering specific, local efforts for just the reason you cite, namely to ensure that local extensions are not overly painful. And as Eric notes, the WG should keep an eagle eye out, looking for kernels of generality to folk into the base protocol. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; (new)fax +1.408.850.1850 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8GbOh002823 for ; Tue, 26 Feb 2002 09:16:37 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1Q8GbPr002822 for ietf-provreg-outgoing; Tue, 26 Feb 2002 09:16:37 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8GVOh002810 for ; Tue, 26 Feb 2002 09:16:32 +0100 (MET) Received: by sentry.gw.tislabs.com; id DAA22693; Tue, 26 Feb 2002 03:21:59 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xmaa22683; Tue, 26 Feb 02 03:21:42 -0500 X-Sender: lewis@169.223.130.14 (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6D9@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Feb 2002 20:33:38 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: grrp - object deletion Cc: "'Tomas Mackus'" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is the kind of issue, if spurred by difficulties in generating interoperable implementations, that would be addressed in a next round of the specifications. I.e., we are submitting the documents (should be in the past tense now) for the first level of standardization. (I believe this is Proposed, I admit I keep forgetting the correct tag.) If all goes smoothly (and it never does), we need to have some time elapse and implementations interoperate before submitting for the next level of standard - Draft. So, earmark issues encountered when implementing, more for input to the next set of documents. (Of course, if we need to recycle at Proposed or resubmit, then we can consider refinements.) None of what I have said addresses the data consistency comment by Scott, I just wanted to address the last sentence. At 10:16 AM -0500 2/20/02, Hollenbeck, Scott wrote: >Thomas, > >I didn't write such text in the requirements document because I thought it >crosses into being a data consistency issue rather than being a functional >protocol requirement. Plus, with the document now in the hands of the IESG >I'm loath to make any changes that aren't directed by them as part of the >last call process. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8GXOh002820 for ; Tue, 26 Feb 2002 09:16:33 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1Q8GX4p002819 for ietf-provreg-outgoing; Tue, 26 Feb 2002 09:16:33 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1Q8GVOh002809 for ; Tue, 26 Feb 2002 09:16:32 +0100 (MET) Received: by sentry.gw.tislabs.com; id DAA22696; Tue, 26 Feb 2002 03:21:59 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xmab22683; Tue, 26 Feb 02 03:21:46 -0500 X-Sender: lewis@169.223.130.14 (Unverified) Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6CB@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Feb 2002 20:45:06 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: Call for agenda items for Minneapolis Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 12:42 PM -0500 2/19/02, Hollenbeck, Scott wrote: >> From: Eric Brunner-Williams in Portland Maine >> >> The authors have created a registry-private extension, as other registries >> have for trademark data, and no doubt will continue to experiment with as >> the registry experience matures. Such things are properly in operational >> registry practices documents, or informational I-Ds, not requiring working >> group change control and process. > >I have to agree with Eric. I'd prefer that we spend meeting time on topics >of concern to the WG as a whole. Hmmmm. I am unsure of this but I think the WG is permitted to review extenstions that benefit a minority of of users (in this case, specifically registries). This would demontrate the "extensibility" of the base and encourage safe extenstions. Such a document may lead to a non-standards document, e.g., informational or experimental. I'm not giving the green-light for a full bore consideration here, but I do want to point out that the WG is limited to just the core/standard documents. Also, being that we (the chairs) haven't see (m)any other agenda suggestions and there was a request for 2 hours, we need to ask: What topics are to be discussed in Minneapolis. (The chairs want to hear from the WG.) (That is besides the obvious - core spec status, implementations...) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1MEQwOh015310 for ; Fri, 22 Feb 2002 15:26:58 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1MEQwg3015309 for ietf-provreg-outgoing; Fri, 22 Feb 2002 15:26:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1MEQqOh015304 for ; Fri, 22 Feb 2002 15:26:53 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA05691; Fri, 22 Feb 2002 09:26:35 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJRY4Z>; Fri, 22 Feb 2002 09:25:21 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6F5@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , ietf-provreg@cafax.se, Jaap Akkerhuis , Ed Lewis Cc: Ned Freed Subject: RE: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt Date: Fri, 22 Feb 2002 09:25:41 -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 to Patrik for quickly pulling together some clarifying information I needed to modify the requirements draft per IESG review comments. I just sent the updated document to the I-D administrator - hopefully for the last time! -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1LJ0EOh010780 for ; Thu, 21 Feb 2002 20:00:14 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1LJ0EkN010779 for ietf-provreg-outgoing; Thu, 21 Feb 2002 20:00:14 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1LJ0DOh010774 for ; Thu, 21 Feb 2002 20:00:13 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA05000; Thu, 21 Feb 2002 14:00:00 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YHTNYF>; Thu, 21 Feb 2002 14:00:42 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6EA@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , ietf-provreg@cafax.se, Jaap Akkerhuis , Ed Lewis , "Hollenbeck, Scott" Cc: Ned Freed Subject: RE: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt Date: Thu, 21 Feb 2002 13:59:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g1LJ0EOh010775 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Thursday, February 21, 2002 1:31 PM > To: ietf-provreg@cafax.se; Jaap Akkerhuis; Ed Lewis; > shollenbeck@verisign.com > Cc: Ned Freed > Subject: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt > > > (1) CORE used but not defined. CORE _is_ defined in section 1.1. It can be removed completely if the IANA considerations section is rewritten. > (2) Reference in appx to IANA ports only. I don't understand this comment. > (3) 3.1[7] refers to transactional security without defining it. Actually, it's transactional _integrity_, not security. I can add a sentence to explain what that means. > (4) 3.4.2[2] talks about validity without defining it - in particular, > preemption not discussed. Would it be adequate to simply change "validity period" to "registration period"? > (5) 3.4.3[2] has 1 IP address with multiple name servers. Is > that really > what you want? Yes, per WG discussion it sure is. > (6) 3.4.3 does not require the association of info with > registrars, but > assumes it in [4]. Hmm, OK, so I need to add an explicit requirement to note that objects are managed by a particular registrar/client? > (7) 3.4.5 does not require the ability to do unapproved > transfer (such as > if registrar is dead). Actually, I think it's covered in 3.4.5-[4]. A dead registrar can't do anything. > (8) Section 4 (MUST not introduce limitations) is not really possible. Sure it's possible. The whole idea of this section is to help ensure that the protocol specification doesn't get into defining implementation specifics. It might be possible to collapse the entire section into a "don't limit implementation" statement, but I'd really like more guidance on what needs to be changed here. > (9) Internationalization requirements are (surprisingly) > reasonably OK. Good! > (10) Searchability requirements are VERY weak (by ID only) - that is > probably how it should be. Yes -- we're talking about requirements for a provisioning protocol, not a search or lookup protocol. > (11) The ID has NSI-specific registrations in it even though > its a WG doc, > i.e. if the registrations has to be done, they should be in a separate > document The text says that what's in there aren't registrations to be done, they are registrations that have been done in the past - which includes more than just NSI-specific stuff. Like I said, though, I'll gladly rewrite this section. > (12) The IANA considerations says: > These assignments should be preserved as long as the > corresponding systems > are operational. Additional IANA services might be required > to support > testing and deployment of protocol implementations. > > 1/ how whould the IANA know to zap registrations? > (this partcular problem is removed if the NSI > registrations are removed) > 2/ how is the IANA to know what to do to do the additiopnal > registrations? Any needed additional registrations will have to be documented in appropriate documents. Perhaps that's all the IANA considerations section should say. Patrik, can you provide more specific instructions on what needs to be changed, or are my suggestions above adequate? I'd really like to make sure that the next edit addresses these comments, but I need more detail to be able to do that. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1LIVPOh010667 for ; Thu, 21 Feb 2002 19:31:25 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1LIVPux010666 for ietf-provreg-outgoing; Thu, 21 Feb 2002 19:31:25 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1LIVMOh010661 for ; Thu, 21 Feb 2002 19:31:22 +0100 (MET) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA25164; Thu, 21 Feb 2002 19:31:18 +0100 (MET) Date: Thu, 21 Feb 2002 19:31:06 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: ietf-provreg@cafax.se, Jaap Akkerhuis , Ed Lewis , shollenbeck@verisign.com cc: Ned Freed Subject: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt Message-ID: <7273290.1014319866@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) 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 (1) CORE used but not defined. (2) Reference in appx to IANA ports only. (3) 3.1[7] refers to transactional security without defining it. (4) 3.4.2[2] talks about validity without defining it - in particular, preemption not discussed. (5) 3.4.3[2] has 1 IP address with multiple name servers. Is that really what you want? (6) 3.4.3 does not require the association of info with registrars, but assumes it in [4]. (7) 3.4.5 does not require the ability to do unapproved transfer (such as if registrar is dead). (8) Section 4 (MUST not introduce limitations) is not really possible. (9) Internationalization requirements are (surprisingly) reasonably OK. (10) Searchability requirements are VERY weak (by ID only) - that is probably how it should be. (11) The ID has NSI-specific registrations in it even though its a WG doc, i.e. if the registrations has to be done, they should be in a separate document (12) The IANA considerations says: These assignments should be preserved as long as the corresponding systems are operational. Additional IANA services might be required to support testing and deployment of protocol implementations. 1/ how whould the IANA know to zap registrations? (this partcular problem is removed if the NSI registrations are removed) 2/ how is the IANA to know what to do to do the additiopnal registrations? paf Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KK6gOh005333 for ; Wed, 20 Feb 2002 21:06:42 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1KK6g7f005332 for ietf-provreg-outgoing; Wed, 20 Feb 2002 21:06:42 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KK6fOh005327 for ; Wed, 20 Feb 2002 21:06:41 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA21161; Wed, 20 Feb 2002 15:06:40 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJQ039>; Wed, 20 Feb 2002 15:05:31 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6DD@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Roger Castillo Cortazar'" , ietf-provreg@cafax.se Subject: RE: Identifiers, Handles and ROID's Date: Wed, 20 Feb 2002 15:05: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 Roger, I'll have to fix the text in 2.7 of epp-06 when dealing with IESG comments to make it match the schema (long since changed per WG discussion); the text reflects an earlier approach. The text that's in there now must've slipped through -- thanks for catching it. I'm _not_ going to re-enter the handle/ROID discussion other than saying that the ROID in the specs and the "globally unique identifier" in the requirements are intended to be the same thing... ;-) -Scott- > -----Original Message----- > From: Roger Castillo Cortazar [mailto:castillo@nic.mx] > Sent: Wednesday, February 20, 2002 2:39 PM > To: ietf-provreg@cafax.se > Subject: Identifiers, Handles and ROID's > > > Hi everybody. > I have a few questions about the globally unique identifiers > for objects. > > In the reqs. we can read. > > 3.4.1 Object Identification > ... > [2] Object identifiers MUST be globally unique. > ... > [6] An object's identifier MUST be generated and stored > when an object > is created. > > Nothing about the indentifier being returned to the client. > > Now, in the EPP specs. > > 2.7 Object Identification > ... > Globally unique identifiers can help facilitate object information > sharing between repositories. A globally unique identifier MUST be > assigned to every object when the object is created, and the > identifier MUST be returned within the response for the > command that > created the object. > ... > > Followed by the algorithm to create such identifier. > > But an identifier as described by that algorithm is not > returned by the > command as described in the specs. > > > And more .... > > This could be silly, but I've been reading past year messages > on the topic > of unique handle generation > to try to figure out a few things, and I just may need a few > clarifications. > > I can see three concepts here: > > - The handle as discussed on the list almost a year ago, > - The globally unique identifier as can be read in the drafts, > - The ROID's as returned in the command response. > > Are all these the same thing ? > > The discussed handle is the local part of the globally unique > identifier ? > Are the contact-id and the FQDN for the domains and hosts > instances of any > of these identifiers ? > > Greetings. > > > Roger Castillo Cortazar > NIC-Mexico http://www.nic.mx > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KJdwOh005228 for ; Wed, 20 Feb 2002 20:39:58 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1KJdwTN005227 for ietf-provreg-outgoing; Wed, 20 Feb 2002 20:39:58 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.nic.mx (mail.nic.mx [200.23.1.17]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KJdvOh005222 for ; Wed, 20 Feb 2002 20:39:57 +0100 (MET) Received: from rcastillo.nic.mx (rcastillo.nic.com.mx [200.33.1.31]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g1KJdNX21218 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 20 Feb 2002 13:39:24 -0600 (CST) Message-Id: <5.1.0.14.0.20020220133719.0358cc88@mail.nic.mx> X-Sender: castillo@mail.nic.mx X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 13:38:55 -0600 To: ietf-provreg@cafax.se From: Roger Castillo Cortazar Subject: Identifiers, Handles and ROID's Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi everybody. I have a few questions about the globally unique identifiers for objects. In the reqs. we can read. 3.4.1 Object Identification ... [2] Object identifiers MUST be globally unique. ... [6] An object's identifier MUST be generated and stored when an object is created. Nothing about the indentifier being returned to the client. Now, in the EPP specs. 2.7 Object Identification ... Globally unique identifiers can help facilitate object information sharing between repositories. A globally unique identifier MUST be assigned to every object when the object is created, and the identifier MUST be returned within the response for the command that created the object. ... Followed by the algorithm to create such identifier. But an identifier as described by that algorithm is not returned by the command as described in the specs. And more .... This could be silly, but I've been reading past year messages on the topic of unique handle generation to try to figure out a few things, and I just may need a few clarifications. I can see three concepts here: - The handle as discussed on the list almost a year ago, - The globally unique identifier as can be read in the drafts, - The ROID's as returned in the command response. Are all these the same thing ? The discussed handle is the local part of the globally unique identifier ? Are the contact-id and the FQDN for the domains and hosts instances of any of these identifiers ? Greetings. Roger Castillo Cortazar NIC-Mexico http://www.nic.mx Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KFIEOh003951 for ; Wed, 20 Feb 2002 16:18:14 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1KFIEKL003950 for ietf-provreg-outgoing; Wed, 20 Feb 2002 16:18:14 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KFICOh003945 for ; Wed, 20 Feb 2002 16:18:13 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA03326; Wed, 20 Feb 2002 10:17:14 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YHSKM1>; Wed, 20 Feb 2002 10:17:58 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6D9@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Tomas Mackus'" Cc: ietf-provreg@cafax.se Subject: RE: grrp - object deletion Date: Wed, 20 Feb 2002 10:16:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-4" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thomas, I didn't write such text in the requirements document because I thought it crosses into being a data consistency issue rather than being a functional protocol requirement. Plus, with the document now in the hands of the IESG I'm loath to make any changes that aren't directed by them as part of the last call process. -Scott- > -----Original Message----- > From: Tomas Mackus [mailto:tomas@litnet.lt] > Sent: Wednesday, February 20, 2002 10:10 AM > To: shollenbeck@verisign.com > Cc: ietf-provreg@cafax.se > Subject: grrp - object deletion > > > >3.4.2 Object Registration > .... > > > [3] The protocol MUST provide services to register name servers. Name > > server registration MUST NOT be limited to a specific period of time. > > Name servers MUST be registered with a valid IPv4 or IPv6 address when > > a "glue record" is required for delegation. > > > >3.4.7 Object Deletion > > [1] The protocol MUST provide services to remove a domain name from > > the registry. > > [2] The protocol MUST provide services to remove a name server from > > the registry. > > > > Mabe in 3.4.7 [1] should be mentioned, that name servers MUST > be deleted > with domain name from registry, if these name servers are > subdomains of this > domain name...i.e. glue records MUST be deleted too.... > > > Tomas > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KF3LOh003889 for ; Wed, 20 Feb 2002 16:03:21 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1KF3LNa003888 for ietf-provreg-outgoing; Wed, 20 Feb 2002 16:03:21 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sc-uni.ktu.lt (nemunas.sc-uni.ktu.lt [193.219.32.13]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1KF3HOh003883 for ; Wed, 20 Feb 2002 16:03:19 +0100 (MET) Received: from naras (naras.sc-uni.ktu.lt [193.219.61.21]) by sc-uni.ktu.lt (8.9.0/8.9.0) with SMTP id RAA11265; Wed, 20 Feb 2002 17:03:10 +0200 (STD) Message-ID: <011201c1ba20$b99ae320$153ddbc1@scuni.ktu.lt> From: "Tomas Mackus" To: Cc: References: <200201161203.HAA04828@ietf.org> Subject: grrp - object deletion Date: Wed, 20 Feb 2002 17:10:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" 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 >3.4.2 Object Registration .... > [3] The protocol MUST provide services to register name servers. Name > server registration MUST NOT be limited to a specific period of time. > Name servers MUST be registered with a valid IPv4 or IPv6 address when > a "glue record" is required for delegation. >3.4.7 Object Deletion > [1] The protocol MUST provide services to remove a domain name from > the registry. > [2] The protocol MUST provide services to remove a name server from > the registry. Mabe in 3.4.7 [1] should be mentioned, that name servers MUST be deleted with domain name from registry, if these name servers are subdomains of this domain name...i.e. glue records MUST be deleted too.... Tomas Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JNBMOh000172 for ; Wed, 20 Feb 2002 00:11:22 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JNBMwU000171 for ietf-provreg-outgoing; Wed, 20 Feb 2002 00:11:22 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JNBKOh000166 for ; Wed, 20 Feb 2002 00:11:21 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1K2AO167201; Tue, 19 Feb 2002 18:10:24 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202200210.g1K2AO167201@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Damaraju, Ayesha" cc: "'Eric Brunner-Williams in Portland Maine'" , "Liu, Hong" , Edward Lewis , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Call for agenda items for Minneapolis In-Reply-To: Message from "Damaraju, Ayesha" of "Tue, 19 Feb 2002 16:36:36 CST." <70565611B164D511957A001083FCDD561FB073@VA02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Feb 2002 18:10:24 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > ... not a good idea to use name value pairs in a string - with no schema > definition it kills the purpose of XML & XML validators Yup. The document (whether a registry operational document, or an I-D) could have referenced or modified existing schema, or proposed something useful. A name value pair is simply ... pre-XML. Fine for RRP-esque things (no offense intended to the RRP-esque afficianados), but infra-dig for EPP. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JLUpOh029762 for ; Tue, 19 Feb 2002 22:30:51 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JLUpvP029761 for ietf-provreg-outgoing; Tue, 19 Feb 2002 22:30:51 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JLUoOh029756 for ; Tue, 19 Feb 2002 22:30:50 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1K0Ts166940; Tue, 19 Feb 2002 16:29:54 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202200029.g1K0Ts166940@nic-naa.net> To: "Liu, Hong" cc: "'Eric Brunner-Williams in Portland Maine'" , Edward Lewis , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Call for agenda items for Minneapolis In-Reply-To: Your message of "Tue, 19 Feb 2002 12:06:34 CST." <23309E398D84D5119D0F00306E07513901181AA6@dc02.npac.com> Date: Tue, 19 Feb 2002 16:29:54 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > Nice to see you jump in on this. You are right, it IS an informational I-D > as an individual submission to the WG. What do you think? Registries have policies. Policies can be generalized until one or more mechanism(s) are identified that allow a class or classes of policies. We could see informationals from every registry, each full of specific utility and gratifying some specific external audience -- Karen Rose in the case at hand -- but not intended for implementors of interoperable services. An I-D could be useful, contain the grain of an idea that is generally useful, and scoped policy is a generally useful idea. We are, as a group, still working on policies that span scopes, e.g., data collection and the multi-jurisdictional registration systems and the trans-jurisctional flow of registrations within a single registration system. Scope tied to a namespace is already in "our scope", so submission "to the WG" is either late or redundant. Turning to the specifics: What NeuStar proposed in addressing the nexus requirement was: registrars obtain (from registrants) certification that o the US DoC's nexus requirement is met, and o the manner in which the requirement is met There is no protocol requirement here. The provisioning of registrars by registrants, however done, and consisting of whatever data, is outside the scope of this registry provisioning protocol. As Scott has pointed out many times, there are issues that are adequately covered by contract, and need not have any articulation within a protocol. This is just such a case. In addition, NeuStar proposed to check selected data provided by the candidate registrant, e.g., valid US ZIP code. There is no _new_ protocol requirement in this statement either. Finally, NeuStar proposed to check the information provided for the primary and secondary nameservers identified by the (registrant|registrar). There is no _new_ protocol requirement in this statement either. As to a "Purpose" requirement, this appears to be outside of the scope of SB1335-01-Q-0740, and therefore, an _operator_ specific feature. As it happens, there are at least two efforts to provide label semantics for UR*s, the W3C PICS effort, and the W3C P3P effort. As it happens, I've worked on both. It is possible that a scoped vocabulary (like PICS attempted in a historic US policy context, or P3P has established w.r.t. privacy in a synthetic three-theories (EU/OEDC/US) context) could be a generally useful extension to a registry provisioning protocol, and of interest to implementors of interoperable systems. I missed something however in this draft. I would have said the same thing six weeks ago. As a personal comment, the idea of using the IETF to publish a national code concerning the classes of persons authorized to use the Internet is not one that comes naturally to me. Section 3.2 More minutia Section 7. Internationalization considerations are about characters and text. Just being "in" one nation state doesn't automatically remove the problem of i18n considerations. Use: These parameters do not introduce any additional international considerations other than those specified for EPP contact object mapping [5]. Section 8. Registry (implementor) private parameters can't require IANA action. Use: "None." Section 9. See 7 above. s/i18n/sec/ Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JHhhOh028880 for ; Tue, 19 Feb 2002 18:43:43 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JHhh1J028879 for ietf-provreg-outgoing; Tue, 19 Feb 2002 18:43:43 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JHhfOh028874 for ; Tue, 19 Feb 2002 18:43:42 +0100 (MET) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA26194 for ; Tue, 19 Feb 2002 12:43:41 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJQMB1>; Tue, 19 Feb 2002 12:42:34 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6CB@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: Call for agenda items for Minneapolis Date: Tue, 19 Feb 2002 12:42:57 -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: Tuesday, February 19, 2002 3:18 PM > To: Edward Lewis > Cc: ietf-provreg@cafax.se; brunner@nic-naa.net > Subject: Re: Call for agenda items for Minneapolis > > > From the abstract: > > > These two new parameters only apply to ... name registry> > > and from the statement of intent: > > > ... specify ... extensions ... required ... interconnect > ... registry > > The authors have created a registry-private extension, as other registries > have for trademark data, and no doubt will continue to experiment with as > the registry experience matures. Such things are properly in operational > registry practices documents, or informational I-Ds, not requiring working > group change control and process. I have to agree with Eric. I'd prefer that we spend meeting time on topics of concern to the WG as a whole. FWIW I _do_ have some pro bono commentary for the authors if they wish to discuss the mechanics of the extensions in an offline exchange. Hint: how does a client learn of the existence of this extension, and how does the client inform the server of intent to use the extension? -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JHIcOh028639 for ; Tue, 19 Feb 2002 18:18:38 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JHIcSc028638 for ietf-provreg-outgoing; Tue, 19 Feb 2002 18:18:38 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JHIaOh028633 for ; Tue, 19 Feb 2002 18:18:37 +0100 (MET) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1JKHj166305; Tue, 19 Feb 2002 12:17:45 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202192017.g1JKHj166305@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Edward Lewis cc: ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Call for agenda items for Minneapolis In-Reply-To: Message from Edward Lewis of "Tue, 19 Feb 2002 09:51:38 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Feb 2002 12:17:45 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk >From the abstract: > These two new parameters only apply to ... and from the statement of intent: > ... specify ... extensions ... required ... interconnect ... registry The authors have created a registry-private extension, as other registries have for trademark data, and no doubt will continue to experiment with as the registry experience matures. Such things are properly in operational registry practices documents, or informational I-Ds, not requiring working group change control and process. I would have said the same thing six weeks ago. Eric Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JEqjOh027802 for ; Tue, 19 Feb 2002 15:52:45 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JEqjHS027801 for ietf-provreg-outgoing; Tue, 19 Feb 2002 15:52:45 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JEqhOh027796 for ; Tue, 19 Feb 2002 15:52:44 +0100 (MET) Received: by sentry.gw.tislabs.com; id JAA26742; Tue, 19 Feb 2002 09:58:11 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma026734; Tue, 19 Feb 02 09:57:48 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Feb 2002 09:51:38 -0500 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Call for agenda items for Minneapolis Cc: lewis@tislabs.com Sender: owner-ietf-provreg@cafax.se Precedence: bulk It's still a month away, but it seems like we do have a two-hour slot reserved for Wednesday (Mar 20). (Apply the caveat that the time/date is tentative when considering travel plans.) In the mean time, your co-chairs will be spanning the globe, so we need to leave enough lead time to generate the agenda. So - topics? PS - I've heard a few, including a request to discuss this individual submission: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : New EPP Parameters for the usTLD > Author(s) : H. Liu et al. > Filename : draft-liu-epp-ustld-00.txt > Pages : 11 > Date : 18-Feb-02 > >This document defines two new EPP parameters to enable the exchange >of additional information between the registry and the registrars for >the United States ccTLD (usTLD). These two new parameters only apply >to contact objects served as registrants for usTLD domains. This is >accomplished according to the EPP extension framework in the command- >response field. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JEkBOh027780 for ; Tue, 19 Feb 2002 15:46:11 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1JEkBgd027779 for ietf-provreg-outgoing; Tue, 19 Feb 2002 15:46:11 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1JEk9Oh027774 for ; Tue, 19 Feb 2002 15:46:10 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA14823; Tue, 19 Feb 2002 09:46:05 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YHR36X>; Tue, 19 Feb 2002 09:46:51 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6C3@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Roger Castillo Cortazar'" , ietf-provreg@cafax.se Subject: RE: Object associations. Date: Tue, 19 Feb 2002 09:45: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 Roger, The general topic of a query mechanism to do reverse-association lookups has indeed been covered in the past. I'd provide a pointer to archived messages but I didn't see anything obvious with a quick glance. I've argued that broad query mechanisms are out of place in a provisioning protocol. The kind of query that you've described below, when used (for example) to return all of the delegations to a name server or all of the domains associated with a contact, can literally return millions of records. There are other ways to provide this info, such as via offline reporting services, without adding search and lookup facilities to a provisioning protocol. More below... -Scott- > -----Original Message----- > From: Roger Castillo Cortazar [mailto:castillo@nic.mx] > Sent: Monday, February 18, 2002 7:39 PM > To: ietf-provreg@cafax.se > Subject: Object associations. > > > I don't know if this has been issued before, but I checked in > the cafax history > and I couldn't find anything about it. > > In the reqs. document > http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-re > qs-05.txt > we can read as folows: > > 3.4.9 Object Information Query > > [4] The protocol MUST provide services to identify all associated > object references, such as name servers associated with domains > (including delegations and hierarchical relationships) and contacts > associated with domains. This information MUST be visible if the > object associations have an impact on the success or failure of > protocol operations. > > Now, as we can read in the host mappings. > http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt > we can find this: > > 2.3 Status Values > > linked > > The host object has at least one active association with another > object, such as a domain object. Servers SHOULD provide > services to > determine existing object associations. > > 3.2.2 EPP Command > > A host name object MUST NOT be deleted if the host object is > associated with any other object. For example, if the > host object is > associated with a domain object, the host object MUST NOT > be deleted > until the existing association has been broken. > > > .............................. > > The service for identifying all associated object references > is a MUST in > the protocol reqs. > > There isn't any problem with the domain object as pointed in > 3.4.9 [4]. > The information about object associations for a domain object > MUST be given > to authorized clients, > and that's how it's described in the domain object mappings. > > This service is NOT described in the host mappings. > How can a client query the registry to look for all the > object associations > for one of his sponsored host objects ? > Looks like the protocol spec is not fulfilling the > requirements for this > service. As you noted, one can determine the contact and host objects associated with a domain object by doing an command on the domain. One can also find out that a contact or host object is linked to a domain object (but they can't get a list of specific domain object(s)) by doing an command on the contact or host object. I wrote the requirement and interpret it to mean that the protocol MUST provide information describing attribute associations, as in "this is an object and these are the attributes of that object". The "linked" status flag in the host and contact mappings lets the client know that an association exists (which in my interpretation meets the requirement as it identifies a reference) without introducing the possibility of having to return a potentially very large result set. As described above, this sort of reverse-lookup service is best provided by som3ething other than a provisioning protocol. > Now, let's assume we offer the service to the clients. > The number of associations for a host object could be a few > hundreds, and > in some cases a few hundreds of thousands. In at least one name space I'm familiar with the number would be much higher in some common cases. Some registrars offer hosting services where their servers and contacts are used for EVERY domain they register. > Has anyone given a little tough about this ? Maybe those who > are working on > implementations. > How can we interpret and apply this considerations of de reqs. to the > object mappings for hosts ? > > Perhaps we can add an child element to the > server response to > the command > to show the number of active associations for the host object. > > > The same considerations can be made for the contact objetc and its > associations with domain objetcts. > > In the contact object mappings, we can read in 3.2.2 EPP > Command, > that a server SHOULD notify > clients of object relationships when a command is > attempted and > fails due to existing object relationships. > > How can a client verify that the contact object he wants to delete no > longer has any active relationship ? Yep, it's been thought about, it's in the archives somewhere. One possibility: when a command fails due to an existing association, the client should receive an error message explaining that the delete fails because of an existing association. A service message should also be created and enqueued as described in the specs. It's quite possible for the server to create a service message that lists the active associations rather than including them in every response. In many cases the number of associations might be small enough to "fit" in the message, and where size becomes an issue the service message could point the client to an offline reporting service where the associations can be determined. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1J0dgOh024715 for ; Tue, 19 Feb 2002 01:39:42 +0100 (MET) Received: by nic.cafax.se (8.12.2/8.12.2/Submit) id g1J0dgnC024714 for ietf-provreg-outgoing; Tue, 19 Feb 2002 01:39:42 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.nic.mx (mail.nic.mx [200.23.1.17]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1J0ddOh024709 for ; Tue, 19 Feb 2002 01:39:40 +0100 (MET) Received: from rcastillo.nic.mx (rcastillo.nic.com.mx [200.33.1.31]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g1J0d7X20172 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 18 Feb 2002 18:39:08 -0600 (CST) Message-Id: <5.1.0.14.0.20020218183218.00befea0@mail.nic.mx> X-Sender: castillo@mail.nic.mx X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Feb 2002 18:38:38 -0600 To: ietf-provreg@cafax.se From: Roger Castillo Cortazar Subject: Object associations. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk I don't know if this has been issued before, but I checked in the cafax history and I couldn't find anything about it. In the reqs. document http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-05.txt we can read as folows: 3.4.9 Object Information Query [4] The protocol MUST provide services to identify all associated object references, such as name servers associated with domains (including delegations and hierarchical relationships) and contacts associated with domains. This information MUST be visible if the object associations have an impact on the success or failure of protocol operations. Now, as we can read in the host mappings. http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt we can find this: 2.3 Status Values linked The host object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations. 3.2.2 EPP Command A host name object MUST NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object MUST NOT be deleted until the existing association has been broken. .............................. The service for identifying all associated object references is a MUST in the protocol reqs. There isn't any problem with the domain object as pointed in 3.4.9 [4]. The information about object associations for a domain object MUST be given to authorized clients, and that's how it's described in the domain object mappings. This service is NOT described in the host mappings. How can a client query the registry to look for all the object associations for one of his sponsored host objects ? Looks like the protocol spec is not fulfilling the requirements for this service. Now, let's assume we offer the service to the clients. The number of associations for a host object could be a few hundreds, and in some cases a few hundreds of thousands. Has anyone given a little tough about this ? Maybe those who are working on implementations. How can we interpret and apply this considerations of de reqs. to the object mappings for hosts ? Perhaps we can add an child element to the server response to the command to show the number of active associations for the host object. The same considerations can be made for the contact objetc and its associations with domain objetcts. In the contact object mappings, we can read in 3.2.2 EPP Command, that a server SHOULD notify clients of object relationships when a command is attempted and fails due to existing object relationships. How can a client verify that the contact object he wants to delete no longer has any active relationship ? .................................................. Greetings. Roger Castillo Cortazar NIC-Mexico http://www.nic.mx